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
    effort
  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
    internals
  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.
  

 

 

SocialTwist Tell-a-Friend
This entry was posted in Business. Bookmark the permalink.

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

  1. Aw, this was an extremely nice post. Finding the time and actual effort to produce a very good
    article… but what can I say… I put things off a whole lot and never seem to get anything done.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Captcha Captcha Reload

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Life @ QA InfoTech

Follow us on

Categories

Archives

Service Offerings :