The test cases are written by the quality assurance analyst in exacting detail from the business requirements documents, functional specifications, design documents, and technical specification documents. They are organized based on the use cases. The test cases will ensure that each of the use case conditions is met by the system. These detailed test cases are written in a standardized way to ensure the tester can execute the test and know the expected results to validate whether the test passes or fails.
Each test case will have the following information:
- A unique number and a description of the test case
- The requirement, use case and module being tested
- Any data preparation required to run the test case
- Any test cases run prior to running the test case
- The name of the person running the test case and date run
- Each step contains the action/procedure being taken, expected results, and pass/fail
Different test cases will be written and used for unit, function, and system integration testing. The systems integration test cases can be used for User Acceptance Testing.
The users can use the use cases and test cases along with real data to test the system to make sure that system meets all of the agreed upon requirements and business needs. The test cases can be used later in the process as a springboard for developing a User’s Guide, training documents, and for future system enhancements.
Test cases should never be too long or too short. What we mean by that is, an individual test case should not test across modules or cover multiple parts of the system. If test cases are written in this manor then one change to any one part of the system could mean rewriting many, many test cases. With some system integration test cases, this must happen but should be limited. If your test cases are ‘modularized” then if a change is made to one part of the system then only the cases that cover that part of the application need to be rewritten. This holds true for manual test cases as well as automated test scripts.
The test plan will cover how the test cases will be developed and how they will be organized. Thought must be given prior to writing the test case so that they are usable by all those testing the application. Having similar test cases written by several QA Analyst is a waste of time and is not the best way to ensure complete system testing coverage.
You have written your test cases and you are now ready for the development team to release the first build. What might help with this are release notes. More on this next time.
-----------------------------------------------
Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com
Posts
