Testing Phases – Static Analysis

I once met a project manager who really didn’t enjoy the testing phase of a project. He was one of those time driven managers where milestones and targets were the most important factor in a project. His badge of honor was to deliver his projects on time and was immensely proud of this. Unfortunately by it’s very nature the testing phase can be slow, indeed if it’s successful and finds errors and issues then it can severely impact timelines. However it’s important to remember that the goal is to release a successful product, there’s little point releasing a faulty product on time. This manager forced through a huge disaster of a software release that ended up crippling a large organisations retail arm for about 24 hours. The reason, the testing schedule wasn’t completed properly and faulty code released into the production environment.

Just like assessments, static analysis looks out for defects without executing the code. Having said that, as opposed to reviews static analysis is completed once the code has been written. Its goal is to find defects in software source code and computer software models. Source code is any series of statements written in some human-readable computer programming language which can then be converted to equivalent computer executable code.

This is actually normally generated by the developer. A software model is an image of the final approach developed utilizing techniques such as Unified Modeling Language (UML); it is normally generated by a software designer. Static analysis can find flaws that are difficult to find during test execution by analysing the program code e.g. instructions to the computer system can be in the form of control flow graphs (how control passes involving modules) and data flows (assuring data is identified and correctly used). The value of static analysis is:

Initial detection of issues prior to test execution. Just like reviews, the sooner the issue is located, the cheaper and simpler it is to fix.  For instance if you’re releasing a software product such as a VPN program in time for a Christmas release, it’s tempting to rush to gain extra sales.  However if the product doesn’t work or is unreliable, perhaps it doesn’t work with someone trying to watch UK TV from France or with a certain browser, then you’re going to lose sales.  Indeed in the long run, even re-releasing a product won’t help as the damage to it’s  could have already been done.

Early warning about questionable aspects of the code or design, by the calculation of metrics, such as a high-complexity measure. If code is too complex it can be a lot more prone to error or less dependent on the focus given to the code by developers. In the event that they understand that the code has to be complicated then they are more likely to check and double check that it is correct; however, if it is unexpectedly complex there is a greater chance that there will be a defect in it.

Identification of flaws not quickly discovered by dynamic testing, such as development standard non compliance as well as identifying dependencies and inconsistencies in software models, such as links or interfaces that were either incorrect or unknown before static analysis was carried out.

Enhanced maintainability of code and design. By executing static analysis, issues will be eliminated that would certainly typically have increased the amount of maintenance needed after ‘go live’. It can also recognize complicated code which if fixed will make the code more easy to understand as well as therefore easier to manage.

Elimination of defects. By identifying the defect very early in the life cycle it is actually a great deal easier to identify why it existed in the first place (root cause analysis) than during test execution, thus providing information on possible process improvement that might be made to prevent the same defect appearing again.

Further Reading, Residential IPs and Security

Leave a Reply