Sections of this topic
Once the application/product has been created and before it goes live, a detailed quality check will be conducted. To perform this check and to ensure that all functionality/features/ attributes/ facets of the product perform as intended, a Test Plan is created and used to perform a detailed check on the application/product. A test plan can be created for prototypes, system and data migrations, system designs etc, but what will be posted here is a sample test plan for a simple field within a product. No matter what type of test plan is created, the logic and organization of the test plan created will be similar to what is noted.
To clarify the definition, Test Plans are needed to help the Quality Assurance (QA) tester conduct a series of tests in order to validate an application via functionality, task oriented or even mathematical or data tests.
To present the Test Plan, use an outline format so that a task can be noted and insert sub-tasks to further define the test. This format seems to be the easiest to follow, as Test plans are usually extremely detailed. As a simple example, if a numerical field is to be tested within an entry form, list this as a task. Then below it, list sub-items that need to be checked.
For example:
- does the field accept the maximum length of numbers,
- If more than the maximum length of characters is input:
- does the field accept it,
- does an error message occur; if yes, note in bug list
- does it accept alpha or extraneous characters; if yes, note in bug list
- does it accept decimals.
- is the data saved when you go to the next screen and return (check previous screen as well)
- check the database
- is the data saved as entered.
All this may seem tedious, but those are the typse of scenarios that need to be tested. Every situation listed has to be tested step-by-step and verified. Every action that a user might perform has to be noted and checked. Along with verification, the test plan should also check to see if the application is logical or if the flow makes sense. The creator of the test plan needs to have placed them self in the mindset of the user and include different actions that a user might perform.
The beginning of the Test Plan, along with pertinent instructions, should include:
- System requirements denoting the platform under which the program would and/or would not work, who can access the program, and what results should be expected. This precedent should also be verified.
- A set of detailed systematic instructions as to how the application should work and what steps the tester can undertake to validate the authenticity of the program or to invalidate it. In other words, the tester needs to see if the program can be broken or fail or has faults in it; to invalidate it.
Test plans are lengthy, detailed, and have to be part of the team’s project plan. Test plans must consist of a series of test cases or scenarios which will aid in retracing steps whenever problems occur as well as for regression testing.
When problems are encountered, different resolutions should be tried and then listed. If no resolutions are listed, note them as irregularities or anomalies within a Bug List.
We will talk about a Bug List in the next post.
