Followers

Thursday, December 16, 2010

My "Cheat Sheets"

I have worked on an agile team for about 18 months now. I have really enjoyed the time I have spent on this team and the challenges that have required me to stretch my skills and use my imagination.


One area that I stumbled over for a period of time was what I needed to have for documentation. I wanted to make sure that I had quick access to the requirements that were implemented into the application/product/system. These requirements were generally located in PBI’s (Product Backlog Items), specifically in the COA (Conditions of Acceptance). The application where these items are stored is often slow and hard to search. And the COA’s of some of the items lacked information that may have been transferred either by word of mouth or email during any given Sprint. While these items of information were documented within the system, they may have been documented on the SBI level; therefore the information on the PBI would be incomplete.

Over the course of a few Sprints, I developed a bit of a “cheat sheet” system which has saved me oodles of time and frustration. It has evolved, and will likely continue to do so if the need arises (what Agile is all about to me). All of the “cheat sheets” were created using Excel spreadsheets.

User Story Headlines – 3 Column Headers containing:

User Story Number – for easy lookup in the system where the stories are located
User Story Title – for locating a particular story by name
Feature/Function document location – for listing which spreadsheet the “requirements” can be found in

***I actually have a How to Use this Document tab as well... in case I "get hit by a bus"...

Feature/Function document – 2 tabs (one for “requirements”, the other a navigation checklist)

Requirements tab columns:

User Story Number – to trace the requirements back to the appropriate PBI
Priority – How important the tester feels this needs to be verified
Test Case Headlines – This is where the actual requirements are documented in what I suppose could be called test case shorthand… These are brief statements about the feature/function requirements describing (generally in one liners) what the feature/function should or should not allow/do.
Notes – If a requirement has changed, it can be noted here. Also any other helpful information or definitions that might save time or be beneficial. – In this column I use a different font color in so that it draws attention.

Navigation Checklist tab columns:

Navigation Item – the name of the item goes in this column
• Condition – conditions of the feature/function at the time of selecting the navigation item
Expected Results – what the results should be when the navigation item is selected under the given condition

Menu Item Checklist – 4 columns, similar to the Navigation Checklist tab from the Feature/Function document, but encompasses the entire application/product/system by including every menu item available.

Main Menu – lists the main menu name
Menu Item – lists the name of the menu item
Condition – condition of the application/product/system at the time of menu item selection
Expected Results – what the results should be when the menu item is selected under the given condition

I have found some benefits in keeping these documents:

1. It is easier for me to search for items in the spreadsheets than it is in the system the PBI’s are stored in.
2. It is easier to find a PBI number in these documents to trace back to the original requirement when writing up a Bug; which when noted in the Bug saves development time in looking for them.
3. They are lightweight, but contain more than adequate information for checking that the application continues to hold true to the requirements.
4. They contain enough information to be useful as a training tool for testers that are new to the project.
5. They provide traceability to the requirements themselves.
6. While they are not test cases, they are beneficial in creating test cases

*** I know I could reveal more details... but I won't... because figuring out what YOU need to document for your team... that is something only YOU know :)

No comments: