How the test process works in an agile development process

[Paul]

Over the last few years, “transitioning to agile” has been flagged by lots of testers as a big challenge. A lot of conference talks and tutorials and webinars focus on this topic and some say what they end up with in moving to agile is a faster version of Waterfall.

Has anyone got any experiences (good or bad) in this transition that they could share?

Does your test process work well in agile?

[Kasper]

As with all things testing: it depends!
If Agile is done right it is an eye opener for the development team.
During refinements and poker/planning sessions testers can have a lot of influence (i.e. give an object an unique ID please – so I can test it properly) and we can get all our questions answered.
Because documentation is NOT the top priority but working software is the successful teams are well adjusted, and aware of each persons strengths and weaknesses and bring this together for the purpose of getting working software out of the door as soon as possible.
The demo of prototypes give quick feedback and so we are able to constantly improve the product.
One of the things I particularly like is the absence of management. The team decides how things are done. The product owner (client) decides what he/she wants first.

If Agile is combined with the use of scenarios (Gherkin/Cucumber) testing becomes a breeze (well nearly).

If agile is done badly it adds nothing but frustration. The product owner does not know what he/she wants or at least can not describe it in other terms as “The same as the last one”. The project manager has become the scrum master and he/she decides how things are done, and not the team.
Stand-ups and refinements / poker sessions are a complete farce and the team performs worse than it would ever do in even the strictest waterfall environment.
Demos and prototypes are used to keep scores and lay blame instead of being used as a valuable source of feedback.
The developers form a close knit team who shut out everybody not deemed a developer. Testing becomes a nightmare (well nearly).

What it boils down to:
What ever method you use – there is the possibility to make the team shine and to make the team fail.
In an open culture waterfall can be as effective as Agile. All it needs is a team that is open and willing to communicate.
I am not really doing things much different than in the 1990’s. I test stuff, I try to verify that it works as intended – so I talk to the people who will use it. I will giver them early prototypes if and when they become available.
I try to break stuff – so I talk to the people who designed it to find out what it is designed to do and than I go out and try to make it do something else.
I wonder how stuff does what it does so I go talk with the people who build it and try to find out and learn something in the process.

I do this whether I work in a waterfall environment or in Agile.
For me there was no transition to Agile.

[Author]

Posts