There are two constants when it comes to software quality: every organization has their own definition of what “quality” means; every new developer/project has no idea where to start. Layer in the desire to deliver releases faster, and you’re stuck between a bug and hard place. How do you implement broad, consistent, repeatable, and fast quality testing?
Outsource the quality expertise
Introduced in Klocwork 2017.2, the Klocwork Quality Standard is a set of quality rules designed to identify the most common root causes of software quality issues. Based on years of real-world academic research and experience with our customers, our in-house software quality experts recommend these rules (C/C++, Java, C#) to find defects that specifically impact code quality. Everything from memory and concurrency issues to performance irregularities.
Watch this video overview of the Klocwork Quality Report.
Quality standard examples
A common error is the buffer overflow, occurring when an application attempts to put or get more data than available in a specified segment of memory. You’ve likely heard of the most popular security vulnerability ever, Heartbleed, which was a buffer overflow in OpenSSL. This error frequently occurs for many reasons (lack of experience, time, code complexity, etc.) but, suffice it to say, developers are still letting buffer overflows get into releases.
Simple buffer overflow highlighted (see our docs)
The Klocwork Quality Standard checks for this error, in many different flavors. And you can easily integrate the Klocwork Quality Report into your team’s dashboard to provide a quick summary of the progress you are making on improving software quality.
The same goes for null pointer dereferences (NPD), memory leaks, mismatched return types, suspicious code practices, and a lot more. You could argue that the skills to detect and avoid many of these issues are taught in college programming courses. But they don’t prepare developers for the real world of thousands of lines of code across hundreds of compilation units…on top of legacy code going back more than three years (easily—one of our customers has a code base stretching back to the 80s).
Now imagine trying to write a test to detect NPDs for a new component that interacts with a much bigger system. Or assigning that test to a brand-new developer because you don’t have time to do it. Will they succeed?
Another thing to consider is this: We’ve been building static code analysis tools for over 12 years, which requires a very deep understanding of how languages, compilers, and application runtime behaviors work. And, when it comes to the Klocwork Quality Standard, we’ve been careful to select only the rules that matter most to application functionality and behavior. There are many others, of course, but if you want to define, run, and report on software quality in one fell swoop, this is the way to do it.
You get the entire software testing lifecycle right out of the box.