How Test Engineer Gets Exploited In Agile Development

Agile development is known to be a process that is un-predictable, iterative and open to changes in software development process.  It is an alternative to waterfall and sequential development methodologies.

There is no doubt that Agile development approach has so many plus points and is therefore widely adopted for software development, but the adverse effects of Agile development do not spare even the Test Engineers, taking its toll on the QA process as well along with other members of team i.e. Developers, Managers and Client. (Yes, even the client!)

As mentioned above, the process is known to be “un-predictable” which means, you never know what will be the next thing that is going to be included or excluded, and would completely alter flow and outlook of the product.

It certainly is a roller coaster ride with twists and turns, that might leave you feeling dizzy by the end but none the less memorable and enjoyable! (Hold on tight!)

This development approach will be critically analyzed in the following and some of the ways in which Test Engineers get exploited in Agile development will also be elaborated.

Scarcity of Time

If there is one thing that agile development requires, it’s “Time”! Loads and loads of time!

Every next step of agile development requires brain storming, multiple meetings, exploration of possibilities, and assessment of where the team is standing. But time is what it usually lacks, since in most cases the client or product manager anticipates quick delivery of the product. This leaves the QA team with a very little time to analyze and test thoroughly.

Paucity of Documentation

Development of Software requires requirements to be jotted down clearly, but since the process is still new; The word ‘Clear’ is unclear for agile development methodology in general, so is the concept of documentation.

In most cases, the documentation provided is very vague, or altered so its highly likely that along the way it loses its credibility, making it hard for the Test Engineer to set criteria of testing.

‘Every’ Next Step is Uncertain

‘Every’ means literally EVERY next step! QA personnel cannot set parameters permanently on a build, though one can break down modules and set standards for a particular part, but due to the uncertainty of final outcome; one cannot make steadfast rules for the complete flow.

Test Engineers are Disregarded:

This is a fact that cannot be denied, Test Engineers are disregarded by the Dev. Team and client (Not that it’s unusual or new :-P). Chances are rare that QA team would be taken into account before taking any major decision(s). Consider yourself lucky if being a test engineer you are consulted before a major change is made in a module.

Hard to Keep Track of Changes:

A test engineer has no authority to harness the changes being made in the software. All he/she can do is try to keep track of what the state of product was before logging out of the system last time. But due to the fact that there is very little documentation and QA team is not part of the decision making process, it gets hard to keep track of all the modifications over time.

Not that life of a test engineer is easy while working in other development processes, but being part of an Agile Software Development process gives quite tough time to the QA team. And if you are going to be part of a team dealing with an indecisive client, then it’s certainly going to be an adventurous ride! Hang in there! 🙂