By Diane Bienkowski
When chatting with a colleague recently, they asked if I liked doing QA. Initially, I found the question rather amusing as it’s been my career choice for several years, but the more I thought about it, the more I realized that the question had merit. The perception and understanding of QA has evolved significantly in recent years, something I attribute to the introduction of new methodologies such as Agile. For so long, Waterfall was the methodology of choice and the role of QA varied from being an integral part of the team to a grudging necessity. But with new approaches to software development came a new perspective on QA.
The age of Waterfall
Personally, I was fortunate in the early years of my career to work for industries that placed a high value on quality assurance. In the health care industry, a software defect could result in loss of someone’s life; in the financial services industry, a miscalculation could result in the loss of someone’s life savings.
Working as part of a project team within these organizations meant that QA was involved in the project from the beginning. We participated in project meetings, provided feedback on requirements, gained an understanding of the technology being used and were able to formulate a plan for testing the software early on in the schedule. One of the benefits of this approach was that issues and potential defects could be identified early on in the process. And even though the team was not necessarily together on a day to day basis, there was a sense of having a common goal.
But as I talked to other QA professionals, I began to realize that my experience was not the same as many of my colleagues. For them, Waterfall meant that they were not involved in the development process until just before it became necessary to test the product. Requirements, if they existed, were often incomplete. When they didn’t exist, QA was forced to puzzle together what the product was meant to do either by using it or by making assumptions. Access to business stakeholders was not encouraged and often prohibited. The emphasis on quality was overshadowed by time-to-market needs and if QA’s schedule was squeezed to just a few days to perform a cursory overview of the product, so be it. All these roadblocks led to friction between the various team members and often resulted in a very dysfunctional environment.
The dawn of Agile
With the advent of Agile methodologies, there has been a shift in the dynamic not just from the perspective of QA’s role but from an overall quality perspective as well. One of the main tenets of Agile is that everyone participates and everyone has a voice in how the project should evolve. The concept that an individual has only one skill set is obsolete. And while most teams don’t follow the pure rules of Agile, where testers are developing and developers are creating wireframes, the lines still have become a bit more blurred.
Agile balances the desire for speed with the requirement for quality. This is accomplished by forming a small, focused team, including QA, that collectively looks at the requirements and determines what can be accomplished within a set period of time. Daily meetings, along with frequent informal discussions, ensure that everyone is kept on the same page.
A product owner is available to respond to business questions raised by the team and a Scrum Master ensures that all roadblocks are removed so that the team can focus on deliverables. Typically, what is accomplished within that time frame is a distinct piece of functionality that is fully formed. To that end, the team as a whole is held responsible for ensuring a product that is as defect-free as possible. This approach ensures that QA must have an equal place at the table, since a defective deliverable means missed stories, and a failed sprint.
In this way, I feel the best practices of well-run Waterfall projects have been incorporated and enriched in Agile projects: requirements are scrutinized for comprehension and technical implementation, adjustments to design and functionality are made during the vetting process, automation opportunities are identified and incorporated into continuous integrations, and technically challenging areas are identified for focused testing.
However, a finely-tuned team is not established overnight. Waterfall devotees, in any role, may have difficultly adjusting to the open and collaborative environment, and even then, there will be a learning curve where the team adjusts to working with each other. Breaking down the old habits and perceptions can take some time, but as the team evolves, and as each person shares the perspective of their traditional role, the rest of the team recognizes the importance of their colleague’s expertise and should begins to incorporate it into their way of thinking.
The span of influence
A remarkable benefit to the lessons learned from working in an Agile environment is that they can be applied back to projects still following a Waterfall methodology and they can also be brought forward as even newer methodologies in software development take shape. The conversations that I have now with other QA engineers have indeed confirmed this shift in approach. From a QA perspective, this is an exciting time to be working in software development. Being able to truly practice quality assurance alongside creative and talented co-workers is not only rewarding, since it greatly improves the quality of the software we produce, but it’s a lot of fun as well!