Quality Testing

Quality is delighting customers

Hello ALL, 

we have been doing manual testing and now planning for test automation. 

1.Test case have been identify

2. tool is defined.

now i want to know if there any test plan which I can present to my team jst for automation

Views: 4641

Reply to This

Replies to This Discussion

Lightweight Automation Test Plan Template

Abstract

This post has been written in order to explain the lightweight template for functional tests document that is the base for the automation process. Test architects can use this template to better integrate with automation experts.

This template is not focused on generic test plan issues (like the document versions) on automation specific issues.

Principles and terms

  1. Definition of the SUT (System Under Test). The components that are part of the system under test including the unique elements of the testing environment.
  2. Separate test and test configuration (Fixture). Usually tests have 3 parts:
    1. Configure the SUT to specific state (Fixture).
    2. Create stimulation. Some type of action that changes the idle flow.
    3. Analyze the system behavior.
  3. In state-full environment the first part contains most of the test logic. Separating it from the test itself is a huge advantage. It enables sharing of fixture between tests. It makes the test focused and simple. It shortens the execution time and it can support test failure recovery models.
  4. Object, Action, Parameters.

    Most of the tests plan templates contain table structure in order to describe the test flow. The table usually includes columns like: step index, step name, step description and expected results. The described structure is usually too open to be a good base for test automation.

  5. Matrix. The degrees of freedom that can be used in the test execution.
  6. Parameters. Test/Step parameters.

 

Template

Test name:

[The name of the test]

Purpose:

[The purpose of the test in a few sentences]

Discussion:

[A paragraph describe the issue in stake]

Setup:

[Description of the setup to be used. The station that should be used and there description. Usually a setup will be common to a group of tests. So a link to deferent document that describes the setup can be used]

Fixture:

[Description of the Fixture that is the base for this test. The process of building the Fixture as well as the process of tearing it down. Usually a fixture will be common to a group of tests. So a link to different documents that describe the Fixture can be used]

Recovery:

[Description of the recovery mechanism in the case of test failure. For example: if the test fails then run it again and only if the second test fail consider this test as failure. If it fails to tear down the fixture to it root ...]

Matrix:

[The degrees of freedom the test can be executed. For example: this test should be executed both using Internet Explorer and Firefox other option can be Chrome ...]

General Parameters:

[Parameters that should be exposed to the user (the person that will execute the test)].

Steps:

ID Object Action(method) Parameters
1 server.web addUser userName = 'Guy'
2 server.web addUser userName = 'Michael'
3 server.web showUsersCheckExist userName = 'Guy'
4 server.db checkExistInUserDb userName = 'Guy'
5 server.web removeUser userName = 'Michael'
6 server.db checkNotExistInUserDb userName = 'Michael'

 

Guy Arieli

AQUA Software

http://itknowledgeexchange.techtarget.com/qa-processes/developing-e...

Aug 29 2008   3:23AM GMT

Developing Effective Test Plans for Automation



Posted by: Greg Annen
Software Quality

An application test plan should contain a minimum set of optimized test cases with maximum test coverage of all critical application functions. It should be executed using a tool that easily adapts to changing data and requirements.

In order to create an effective automation test, it is first necessary to review the application test plan provided by the application owner to evaluate its suitability for automation. You don’t want to automate a “BAD” test case. Consider the exact intent of the test plan and determine if you can create an effective test case (same coverage) more simply with more reliable automation. It is not acceptable to simply write all the automation scripts directly from the manual test plans. This has the same inherent limitation as doing record/replay for every script: the test is unreliable.

Design test cases and test scripts to be modular. Instead of using one script to perform multiple functions, break the script into separate functions.

Design test cases and test scripts to be generic in terms of process and repeatable in terms of data. Read test data from a separate source: keep the scripts free of test data so that when you do have to change the process or the data, you only have to maintain one item in one place.

Consider the goal of the test

Don’t just blindly follow a manual test plan. See if there is a simple way to accomplish the objective stated in the test plan.
Focus on modularity and reusability. Create a set of evaluation criteria for functions to be considered when using the automated test tool. These criteria may include:

  • Repeatability of tests
  • Criticality/Risk of applications
  • Simplicity of operation
  • Ease of automation
  • Level of documentation of the function (requirements, specifications, etc.)

Targeting Test Plans for Automation

A test plan representing a good candidate for automation would have the following characteristics:

  • Contains a repeatable sequence of actions
  • The sequence of actions is repeated many times
  • It is technically feasible to automate the sequence of actions (tool is capable, no external hardware actions)
  • The behavior of the application under test is the same with automation as without
  • Testing involves non-UI aspects of the application (almost all non-UI functions can and should be executed using automated tests)
  • The same tests must be run on multiple hardware configurations
  • The same tests must be run with varied combinations of other applications to verify compatibility (i.e., Interoperability Testing)
thanks a lot

RSS

TTWT Magazine


Advertisement

Advertisement

Advertisement

Advertisement

© 2021   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service