What is Agile Software Development?
In general, Agile development works with relatively few, very briefly-defined requirements in the form of user stories. Agile’s requirements usually are in the form of user stories, which by definition are very brief and relatively few in the number in keeping with Agile’s focus on just the work to be done in the near term. User story acceptance tests also tend to be limited to the small user story, which is closest in scope to integration tests.
Agile tends not to devote much attention to software design. Instead Agile usually limits its attention to the individual small pieces of code implementing particular features, often without necessarily addressing the design–how those features fit together with each other and with other components. Consequently, typical agile development often lacks system testing. Not surprisingly, such lack of design can cause agile development upstream difficulties when the individual features fail to work together adequately overall.
What is the test in a scenario of Agile development?
The test strategy and the Agile development approach could be very different from the traditional testing.
- You must start testing activities without design documents and specifications. Test and development activities are conducted simultaneously on an agile project. This means you’ll need to find a way to start writing test cases without documents or code from development. I’ve seen more than a few testers implode from the change this represents. I would say about half the time (as a completely unofficial estimate) the testers who struggle with this idea end up quitting and getting a job at a place like Microsoft where they still do sequential development.
- You will be expected to work ahead of the current release cycle to help define acceptance criteria for the user requirements. The requirements you’ll be handed as a team is going to be impossible to accurately estimate That is not an opinion so much as my and all my colleagues’ experience. Someone will then need to work with the customer to “right size” the requirements, so they are detailed enough to estimate without being so detailed as to tell the team how to solve the problem. QA is the natural fit for this task.
- You and your team must jettison the idea, there are development and QA tasks. On an agile project, their requirements, stories, or requests. Each of these will have tasks the team must complete for the item to be considered done. These tasks need to be completed by the most logical person on the team, even if that means a developer writes test cases or a tester writes code. If you have a situation where people are sitting around or racing ahead to the next release while others are swamped with work, you’re doing it wrong.
- You will be expected to estimate your task effort the same as anyone else on the team. This one should go without saying, but a lot of sequential testers have been allowed to simply “test until we reach the deadline” or plug in some completely random number based on a percentage of what development has estimated. You cannot do this on an agile project, or you’ll constantly miss your deadlines. QA has to take ownership of estimating their tasks, by which I mean the tasks they’ve agreed to take on since there are no “QA tasks” on an agile project.
So in summary in agile testing you will be dealing with:
– emergent requirements. Some requirements will start with a single-line description. You, and the rest of the team, have to take that to working software.
– very tight feedback cycles. Something will likely be delivered to test every day.
– high levels of automation
– more of a focus on “do the right thing,” less on following an established process. That can make some people uncomfortable.