With the rise of Agile development, testers need to be prepared to perform a variety of testing activities - both traditional activities and some new, potentially unfamiliar ones. The general expectation is that these activities will be performed in less time, with even less structured requirements. If you're already a context-driven tester, this won't come as too much of a shock to you. If you come from a more traditional testing background, this could be a pretty sizeable change for you to grasp.
In the Agile world, all roles and contributors within the team are considered equal. That is, all are equally required for the team to be successful - there is no "rockstar". And from time-to-time, each and every member of the team WILL be called upon to perform actions outside of their standard responsibilities. I believe for some people, this is a scary concept. A classical developer is as likely to respond with "I'm expected to test?" as a classical tester is with "I'll have to develop things?". My answer to any of you with these questions is "yes". And I don't want you to simply grasp this concept - I want you to embrace it.
If you want to be a successful tester on an Agile team: you're going to need a bigger hat rack.There, I said it. Now let me explain why.
Throughout my early years in testing, I understood that as I grew, I would learn about more hats to include in my theoretical "hat rack" of testing skills. I began honing my functional, blackbox testing skills. I would follow test plans and test steps, keeping a keen eye out for things that were unexpected. Then I developed skills in performing the test planning - learning how to functionally decompose a feature and figure out how to test it against its expected behaviour (as provided by the dev team via the project manager). As I gained more credibility within my test team, I was able to work closer to the dev team and hone some whitebox testing skills, where I could see what the code was doing and test accordingly. This all happened throughout the course of a few years working with the same testing team.
Eventually I switched companies and joined an Agile test team. Within the first year, on any given work day, I could be expected to do any of the following:
- Work with a developer and/or designer to talk about how a feature could potentially be tested when it was finished development
- Functionally test a new feature
- Accessibility test a new feature
- Usability test a new feature
- Performance test a new feature
- Security test a new feature
- Perform full system regression testing for all of the above
- Gather statistics from internal and external sources and analyze data (for the purposes of improving testing focus)
- Write code to support the test automation framework
- Write automated test scripts
- Develop test tools & scripts to assist testers wherever possible
- Mentor team members (testers and non-testers) in improved testing techniques
- Contribute to overall test strategies for Agile teams
- And so much more...
Of course, not everyone has to do all of these things. But the opportunities for a purely functional, blackbox tester are diminishing. In Agile, they're virtually non-existent. As I said:
You're going to need a bigger hat rack.
We see Agile testing often go hand-in-hand with context driven testing. In context driven, you are the test planner AND the test executor. You are given a handful of requirements and expected to determine if they are met. You are also expected to advocate for the customer. Question when things don't feel right. And you have to do this all with limited time, using the most effective method. Is one exploratory pass good enough? Should this be automated and added to the regression suite? HOW should this be automated? Where does this fall within our testing priorities?
Hopefully you are prepared for this. It's a new and exciting world, where testers are being handed more responsibility than ever before. Testing is definitely not becoming obsolete - but bad testing is. And with that comes the need to constantly learn new things, continuously improve and find new and creative ways to contribute to the Agile team and keep quality improving. Just as programmers must continue to learn and keep up with the latest technologies and languages, testers must continue to learn new practices, new ways of thinking, and keep collecting those hats.
