The Break-Up
True Story.
It was a painful breakup. I thought things were going fine, but “it’s not you” she said “it’s me”…. and just like that, our relationship was over.
I really didn’t see it coming. We have been working together for a long time now.
Really? Really, I said. You no longer need QA?
She went on to explain that as her team has gotten better and better at building software, the whole team has taken more ownership of quality. They are on a pretty consistent cadence now and have working tested software ready to ship every two weeks…which is just about the time it used to take to just get through a QA testing cycle. “We are just moving way too fast for that nowadays” she said.
At first I was incredulous. Everyone needs quality assurance! QA is an essential role! You can’t just pump out code and hope it is good enough. The customers would crucify us for that. At first, I thought what she was saying was ridiculous, but the more she explained it, the more it started to make sense. Her team had started Test Driving development a couple of years ago and now they have really high levels of confidence in the entire codebase. “It’s a team quality thing” she said.
I knew this team was good. The code is both Clean and SOLID.
Their quality metrics are on par with any other team. They consistently produce 90% automated test code coverage, including code branches. Code reviews made sure that everything was covered, and they had automated jobs that broke whenever they decreased that coverage. Ultimately, they have virtually no defects that get into Production; some of the best code there is. They also have automated acceptance tests, UI tests and load and performance tests. They have pretty much automated the entire testing pyramid.
Test Driven Development (TDD) was just the start though. Soon after the programmers were test driving, the QA folks started automating UI tests in Selenium. To learn how, they had been pairing with programmers and their relationships in the team were the best of any of my QA teams. After that, they started using CucumberJVM to build behavior tests with the Business Analysts and the Product Owners. The pace of development with this team was better than any other team and I had pretty much let the team run on autopilot because they never seemed to have the same kind of problems
the other teams have.
“We no longer have a QA verified cycle” she said. “We have renamed it to ‘Team Verified, because the whole team does testing before we demo it”. She went on. “We’ve also taken ownership of exploratory testing. The whole team does exploratory testing every week and this has really been a place where the QA folks have been a big help.”
“So you do need us” I said. “Oh yes” she said, “your people are great, but let me explain. We still want all the quality experts we can get. As long as they are committed to the team, are committed to continuing their learning, and stay with the team every day”.
She looked right at me and said, “What we don’t need is all the management oversight we used to have”.
I was beginning to understand. I realized that she still wanted quality. In fact, she was more dedicated to quality than just about any other team in the organization and we are a huge organization. She was advocating for a level of quality the other teams could only hope to duplicate.
She went on to say, “we’d like to keep some of your team members if we can”. “What do you mean?” I said. She went on…”Most of your team members have embraced the changes we have introduced. They love test automation, learning and the collaborative nature of how we produce quality now. And those folks have a place on our team.” She went on, “The QA folks really took a leadership role with exploratory testing. We want to keep them because they see things differently. They look for anomalies and edge cases and they really help the team round out all the aspects of testing that we need.”
Granted, this team has really taken agile adoption and self-organization seriously. They really epitomize teamwork. They do not behave like an assembly line, passing work from one role to another. They’ve eliminated a lot of the limitations of specific roles in the team room through organized cross-training and pairing. For just about any task, most anyone can pair with someone if not complete the task themselves outright.
“But we move fast now, as a team” she said. “And I guess what I’m saying, is that we want to keep your folks on the team and…well, there’s still a lot more that I can go into, but the short answer is…We just don’t need a QA Lead anymore.”
I was crestfallen. The breakup wasn’t painful from her perspective. The pain was all in my head. It was just a matter of my realization that self-organizing teams don’t need as much management as a traditional team. The whole team owns quality now, and, I suppose, in the long run, that’s going to turn out to be a really good thing.
Comments (10)
Garry
Great post. I like the way the QA members became an integral part of the team. In many places I have worked, QA was always seen as an outside influence that got handed code when the devs where finished with it. Over the fence as they say. QA members should be part of the team building the software as you say, they find the edge cases and other things that the dev team can sometimes overlook.
Tom Churchwell
I’m glad you liked it Garry. The integration of the QA folks into the team didn’t happen overnight, but was essential both for the whole team, and also for the continuing growth of the QA folks themselves. Moving quality left….a way of saying to get QA involved WAY sooner in the game…was/is really the way every team needs to be working. QA folks have essential skills, and the sooner they get involved and collaborating, the better.
Rupert Schmidtberg
Great article Tom. So many teams think they are being agile because they have a backlog and are doing Scrum or Kanban. Your article reinforces how important self organizing teams, strong technical practices and supporting infrastructure are to attaining high performance. Thanks for sharing.
Tom Churchwell
Thanks Rupert
I agree. Agility is more a skill than any of the rituals. Don’t get me wrong, teams have to start somewhere, but you are correct, the bar needs to be set around self-organization, working tested software and a total environment that supports the work of the team.
Kevin
Thanks for sharing your experience!
I agree: “We just don’t need a QA Lead anymore.”
=> QA team, QA lead, QA manager whatever if they slow things down and increase bureaucracy, instead of praying Agility God, removing them is a good way to go.
I agree: “We no longer have a QA verified cycle.”
=> Testing should be shift-left, tester as well. I see testing before integration is way better than verification & validation (aka. time wasting).
I don’t agree: “They have pretty much automated the entire testing pyramid” ….”They consistently produce 90% automated test code coverage”
=> Testing pyramid is a good model but it could misguide people focusing on number (coverage, fail/pass) and missing the real risk. Programmed checking only works well for “known area”, but not for “unknown” area. Full test coverage isn’t equal to quality is assured, never.
I don’t agree: “QA == Quality Assurance…”
=> At least for me, I’m doing QA == Quality Assistance
Thanks for reading and replying Kevin-
Their testing was most certainly a “shift-left” testsing orientation. Thanks for amplifying that.
Also, I see what you are saying about full test coverage not equalling quality assured. The testing pyramid is just a small part of the constellation of practices and tools that team used/uses to assure quality and even prevent more than detect quality issues. My intent was not to minimize that whole constellation of practices.
Also, QA==Quality Assurance. I like your Quality Assistance posture. Words matter and that term reflects a better orientation around the relationship in the teams.
Thanks for your feedback.
:-)
tc
Imran
Impressive…..most impressive!
Tom Churchwell
They were/are a great team. I say were, because I don’t work with them anymore, but the same folks are still on that team and it is still kicking butt.
Dan
LOL!! So many misconceptions about software testing in one blog post…. My head is about to explode at how silly all of this is!
Some friendly advice: Checking known expectations through automated assertions is just one part of testing. It’s not ALL of testing. I suggest you learn about the bigger part of testing, which is all about investigating unknowns and uncovering information about the software / the design / the idea of the software / etc.
I agree that the full team share responsibilities regarding quality – that message is true, but there are so many testing activities, and some require vastly different skills than others. You need to get out of the ‘automate it all’ misconception quickly if you want your products to be successful.
Tom Churchwell
HI Dan-
Thanks for your reply.
I appreciate you sincerity.
I hope you are able to achieve the same year after year successful launch of new product after new product, on-time, under budget, defect-free. They are truly remarkable, but you are correct….it is a journey game….we all have more to learn.
:-)