Member-only story
Not your ordinary testing tool: Static code analysis
In the first part of this series Not your ordinary testing tool: Observability Tools, we talked about observability tools and why they are not testing tools but still testers tools. Now let's turn from DevOps/SRE tooling to the developer's tooling, and talk about static code analysis.
Static code analysis tools are often used only as something to enforce quality gates and get reports about test coverage. I believe that static code analysis tools are such an incredible source of information. Even if developers in your team do not want to use them QAs should hook static code analysis tools to the repo and enjoy a bunch of insights.
The first incredibly useful piece of information is the unit test code coverage. It's a great place where you can see where to start your testing. A module with 35% of code coverage statistically will have more bugs than a module with 85% of coverage. Not only because it is not tested but because it shows that the developer was either in rush, or did her job only to get it done and forget, or it's hard to write unit tests for this specific piece of code or there is no quality culture or… There can be plenty of different reasons but none of them usually leads to good quality.
The next reason why you want to use static code analysis tools is that they show you bugs. Literally…
