You will find out this is a great model!
End users express their whish for a solution for one or more problems they have. In testing you have to start preparation of your user tests at this moment!
You should do test preparation sessions with your acceptance testers. Ask them what cases they want to test. It might help you to find good test cases if you interview end users about the every day cases they work on. Ask them for difficulties they meet in every days work now.
Give feedback about the results of this preparation (hand the list of real life cases, the questions) to the analyst team. Or even better, invite the analyst team to the test preparation sessions. They will learn a lot!
System requirements
One or more analysts interview end users and other parties to find out what is really wanted. They
write down what they found out and usually this is reviewed by Development/Technical Team, end users and third parties.
In testing you can start now by breaking the analyses down into 'features to test'. One 'feature to test' can only have 2 answers: 'pass' or 'fail'. One analysis document will have a number of features to test. Later this will be extremely useful in your quality reporting!
Look for inconsistency and things you don't understand in the analysis documents. There’s a good chance that if you don't understand it, neither will the developers. Give Feedback your questions and remarks to the analyst team. This is a second review delivered by testing in order to find the bug as early as possible!
Lets discuss Left side of V Model:
- Global and detailed design
Development translates the analysis documents into technical design.
- Code / Build
Developers program the application and build the application.
- Note: In the classic waterfall software life cycle testing would be at the end of the life cycle. The V-model is a little different. We already added some testing review to it.
The right side shows the different testing levels :
- Component & Component integration testing
These are the tests development performs to make sure that all the issues of the technical and functional analysis is implemented properly.
- Component testing (unit testing)
Every time a developer finishes a part of the application he should test this to see if it works properly.
- Component integration testing
Once a set of application parts is finished, a member of the Development team should test to verify whether the different parts do what they have to do.
Once these tests pass successfully, system testing can start.
- System and System integration testing
In this testing level we are going to check whether the features to test, destilated from the analyses documents, are realised properly.
Best results will be achieved when these tests are performed by professional testers.
- System testing
In this testing level each part (use case, screen description) is tested apart.
- System integration testing
Different parts of the application now are tested together to examine the quality of the application. This is an important (but sometimes difficult) step.
Typical stuff to test: navigation between different screens, background processes started in one screen, giving a certain output (PDF, updating a database, consistency in GUI,...).
System integration testing also involves testing the interfacing with other systems. E.g. if you have a web shop, you probably will have to test whether the integrated Online payment services works.
These interface tests are usually not easy to realise, because you will have to make arrangements with parties outside the project group.
- Acceptance testing
Here real users (= the people who will have to work with it) validate whether this application is what they really wanted.
This comic explains why end users need to accept the application:
During the project a lot off interpretation has to be done. The analyst team has to translate the wishes of the customer into text. Development has to translate these to program code. Testers have to interpret the analysis to make features to test list.
Tell somebody a phrase. Make him tell this phrase to another person. And this person to another one... Do this 20 times. You'll be surprised how much the phrase has changed!
This is exactly the same phenomenon you see in software development!
Let the end users test the application with the real cases you listed up in the test preparation sessions. Ask them to use real life cases!
And - instead of getting angry - listen when they tell you that the application is not doing what it should do. They are the people who will suffer the applications shortcomings for the next couple of years. They are your customer!
 |
| V-model is the basis of structured testing |
- The left side shows the classic software life cycle & Right side shows the verification and validation for Each Phase
End users express their whish for a solution for one or more problems they have. In testing you have to start preparation of your user tests at this moment!
You should do test preparation sessions with your acceptance testers. Ask them what cases they want to test. It might help you to find good test cases if you interview end users about the every day cases they work on. Ask them for difficulties they meet in every days work now.
Give feedback about the results of this preparation (hand the list of real life cases, the questions) to the analyst team. Or even better, invite the analyst team to the test preparation sessions. They will learn a lot!
System requirements
One or more analysts interview end users and other parties to find out what is really wanted. They
write down what they found out and usually this is reviewed by Development/Technical Team, end users and third parties.
In testing you can start now by breaking the analyses down into 'features to test'. One 'feature to test' can only have 2 answers: 'pass' or 'fail'. One analysis document will have a number of features to test. Later this will be extremely useful in your quality reporting!
Look for inconsistency and things you don't understand in the analysis documents. There’s a good chance that if you don't understand it, neither will the developers. Give Feedback your questions and remarks to the analyst team. This is a second review delivered by testing in order to find the bug as early as possible!
Lets discuss Left side of V Model:
- Global and detailed design
Development translates the analysis documents into technical design.
- Code / Build
Developers program the application and build the application.
- Note: In the classic waterfall software life cycle testing would be at the end of the life cycle. The V-model is a little different. We already added some testing review to it.
The right side shows the different testing levels :
- Component & Component integration testing
These are the tests development performs to make sure that all the issues of the technical and functional analysis is implemented properly.
- Component testing (unit testing)
Every time a developer finishes a part of the application he should test this to see if it works properly.
- Component integration testing
Once a set of application parts is finished, a member of the Development team should test to verify whether the different parts do what they have to do.
Once these tests pass successfully, system testing can start.
- System and System integration testing
In this testing level we are going to check whether the features to test, destilated from the analyses documents, are realised properly.
Best results will be achieved when these tests are performed by professional testers.
- System testing
In this testing level each part (use case, screen description) is tested apart.
- System integration testing
Different parts of the application now are tested together to examine the quality of the application. This is an important (but sometimes difficult) step.
Typical stuff to test: navigation between different screens, background processes started in one screen, giving a certain output (PDF, updating a database, consistency in GUI,...).
System integration testing also involves testing the interfacing with other systems. E.g. if you have a web shop, you probably will have to test whether the integrated Online payment services works.
These interface tests are usually not easy to realise, because you will have to make arrangements with parties outside the project group.
- Acceptance testing
Here real users (= the people who will have to work with it) validate whether this application is what they really wanted.
This comic explains why end users need to accept the application:
 |
| This is what actually Client Needs :-( |
During the project a lot off interpretation has to be done. The analyst team has to translate the wishes of the customer into text. Development has to translate these to program code. Testers have to interpret the analysis to make features to test list.
Tell somebody a phrase. Make him tell this phrase to another person. And this person to another one... Do this 20 times. You'll be surprised how much the phrase has changed!
This is exactly the same phenomenon you see in software development!
Let the end users test the application with the real cases you listed up in the test preparation sessions. Ask them to use real life cases!
And - instead of getting angry - listen when they tell you that the application is not doing what it should do. They are the people who will suffer the applications shortcomings for the next couple of years. They are your customer!
No comments:
Post a Comment