<img alt="" src="https://secure.wauk1care.com/164394.png" style="display:none;">

Static Analysis Tools: True or False

Posted by Tony Simms on 26/07/2022

Not everything that you believe is true. You'll be surprised about the things that you think you know and that you think are true but are, in fact...false.

2022 Posts Images (1)-1

1: Tins of baked beans

I bet you think that tins of baked beans contain baked beans. To be honest, I wouldn't blame you if you did.  I mean, it's there on the label. There are rules about what you can and can't put on the food labels. However, the truth is that tins of baked beans don't contain baked beans. The beans in cans of baked beans have been stewed, not baked. (Source.)

2: Napoleon Bonaparte

Do you believe that Napoleon Bonaparte was short? I'm sure you've heard people described as having a Napoleon complex, having to overcompensate for their short stature. Why would they call it that if Napoleon wasn't vertically challenged? But the truth is that Napoleon Bonaparte was 5 foot 6, the average for those days. The idea that he was short or petite was a piece of British propaganda. (Source)

3: Viking Helmets

If I asked you to draw a Viking helmet, tell me honestly...would you draw horns on it? Every school child knows that Viking helmets have horns on, as they have seen drawings of it in their history books, so it must be true. The sad fact is that Viking helmets do not have horns. None of those recovered from archaeological sites has ever had a fitment for horns! (Source.)

4: Testing Code

Do you agree that you can only test code once the coding is finished? It makes sense if the coding is still in flight, what is there to test? However, the reality is that testing can and should start earlier than at the end of coding.

You can argue the point as to whether requirement, user story review or writing code, independent test cases are still testing. Putting that aside for a moment, one type of testing, static analysis,  which is often neglected, can add huge value and help avoid costly mistakes. 

Static Analysis

Whilst a peer review based approach to static analysis can be adopted, there are powerful static analysis tools that can save a vast amount of time when scanning large quantities of code. These tools allow developers to test their code, often as it's being written, but without the need to run the code.

In effect, the tool scans the code being developed and tests it against a set of predefined criteria, for example you can scan for violations against:

  • Your coding standards
  • OWASP & other known security vulnerabilities
  • Programming errors
  • Undefined values
  • Syntax violations

This ensures that errors are picked up and fixed long before they become a “bug”. I am sure that you are aware, the earlier a defect is found and fixed, the cheaper that fix is. The tool’s algorithms create a level playing field for code analysis and by that, I mean the tests are vigorously and consistently applied, so that things are not missed due to inexperienced reviewers or insufficient review time.

The tools also create comprehensive feedback on the results, allowing the developer to immediately fix their code. For large complex code bases, some tools allow for “what if” analysis to decide how much time and how many developers should be assigned to fix which defects. However, static analysis is not a ‘silver bullet’ that negates the need for dynamic testing, it has its pros and cons...

The pros of using static analysis include:

  • Effective analysis of the code resulting in better code quality.
  • Vastly quicker review and feedback on code quality compared with undertaking a manual review.
  • More depth and breadth of test coverage if part of the overall test activity.
  • A more uniformed set of tests and test results that are less prone to human error.
  • A better chance of finding vulnerabilities in the code, increasing web or application security.
  • It can be done in an offline development environment.

The cons of using static analysis include:

  • With the use of tools, false positives can be reported.
  • May not be able to follow every coding rule or standard, for example rules that need external documentation to be verified.
  • Static analysis can't detect how a function will execute (due to the STATIC nature of the analysis).
  • System and third-party libraries may not be able to be analysed.

Another challenge with using a static analysis tool is the fact that there are so many of them available.

nFocus are able to help you understand the static analysis tool landscape and advise how your organisation are able to determine the right tool for them. We help you understand and articulate:

  • The specific pain points you want to address
  • What you are already doing to address those issues
  • How static analysis will help

We can also help with the process of tools selection including the technical considerations you need to consider as well as vendor suitability.

nFocus SDET Academy

Topics: Software Testing, Testing Techniques, Static Analysis

nFocus Blog

Welcome to the nFocus software testing blog. As thought leaders and technical innovators, we created this blog to distil our thoughts, ideas and musings on improving software quality.

Fill out the form below to receive future communications from nFocus including our latest:

  • Blog articles
  • White Papers
  • and plenty more!

Follow us

Follow us on LinkedIn to see our latest content!

Subscribe Here!

Recent Posts

Posts by Topic

see all

Posts by Topic

see all