Test strategy
What is it?
Before you start implementing the system you must decide on how to test it. Using your design you need to consider what tests must be run to ensure that the program can be deemed working. It will normally take the form of a table.
Testing layout
All of your tests must be in the following table. You will have one for every form in your system.
Test num |
Description of test |
Test data |
Expected outcome |
Actual outcome |
1 |
Ensure that login works for a standard user |
Username – Bob |
Will take the user to main form (form 1) |
|
- Test num – Each test is numbered so it can be easily referenced
- Description of test – You say exactly what you are testing and what you are testing for.
- Test data – What must be entered onto the form for this test
- Expected outcome – What should happen
- Actual outcome – left blank for now!
Each form must have its own table like this. To make life easier for you it is best to lay this out in sections. Each form will have its own section and you will include -
- Copy the input form design image
- The testing table
The input form is not needed but it should make things a bit easier.
What should be tested
You need to test the following –
- Main functionality (for example adding a user, calculating correct totals etc)
- Validation rules
- GUI items act correctly
- Extreme test cases
- Abnormal test cases
You will end up with a lot of tests! This is a good thing! There are a lot of marks over the project for testing so although there are only 5 marks here, later on there are many more marks to be had!
Mark boundaries
5 marks |
A detailed test strategy and plan covering all aspects of the system with data to test under normal, extreme and abnormal circumstances. |
3–4 marks |
A detailed test strategy and a plan covering several aspects of the system but with inadequate data to effectively test the system, eg data covers only normal circumstances or covers only a limited part of the design specification. |
1–2 marks |
A vague discussion of how the system might be tested. |
High mark boundary
- All functionality from the requirements specification is tested at least once.
- Each validation rule is tested at least once.
- Each form has extreme and abnormal tests on the MAIN fields only
Middle mark boundary
- All functionality from the requirements specification is tested but there may be some of the smaller functions un-tested
- Most validation rules are tested.
- Some extreme or abnormal testing.
Low mark boundary
- Some testing used on most of the forms.
- Testing will be brief or limited.
Top tips
- Spending time on this section will save time later on!
- Testing carries marks in this section, development and evaluation. It is critical it is done in detail.
- Use separate tables for each form. This makes managing the test much easier!
- Be specific about test data. This makes test repeatable which is very important when tracking down bugs. Random testing is hard to repeat!