The fact is, there can be many kinds of defects in software. Organizations are constantly working to minimize those defects. But to minimize any sort of defect most effectively, organizations need to look to the source. Most people think software defects come out of development because that is where the design is brought to life. But, is development truly the main source of software defects?
What is a Defect?
To answer that question, we first have to look at what constitutes a defect. By definition, a defect is a shortcoming or imperfection. In software, that would mean there are shortcomings or imperfections in what the application was intended to accomplish. Where does that intent come from? It comes from the business requirements. Logically, most people look to the design for the source of truth of what the application is intended to deliver. But rather than looking at the design, you need to understand the requirements coming from the business. The application should be designed to fulfill the requirements of the business, so the origin of the intent is actually in the requirements.
Understanding Requirements
In order for the application to fulfill the requirements of the business, those requirements must first be fully understood and then clearly and accurately communicated to the application designers. Even in this age of powerful computers in every pocket, with perhaps hundreds of applications running on them, that process of clear and accurate communication is very challenging. If you take the IVR industry as an example, where many very large organizations still use lengthy complicated written documents to capture IVR requirements, you begin to see the problem.
The next step in the evolution of IVR requirements documents over the last 15-20 years has been to take those written documents and to turn them into flow-charts in a free-form tool such as Visio. While a picture is truly worth a thousand words (or perhaps a thousand requirements in this case) the problem with those tools is that they are, to a large extent, free-form and relatively unstructured. It is a creative challenge to make sure all of the requirements that need to be clearly and accurately communicated to the designer are captured in those pictures. Any shortcoming or imperfection is by definition a defect in the requirements themselves, far in advance of a single step in the development process.
Avoiding Defects from Day One
To make sure that defects are not introduced into the process in the requirements, you need a well thought-out, collaborative, intuitive requirements management process supported by technology that is intended for that specific task. But there is no silver bullet. Those archaic requirements processes have been around for a long time and many people are comfortable with the status quo. And, there has not been much focus on the technology that supports an efficient requirements process in the IVR world. And let’s not forget that the requirements process is where the business typically meets with IT, and in many organizations, that is not the most collaborative of relationships.
Cyara has been in the business of finding defects as early as possible in the IVR development process (where they cost the least to rectify) for 10+ years. That is why we have pioneered a design-driven approach to IVR testing called Velocity. Velocity is the task-specific solution that supports a visually intuitive collaboration and validation of the IVR design between the business analyst and the application designers. Being task-specific is what separates Velocity from those free-form tools. By requiring that the appropriate information is captured at every step of the IVR flow, Velocity ensures that nothing is lost in the communication of the requirements into the design.
One large Cyara customer in the telecommunications business has described the introduction of Velocity to their Business Analysts as a groundbreaking moment. Enabling those Business Analysts to collaborate with the business users around a visually intuitive design will not only improve the understanding of the requirements, it will reduce the likelihood of any defects being introduced into the requirements.
“We have been using those Word documents forever. Giving our Business Analysts a solution like Velocity to capture the requirements is like introducing the wheel to people that have had to walk everywhere their whole lives.”
Voice Delivery Lead, Top 5 Telecommunications Company
The cost of introducing defects into the requirements can be quite significant. In many development processes, those defects won’t be discovered until the user acceptance phase (UAT), at which time any defects have already accumulated development costs. In addition, significant time has likely been lost in the process of creating software from defective requirements and then there is the additional cost of rework. These costs are all avoidable if you have the right requirements management process and appropriate testing based on the design.
Cyara knows knows this all too well, which is why Velocity can automatically generate the test cases that follow the design all the way through the development and testing and deployment process. In doing so, Velocity helps prevent the introduction of shortcomings or imperfections and defects into the requirements, as well as the accurate as-designed testing that captures defects at the earliest possible step in the IVR development process.
For more information on Velocity, watch the video.
And contact us today to learn more.
