Quality Assurance in Agile Software

What is the role of QA in high-quality software development? Is this about quality assurance or quality control? QA is one of the roles that changes significantly in the transition from traditional software development to high-performance agile software development. It’s not all about QA testing or QA as gatekeepers. So what is the role of quality assurance in a modern hyper-agile continuous delivery team?

Agile software development is really about moving fast and learning things, speed of feedback is of the essence, how do QA professionals fit into organisations like this, and how do they contribute most to helping to deliver high-quality software quickly and efficiently?

In this episode, Dave Farley explores the role of QA in modern agile teams and explores the move in some detail from gatekeepers to quality experts and ideas like continuous testing and QA as trusted advisors.

_____________________________________________________

📚 BOOKS:

In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------
Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 JOIN CD MAIL LIST 📧

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[yapdog]

I came across your channel last year, and it continually amazes my just how in sync we are _(i've been developing software for ~3 decades)._ It feels like you're speaking my mind. I've been *really* needing that; sometimes, with certain teams, I've felt as if I were seeking something that's too idealized and unrealistic. Now I feel vindicated. Thanx a bunch!

[edwardallenthree]

My wife works at a pharmaceutical company in QA. I am a semi-retired software engineer. Your videos interest both of us!

[silentexploration]

I work as a software tester more or less in a way you described. I say less because of a number of reasons:
1. It's a 17 minute video about quality, yet there was not one hint at what quality means. I find this problematic because if we don't agree on some shared definition, it might end up devs thinking quality means quality of their code, whereas testers typically understand quality as value to our customer. These are not the same thing and people will work differently based on what they believe quality is.
2. I'm still surprised that there seems to be a notion that testing equals demonstration that the software can sometimes work. It's maybe part of testing, and not even a very important one. Testing answers the question: "What are the problems with the product?" That's not the same as checking the product can sometimes work.
3. "Software testing proves the existence of bugs not their absence." Dijkstra said that many many years ago, yet we still believe that our job is to assure the software is without bugs. The name quality assurance is problematic for this very reason, in addition to the fact that people, even QA people, many times have no idea what quality means and what they are assuring.
4. There is no manual testing, just like there is no manual development. What would manual development even mean? How about manual doctors? Are pilots manual or automated ones when most of the flights are handled by a system? Why is it that testing seems to be the only role that's strictly divided into manual and automation? Does it mean that manual testers doesn't use tools to make themselves more powerful testers? That's ridiculous. I find it more useful to devide testing into attended and unattended testing based on whether or not a human is involved in performing testing.

[Julio-uxry]

I will get the book right now; one, because I am so curious on getting deep into the Farley's thoughts on this approach and second because It's the least thing I can do for supporting this great work. Yea, probably the majority of the organizations are still far from this approach, but every QA and DEV that works with QA professionals watching at this video should do it's part to make it real and take the collaboration between teams and efficiency to the next level.

[queenstownswords]

Thanks for the video. I do agree on several points of the video. The 'old approach' to QA is ingrained in most teams. The 'old approach' tends to be dictated by either a group manager or CTO as they have a set way of doing things. I have sold a few teams on the new approach with some success. To IT professionals that want to use the new way of QA (as the video suggests) I strongly suggest pointed and deliberate questions in the interviews.

[kickpuncher]

I manage qa resources across our org and I am in 100% agreement. The challenge is getting all the different teams in alignment across the org.

[DavidTran-yfrh]

Dave you are spot on. I would dare to say 95% + of QA organizations are tied to the same QA practices from decades ago. 3 Amigos embracing BDD has elevated the QA role and not thought of as a "QA gatekeeper".

[Torsan]

Manual testing also has the benefit of upholding knowledge of the system(s). These manual testing sessions might be the only time developers interact with certain parts of the system and learn how the are supposed to work. If we stopped doing manual regression testing we would soon loose knowledge about what the system does and how it works.

[ddanielsandberg]

The one hill I will die on: Stop having QA departments, stop having QA teams and please, stop calling testers "QAs". Heck, ban the word QA if needed.

My reasoning is simple - Having a separate group/role called "Quality Assurance" entrenches the belief that quality is the responsibility of a separate specialist group and that they can "inspect quality in".


Some will interpret this as "you just dislike testers". Nothing could be further from the truth. Testers are awesome and are usually paid to little and treated as second class citizens, but testers are not QAs, nor are they in charge of quality or "approve" of changes. Testers brings a unique perspective and skillset to the team and provides input and feedback so that the entire team can make informed decisions about the next steps.

As someone else has mentioned elsewhere - "DevOps is not a team/role, it's a feature of the team" and just so is Quality Assurance a feature of the organization as well.

[benfellows]

Great video, your ability to articulate and explain concepts simply and clearly is next to none. I look forward to every QA testing video you make and I'm becoming a huge fan 🙂

I wrote a blog post on this recently as it seems most testing, manual or automated, is just asserting underlying code functionality with a binary pass or fail result. Fine for regression testing, but where is the testing of the value described in the user story? QA testers also test this by investigating and telling counter user stories of threatened value and harm. This can even be done during story mapping before any coding or even designs have been done, so the three amigos/amigas and manual testing points resonates with me really well.

Contentious testing throughout the SDLC: For every development or PO activity in devops, there's an equal but opposite QA testing activity running in parallel.

[yanlobau]

Dave, i completely agree with this shift left approach, thanks for evangelizing it!

[kamertonaudiophileplayer]

So it is not only Continuous Delivery, also it is Continuous Testing. Good point.

[TheEvertw]

QA's job is to _assure quality._ So as long as the quality of the code is good, QA is doing a great job.
QA should work on setting standards for e.g. test coverage and static code quality rules, and reviewing the tests that are run or writing those tests before the code.

[mgpmul]

Thank you Dave, I very much appreciate the way you share your knowledge and experience with the world.

A critical note though:
In the video, the role of QA seems to be restricted to testing, during the development phase.
However, QA is more than testing. QA is also about motivating the team to do some form of root cause analysis, which isn't necessarily a time-consuming formal meeting, but can be an informal chat between QA and a Dev. Update the bug report (if there is one) with the cause and lessons learned. Maybe the bug learned us that we should refactor some parts of the code, or make the logging more readable and valuable.
QA is also about reporting on the number and severity of bugs that make it to production (preferably in relation to the number of code changes). Are the test efforts paying off?

[teoconserv]

A thing that is often neglected is test maintenance. Tests break as software is refactored and underlying technology and infrastructures change. Ideally, they would be fixed or retired the moment a breakage is seen and that would be a joint effort of Dev and QA halting development until fixed. But often development moves on while QA struggles to keep the tests running. As time goes on, the amount of code typically increases and so does the amount of tests and test breakages, but the size of Dev and QA teams doesn't keep up. So if not handled carefully and kept in check, test breakages can overwhelm a team. There needs to be clear understanding, that broken tests halt all development.

[Vietagonia]

Great and simple explanation!
My biggest challenge with CD pipelines and QA is where/how to include automated regressions into the pipeline.
Doing multiple atomic changes in a CD pipeline is at some point easy and fast, but when full regressions are part of the pipeline as a quality gate, it start slowing down the process a lot.

[JorgeEscobarMX]

This seems like an essay on why test driven development is a must on CI/CD teams.

[defeqel]

Thanks for this. This is pretty much exactly how I've been thinking the process should go. In general, it's another problem of people falling into their own isolated silos, to emerge only when they think they've finished. Perhaps unfortunately, some industry standards require manual testing to be done before release, with a release candidate, with meticulous test plans and reporting. Most projects do not need that, and even if they do, those test plans are often best done together rather than making them someone else's problem.

[figlermaert]

I had a team where the devs refused to “cross over” into automation or QA minded approach. Instead, we had QA/QE that wrote redundant automaton test scripts across every story the devs coded ( which they had written unit tests for). It was checking a box and as the product owner it was maddening to get pushback from QA management when I wanted the team to change how they approached it to a method similar to what Dave is saying here.

[Mario-jjqy]

Another great video Dave! I have greatly enjoyed your weekly content so far and I share many of your viewpoints on what good software engineering should look like. With every video, I long to be part of an organization where people are driven to do things right. Unfortunately this seems so rare, and even if we want to use our newly acquired insights to bring about change, we often run against political walls and resistance in the organizations we work for. I say "we", because in the comment section I frequently read that others struggle with the same problem. Perhaps this could make a topic for a future video, how to drive change in an organization and convince our peers and managers that we can do better by following advice like yours?