Lean software development is rapidly gaining popularity as software development teams tire of the high risk of...
mistakes and the high cost of change associated with application lifecycles that emphasize extensive planning and design early in the project. Lean software development minimizes these problems by making it easy to change course or correct mistakes by planning and adjusting continuously throughout the development process. Lean development, with roots in manufacturing, is an agile style of development using concepts such as continuous flow with the goal of eliminating waste.
This approach can seem chaotic to a quality assurance manager who is used to a phased project management approach. There is little, if any, time for creating test strategies, test plans, or performing other testing preparation activities. A lean QA manager must prepare his team for a different approach to testing software if they are going to add value in the lean software development lifecycle.
Lean requirements are stories
In lean software development, product features tend to 'emerge' from short cycles of development, testing, and user evaluation rather than from extended analysis and design of needs. Facilitating this approach requires a unique approach to requirements gathering that is simple and can be done quickly and continuously throughout the application lifecycle.
User stories are the most widely used tool for collecting requirements in a lean project. Generally speaking, they are simple descriptions of something a user can do with the product in a sentence or two, along with any needed clarification of their expectations (often called acceptance tests). Here's an example of a story from User Stories Applied, Mike Cohn's definitive guide to using stories to drive a software development project:
Users can view information about each job that is matched by a search. Marco says show description, salary, and location.
The acceptance tests associated with this story are:
- Try it with an empty job description.
- Try it with a really long job description.
- Try it with a missing salary.
- Try it with a six-digit salary.
QA professionals who are used to detailed requirements documents may struggle at first with these brief descriptions of functionality. It's important to remember that user stories are not functional contracts in the way requirements documents often are. Rather, they are the starting point from which a feature emerges, therefore it isn't critical that they be exactly right from the very beginning.
Out of the icebox and into the backlog
All user stories start out in a big, un-prioritized pile that is often referred to as the 'icebox.' As a development team decides to work on a story, it is pulled from the icebox and placed in the 'backlog,' where it is estimated and prioritized against the other work in the backlog.
Developers pull stories from the top of the backlog one at a time. When they are finished and they have delivered the code, the story is ready to be tested and goes in another pile for that purpose. Once tested, the story will go into one of two piles: the done pile or the rejected pile.
Tools for managing user stories
Keeping track of the state of a big collection of user stories might seem daunting, but it really doesn't have to be hard. Co-located teams will often use index cards and a blank wall to keep track of them by marking different sections of the wall for each state the stories pass through. Typically, there will be sections for the icebox, the backlog, 'delivered' stories (i.e. ready for testing), accepted stories, and rejected stories.
As the team prioritizes and performs work, they simply move the cards around on the wall. This is a straight-forward approach for managing stories that also gives stakeholders instant insight into the progress of their project.
Remote teams must create a virtual wall for managing their stories. In the past, I've used many different approaches for this, including spreadsheets, Microsoft SharePoint templates, and wikis. Each of these approaches has limitations that may make them less than ideal, which is why I now recommend the use of a Web-based product specifically designed for managing user stories. I currently use Pivotal Tracker (pivotaltracker.com) for managing user stories on my projects, but there are many other products available including Rally and CollabNet.
Quality assurance is accepting and rejecting stories
Once a story has been delivered and is ready for testing, it's QA's turn to do some work by accepting or rejecting the story. Using the user story as a guide, you need to make sure the story really is finished and, at minimum, meets the expectations described by the story. You also need to make sure that appropriate automated tests have been created for the story and that the story is, as much as possible, bug-free.
Before accepting or rejecting a story, you will need to do at least three things:
- Review the code the developer has created to verify the coverage of automated tests is appropriate.
- Run the automated tests to make sure they work.
- Perform manual testing of the story to make sure the requirements are met, is reasonably bug free, and is consistent with the standards you use for development.
Once finished, the story will either move to the "done" pile or the "rejected" pile. If you decide to reject a story, you will need to explain what needs to be done for the story to be accepted. You might also choose to accept a story but create bug reports if the bugs are too minor to prevent the feature from shipping as is.
Continuous quality assurance
Lean software development doesn't have phases the way traditional software development approaches such as waterfall or RUP do. Instead, it is a continuous, rolling cycle of creating, prioritizing, implementing, and testing user stories. QA professionals on a lean development project must provide a useful service that makes the product better without slowing down development or allowing user stories to accumulate in the 'ready to test' state. To do this, you must be able to embrace the "pull" mentality of lean software development and become an integral part of the development rhythm of the larger team. If you do, perhaps you too will discover just how fun and effective building valuable software can be. Share