Making the switch to Agile requires laying the groundwork around education, documentation, and metrics.
Agile development and testing is not a methodology – it’s a mindset. According to a VersionOne survey, 88 percent of businesses are practicing agile development, but many are struggling with the transformation, with failures generally attributed to “culture and resistance to change.”
If you fail to transition testers to the correct mindset before trying to tackle the process changes, then you’re setting your team up for failure.
The adoption of agile techniques has traditionally been assigned to developers, but agile testing is a vital component of the process and deserves its fair share of attention. The challenge is that traditional methods of testing do not comfortably fit with agile methodologies.
If your team is thinking about making the switch to Agile or you are a tester struggling with the transition, you may need to broaden the focus from an agile methodology to an agile mindset.
So what exactly does that mean to your team?
Read more Agile testing articles here => Agile Testing and Scrum Guide
What You Will Learn:
4 Steps Towards Developing The Agile Testing Mindset
Step #1) Education, Education, Education!
If you want your testers to embrace an agile mindset, then it all starts with education.
- Testers must educate themselves about what agile processes are going to entail. What will the new workflow be? What will be expected of them in their new role?
- The testing group needs to have a voice in the business. They must be empowered to educate management or the agile steering group. It’s important that they contribute to the adoption of agile and feel that their own requirements are being considered. This will secure buy-in at all levels.
- Testers must be proactive in educating themselves about each project. They must be informed and included from the outset of a new project; they must understand the business value and work to understand the needs of the end-user.
Step #2) Balancing Documentation
The traditional reliance on documentation is a habit that must be broken and the expectations surrounding its creation must be reset. Relying on requirements documents that were written before any development has started is no longer going to work.
Agile is all about adapting to a user feedback loop that hones the final product in iterations as you go along, and it’s a fluid process. That means any documentation you do rely on must be kept up to date as development and design evolves.
An Agile testing mindset means avoid bogging testers down in red tape and bureaucracy. The more time testers spend doing menial tasks like documenting test cases, the less time they have to do value-added activities like finding defects. Automatic script generation for regression testing that organically grows out of exploratory testing sessions is one clever shortcut you can take.
What’s required in an agile environment is smart documentation. There needs to be an acceptance that not everything can be documented and a focus on what’s genuinely needed to keep the processes going.
Striking a balance between documenting enough to allow for future knowledge transfer while keeping unnecessary work to a minimum can be one of the trickiest parts of implementing an agile process.
Recommended Reading => How to Test Smarter with less documentation
Step #3) Realigning Your Metrics
Perhaps the biggest attitude adjustment that’s required for a successful transition to agile testing comes when trying to replace the traditional testing mindset towards metrics. QA teams and Testers are used to metrics that track the completion of testing activities and the creation of defects.
Those metrics do not align with the value-added nature of agile development. This list of “Don’ts” might make testers accustomed to traditional metrics shudder, but it will drive the team to think of metrics that are aligned with the success of the business:
- Don’t focus on the overall defect count. The number of defects that a tester finds is not an adequate measure of their effectiveness. Focusing on quantity over quality is a mistake. If testers feel pressured to hit numbers then they are more likely to throw questionable defects over the wall. Feature requests, design gaps, and unclear requirements are not defects.
- Don’t focus on the number of test scripts executed each day. Each test is not created equal. The number is misleading and the focus should be on delivering quality.
- Don’t focus on overall pass rates for scripts. Whether individual test scripts ran without incident doesn’t tell you about how the product feels to use, or whether it is meeting end-user expectations. In the end, the tester is the greatest advocate for the end-user and should be concerned with keeping them happy.
The focus should shift to the satisfaction of the end-user and a way from activity tracking. If everyone in the company is aiming to deliver the best product for the customer and listening to their feedback, then success will naturally follow.
Step #4) Changing Attitudes
A willingness to communicate and collaborate is paramount to the success of agile. In the past, QA departments have often been able to succeed as an isolated unit – they would position themselves as gatekeepers of the product, feeling as though they work in opposition to developers.
That era is over – it’s time to bring testers into the fold. Educate them, empower them, and they will deliver much greater business value.
This is a two-way street. Empowering testers from the top down and taking responsibility for their development from the bottom up. It’s about aligning goals across your company so that every department and every member of your staff is pulling the team in the same direction.
Everyone must be focused on creating the best experience possible for the end-user.
About the Author: Kevin Dunne is a product specialist for QASymphony, a leading provider of test management platforms for agile development teams. He was previously a Business Technology Analyst for Deloitte in Atlanta. You may contact him at kevindunne@qasymphony.com
Are you facing any challenges adopting an Agile mindset? Let us know in comments about your experience and queries.
“The focus should shift to the satisfaction of the end user and away from activity tracking. ”
this is awesome.
What about fifth step? :)
ha ha. good catch Alexandr. btw, 4 are sufficient to get started ;-)
good eye opening for teams who want to transition to agile
this one is also good
“Everyone must be focused on creating the best experience possible for the end user.”
Brief and clear steps, thanks
Good article and very true – especially changing the mindset of the team before starting to practice the Agile process.
Yes i am agree with your all of the steps but i have some concerns as follows if you would like to answer:-
1. As Every Testing professional says A tester must be involved into picture from very beginning but it doesn’t happen generally.
–What we can do to implement such sort of environment
and what if someone leaves organization in between and someone new joins in between.
You agree or not during KT never whole knowledge can be transferred.(we must have to keep preparing organized documents?)
2. Changing someone attitude is not as easy as we think. A Testing Board should come into picture and should set some standards or educating people by websites is bit difficult as everyone does not prefer sites
Thanks,
Reegan,
Thanks for giving the article a read.
In regards to your questions, I would offer the following advice:
1. I agree, Knowledge Transfer (KT) would not always be complete, but the idea would be to integrate KT with other processes you are doing. Rather than dedicating time to KT only after sprints or when key personnel are leaving, you would try to integrate it along the way, in methods similar to how James Bach outlines in his debriefs for Session Based testing (http://www.satisfice.com/sbtm/debrief_checklist.htm)
2. Agreed – I think there are many other resources you can use beyond websites as well, and the goal is to have everyone leverage a learning style that works for them. Many testing consultants will come on site and teach to groups, there are also many local meetups (meetup.com) for testers, and conferences to attend to learn from thought leaders and other testers. Please feel free to reach out to me directly if you would like some more specific recommendations – kevindunne@qasymphony.com
Best,
Kevin
With the developers and testers responsible for fleshing out the acceptance criteria with the product owner, I can’t see a need for a business analyst. We currently work with a BA and the role certainly seems redundant and dare I say, detrimental to our projects. Our BA is without a doubt the least knowledgeable in the team on system and domain.
In our team, the developers and QA almost always know between them what the system does. The product owner understands the domain and customer requirements and together we are able to hammer our acceptance criteria.
We all feel that the BA role is redundant, or worse, destructive in our team. In the way that a child that wants to participate in a conversation between understanding adults. It feels like we have to slow down, explain and mentor the BA to come up to speed to agree with us (after many a painful conversation)
Is there a role for a BA in this anymore? I could understand perhaps if the product owner delegated some of their responsibility. I could understand if the BA was a domain or system expert. I could understand if this was meant to pool in to a long standing project to manage the documentation. I could understand if the BA used their time to research answers dev,QA and the product owner could not get.
Sir,I am confuse in the agile testing…so simple meaning of agile & exampl…plz
@Bill Winters: I am agree with you. because of that we mixed up BA and QA roles in our company, It’s better and tester can participate in all KT sessions and give better ideas.