This is a guest blog by Zephyr, a Valiantys partner offering real-time solutions designed to transform how development and QA teams of all sizes work and collaborate, helping them release higher quality software on time. In this blog, we take a look at what it takes to be a successful software tester in an increasingly agile ecosystem.
The agile development process has transformed the way teams fit together. The physical walls came down, most of the cubicle walls came down, and development teams are now shipping software that works every few weeks, instead of once or twice per year.
So how does this change things for testers?
Getting technical
You don’t have to learn how to write production code, use SQL, or work your way through a Linux server to be a great agile tester, but it certainly won’t hurt.
One big focus for agile is scope control. This means that rather than waiting for the first testable build weeks after starting a new release cycle, we might get something to test the next day. That thing might be in the shape of an Application Programming Interface (API) or web service, rather than a fully fleshed out piece of software.
Technical knowledge helps us to test software earlier and with different strategies that dig underneath the user interface. A person with developed testing skills and a little technical know-how will make a powerful addition to any team as an agile tester, and there are plenty of ways to do this without becoming a programmer.
Coping with change
Things change quickly in software. On agile project teams, focus can pivot in the middle of a sprint without much warning. One minute we are developing a new feature, and the next, we’re redesigning that same feature based on customer feedback.
This sort of rapid change can be difficult for anyone to handle – especially when coming from slower moving waterfall projects where you work from an explicit, fixed specification.
It is helpful to separate your personal identity from the work you produce. Developing the skill of asking the right questions about how to achieve what the customer wants before commencing coding can go a long way towards reducing change mid-project.
Pairing
When two developers work together, far fewer simple bugs — buffer overflows and handling null — end up making it into a build. Pair testing between a developer and a tester specialist can help you find and fix both common and more complex problems.
Lightweight communication
In agile contexts, there is no time for the traditional means of test work documentation like detailed test plans and test cases. While testers are tied up writing documents, a build with new software to test might be waiting in the test system for review.
Faster, simpler documentation like mind maps can work better for documenting and sharing test ideas. Plain old conversation works great, too. In open plan offices, this might be the first and best choice. Sometimes, we can walk over to a developer, demonstrate a bug, and get it fixed on the spot rather than spending time researching and documenting it in a tracking system.
Open team communication can save days that would would otherwise be spent pouring over documentation, triage, and waiting for build after build. Problems that can’t be fixed right away can be put in the bug tracking system to be dealt with later.
Agile changes a lot when it comes to the pace of development and how we work with teams, but we are still fundamentally software testers. Focus on these skills, along with the testing essentials like critical thinking, modelling and observation, and you will make you a powerful addition to any team as an agile tester.
