What automation skills do you think are most important for Agile testers?
In my experience, the most essential skills a tester needs to succeed with test automation are collaboration and communication skills. If you are working within a software development organization where there are programmers writing well-designed production code, those programmers are the right people to write the automated test code. Testers know the right things to test. A tester-programmer pair can decide together which tests should be automated, and how. They should at least start this process before coding begins, so that the programmer can design the code in a way that will make it easier to code automated tests.
There are many test frameworks that promote this tester-programmer collaboration. For example, my own team uses FitNesse for tests at the API level, behind the GUI. For each user story that can be tested at this level, a tester gets together with a programmer working on the story to discuss the test design, and possibly write the first simple test. The programmer writes the fixture which will take test inputs, pass it to production code which will operate on it, and return the results to compare to expected results. The tester can write multiple test cases with different inputs and expected outputs. We follow a similar process automating GUI tests with Selenium 2.0 and Webdriver. The programmers write page objects for the various GUI pages in Groovy using a Geb framework, and testers can write multiple test cases using the page objects. This collaboration helps ensure properly designed test code, which is maintainable for the long term and provides a good return on investment.
The programmers on my team feel most comfortable talking to someone who “speaks their language,” who has some technical knowledge, who uses the same or similar integrated development environment (IDE) as they do, who has a basic grasp of object-oriented concepts. If you’re a tester without much programming experience, start familiarizing yourself with some basic concepts. A book such as Everyday Scripting with Ruby: For Teams, Testers and You (Brian Marick, 2006) provides examples you can work through to develop familiarity with object-oriented concepts, and programming terminology, even if your team doesn’t use Ruby. For some introductory object-oriented design knowledge, check out “Keep it Dry, Shy, and Tell the Other Guy” by Dave Thomas and Andy Hunt. Ask a programmer to help you install the IDE she uses, and help you create a project where you can check out your team’s production and test code
If you don’t have any access to programmers – perhaps you work for a testing outsourcing company – the resources in the above paragraph will get you started with skills you need to design your own automation. If you can’t pair with a programmer, pair with other testers on your team to learn together.
Dig Deeper on Topics Archive
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading