Agile tends not to devote much attention to application 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 application development often lacks system quality assurance. Not surprisingly, such lack of design can cause agile software development upstream difficulties when the individual features fail to work together adequately overall.
What's the test in a scenario of Agile development?
The test strategy and the Agile development tactic could be very different from the traditional testing/validation.You must start qa/testing activities without design documents and specs. Test and software development activities are conducted simultaneously on an agile job. This means you'll need to find a way to start writing qa scripts without reports or application code from development. I've seen more than a few qa analysts implode from the change this represents. I would say about half the time (as a completely unofficial guesstimate) the qa analysts who struggle with this idea end up quitting and getting a job at a place like Microsoft where they still do sequential software development.
You shall be expected to work ahead of the current application release cycle to help define acceptance criteria for the user specifications. The requirements you'll be handed as a team is going to be impossible to accurately calculate That is not an opinion so much as my and all my colleagues' experience. Someone will then need to work considering the customer to "right size" the prerequisites, so they are detailed enough to estimate without being so detailed as to tell the team ways 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 job, their specifications, stories, or requests. Every one of these will have tasks the team must complete for the item to be considered done. These tasks have to be completed by the most logical person on the team, even though that means a designer writes test scripts or a qa tester writes code. You probably have a situation where people are sitting around or racing ahead to the next code release while others are swamped with work, you're doing it wrong.
You will be expected to guesstimate your task time the same as anyone else on the team. This one should go without saying, but a lot of sequential qa analysts have been allowed to simply "test until we reach the deadline" or plug in some completely random number based on a percentage of what application development has estimated. You cannot do this on an agile job, 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 conclusion in agile quality assurance you are going to be dealing with:
Emergent requirements: Some specifications will start with a single line description. You, and the rest of the team, have to take that to working application.
Very tight feedback cycles: Something will likely be delivered to test every day.
High levels of automation: more of a focus on “does the right thing," less on following an established method. That can make some people uncomfortable.
Post a Comment