27 March 2014

Testing in Agile

A broad topic, and I should narrow it down, but I just wanted a quick post about something I've been getting frustrated with lately.

A developer who can write useful tests for their own code is awesome, although as the head of Engineering in my current job once described it, it should also be Developing 101: write unit tests, so you know when something breaks, write integration tests where it makes sense, reduce your own headaches later, ease debugging, have some idea of where not to look when things go wrong.

What we don't need are developers who specialise in test automation. Now, I have met some very fine testers who started their careers as developers, so I want to make it clear that I'm not talking about them. They were passionate about quality, wanted to get to the root of how to make things better, and decided that testing would give them a wider view of the situation. They put in the effort to learn what a good test is, to learn how to test, to learn techniques for finding weaknesses in the SUT quickly and efficiently, and they generally had a very good grasp of when to use their tools and when to use their brains.

But what I'm talking about are those who want to write code, and have been directed to write code to automate the higher level functional tests that are the normal domain of testers. And who spend more time thinking about the technology that they are using to do this than the tests that they are trying to automate. Or whether those tests are good tests to automate. Or whether you should break down those high level functional tests into smaller tests and automate those smaller tests to get the same information, minus the brain of the tester to interpret the results.

What we need instead in Agile are more people coming from a testing background, who are technically savvy, who are passionate about quality, passionate about testing well, testing better, automating the boring stuff using tools that they can learn about and start using in a few days, pushing back on the rest of the agile team for the things that they need to be done to automate what makes sense to automate, manually testing what needs to be tested only once, using exploratory testing for fuzzy areas, writing their own tools to generate their test data or environment setup. Able to talk with developers and understand what is being done, spot the holes between subsystems before they become bugs, talk to Product Owners to find out what they really want, find out what the users have been saying to direct future design or criticise current design - we need testers who can do all the traditional test tasks well, who are also technical and quick on the uptake. As a born tester, I don't like being labelled as "QA", but looking at what I do on a daily basis, that is the better description compared to "Automation Engineer".