Is your team struggling with getting your QA and developers to work together in an agile/DevOps environment? My guess is that it’s a struggle.
Part of the problem, often, is agile development itself. While agile methods are not new, agile continues to be a disruptor. What is new is that more and more large enterprises are starting to implement agile and DevOps practices. And to larger enterprise teams, these changes significantly disrupt the ways they develop and test software.
One team, working together
There’s a lot of confusion and misunderstanding around what a tester’s role is in an agile environment. The company I work for began to make the shift to agile practices almost three years ago, yet the teams I work with still struggle to find the right balance between developers and QA.
The power of agile is that it breaks down the walls or silos that most teams used to have to accept in a waterfall development environment. Removing this separation between testers and developers forces teams to work together in the same sprint and in the same iteration.
Testers should be technically aware
This concept of working together—as opposed to having separate development and QA teams—can cause confusion when a company begins making the move from waterfall to agile practices. There are many reasons for this, but a common one is that it's hard to find technically aware testers that can work effectively in an agile team.
The power of agile is that it breaks down the walls or silos that most teams used to have to accept.
“Technically aware” is a phrase I’ve heard from Lisa Crispin and Janet Gregory, co-authors of the books Agile Testing and More Agile Testing. So what does being technically aware really mean?
In More Agile Testing, the authors describe technical awareness as covering both the technical skills needed for testing and communication with other members of a development team.
Testers need to be technically aware, and that will mean different things to different teams.
If your team really understands the whole-team approach—everyone working toward the same goal—then testers and developers can share the task of, for example, coding an automated test. A technically aware tester can also collaborate with the programmer (whose life is programming and who is really good at it); and if your tests are written in the same language your developers use, it will help your testers collaborate more effectively with your developers.
It’s a challenge to find people who are great exploratory testers and at the same time have the technical awareness necessary to be able to collaborate.
If testers can’t articulate these types of things, it makes it difficult for them to, for example, approach their managers and tell them why something can or cannot be automated. Or why an approach the development team is taking is not the best option.
Lisa Crispin: Group-hug testing
I began thinking more about this after I interviewed Crispin for the Group Hug Testing TestTalks episode. She mentioned that it’s quite difficult to find testers with the right kind of attitude and mindset to work on an agile team. It really does take a mindset shift for testers if they've previously worked in more traditional development environments.
And because most companies have a hard time finding testers with the right skills, most Scrum teams have to shift the testing to their developers.
I conduct most of the phone screening interviews of testers looking for positions at my firm. And I can assure you it’s a challenge to find people who are great exploratory testers and at the same time have the technical awareness necessary to be able to collaborate easily with the technical team members.
What to do about it? Try pairing
One tip Crispin offers is to use your technically aware testers to train the developers to build relationships and to transfer those good testing skills.
Testers can’t possibly test every single story, so they test charters at the feature or epic level. That means that they’re testing more layers and will probably find issues they couldn’t find by focusing on one story.
She suggests pairing testers with the developers so testers can learn to write production code while at the same time teaching developers how to write testing charters. Teach them exploratory testing, she says. Make sure they’re covering adequate test cases with their automated tests, she insists; and help them with things such as driving development with customer-facing tests and doing behavior-driven development.
That’s the route Crispin’s team is taking. They do test-driven development, or else they’re doing behavior-driven development. They’re writing Cucumber tests to capture the more end-to-end scenarios, and they do exploratory testing on that story before they call it finished. Naturally, the testers, who can’t possibly test every single story, then do testing charters at the feature or epic level. That means that they’re testing more layers and will probably find issues they couldn’t find by focusing on one story.
This practice of testers and developers pairing together also fosters more of the one-team mentality that successful agile implementation requires.
Mob testing
Mob testing is another technique for creating a one-team environment. Mob testing is like pair programming, but instead of pairing a tester with a developer, you have a group of developers and testers working in sessions that you time box, and you rotate everyone’s role periodically.
For example, a mob-testing session would have someone at the keyboard driving, somebody else serving as the navigator, and the rest contributing however they see fit. Every five or ten minutes, you switch roles for everyone in the group so that everyone gets to contribute.
You can apply this to testing, too. You can do testing with a group of people. Crispin described mob testing as a great way to help people get experience transferring skills between all team members. Of course, these methods assume that your developers will contribute to the testing effort.
The objection I hear from many people comes in the form of a question: Can developers even test?
Trusting your developers to test
I know that other well-respected testers, such as Alan Page of Microsoft, believe that developers can learn to test. He feels that his developers are actually writing pretty good tests. As a very technically aware leader, he sees his job from an end-to-end perspective, recognizing the need to know where the holes are and ensuring that his team is approaching engineering such that quality software is the result. Ideally, the team builds something that's fun and useful for customers.
Agile evolution
Practices such as pair programming and mob testing are a couple of the ways in which you can start right now to bring your team’s developers and testers closer together. In my experience, one of the main issues with dysfunctional mixed dev/QA Scrum teams is a lack of communication.
These methods should help encourage more collaboration between testers and developers, which should lead to better communication. And I believe better communication is the foundation of getting QA and developers to work together.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
