The benefits of software are abundantly apparent in our daily lives, so much so that most people take this for granted… unless of course that software has bugs. The software development community is constantly pushing the limits of introducing innovative uses for software that will allow us to reach new heights and certainly the digital revolution has made modern life better, but it hasn’t been without its challenges.
Along with moving fast and pushing the boundaries on new technology, software defects are very much part of the process and often prevent users from realizing their goals and result in countless hours of frustration. Defects, no matter where they originate from, are also expensive especially when they make their way to production. It is estimated that bugs alone cost the American economy over $1.7 trillion in 2017. This number is likely to rise since the challenges to creating quality software solutions, such as a lack of time or failure to adequately test products, will remain.
A critical element of developing software is to eliminate or reduce the number of issues within the system. That’s easier said than done, since even advances in artificial intelligence cannot completely eliminate buggy code or error prone test cases. However, by identifying the origin of the defects during software development, you may be able to actually reduce – or, in some cases, even eliminate – certain types of problems. Reducing these defects can improve the quality of your end product and enhance the development of future projects.
A quality revolution in software development is possible, and it all starts with an evaluation of where defects creep into your software.
Defects That Originate in Requirements
Software defects can start before a single line of code is generated. They can be found in the software solution’s requirements or at the time agile Stories are developed. Often, the original specifications include missing, incomplete or ambiguous information; additional problems can also occur when the original specifications are changed after development has begun. There also is the problem of misinterpretation, which can arise when the language has different meanings to the various stakeholders involved in development. Whether there is a gap in the requirements or what the client thinks and the developers know, the software does not deliver the desired outcome, resulting in negative consequences.
A logical approach to solving requirements problems involves communication, education and tracking. Team members involved in the development process, from the requirement authors, the software developers and the testers, should be encouraged to evaluate the feasibility and necessity of the requirements. Authors should also be educated about what “good” requirements look like and then be able to flag unclear verbiage for correction or deletion before development begins. Finally, since no process is completely perfect, implementing a tracking method for requirements issues can help reduce problems with the software being developed and highlight possible future trouble spots going forward.
Defects Arising from Functional/Technical Design Flaws
Functional and technical design flaws are particularly nefarious to root out because they involve a deep understanding of how the system works and how each part logically connects to deliver the desired outcome. This difficulty can result in problems with the software functioning properly or design flaws that allow the program to operate, but limit its ability to be effectively utilized. Equally as troublesome is that these types of defects can appear or be realized very late in the development life cycle or sometimes not until the software has been deployed to production. Addressing logical issues involves the careful architecture of the solution before development starts; the development team discusses and evaluates the approach to the solution before beginning to write code for it. Critical here are design walk-throughs with all relevant parties to ensure the suitability and feasibility of the approach. This applies not only to traditional software methodologies but also to Agile development. In particular, pair-programming techniques and code reviews to ensure not only coding standards are maintained but also the design is appropriate. Tracking these types of defects will be insightful and assist with identifying areas and resources that could benefit from proper architecture and design education.
Defects Due to Software Bugs
There really isn’t a whole lot to add to this topic as Software Bugs are probably the most scrutinized and tracked of all defects. Of course, many software defects are caused by logic errors, which can actually be any kind of flaw in the program. Coding or syntax errors, like a missed hyphen or accidental misspelling, are often common. One of the most infamous of such bugs was the “typo” that resulted in the destruction of the Mariner I satellite.
However, a key contributing factor of Software Bugs are the two topics previously discussed. Developers often get a “bum rap” because their Software Bug was the direct result of them following a set of poor requirements or technical designs.
Defects Caused by Test Cases
Quality Assurance Testing in and of itself cannot prevent software bugs; but rather it identifies defects, and when corrected, minimizes their introduction into production. It is important to focus on the quality of test cases as they will have a direct impact on the ability to identify real software bugs.
Most people would not consider Test Cases as being originators of defects but this does indeed happen. We may never think about associating defects with Test Cases but we should because it turns out that it is simply a good practice to adopt.
When a Test Case is executed and the expected result is not met, the Tester or the Test Lead usually opens up a bug. At that point it will be worked by a number of individuals. The project manager may get involved, perhaps a business analyst and almost assuredly a Developer. However, on occasion it may turn out that it was not a bug after all, but simply a poorly written or misinterpreted Test Case. This results in one of my biggest “pet peeves”, which is the cancellation of the bug. Tracking down bugs that aren’t really bugs is a waste of time and can be demoralizing and frustrating to the team. Of course, one cannot forget the refactoring of the incorrect Test Case as additional re-work as well.
Again, as with Developers, Testers can be victims of incomplete or poor requirements which might be the true origin of why a Test Case was defective.
Nevertheless, identifying repeat offenders, specifically individuals or areas that seem to generate sub-standard Test Cases, can be of value when your focus is on improving your software development process.
The Power of Knowing Where Defects Originate
Recognizing where defects are injected into the software development process can help your organization focus on reducing or eliminating them. While there will always be challenges in software development, catching the most impactful errors in requirements, design, code logic and testing procedures will help your team create the highest quality software possible. Managing defects not only improves the quality of your solutions, but it also encourages all teams supporting software development to consider quality at all stages of the project life cycle, resulting in the continuous improvement of your deliverables.