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.
Agile Disruption
Agile itself is not new, but what is new is that more and more large enterprise companies are starting to implement Agile and DevOps practices. To larger enterprise teams, these changes are significantly disrupting the way in which they develop and test software.
There’s a lot of confusion and misunderstanding around what a tester’s role is in an Agile environment. I know that 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 with finding the right balance between Developers and QA.
One Team Working Together
The power of Agile is that it breaks down the walls or silos that most teams used to work in within a waterfall development environment. Removing this separation between testers and developers forces team to work together now in the same sprint developing and testing, and in the same iteration.
This concept of working together rather than having separate development and QA teams can cause confusion when a firm begins making the move from waterfall to Agile practices.
There are many reasons for this, but a common one that most teams struggle with is finding technically aware testers that can work effectively in an Agile team.
Testers should be Technically Aware
The phrase “technically aware” is a common one I’ve heard from Lisa 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, Lisa and Janet describe technical awareness as something that covers the ideas of technical skills needed for testing and communicating 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 of everyone working toward the same goal, then testers and developers can share the task like job the coding of an automated test, for example. 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 to collaborate more effectively with your developers.
If testers can’t articulate these types of things, it makes it difficult for them to, say, 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 Lisa Crispin for the Group Hug Testing TestTalks episode.
I agree with Lisa, who 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 accustomed to working in more traditional development environments.
Furthermore, the fact that most companies have a hard time finding testers with the right skills forces most scrum teams to shift the testing to their developers.
I also conduct most of the phone screening interviews of testers looking for positions at my firm, and I can vouch for the fact that it’s a challenge to find the people who are great exploratory testers, yet 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 Lisa offers to bring your team together is to use your technically aware testers to train the developers to build relationships and to transfer those good testing skills.
Lisa suggests pairing with the developers to write production code while at the same time teaching them how to write testing charters. Teaching them exploratory testing. Making sure they’re covering adequate test cases with their automated tests. Helping them with things like driving development with customer-facing tests like behavior-driven development, etc.
That’s the route Lisa’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. They do those, and they do exploratory testing on that story before they call it finished.
What follows then is that the testers, who can’t possibly test every single story, 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
Another technique to create a one team environment is mob testing. Mob Testing is like pair programming but instead of just paring a tester with a developer you have a group of developers and testers working in sessions that you time box and rotate everyone’s role periodically.
For example a mob testing session would have someone at the keyboard driving, somebody’s the navigator, and then the rest of the people are just contributing however they see fit. Then you switch every five or ten minutes everyone in the group’s role so that everyone gets to contribute.
You can apply this to testing too. You can do testing with a group of people. Lisa mentioned that she found Mob Testing to be a great way to help people get experience transfer skills between all team members.
As I mentioned that of course these methods assume that your developers will contribute to the testing effort. The objection I hear from many people is that can developers even test?
But can you trust your developers to test?
I know that other well respected testers like Alan Page of Microsoft believe that they can. When I interviewed him, he mentioned that he feels his developers are actually writing pretty good tests. Since he is very technically aware, though, he sees his job in more of an end-to-end perspective; recognizing the need to know where the holes are and ensuring that his team is approaching engineering in the proper way in order to make quality software — and hopefully build something that's fun and usable for customers.
Agile Evolution
In my experience, one of the main issues with dysfunctional mixed Dev/QA scrum teams is a lack of communication. Using methods like Pair programming and Mob testing should begin to 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.
Using practices like 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.
