This past Wednesday, Apr-20-2011, I attended the DFW Scrum meetup with guest Lisa Crispin, @lisacrispin, presenting over Skype, and I managed to take a wonderful 7 pages of notes in my composition book on her presentation. Because of this I will be breaking this up into a number of posts to help make it more digestible. I hope I didn’t butcher her talk up too much as I was busy trying to keep up with all of the gems she was throwing out to us. Apologies to Lisa if I did.
The big thing she started with was: before a team tries to go off and make any decisions, or do anything, they need to answer the question: “What does a commitment to quality mean?” Once answered, only then can they procede to improve the quality of their product.
On Reducing Show-Stoppers
The steps Lisa’s team went about reducing the number of show-stoppers they had in their product.
- 1st they setup the basics: Continuous Integration and a dedicated test environment.
- Once they had those in place, they setup a police light for show-stoppers. And anytime someone would report a show-stopper, that person then had to turn on the light. This had a two fold effect; it made the business person look silly if it was really a trivial bug, and it got annoying for the team if that light was constantly on.
- Development started TDDing their code. She made a quick side note that TDD is hard to learn, and really, any test automation is hard to learn. She pointed out that it took the developers 8 months to get over the hump of TDD.
- In the meantime, they wrote manual test scripts over the critical parts of the application. It was painful, and a great motivation for automating tests.
- Got UI based automated tests running.
- Worked to get functional automated tests instead of UI testing. Lisa mentioned that her team used Fitnesse.
- They started with a happy path case, after they had that going they woud then add tests around the more boundary and error condition cases.
- She noted that it took lots of baby steps over 8 years with a commitment to testing.
Testing is Not a Phase
The goal is a short feedback loop, as it is easier to recall the code an hour later as opposed to a month or two later. She noted that testers may be against this at first since it means testing the same thing multiple times, but that is important to shortening the feedback loop and improving the quality. I would also personally venture that it would help emphasize the importance of getting tests automated against a baseline set of expected functionality.
Lisa advised against calling a story done until all of the exploratory testing has been done.
She then pointed out some things to watch out for when planning. Watch out for overcommitting, since it usually doesn’t take into account the testing activities and anything they uncover. Also watch out for testing estimates that are not inline with development effort/estimate. Giving the example that if the testing effort is 2X the development effort, that may mean development might be missing something.
I will be posting part two soon as this was only two-and-a-half pages of the seven pages of notes.