The Art of the possible with Quality.
Part 1. QA team vs built-in QA practice.
Traditionally Quality Assurance (QA) has been referred to as a separate team, resulting in the QA role being involved toward the end of the software development lifecycle – once all coding was complete. This separation removed much of the responsibility of the developers to test their work, resulting in cost and timeline overruns, and increased time-to-market. The common excuse was “there’s a QA team that is responsible for all bugs”. So, developers didn’t really care about the quality of their work as much as they should have, the entire responsibility was passed over to the QA team.
Contrary to the synchronous activities of legacy approaches, the dawn of Agile has slowly changed the role of QA and when QA gets involved in the software development lifecycle. With Scrum, software development activities are performed in the order they are needed, asynchronously and in small increments. With Scrum, QA Analysts participate and fulfill a variety of responsibilities conjointly with other engineering team members.
Generally speaking, scrum is about collaboration between people with different expertise, levels, and even mindsets. If we were to start building a separate QA team that was not embedded with the Engineers and Product Managers, we would be creating a wall between Engineers and QA. This leads to the separation of QA engineers from many vital discussions with Product Managers and Engineers especially in the earlier stages of the software development life cycle (SDLC).
Whereas in scrum, a common practice is to embed QA engineers (QA practice) into the scrum team. There is no QA team per se in Agile, only QA practice. In fact, in many cases, we experience our software engineers pitching in to help with QA related activities that need to be completed as part of a sprint commitment, which is absolutely toward the spirit of scrum.
In scrum the team is a cross-functional team where developers, analysts and QAs all work together. Quality is a focus right from the get-go. Apart from spreading responsibilities between all members of a scrum team, QA Engineers add huge value to the quality of the product when they participate in planning exercises, feature solutions presentations, etc. As a practical example, QA Engineers can prepare test cases before the functionality is developed or help identify missing acceptance criteria within user stories. These test cases are then used as detailed acceptance criteria by developers during the development process.
Developing such an in-built quality practice instead of building a QA team that comes in later, allows reduction in costs needed to fix issues and decreases the probability of reworks. Today, organizations are catching on to these benefits and are focused on accomplishing this with “shift-left testing” techniques. Ultimately, we should always be looking for opportunities to foster better collaboration between not only QA but all members of the scrum team.
Written by: Volodymyr
