I've written before about agile testing, and how I feel the role of tester is possibly one of the hardest to transition to agile software development.
In so many ways, agile testing goes against what testers are traditionally taught. Some of the things that worked before, and were important, in traditional projects, in agile projects are no longer relevant. Some even conflict with some of the key agile principles.
The testing process, principles, and deliverables a tester produces, in agile testing are somewhat different. That's what makes the transition hard. And particularly for professional testers with years of training and experience in more traditional methods.
The skills may be the same, but the role of a tester changes in agile software development.
Nevertheless, the skills of a tester are an essential ingredient of any agile team. I believe strongly that a professional tester is a huge asset to any team, because we can kid ourselves, but we all know really that most developers can't test for toffee!
If you are uneasy about the transition to agile testing, or you're just new to it, I recommend watching this video (above). It's a techtalk presentation at Google. It's about an hour long, so you'll have to put some time aside to watch it. Elisabeth Hendrickson from QualityTree Software is an excellent speaker, and gives a real, practical insight into the transition to agile testing.
Most importantly, she does so from the perspective of a professional tester.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
3 comments:
Thanks Kelly
We will be doing Agile as well as Waterfall projects so the change will happen for me which is going to be a challenge.
The talk was very interesting, especially as Elisabeth has been through this transition and presents the outcome as very positive. I found a PDF that Elisabeth wrote that relates to this talk which can be found here: http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf
I can see benefits from this approach - having looked at user stories, I like the format and the idea. Its easy to understand. Breaking down the work and allowing business change to be incorporated makes a lot of sense.
Having spoken to people about the process and the above talk, I'm actually looking forward to doing a project in an Agile way to see how well it works and where things can be improved.
I am not convinced about Agile at_all. It goes against everything that software development has built upon over the past few years, in terms of documentation, process and scheduling. OK it seems fine for itty bitty little projects but to have post-it notes, cards and month-long-only sprints makes long term planning and development a nightmare as far as I can tell. As a QA Manager, it just appears to be another reason for lazy programmers and developers to validate their sloppyness with this BS method, as well as allowing a customer far too much opportunity to change their minds at each and every step (which we all know they will). Hopefully it is just a fad and will pass over once it has all come crashing down since no-one knows what does what because the post-it notes got thrown away. This is no hate upon yourself, just you seem to be prolific in selling Agile and so seems a reasonable place to voice my concerns.
all of this random boldfacing is annoying as hell.
Post a Comment