In fact, not only do we still love the testers, we love them even more in our new Scrum world! I really feel that this is an important point to emphasize, and I’ll tell you why.
I remember when I was excitedly presenting Scrum 101 concepts to my first soon-to-be Scrum team. I was sure everyone was going to pick up on my infectious enthusiasm, and indeed I gleaned a whole bunch of decisive nods and smiles. However, when I looked more closely, I started to also observe some noticeable fidgeting and darting eyes (synonymous with discomfort and fear) among a few of the testers. To understand this discomfort, we need to look into the past and briefly explore what has happened to the testing function in recent times.
Waterfall friendship
Thanks in large part to the earlier adoption of the traditional waterfall model, a more profound appreciation for the testing function began to take hold. Within many organizations, a strong, independent testing team that stood on more of an equal footing with the programming team was becoming the norm. Testing standards were developed, professional development paths purely for testers were established, and the test team “owned” a whole phase of the cascading waterfall process.
Then along comes Scrum (and its other agile cousins), and all of a sudden, life changes. Testing becomes the responsibility of everyone on the team, unit testing becomes a programmer-centric practice, and even functional tests can be automated by programmers. Suddenly the question starts creeping into worried minds: How and where do the testers fit in? Before going on, and to avoid any undue panic for readers at this stage, I will cut straight to the chase and state that the tester has never been so important. Lisa Crispin and Janet Gregory, authors of Agile Testing, emphasize that the whole-team approach is one of the biggest differences between agile development and traditional development. Some testers recognize this difference and are immediately relieved and excited by Scrum, and others remain fearful of the new world order.
Change is in the air
Change is scary. Crispin and Gregory offer some important insight into why the transition to agile development can be particularly worrisome for some testers.
They contend that “Loss of Identity Fear” is at the heart of a tester’s concerns and below is a selection of these specific fears:
- Fear that they will lose their QA identity
- Fear that they lack the skills to work in an agile team and will lose their jobs
- Fear that when they’re dispersed into development teams they won’t get the support they need
– By Lisa Crispin & Janet Gregory from Agile Testing – A Practical Guide for Testers and Agile Teams
As I will explain, when working in a genuine Scrum environment, none of these fears are justified. Yes, there is an identity shift; however, all of the worthy testers I have worked with have either immediately or eventually embraced their enhanced identity with open arms.
When change occurs, it is a natural instinct to romanticize the past, clinging to anything that was warm and fuzzy rather than remembering the darker, negative times. Testers shouldn’t forget that life certainly wasn’t a walk in the park in the old days (even if there were pretty waterfalls along the way). An image that I have etched into my memory is that of the frazzled, worn-out testers at the end of a waterfall project.
“Traditional test teams are accustomed to fast and furious testing at the end of a project… in agile projects, you are encouraged to work at a sustainable pace.”
– By Lisa Crispin & Janet Gregory from Agile Testing – A Practical Guide for Testers and Agile Teams
New identities
How do we help testers embrace their role in the new world where the waterfalls have dried up?
Let’s first address the elephant in the room: the fear of being made functionally redundant. Fundamentally, the testers should feel safe because they are different. They possess a unique skill set and a way of thinking that is critical to the success of any software project. I like to use the description offered by Nick Jenkins in “A Software Testing Primer” to help illustrate this point:
There is a particular philosophy that accompanies “good testing.” A professional tester approaches a product with the attitude that the product is already broken — it has defects and it is their job to discover them…. Developers approach software with an optimism based on the assumption that the changes they make are the correct solution to a particular problem…. By taking a skeptical approach, the tester offers a balance. They seek to illuminate the darker part of the projects with the light of inquiry.
– by Nick Jenkins from A Software Testing Primer
In a nutshell, testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think.
Now that we’ve got that big concern out of the way, let’s explore some of the exciting new subidentities that a Scrum tester can assume that are clearly above and beyond the mind-numbing, repetitive manual testing that previously played such a disproportionately large part in a tester’s life.
Tester as a consultant
Testers are specialists at their craft, and as such, they are in a unique position to help guide nontesters to improve their testing game. With Scrum’s focus on delivering quality working software on a regular basis, this has never been so important. For starters, the tester can (and should) act as a sounding board for the programmers as they start to get their heads around test-driven development.
Also, while pair programming is certainly a powerful Extreme Programming (XP) technique (that is sometimes adopted by Scrum teams), I feel that “pair testing” (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer. It also fosters further appreciation for one another’s skills and abilities.
Consulting to the user-experience designers can also be of significant benefit by helping to anticipate potential issues associated with the more complex workflows.
Finally, the product owner can no doubt leverage the tester’s inherent understanding of the core acceptance criteria by assisting in various intra-sprint walk-throughs and helping with the final verification of the done user stories.
Tester as a designer
I believe that the core skill of a tester is actually that of design. Irrespective of who actually runs or implements a test, a seasoned professional tester will always be able to design the most effective test cases compared to anyone else on the team.
Well-designed tests not only form the foundation for the eventual testing itself but can also provide vital input into the technical design that takes place during sprint planning. When a tester is involved in the design of a user story’s test cases prior to the sprint planning session, I can assure you that the meeting will be a great deal smoother and faster with fewer contentious debates. For those concerned that this advice is slipping into the realm of waterfalling sprints, I support Mike Cohn’s thoughts:
Being part of the team on this (current) sprint and spending some time looking ahead is not the same as working a sprint ahead of the team… their top priority is delivering whatever is committed for the current sprint. Beyond that, their job is to look ahead in exactly the same way everyone expects a product owner to be looking ahead.
– By Mike Cohn from Succeeding with Agile – Software Development Using Scrum
The tester as an explorer
Test automation is integral to the success of Scrum. However, even with extremely thorough test automation in place, there will always be the need for manual exploratory testing that no level of automation is able to replicate. This element of testing is without doubt more art than science, and for those under the false impression that exploratory testing is just another name for gorilla or ad hoc testing, the following commentary by Crispin and Gregory will give you a new appreciation for the subtlety of this function:
With exploratory testing, each tester has a different approach to a problem, and has a unique style of working. However, there are certain attributes that make for a good exploratory tester.
A good tester:
- Is systematic, but pursues “smells” (anomalies, pieces that aren’t consistent)
- Learns to recognize problems through the use of Oracles (principle or mechanism by which we recognize a problem)
- Chooses a theme or role or mission statement to focus testing
- Time-boxes sessions and side trips
- Thinks about what the expert or novice user would do
- Explores together with domain experts
- Checks out similar or competitive applications
– By Lisa Crispin & Janet Gregory from Agile Testing – A Practical Guide for Testers and Agile Teams
A new beginning
In a Scrum team, everyone is responsible for testing. Quality is no longer an afterthought, and testing should become an inherent part of every stage of the user story development, including before a single line of functional code is written.
The transition to Scrum should feel like an exciting rebirth for the tester. Removing the manual testing shackles offers Scrum testers an opportunity to focus on what they do best: design, consulting, and exploratory testing. They are finally given an opportunity to flex their unique skill set in far more interesting ways than before.
If you liked this article, you can:
Subscribe to this RSS feed!
Find out more about testing in Scrum by taking one of our CSM training courses.
No need to say much more. I prefer being the single tester in scrum teams, and I just love it. Challenging, welcoming and whole lots of fun.
Great post!
Lots to like in this post, though I’d take it further and suggest that this type of sapient tester is needed in both agile and in waterfall. Anyone *not* performing this type of testing is performing the task of a glorified clerk.
In waterfall there is this old and misleading idea that testing is about following a process that is repeatable and reproducible. This is not true, testing is a verb, its an activity, its not about artifacts and counting test cases.
many thanks for helping spread the message 🙂
Anne-Marie
Note: if your readers want to research more on this type of testing, there’s lots of great stuff at http://satisfice.com (James Bach) & http://kaner.com (CemKaner). These testers are the original thinkers for much of the ideas you refer to.
Hi Anne-Marie – I totally agree. I feel that the need becomes even stronger in Scrum due to the lack of a so-called regression testing ‘phase’ typically evident on waterfall projects.
Thanks also for the references!
The article is really a good one and I can connect to it very well. I am a professional tester since past 5 years (first 3 years in waterfall and 2 years in Agile Scrum). My only concern is that QA efforts in Scrum process are not as “transparent and visible” as it was in the water fall method. In the waterfall when I see a bug, I immediately put it into “Bug-tracking” database and my effort was easily “recognized” and the whole process was very transparent. But now, at the end of all the day, it is really difficult to distinguish between a “tester who has done effective job” and a “tester who has not done”. I agree that it is the Manager’s duty to see all these stuff, but when people are across the globe, the work is cross-functional etc, it would be even difficult for them to identify the good testers. I would be very happy to see good ideas on it?
Thanks for your thoughts Babu. I would say that that the best indicator of whether a tester is doing their job well is the quality of the software being released and the value they delivering to the team. Both are easy to measure.
@ Ilan Goldstein –
I am trying to figure out the same issue. How the individual contribution is measured ? in waterfall its easy, in scrum ummm i am not sure.
You said ” “best indicator of whether a tester is doing their job well is the quality of the software being released ”
but when multiple testers are working in scrum , some doing thier job great and some not then how would it be identified?
why we cant use quality metrics in scrum model, where we can see if quality is improving on not sprint by sprint