Agile Testing
- March 2nd, 2010
- By Vemu
- Write comment
Hi All,
Anyone interested in Agile testing methodolgy?
Let me know and I can cover this topic off with some real time examples.
Cheers,
Vemu
Here are few details about the Agile development that we follow
One of the framework in Agile is called Scrum that we follow in our company
Scrum is a lightweight process framework for agile development, and the most widely-used one.
- The Scrum process framework requires the use of development cycles called Sprints
- “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic “waterfall” processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.
An agile Scrum process benefits the organization by helping it to
- Increase the quality of the deliverables provided every team involved is disciplined enough
- Cope better with change (and expect the changes)
- Provide better estimates while spending less time creating them – because estimates are given by individual team members who does the actual work rather than given by technical lead
- Be more in control of the project schedule and state
As a result, Scrum projects achieve higher customer/business stakeholders satisfaction rates.
Requirements in scrum:
Scrum does not define just what form requirements are to take, but simply says that they are gathered into the Product Backlog, and referred to generically as “Product Backlog Items” . Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time to implement than the duration of the Sprint.
Most Scrum projects borrow the “XP” (Extreme Programming) practice of describing a feature request as a “User Story,” although a minority uses the older concept of a “Use Case.” We will go with the majority view here, and describe three reasonably-standard requirements artifacts found in Product Backlogs.
User Story
A User Story describes a desired feature (functional requirement) in narrative form. User Stories are usually written by the Product Owner, and are the Product Owner’s responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents (such as screen shots), and information about how the implementation will be tested.
For example, a Story might resemble the following:
As a <type of user role>
I want <some goal>
so that <some reason can be achieved>
How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.
There are two reasons for including the information about how to test the Story. The obvious reason is to guide development of test cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to estimate how much work is required to implement the story (since test design and execution is part of the total work).
Technical Story
Not all requirements for new development represent user-facing features, but do represent significant work that must be done. These requirements often, but not always, represent work that must be done to support user-facing features. We call these non-functional requirements “Technical Stories.”
Technical Stories have the same elements as User Stories, but need not be cast into narrative form if there is no benefit in doing so.
Technical Stories are usually written by Team members, and are added to the Product Backlog. The Product Owner must be familiar with these Stories, and understand the dependencies between these and User Stories in order to rank (sequence) all Stories for implementation.
In our company we follow 4 week sprint cycles but i know few companies which follow 1 week spring and few that follow 3 month sprint cycles.
it really depends on amount of work that you want to do and amount of resources available.