Past few years,many companies have started adopting Agile process for their software development.I will try to share some experiences and related technologies that QA can use to make the transition from the waterfall model to Agile model.For this particular post let’s dive right into the first stage of waterfall model and a parallel process in Agile.
Requirements
Waterfall model requires that requirements are listed before any design/implementation begins(There are variations of it like prototyping which involves some coding).But the basic concept is to have requirements cleaned up before full-scale development begins.This usually requires a dedicated person who needs to work with the user/owner to get the requirements and write them down in a format understood by Dev/QA(Usually MS Word or other graphic design tools like Visio etc).
The Agile process actually turns this concept upside down and throws in the concept of being “Agile” in accomodating new requirements during the release.The idea is to plan for the big picture but keep refining details as we go and as part of a team rather than being owned by a single person.
From my personal experience for a QA person
Advantages
- Requirements are often discussed/refined as a team(standups/scrums) and covers the business/technical aspects of the requirement.This leads to better understanding of the product by each team member and avoids late in the game objections
- Agile process often requires having an entry and exit criteria for stories(a compression of things to do in a particular release/iteration).This makes sure that the requirements are well defined and have a measurable way to tell whether the requirements were actually completed or not
- Having a concept of backlog definitely helps,where new ideas don’t get sidetracked but are kept for future releases(so that it can be sidetracked in future :)).While it can be argued that something similar can be achieved in waterfall model,normally a Agile management software(like Rally,TargetProcess etc) ensures proper management and transparency not available in Waterfall model
Disadvantages
From my perspective,the disadvantages or weaknesses does not stem from the process,but gaps in correctly implementing the process.However some of them are easy traps and can be perceived as Agile’s weakness in this area(SW Engineering Rule 1:When a product fails,blame the process not the people 🙂)
- If big picture requirements are not clear,the details within will be muddled as well.Normally for new products the SW architecture takes a path based on the intial requirements.If you start changing the requirements(as allowed in Agile) during the release,it’s very hard for Engineering to adapt to those changes as lot of effort has already gone into the intial requirements development and testing.
- Sizing requirements and estimating how long it will take is a big people dependent task.Normally QA gets the short shrift ,since it’s logically the last task in marking a story as done,any delay in the prior task(development) is going to hurt QA timelines.Lot of time QA doesn’t even get to execute even one testcase in the whole iteration and QA is struggling to finish the task.Ofcourse this can be improved by better estimation and scheduling,but it’s harder in practice.There are ways to get QA getting hands dirty earlier(like writing integration tests,which I will cover later)
Last,What’s the role of QA when requirements are getting written
- Stay involved when the big picture requirements are written.It’s your chance to make sure testing estimates don’t get overlooked
- Ask questions(and lots of it) when the story gets picked up for implementation(Assumption is the mother of all screwups-Anonymous) .It will save QA lots of time later
- When new stories are added during the iteration,make sure that QA time is counted and also get commitment from development to have initial estimate include bug fixing,optimization etc.
