Breaking down silos: The Changing Role of Quality Assurance in IT Projects

complexityIn 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’ and ‘doing the thing right’.

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.

  1. 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.
  2. 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.
  3. 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, and you can check out our process for this type of project pre-planning in our Pathfinder white paper.

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?

At Daysha we have a range of services to help with IT project planning, management, and implementation. We can help you change your development organization. Please contact us to find out more.

Tags

5 comments

  • In the late 80s, early 90s we saw the emergence of “total quality” in the manufacturing sector, largely influenced Taguchi et al in Japan. That was the beginning of process that broke the barriers between QA/QC – as the gate keeper at the end of the manufacturing process – and the rest of the business. A process which culminated in the end-to-end quality focused lean processes such as Kaizan and 6 sigma
    It appears to me that the DevOps is taking the first steps towards a total quality driven delivery of IT projects in much the same way as manufacturing. Interestingly, in the manufacturing industry the main stay of the total quality approach was continuous improvement by small iteration. This improved costs as well as quality, much like the DevOps approach. Surely there is an opportunity for QA professionals to enhance their role in the delivery of IT projects

  • Thanks Mark. Great insight.

  • Mark Kavanagh /

    Be interesting to see what management types are going to label this “new” role of BA and Tester combined ?!
    Any person working in Software Delivery who is good at their job is doing these roles naturally and also doing a great job of Customer Support too after release to Production, yet I don’t think this is realised or appreciated by Management who rather silo all roles.
    If you go to a job interview or talk to recruiters they ask well what are you or where do you want to go next ?, BA or Test or Support ? The fact that a person is quite competent in all roles is really foreign to them and sadly these people hold the power. You couldn’t possibly have the skills in ALL these roles !

    I like your article and the fact that it’s getting the agile mentality for more non programming types out in the open and if this is the way your company is thinking right now about QA and BA roles then it will definitely attract really good candidates who can finally breathe a sigh of relief that at least one company gets it.

    Good people working in Software Delivery will always be looking to improve both technical and business domain skills, We should also demand user experience design knowledge of the “Agile BA/Tester” or whatever it may be labelled and I’m sure there are many more skills we could add to the list.

    • Thanks Mark. Great comments.

    • Mark Stokell /

      Could not agree more. Regardless of the label the emphasis should be about “quality first” along the whole process from analysis to implementation..Historically it has been quality centric approaches, not cost control, that have added most value and lead to improved business competitiveness. The functional management approach has been shown to be limited in other sectors. The same is true for software delivery

Leave a Reply

Your email address will not be published.

top
mautic is open source marketing automation