Breaking down silos: The Changing Role of Quality Assurance in IT Projects
In our previous article, “DevOps: Can we automate our way to Business and IT Alignment?” we discussed how agile software development has merged with IT operations to better align technology and business teams. Ultimately, the agile movement that spurred on the DevOps phenomenon is test-based, and requires developers to take on a greater role in the validation phase through automated testing. This approach to early validation and automation is at the heart of DevOps. However, where does this leave Quality Assurance (QA)?
Remember DevOps is about doing away with silos. And the QA department is definitely a silo that has grown in many organizations. It is easy to see how such a transformation can displace QA professionals, many of whom have built long careers by being on the other side of the “wall” that agile software methodologies seek to break down.
Are movements like Agile and DevOps doing away with the QA professional? How can IT organizations re-organize themselves to leverage their QA skills to produce more reliable software and more quickly deliver business value?
It is true that the QA profession will never be the same, but rather than going away entirely, I think that QA needs to become less like a “bug inspector” and more of a partner that helps to ensure that the business is ‘doing the right thing’.
The QA Disruption
Some commentators have declared that we are seeing “The Death of the QA Department.” However, this does not have to be taken as a dire sign for QA professionals nor a pronouncement that code scrutiny no longer matters. On the contrary, it matters more than ever. What it does signify however, is that compartmental QA, the type that is biased overwhelmingly towards process and is only involved in the last stages of the development cycle, is coming to an end.
This type of QA became the norm as companies became flush with money during the internet bubble. While in theory it should allow developers to simply focus on code and let the quality experts judge whether or not it works, in practice this methodology led to far too much sub-par code reaching the validation phase. As agile development became normalized, validation worked its way more closely into the actual coding phase using techniques such as Test Driven Development. Rather than becoming extinct however, QA is experiencing something similar to the merger of development and IT Operations that is cornerstone of the DevOps philosophy.
QA as a Business Partner
According to Tech Target, 2012 was a watershed year in which QA transformed from a distant watchdog group worried about being replaced by test automation to a valuable stakeholder proving its worth to the line of business. Part of this is owed to the fact that QA professionals embraced coding like never before, stepping up into the new relationships created by iterative test case development and automation.
However, QA is not only showing its value to business by immersing itself more in the core technology. It is taking responsibility as the steward of overall quality. Keep in mind that the modern IT environment does not deal with shrink-wrapped products pushed out the door after code sign off, but rather dynamic entities serving a huge live user base in which countless unpredictable variables influence quality. QA professionals must now be able to maintain watch over the entire lifecycle of the product, staying aware of issues that developers, security professionals, IT architects, Project Managers, and even the customer may not be able to see.
This is a great leap forward, but in my opinion it is not enough. Unless we understand what we mean by Quality, we can’t measure our investment in quality control or improvement.
A system that does not deliver business value or meet business expectations cannot be considered high quality, even if it actually implements all the requirements that were asked for. QA must be the guardians that determine if a feature, implemented as planned will actually deliver this value. So QA is not just validating the code or technical delivery, but also validating that the actual requirements being asked for represent real business value.
So actually we are talking about merging QA and the traditional role of business analysts. Where once these were silos, I think that leading organizations are beginning to merge the responsibilities and giving QA a role that spans the entire project lifecycle. QA engineers need to understand the requirements and needs from the business and user perspective, whilst BA’s need to understand their role in developing requirements that ultimately deliver real value.
How do you transform your QA department?
So how can you achieve this transformation? There are many incremental improvements that can be made to shift the QA culture.
- Earlier Engagement: QA professionals need to be involved as early as possible in the lifecycle of a project. This not only provides QA with early sight of upcoming work, but gives them an opportunity to contribute to shaping the project, understanding the business objectives and the value that will be derived, and selecting appropriate processes.
- More Automation: In our previous article we talked about DevOps and how automation is an enabler for the DevOps culture. The same is true with respect to changing the QA philosophy. If we want the same QA resources to do more valuable work, we need to give them the tools that reduce the amount of manual work they do now – for example manual testing, entering bugs, and preparing reports. If the work can be automated, and if it will be repeated many times, then automation should be considered. This will free up QA to concentrate on value add activities.
- Measurable Value: Agile methodologies emphasize the prioritization of features that deliver the most business value. I’ve not really come across any definitive measures of business value, and don’t expect to, but there is no doubt that we need to at least have a clearer and shared understanding on every project of the definition of business value and how we measure it objectively. Maybe more thorough upfront planning and modelling of the business case is required. Maybe systems and processes need to be better instrumented so that management has the right data on which to make decisions about business value. And we must remember that not all business value is measured in monetary terms.
There is no doubt that with Agile, DevOps, and the shift in QA, we are seeing the emergence of closer integration between specialists and more alignment between business and IT. All stakeholders need to work together and understand each other more. Methods need to be developed to enable this and help combined teams plan projects more effectively.
But also I believe education plays a vital role. Business Leaders need to better understand IT. According to the Technology Business Management Council and reported in the Huffington Post, business leaders believe IT has 60% more budget to spend than it does. This is a stark and scary indicator of the lack of alignment and understanding of the true nature of IT in business. IT Leaders need to do a better job of communicating, anticipating and explaining the implications for changes, and measuring the real value they provide to the business.
There will be a greater emphasis on pre-project analysis and planning work. Unfortunately the Agile movement has been misinterpreted in this regard, or perhaps has not adequately explained its position on Analysis. In fact you can find documented throughout the web many anti-patterns objecting to significant up-front design and analysis work. We don’t subscribe to this blanket argument.
We would love to know what you think. Do you get measurable value from your investment in QA? Can you see that advantages of eliminating the silos in your development process? How could you benefit from involving QA earlier in the lifecycle and giving them more responsibility for overall quality and business value?