Skip to main content

How do you create a test plan/design?

Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results.. Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.. Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. . It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.. Test scenarios are executed through the use of test procedures or scripts.. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.. Test procedures or scripts include the specific data that will be used for testing the process or transaction.. Test procedures or scripts may cover multiple test scenarios.. Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.. Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.. Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.. A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.

Inputs for this process:. Approved Test Strategy Document.. Test tools, or automated test tools, if applicable.. Previously developed scripts, if applicable.. Test documentation problems uncovered as a result of testing.. A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data.

Outputs for this process:. Approved documents of test scenarios, test cases, test conditions and test data.. Reports of software design issues, given to software developers for correction.

Comments

Post a Comment

Popular posts from this blog

What is Installation testing?

Installation testing is done to verify whether the hardware and software are installed and configured properly. This will ensure that all the system components were used during the testing process. This Installation testing will look out the testing for a high volume data, error messages as well as security testing
1 comment
Read more

What is Smoke Testing ?

Smoke testing is a relatively simple check to see whether the product "smokes" when it runs. Smoke testing is also sometimes known as ad hoc testing, i.e. testing without a formal test plan. With many projects, smoke testing is carried out in addition to formal testing. If smoke testing is carried out by a skilled tester, it can often find problems that are not caught during regular testing. Sometimes, if testing occurs very early or very late in the software development life cycle, this can be the only kind of testing that can be performed. Smoke testing, by definition, is not exhaustive, but, over time, you can increase your coverage of smoke testing. A common practice at Microsoft, and some other software companies, is the daily build and smoke test process. This means, every file is compiled, linked, and combined into an executable file every single day, and then the software is smoke tested. Smoke testing minimizes integration risk, reduces the risk of low quality, suppo...
Post a Comment
Read more

Software Testing - Boundary-value analysis

Boundary-value analysis is a variant and refinement of equivalence partitioning, with two major differences: First, rather than selecting any element in an equivalence class as being representative, elements are selected such that each edge of the EC is the subject of a test. Boundaries are always a good place to look for defects. Second, rather than focusing exclusively on input conditions, output conditions are also explored by defining output ECs. What can be output? What are the classes of output? What should I create as an input to force a useful set of classes that represent the outputs that ought to be produced? The guidelines for boundary-value analysis are: · If an input specifies a range of valid values, write test cases for the ends of the range and invalid-input test cases for conditions just beyond the ends. Example: If the input requires a real number in the range 0.0 to 90.0 degrees, then write test cases for 0.0, 90.0, -0.001, and 90.001. · If an input specifies a numb...
Post a Comment
Read more