Quality Assurance (QA), like every aspect of software development today, is evolving. Traditionally, the idea of QA and the processes around it come from trade and artisanal contract work and early manufacturing. In contract work, the concept evolved to ensure the final work product for a client met their original requirements. In manufacturing, QA was a process applied at the end of a manufacturing line to assure that every individual item was of the same quality and as specified. In both cases, the problem was similar – ensure the product fulfilled its promise – whether it was a one-off project or one item in a continuous flow of things just like it.
When the idea of QA was formally applied to software development – the same general concept was followed. The QA process was controlled by a QA Department – a separate entity in IT – alongside Software Development, and IT Operations. In the flow of software development, QA is not, strictly speaking, just formal testing. Testing maybe a part of QA operations to determine the quality of work, but testing can and does occur in many different parts of the development process through to production. QA is meant to assess if resulting work products fit their purpose as required and if the work process itself is free of mistakes and rework, even if the final product meets requirements.
When a QA process is applied as the final step in application development, before an app is released for production, a natural tension is built up. If QA determines that the product does not meet requirements, it will result in project delays and rework. The question becomes, “When will the work be done?” It could also result in the recognition of failure for a project if the remaining time and budget are too limited to achieve the required results. With these issues in mind, many times QA is forced to overlook significant problems that are not considered to be “show stoppers.” In these situations, “technical debt” increases throughout the project when issues are recognized that cannot be addressed. In hierarchical organizations, because of the pressures, it made sense to keep QA separate from development to maintain independence and autonomy from other elements of software development and IT. It was thought that an independent QA group could be located anywhere, and was better off if they were not under the thumb of other entities that could pressure QA to step away from the mission.
The evolution of QA began as waterfall-based project management began to fade with the rise of lean, agile, DevOps and similar methodologies that rely on less detailed initial requirements and short, incremental development cycles. The basic idea behind these methodologies is that the client or product owner is able to see the working product much sooner in the process, as it evolves through development. This gives the product owner more confidence that the end product will meet their needs and the opportunity to change direction during development to achieve new goals or take advantage of information learned during a review of work. But, that also puts stress on QA because, in these methodologies, the requirements can be ever-shifting, evolving – especially in DevOps groups where apps are under continuous development by dedicated teams.
In these situations, a traditional, independent QA group would create a wall that would prevent incremental or continuous development processes from being successful. All the benefits of incremental development cycles are lost when a problem is brought forward at the end or near the end of a major phase or a project. This evolution of software development methodologies has caused QA to “shift left” to cover both the start of a project to ensure the work process is led by the recognition of quality throughout and that evolving requirements are managed so they continue to meet organizational and user needs and not spiral out of control under time and budget constraints. The rise of combined teams under DevOps, also means that testing for bugs and quality are fully integrated throughout the development process so that as work is incrementally released, it will continue to meet QA requirements without stopping or creating rework loops that would lower productivity.
So, in summary, what is happening to QA today?
- Traditional QA, as a separate process at the end of the software development, before an application is released for production, is largely dead. It cannot be relevant and productive in an environment of current lean, agile and DevOps methodologies.
- Software development projects continue to need the basic concept of QA – that applications are fit for their purpose and the development process itself is free of mistakes and highly productive.
- QA processes have largely “shifted left’ to the start of the development process to uncover issues before they can become “show- stoppers” that would stop progress or lower productivity.
- Development teams, especially those involved in continuous production, have removed the silos of development, operations, and quality assurance to flatten the organization and integrate quality processes and outcomes throughout the work process. QA is the responsibility of the entire DevOps team.
But going back to the title of this article – what does all this have to do with “where” the QA process “lives” as a part of a project or DevOps team? Everything.
If people involved in QA are in a separate location from the rest of the project team – it is likely they will again form a silo that can block production and lower productivity. The people don’t have to be a traditional QA team to have this happen. It can just as easily happen in DevOps implementations – when the satellite location is not a fully integrated part of the team and is allowed to operate as an independent element. If communication and collaboration are blocked or limited by separate work environments, off-set working hours, management hierarchies, language, culture, technical systems or trust – silos will rise and QA will either be lowered in importance or lost as a universal function.
So coming back to the question again – Where should QA be located in projects with current agile-based methodologies?
Location is important, but not in the sense that everyone has to be in the same room to get a benefit from both current methodologies and the discipline of quality assurance. Some organizations have removed formal testing positions altogether, in the belief that QA is everyone’s responsibility. In these situations, while there may be some team members dedicated to aspects of QA planning and test automation, QA tasks are seen as general responsibilities and something that anyone 0n the team should be able to contribute to as needed for their work or at the project level.
To be successful in DevOps implementations and similar situations requiring incremental releases, teams generally operate under agile with:
- QA formally integrated both as project tasks and as steps in user story-based development. Team members take responsibility for QA at the same time they take on a task.
- Individual team members are responsible for asking product owners open-ended questions as needed to fill out their understanding of both the user story and its outcomes from a technical and user point of view.
- Team members able and empowered to communicate in real-time without barriers to assure there are no delays from intermediaries or communication loops.
- Teams who have had the opportunity to talk to each other and build trust with informal interaction and team-building exercises. In the best case, these happen at the beginning of a project, but they can also occur at any time throughout, especially in longer projects or with dedicated teams.
- Shared technical resources (repositories, automated processes, scripts, tools, etc.) so that everyone is on the same page and aware of how best to use the resources available. Variation from standards can create blind spots and lower trust across the team.
In the case of outsourced teams who are remotely connected to the rest of the project team, it is particularly important that the remote team is experienced with integrated QA (they have the processes and procedures down at a level that allows them to modify individual elements to match selected approaches without loss of fidelity in the QA process), and has no communication barriers. However it is accomplished, it is particularly important that the majority of working hours overlap between teams and team members. If part of the team is on a separate day segment without significant overlap, communication, productivity, and quality will suffer greatly.
Where is QA in your organization? Have you moved or are you moving to a flatter, DevOps type implementation? How do you organize your software development teams? What do you look for when you consider an outsourcing vendor for a remote team? Can they integrate successfully and bring experienced team members to the table who can take responsibility for their role in QA as well as other tasks in a DevOps implementation?
It isn’t a theory anymore. QA is and should be everywhere in your projects.
Scio Consulting is experienced as a nearshore service provider for our North American clients with DevOps-based implementations. We can provide team members who can take their place as a part of an integrated team – fully responsible for their roles and tasks. We would be happy to discuss your projects and suggest how we can provide value in your situation. Whether your need is for a discrete project or a dedicated team for continuous development, we can bring together the services you require.