If you are a software tester, you don’t need to be ISEB or ISTQB certified to know how difficult it can be to identify the maximum number of software defects possible. This is true whether you are starting a new testing effort or joining an existing one. In fact, it can be even more difficult when you are thrown into an already up-and-running testing effort.

In both cases, it is obviously prudent to use all the tools available in your toolbox. Use best practices, take screen shots, and make good use of the technological tools available within your organization. But when you join an existing project, you’ll have to go the extra mile to truly add value to the process.

When joining an existing project, the first thing you should do is read the scope doc to find out what should and should not be tested. Then check the bug reports already logged by other testers. This will give you an indication as to what parts of the application have already been tested versus what has yet to be tested.

Armed with this information, you can now begin to focus on ways in which to identify scenarios that have not yet been tested. Go through the other bug reports again and try to reproduce each defect, and attempt to dive deeper to identify any offshoot defects.

As you go through this process, split the software application into logical functions, and then drill down in each part to uncover the deeper issues. This is helpful because it is likely that the “low hanging fruit” has already been identified, so you need to pull back the covers to reveal hidden bugs and subsequently add value.

Follow these tips and you are sure to add value to any software testing project, even those that you are thrown into at the 11th hour!