see if the defects are fixed as per specs or not.
Adapting to the changes:
If demanded by client/development-vendor, clarifications should be given on defects reported earlier. Appropriate methodology should be devised to keep a log of all the communication done. Here I will once more emphasize the importance of format /tool used for reporting defects, and communication done.
Adapting to STPLC
After knowing the phases of STPLC, let us try to analyze these. It should be noted that phase 1, and 2 are one time activity at the start of any testing project. While, steps 3 through 5 are repetitive tasks, to be carried out on daily basis. More importantly, these steps are the most important from client's perspective. The client might be more interested in the number, and kind of defects a testing-vendor finds, or skips.
Phase 1 may not even consist of any deliverable to the client. Phase 2 does consist of deliverables to the client. But, as this phase does not consist of daily deliverables, the testers may have some time to work on their deliverables, and polish them well before they are delivered to the client. The test cases/ test scripts may be thoroughly reviewed for quality, and completeness before final delivery.
In contrast to phase 1, and 2, phases 3 through 5 are daily activities, and consist of daily deliverables. Daily delivery may not allow testers to conduct thorough reviews of their deliverables. This increases the importance of being first time right, every time. Your client sees your work through your deliverables. Majority of the deliverables in these phases will require good communication skills, apart from testing skills. Even if your work is very good, if your deliverables are not really professional and flawless, you might be in soup. Hence, the testers need to be very clear, and precise in communication.
One more important aspect is the processes set for phases 3 through 5, or the tool used while these phases. Before setting the processes, a thorough analysis should be carried out to understand the kind of reports, and analysis needed from the results of execution of these phases. And, the tools should be selected in such a way that generation of required reports, and analysis is possible, and easy. Testers will have to generate these reports on daily basis. So, reporting tools should be selected such that generation of these reports /analysis take minimum time, and testers can devote more time on productive work (testing).
To summarize, executing a testing project is not exactly the same as executing a testing phase of any other project. As testing projects are projects in themselves, they carry with them all overheads carried by any other kind of project.
We know that if one developer can do a work in 10 day, 2 developers cannot do the same work in 5 days. They will take some more time. Say 6 days. The reason is the overheads of increased team. As the team size increases, communication, training, and many other overheads increase.
Similarly, the overheads increase when testing is taken as a project. To minimize the effect of these overheads on project schedules, testers need to visualize the problem areas in advance, and devise appropriate methodologies. This calls for changes in various aspects.