V-model is the basis of structured testing
 |
| V-model is the basis of structured testing |
- The left side shows the classic software life cycle & the Right side shows the verification and validation for Each Phase
Analyze User requirements
End users express their wish for a solution for one or more problems they have. In testing, you have to start preparing for your user tests at this moment!
You should do test preparation sessions with your acceptance testers. Ask them what causes they want to test. It might help you to find good test cases if you interview end-users about the everyday cases they work on. Ask them for difficulties they meet in every day’s 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 on 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!
Let’s discuss the Left side of the 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 reviews to it.
The right side shows the different testing levels :
– Component & Component integration testing
These are the test’s development performs to make sure that all the issues of the technical and functional analysis are 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
At this testing level, we are going to check whether the features to test, estimated from the analysis documents, are realized 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 webshop, you probably will have to test whether the integrated Online payment services work.
These interface tests are usually not easy to realize, 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 of 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 the 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 application’s shortcomings for the next couple of years. They are your customer!