Do you often find yourself realising a lot of important information is missing from your requirements half way through the development of a feature?
What if you could test that feature before writing any code? Software development teams will often jump into writing code too early as developers are eager to solve a challenge and businesses want a high velocity to ensure iterations are shipped sooner.
This in practice can cost time if the feature being built is complex and there’s very little in the way of shared understanding between the business and the development team.
By stepping away from the code and building up artefacts that assist with building this shared understanding, such as prototypes and documentation, development teams can identify a number of bugs and ensure the work they deliver are of a high quality.
This approach is called static analysis and can be applied to both requirements and code (we’ll save that for another post) in order to iron out a range of different bugs before the team even commit to working on a feature.
What is static analysis
The ISTQB defines static analysis as:
The process of evaluating a component or system without executing it, based on its form, structure, content, or documentation.
Essentially, static analysis and it’s sister term, static testing, involve testing things other than the running software.
How does static analysis help catch defects early
It might seem a little odd at first, but by starting the testing process at the requirements stage you can verify how that software will work and test the business rules that software looks to implement.
By carrying out exploratory testing around user flows and journeys before there’s any code written, you can catch any potential gaps in the requirements that might see users having issues and get a solution to the issue defined before the developers start coding, saving the team from any lengthy rework that will happen if caught further into the development process.
If the team is integrating with a third party service you can start documenting the requests and responses needed as part of the integration, allowing the team to gain a better understanding of the structure of the data which will then help inform the approach they take when building the interface logic.
In highly-regulated environments such as gambling, static analysis could even just be as simple as ensuring that all screen designs have the appropriate imagery needed in order to comply with the laws in the market the product will be released into.
Similarly, if you have designs you can carry out accessibility testing against to ensure that the colour contrast and text complies with WCAG guidance.
Each team and domain is different so there may be additional ways that building static analysis into the requirements stage can help catch potential defects early.
How to implement static analysis into your SDLC
Static analysis is a great tool but depending on the team and it’s priorities it can be hard to get everyone on-board to spend more time working on work items before the team start working on them.
If you’ve not already documented your Software Development Life Cycle (SDLC) or set up a Definition of Ready (DoR) for the work that your team does then doing this will allow you to build static analysis into the process the team follows when creating and working on features.
If you’ve already set up your Definition of Ready then you can use the data around the amount of rework the team does due to defects that static analysis could catch early and use your team’s continuous improvement process to push for static analysis to be included in the Definition of Ready.
Measuring the impact of static analysis
You can measure the impact of static analysis in a similar manner to how you measure feature branch-based defects caught before the code is merged into the main branch — log the defects and hold a root cause session to understand why these defects happened.
Over time, the number of defects caught via static analysis should go down as the team improves the process used to write requirements and as their domain knowledge increases, but it’s important to keep doing the static analysis even if no new issues come out of it.
If there are defects that make it past the static analysis stage and end up causing rework during the development of the feature it’s also important to understand the root cause of these and where appropriate build up your static analysis tooling to help catch these.
Summary
Static analysis is a valuable tool for catching bugs early on in the SDLC and for helping the team build up a better understanding of the features they are implementing.
By testing your requirements you can stop any potential defects from popping up during testing later on which will cause lengthy rework and impact the team’s ability to deliver the functionality that will provide value to the end-user.
Over time, carrying out static analysis against your requirements will lead to better requirements, which in turn will lead to a higher level of shared understanding across teams and this should mean that the output of the team is of a higher quality overall.
@AvermentDigital on Twitter, Facebook and Instagram