Anna Baik wrote:Hi Lisa, Janet,
What sort of retraining would you expect to be useful for a tester in an organisation transitioning to Agile? What kind of skills would be useful to pick up if your workplace was talking about "going Agile"?
And is there any place in an Agile team for non-programming testers? My colleagues in my current team have a pretty wide range of backgrounds: some of us have CS degrees, some came into testing from technical backgrounds like system support, some came in from the business and have no technical background at all. I don't see that it makes any difference to how good a tester someone is, but my boss thinks that you have to be able to program in an Agile team, because there's no specialisation and everybody needs to be multi-skilled and able to pick up any job in the team. I'd love to have more opportunity to write code in my day job, so this doesn't particularly bother me, but it does seem to me that this approach undervalues what a truly skilled tester can achieve without ever writing a line of code.
thanks,
Anna
Hi Anna,
There is definitely a place for someone with good testing skills on an agile team, whether or not that person has programming skills. Of course, it depends on the team. A very small team might require that everyone on the team can code. Our experience is that programmers on the team can help with tasks such as test automation. Agile teams need good exploratory testers, just like any development team. They need people who see the big picture from multiple viewpoints, and ask good questions the programmers and customers might not think of.
We advocate a whole-team approach where everyone on the team helps with testing activities. While agile does tend to discourage specialization, we feel there's a need for experienced testing professionals. It's possible that a team could have programmers who are also great testers, but in my experience, that doesn't happen a lot.
That said, I would encourage you to pick up some technical skills that might make you a more effective tester. Even if you don't automate tests, you can automate tedious tasks to leave more time for more important manual work. For example, Brian Marick's "Everyday Scripting with Ruby" is a good introduction to using Ruby for practical automation.
My team chose to use FitNesse for the bulk of our functional testing, partly because it promotes collaboration between testers and programmers. We testers write the test cases usually (although the programmers often write them also), and the programmers write the fixtures to automate them. That gets us talking more about the story and how the functionality should work. That's a good thing.
-- Lisa