System test cases are prepared and assigned to the vendors responsible consultant. The vendor builds the solution according to the use cases. You have probably read the article about System test preparations.
Vendor checks the test cases
After the test cases of one use case are ready, assign the cases to the vendor’s consultant. The vendor checks the test cases and adds the necessary technical information.
This is very important because errors in specifications are the most expensive errors. The price of errors is even more expensive, the later they are found. In this way, errors are found in the building phase already. This will give the system and approval testing better quality.
The vendor can also use these test cases as documentation for their own unit testing.
Testers need to be familiarized with how the built solution works. This is a requirement for effective testing. One solution to this is that the supplier adds technical information to test cases and that’s usually enough. There is also a need for knowledge transfer from consultants to testers. This can be accomplished by arranging common test sessions at the start of each build package.
Release the case for testing
After one case is ready for testing, the vendor assigns the related test case to a test manager and changes the status to “Ready for testing”. This way we get real-time reporting about building readiness.
This is also important. Traditionally, up to 40% of the errors come from uncompleted implementation. According to the Projcettop Process, you avoid these errors completely.
Building readiness reporting
You can report real-time building and system testing on the project dashboard. Here is an example picture of Count by type and status -widget.
What is the right order to test
By testing in the correct order, you will find critical errors earlier. This will leave more time for their repair. This is done by first testing the most critical test cases of every released use cases and then moving on to less critical cases.
If you test all the test cases at the same time, you come across two issues.
- You will find critical errors in the last use cases only at the end of the test. The editor will have less time to repair them.
- Process changes that take place at the end of the testing phase generate the need for re-testing.
How to know what to test?
The idea is that every tester finds his own activities in the My activities -view. By default, the view will show activities that are assigned to a person.
The easiest way to assign test cases to the right tester is using the Mass Change functionally. The tester gets an email notification about assigned cases.
The tester opens test cases from My activities -view. The test case will be visible on the header page and the tester will see what the case is. By clicking start testing, test steps are opened.
The tester tests the follow up test steps. He sets the status OK or Not OK, depending on the test result.
If all test steps are tested OK, the tester ends the testing by clicking Stop testing. The tester changes the status to Tested OK.
Next tester continues testing
If the next tester should continue testing, the status will be changed to To next testerand Assigned to the person is changed to next tester.
If test stops because defect found
By clicking the red X, the tester can report the defect. Projecttop opens a wizard where the tester can describe the defect. After the defect is created, the person it is assigned to gets an email notification.
The defect process is described in Defect management -article
Test status of use case
During test preparation, test cases are linked to the use case. This enables monitoring of use case testing status in real-time.
After all the planned tests in the case have been approved and defects closed, you can change the status to Tested OK. You can monitor the status of use cases from the Dependencies -view. If you need to send a detailed report about testing, you can export the view.