Recently, I was talking to a few computer graduates, and we found ourselves talking about different Software professions. Needless to say, we talk about the role of a QA in the software industry. QA is a misunderstood profession, but to be honest, I was a little surprised with how misunderstood it is. They say you have to explore the past to understand the present and then shape the future. I felt a need and responsibility to share QA as a discipline and the way I understood it.
Quality as a function is with Mankind for ages. Think about the organization, planning, scheduling, design and calculations involved in building the pyramids of Egypt. Proper quality check and balances are needed to create something that epic. Only good quality check and balances can produce a quality product, and our history is full of them. Quality Assurance as a practice has evolved from its early stages. QA as a discipline started at the beginning of the 20th century with an industrial revolution. The revolution and competition in the manufacturing world increased the need for quality checks and balances. Safety regulations and auditors took birth during these times.
In its early stages, the software industry borrowed many of its processes from the manufacturing sector. QA stayed at the end of the waterfall model. Software industry adopted the production process and worked like an assembly line – design, implementation, and testing. The above process would function correctly if the product didn’t change too much. But the same process didn’t work very well with the ever-changing nature of software products.
Software industry soon realized that the above structure is not suitable for them and new approaches like Agile, Lean and Kanban were born. Constant change and sprints became the norm. Requirements, design, and interactions were allowed to evolve throughout the project. Changes became part of the software life cycle. The new products were broken into chunks and build in parallel.
Somewhere in that evolution, QA was forgotten. The general understanding is still that QA is not needed until the application is ready. Being brought late in the development process, QA felt overwhelmed and lost. The team lost momentum because they find themselves waiting for testing to finish. QA found themselves waiting while team delivered something that is testable.
In the traditional structure, developers and QA’s were part of two departments. They sit in different locations and time zones. Coders and developers hardly knew each other. The QA manually went through entire regression. QA’s performance was measured with metrics like Defects caught. QA’s spend most of their time in establishing traceability. Needless to say, all the focus was on quality after the code was ready.
Software community soon recognized the need to adapt and get better at integrating testing with the other parts of the agile development process. Small pieces of software are testable now. The concept of test early and as often became the norm of the industry. Software community soon realized that QA’s need to be involved from the start in software development life cycle. An important concept of “continual engagement” was born. QA teams think about quality and testing at all stages of project lifecycle not just once a code is delivered.
One of the most important concepts in continual engagement is “Shift Quality Left,” which was coined at the 2013 state of QA conferences at SXSW. QA is now engaged right from conceptualization, design and user stories. The focus of QA is more on preventing defects entering in the system.
“You cannot inspect quality into a product. The quality is there, or it isn’t by the time it’s inspected” – W. Edwards Deming
The team structure changed, coders and QA’s came under one management. The goal is to prevent defects, QA is talking to coders, product, stakeholders and they have added the additional check to make sure errors did not creep in.
Success and failure belonged to team not to an individual, The old metrics used to measure coders and testers performance are dead. Quality is cross-functional and is everyone’s responsibility. Automation has become part of the development process. Failing Fast enables a team to start working on a product, learn whether we made the right decision and if not, kill it quickly before losing more money.
Everything in our life is being driven by one human behavioral pattern that serves as the underlying motivation for every change in the world. Our race to shorten the time we are willing to wait to get what we want. The change in the QA role in software industry came from this need. The present role of QA is somewhere in the middle of a transition. Some teams do it well, some are still struggling. I am not saying that represents the entire software industry, but that is the truth of more than 75 percent of the industry. Automation requires strategy and planning so that it can be maintained with the ever-changing need of software needs.
QA’s role has evolved. We are already moving towards the team structure where the development process will have deeply embedded quality checks and balances. With the increased competition and need to deliver software faster, There will be more focus on quality checks and balances and the role which will help enforce them.