3. Set up
Clearly, lots of critical decisions need to be made and the meatier part of the process is coming up. However, before starting the actual testing, project leaders and teams need to ensure that several questions pertaining to set-up have been answered including:
- Do I have the required templates in place?
- What will I use for Bug reporting?
- Is the Change Control process in place?
- Are the communication protocols in place?
- Do I have the right test environment/test data set up?
Answers to these questions become exceedingly important if there is (or will be) an offsite or offshore component to a testing team. Lots of managers breeze over this stage, then realize their mistake later when things start to fall apart. So before moving on, managers need to make sure that they have decided and locked in on the test plan template and the bug reporting that works for the project.
Most industry-standard tools provide the flexibility to customize down to the last field. For those who want to go the cheaper route, there is always Microsoft Excel. Another important component is the Reporting templates, which often have two separate versions, depending on the size of the project:
- The full-blown/detailed version which can be circulated to the entire Project team.
- The high -evel summary report which is probably created less frequently and has a specific target audience including Senior Management.
Furthermore, each tester should know exactly whom to reach out to for specific bugs/questions. Project managers and developers should be aware of the testing being carried out. While this might be straightforward, this often becomes a challenge.
One important criterion for success is having the right change control system implemented. Without a proper change control system, a testing team could spend weeks fixing bugs and one last (untested) code change could take it all away and make the project look like a failure.
How does a testing team prevent this? By ensuring each and every "significant" code push in to the Test environment must, at the least, have:
- Approval from the Development Manager and Release Manager.
- A QA tester's name associated with it.
- A list of dependencies--direct and indirect--associated with the change that should be tested.
- A level of Risk and a Priority.
Lastly, the Test Lead should ensure that an appropriate test environment (which mimics the current or proposed production environment as closely as possible) should be provided to the testers. This should also include production like data (which is often obfuscated to protect confidential client information) in case of existing applications or appropriate "dummy" data that would exist in production after the software went live.
