The “When” and “Why” of Static Code Reviews by Software Testers

Back in the late 1990’s and early 2000’s software testers were primarily confined to black box testing, where they just test the system from an end user stand point. While that is very important, a whole piece of understanding system internals was being missed. This led to a lot of disconnect between the testers and the rest of the product team, missed defects, testing not being a respected profession given its superficial coverage and so on. Similar to how test code is peer reviewed within the test team, source code needs to be reviewed statically (in a non-execution mode) within the development team. However, it is equally important for the test team (at least a select set of test representatives) to review the source code for the following reasons:

  1. Understand the system from the design and implementation aspects to ensure comprehensive test coverage
  2. Help identify dead code paths (code paths that would never be reached) from an end user stand point; it is important to remove
    these from the source code to increase overall test traceability and make the code more lean and maintainable
  3. Provide recommendations for performance optimizations architecturally
  4. Look for security vulnerabilities at a source code level
  5. Look for storage optimizations especially around database implementations and caching techniques
  6. Perform root cause analysis of defects to a certain extent saving debugging and defect fixing time for the product team;
    this also improves the overall defect validity rates
  7. An independent review of the source code done by a team that was not involved in actual coding, which makes it an unbiased
  8. Besides the above mentioned tangible benefits, such reviews also improve the developer – tester relationship and goes a long way in establishing mutual respect for each other, when it is done in the best interest of both teams rather than seeing it as a fault finding exercise

While at a concept level there is agreement that there is value in having the test team take on static code reviews, they represent the user when it comes to the dynamic testing efforts, where they test the system in its execution mode. If these 2 tasks need to be prioritized the dynamic test efforts are their core responsibility while the static code reviews are add-on tasks which help them understand the system better and bring in more test coverage. So, if you were to see from a timing angle, the dynamic test efforts need to take precedence over the static code reviews. This is not just for prioritization of tasks, but also from the logical order of tasks that need to be done.
As advocates of the end user it is important for the test team to test the system first from a black box angle without a view into system internals at the code level; once they have visibility into the code level details, they may be biased / influenced by what to expect in the sequence of operations to follow, areas where defects potentially exist, which dilutes the whole point of black box testing. Following a brief round of black box efforts, the test  team should take on white box testing at a dynamic level (where the program is under execution) so they can get to the next level of details at the system level, testing for web services, databases, APIs etc. Black box testing is also simultaneously carried on by another group of testers to bring in overall E2E coverage. But when the flow proceeds to start with black box then white box dynamic followed with white box static testing, the tester is able to gradually progress in the level of system understanding but more importantly is able to:

  1. Provide true justice in testing the system as an end user advocate without being biased by the understanding of the system’s
  2. Not just review the source code but is able to diagnose the system for additional test coverage because the code coverage runs
    from the earlier test efforts would have given a view into modules that need more testing depth



If the test team can focus upfront on prioritizing its test efforts in a similar fashion, subject to the product they are testing and associated time and cost constraints and accommodate them in their testing strategy, it would not only maximize testing efficiency but also their productivity and more importantly help build a product of exceptional quality. This may sound overwhelming to implement initially, but after a couple of
milestones, the process will start to flow through seamlessly, the team would have started interacting much better and the overall benefits reaped from the product quality, team productivity and morale will make this an effort worthy of all the time and resources spent.

About the Author

QA InfoTech

QA InfoTech

Established in 2003, with less than five testing experts, QA InfoTech has grown leaps and bounds with three QA Centers of Excellence globally; two of which are located in the hub of IT activity in India, Noida, and the other, our affiliate QA InfoTech Inc Michigan USA. In 2010 and 2011, QA InfoTech has been ranked in the top 100 places to work for in India.

Related Posts