I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.
What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.
For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.
I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.
As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!
You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”
OK, allow me to elaborate…
For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.
It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.
It means that you embrace change; you collaborate well with your team members as well as those outside the team.
It means you know how to help other folks on the team automate tests and help drive exploratory testing.
It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.
It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.
It means you guide other folks on the team, helping them improve upon their testing knowledge.
It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.
It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.
It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.
It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.
It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.
It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.
It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.
It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.
It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.
In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.
It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.
It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.
And yes, it means you actually run tests too, whether they’re automated or manual.
Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.
If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?
