A specialist tester will know the importance of static testing (Static Vs Dynamic testing explained in earlier chapters of this book) and how a great execution may lead to better dynamic testing and greater resilience for the end product.
The specialist tester will take this testing type and master it to perfection, and why mastering such testing method? The answer…because he knows that mastering Static testing is must, you cannot perform a great testing process when you failed to make such tests.
Just for example, think about testers who telling their manager that they cannot make tests without a working build, yes, in some cases this statement is true, but not in all cases, the specialist tester will understand very quickly that without a working build he cannot execute the “Dynamic” testing part and as a result he starts or continuing the second part of the process (Static testing). The end results are very simple, the first tester will sit on is a$% and continuing is complaining while the specialist tester will see such failure as a great opportunity to perform additional tests that relevant to the static part. In addition, although that “Static” testing performed at different points during the software testing life cycle, the specialist tester will know that best results will be achieved when using this method early as possible, the tasks you can accomplish without code execution is massive, few examples:
- Review the SRS and SDD documentation.
- Design the test strategy.
- Design test cases and review.
- Investigate the client environment (all info should be available from the PM or SE).
As you can see, all examples above are crucial for a successful testing cycle, the benefits are:
- Reduce spec bugs that have direct impact on the entire engineering process (Coding/testing).
- Allow the tester to see the project “Big” picture and as a result the timelines and testing scope will be determined in greater efficiency.
- Knowing the big picture is crucial when making a “Risk Analysis” for the current version.
- Based on documentation, the tester will know the integrated systems for his software, as a result the testing environment can be papered before the actual testing executions.
- Allowing the tester to be familiar with the complexity of the future testing process according to the expected developing results taken from the SRS design.