Defect Prevention formerly, now, and in the future — from an early reactive approach to AI-based solutions
DEFECT PREVENTION — A HISTORICAL PERSPECTIVE
In the early days of software development, defect prevention was not given the same level of importance as it is today. The focus was primarily on detecting and fixing defects after they occurred. This reactive approach resulted in increased costs, delayed timelines, and dissatisfied customers. However, as the complexity of software systems grew, the need for a more structured and systematic approach to defect prevention became evident.
The idea of defect prevention is strongly related to the “shift left” approach. The furthest to the left in defect detection can be moved just to the moment when the defect is about to arise. Bringing to a situation in which the defect does not arise reduces the cost of its repair to zero. Therefore, it is a highly desirable situation in every aspect.
TRADITIONAL METHODS OF DEFECT PREVENTION
Traditional defect prevention methods focus on a reactive approach focused on analyzing defects already found. Traditionally, the developer was responsible for code development, while the tester was responsible for its quality. In this way, the programmer did not feel so obliged to care about quality.
According to traditional reasoning, if developers are responsible for the code, they are also responsible for the defects. Therefore, if we want defects not to arise, we must teach developers to work in such a way that they do not make mistakes. (Sounds so realistic, right?)
So, how can we effectively teach developers to avoid making mistakes? First, we need to understand the types of errors developers commonly make, identify the most critical ones, determine what proper code should look like, and then prepare training materials that developers can implement in their work and everyone will be happy.
To achieve this, methods of defect analysis have been developed, including systems for categorizing defects and their causes.
TECHNICAL SOLUTIONS IN DEFECT PREVENTION
An interesting and still relevant direction for defect prevention is the use of technical solutions that reduce the likelihood of mistakes or make mistakes immediately visible.
People who have worked with languages like C and C++ in the early 21st century are surely familiar with the concept of Hungarian notation. Although it holds only historical significance nowadays, I will mention it to illustrate how the development of tools affects the potential for making mistakes.
Early development environments offered little more than syntax highlighting and the ability to compile and debug. It was easy to confuse the type of a variable, and such a mistake was not immediately signaled as it is in modern IDEs. To reduce the likelihood of mistakes, a naming convention was introduced consisting of adding prefixes that determined the type of the variable. This way, when a programmer saw a variable name in any code fragment, they knew its type. Today, this function has been completely taken over by the IDE, and in any part of the code, we can easily find out not only what type the variable is, but also where it is defined and in what other parts of the code it is used.
A problem that was common in C and C++ in the old days was memory management bugs. The technical solution to these problems was the introduction of automatic memory management and garbage collection in languages such as Java and C#.
Finally, static analysis is currently the major example of defect prevention by technical solution. This direction of defect prevention remains useful and will never become obsolete.
NEW APPROACH — REDEFINING THE PROCESS
Peter Drucker, who is considered the founder of modern management, is the author of the following quote:
Productivity is about your systems, not your people.
— Peter Drucker
What does this quote tell us? If we want people to make fewer mistakes, we need to focus primarily on the aspects of work organization that lead people to make mistakes, rather than trying to “fix” specific individuals. What does it mean? It means that if we approach mistakes with boring training and the message of “Don’t do that again,” it is unlikely that much will change. What can help? Changing the way work is organized. This is precisely where Agile thinking comes into play.
You might be thinking right now, “But how can Agile prevent errors?” Let me explain. The problem with the traditional approach is the separation of responsibility (I wrote about it in the post on ISTQB). Agile and BDD emphasize collaboration.
Let me quote John Ferguson Smart…
Did you know that the goal of Test Automation in Agile is NOT to find defects. OR to make testers redundant.
In the early days of test automation, the focus was on automating manual test scripts. This was often done by a separate team and almost like a separate project, in isolation from the development work. The main goal was to reduce the time taken to do the manual testing.
But back in the day, this manual testing was largely a scripted affair. Because the main goal of automation was to speed up regression testing.
And catch a defect or two…
But here’s the thing: Test Automation isn’t actually all that good at finding defects…
[…]
But here’s the paradox: if you define clear, well-defined, acceptance criteria that give the whole team clarity on what they need to deliver, and uncover as many assumptions as possible, and then you automate these as early as possible, then you will typically find very few defects with these tests — because they will already have been caught during the development process, or never introduced in the first place.
[…]
Note that this applies to any Agile implementation that emphasizes the collaboration of all team members. Thanks to the organizational change, we achieve the effect of preventing defects (although we still need a tester).
The idea of modern defect prevention, therefore, looks as follows:
- Quality is a common responsibility.
- Testers are familiar with software development, and developers are familiar with test development.
- The whole team works on test scenarios.
- The whole team knows the test scenarios.
- Test scenarios are automated early.
- Development work takes test scenarios into account.
- Defects hardly appear or are immediately removed.
Developers cannot say, “It’s testing. I am not interested,” and testers cannot say, “It’s development. I am not interested.” This new style of working requires being a T-shaped person, i.e., having not only core skills required by a specific position but also some skills typical of the positions of co-workers. For example, being a QA specialist requires some knowledge about programming, DevOps methods, databases, etc.
FUTURE PERSPECTIVES
In my opinion, the future of defect prevention lies in the more intense development of technical solutions, especially AI-based solutions at the level of static code analysis. These solutions have shown great promise in automating code review and generating unit tests.
An example of such solutions is the possibility of generating unit tests with GitHub Copilot in Visual Studio Code, Visual Studio, Neovim, and JetBrains integrated development environments. Another example is Amazon’s CodeGuru, an AI-based code reviewer.
This trend indicates a significant interest in such ideas, and it is certain that these initial plugins are just the beginning of what AI can offer.
Additionally, I expect that Agile methods focusing on the cooperation of all team members from the very beginning till the very end will dominate in software development.
SUMMARY
Defect prevention has evolved over time and has adapted to new challenges and opportunities in software development. Agile implementations are a significant part of defect prevention methods. There is a great potential for AI-based solutions in defect prevention.
The story was originally created by me, but it may contain parts that were created with AI assistance. My original text has been corrected and partially rephrased by Chat Generative Pre-trained Transformer to improve the language.
