Tuesday, February 14, 2012

The Agile Tester

Analyze, develop, test, deliver .... still sounds familiar?

Getting rid of the waterfall mentality is difficult within some roles, specially when it comes to testers, they will always tell you:
 "How can I test, this is not finished, the story is halfway done, there is no point in me testing anything!"
 Well, actually there are quite a few...


Testing after development is done is already too late. The first sprints we had when we switched to scrum mode were common in two things:
  • Testing was not done at all
  • Whatever testing was done was useless
In every story there are some acceptance criteria, or at least there should be some, and most developers have become used to making sure that those acceptance criteria are fully covered, hey!, it's what the Product Owner will check after all.

So, is there really a point to focus testing on that, and only that?

No, the developer tests then the tester tests the same thing, in most cases it will work (although I've come across some cases in which the developer didn't even test, but I'll get back to that in another entry!).

The added value for the tester in the scrum framework come in three ways:

Testing tasks

As I said, there is no point in waiting for the story to be done in order to test. We've all seen stories finished just a couple of hours before the demo, in a rush. There is simply no time to validate these by testing them at that moment. If there are errors (hopefully not) they will be shown during the demo itself. And believe me, there is no better remedy for "untesting" developers than see their bad work shown up in front of a large audience.

So, what how do we test the stories then? In the same way you develop them! You do not develop the whole story at once, you develop task by task, then, why not test task by task? Have the developer test anything that is possible for him to test as soon as it is available for testing. Of course, depending on the "quality" of the tester, (s)he might be able to do more functional and/or technical testing. Up to you to see the limits.

Try to break the application

I'm sure you already heard excuses for bugs such as "But, the user must be stupid to do that" or "why on earth would he do that?". Well, if it is feasible, someone will eventually do it.

Developers tend to thing inside the box, they usually never get into the role of an end user, so they kind of forget what a user might do when confronted to the application they are developing. Here's where your tester comes in handy.

Ask him to try to break the application, to do as many crazy things as possible, and see what he comes up to. As a matter of fact, the less he knows about the application (or even testing) the better (s)he will be in breaking it.

Regression testing

Last but in no way least, there's always something that was done a couple of sprints ago that got broken by the changes in the current sprint.

Have your tester use a testing tool (there are plenty of free ones, so there is no excuse not to) that allows him to create test scenarios. Ask him to create scenarios for everything he's testing, and then, have him run this scenarios every time a change is committed. This will not get completely rid of regression issues, but it will help you a lot.


No comments:

Post a Comment