By understanding the system under test the test analyst can proceed with their primary task which is to create, execute and document the results of running a repeatable set of documented tests.
If I’ve learned anything in the time I’ve spent testing and managing the testing of software systems it’s that this is actually the hardest part of the job.
It’s a rare treat to find requirements and their traceability adequately documented.
Not only does this make it difficult to gain the “understanding” so crucial to the task outlined in the opening paragraph but it compounds the problem by making the impact of change difficult to assess in a cost-effective way.
By documenting assumptions and building a collaborative relationship with your design and development teams based on experience I can help identify the key functional requirements for test. Having understood the key requirements, extra value can be added by thinking around the required behaviour to define a comprehensive set of negative tests to compliment the functional tests that can now be traced directly back to requirements.
Having a traceable set of tests allows me as a tester to contribute to the impact analysis activity when the need arises to help you assess a proposed functional change to your key business applications or to help you assess the risk and target resources when the project timescales are closing in and you are considering ending testing.
Naturally, all testware developed as part of the testing project remain with you upon completion of the testing project to provide a firm bedrock for future development and test maintenance.