I like waterfall, there I said it.  Testers got the time they needed to complete the testing required (mostly)…


With most IT organizations now using an Agile-ish methodology the time available to test prior to each “release” has drastically reduced.  We’ve also learned that the earlier we catch bugs the less impact they have, so testers have been asked to be involved earlier in the development process.


Some companies have also realized that testers are valuable resources that can offer different perspectives during code reviews and peer programming.  Testers are also often asked to help build environments, deploy the code and build automated tests/processes.  Yet most companies don’t have even 1 tester for every 2 devs.  How are they supposed to keep up?


If we look at the way our stories are broken out, they are frequently test heavy.  With a ratio of 1 tester to every 2 devs, at best, this leaves a lot of testing work for few dedicated testers.


These two problems together end up with testing often being a serious bottleneck in the development process.  This seems to be a frequent story.


At the start of each new project, hope is in the air and this time things will be different.  Testers work with the devs on the initial stories, this is great and will reduce the number of bugs in the code.  But unfortunately, the story is ready with only 1 day left in the sprint to test.  There is too much to test for the testers to finish in the time left and any bugs found are unable to be fixed by end of sprint.


Now Dev’s could help with testing but they have been tasked with either cleaning up/refactoring some other code, finishing a dev light task for additional points or getting a head start on the next story.  But this just compounds the issue, suddenly there is even more testing to be completed and the testers have less of an idea of the important areas to test.    If the goal of Agile is to create deployable, tested applications at the end of each sprint, then for the sprint above I would give them zero points.


The testers will get further and further behind, and as they have been less involved with the development their testing will be less effective.  All this will end with there being an additional clean up sprint(s) being needed.


So how can Testing work within Agile?


Cross functional teams are often deemed to be important to Agile development.  It has been debated whether cross functional teams require team members who are capable of fulfilling all roles.  One of the main advantages of having team members who are multi-skilled, rather than specialists, is that when stories are heavy in certain work that other team members can pick up this work from the “QA”.


Additionally Quality needs to be owned by the entire team.  Having team members who are multi-skilled help with this.  You need to have an understanding of which tasks can be picked up by which team members.  Try to ensure that the amount of QA effort per story is understood and that the development is finished with enough time for testing.  When devs are assisting with the testing, try to make sure that the devs aren’t testing their own code…


Unfortunately, every organization is different and so is the best solution to having a functional agile test team.  If you want help finding a solution to your testing problems then contact us.
Contact Appsurify
close slider