In this episode Federico and Matthew talk about how to apply a concept from lean manufacturing to rethink the processes of software development. Taking the real example of a “Regression Run” they discuss how to dissect the process to identify waste that the team can then drive to eliminate.

News

• Visual Studio 2010 Beta 2 released.

The process of a regression run and the waste associated with it

• For our team, a regression run is the automated execution of tests that where written for features released in previous releases.
• For every process, the question to answer is “what does the customer wants for this process”?
• If we think of a regression run as a process, we can define that what the customer wants from it is to be able to install a new version of the product and have his/her applications continue to work as before.
• The goal of a regression run is then to find breaking changes for the customer.
• Waste is any activity that does not add value to the outcome of the process. In the context of a regression run it could be any activity that did not identify a breaking change for the customer.
• Types of waste
• Waiting. Time spent waiting for results, for a tool or for fixes.
• Unnecessary analysis. Analyzing a failed test that was not caused by a breaking change.
• Over analysis. Analyzing a test that ensures higher quality than necessary.
• Time of analysis. Time spent between receiving a result and identifying the breaking change.
• Unused creativity. Creativity of the people that could be used to improve the process.

Instead of thinking about identifying and enhancing the value-add activities, you could work on identifying and eliminating the non-value-add activities.

On this episode Matthew and Federico talk about how our team partitions the test bed by using priorities. They discuss why having an incremental automation test bed is important and how having a standarized meaning for priorities can help.

News:

• Microsoft Ajax Library Preview 6
• Welcome to our new team member Drew Miller.

Test case priorities

• Grouping tests by a common priority bar is useful when dealing with a big test bed.
• Pri 0
  • A small number of positive tests under one configuration.
  • Constitute 10-20% of a feature's tests.
  • Regression amounts to a ship stopper.
• Pri 1
  • Coverage for 80% of the use cases of a feature under multiple configuration.
  • Constitue 80% of a feature's tests.
• Pri 2
  • Edge or low impact scenarios.
  • Constitute 10-20% of a feature's tests.
• Why do we need pri 0 functional tests if we already have unit tests?
• Your guidelines are ambiguous, how do you apply them?

In this episode Federico and Matthew share some of their personal anecdotes regarding process overhead. By examining concrete examples, they discuss pitfalls and how to remove unnecessary processes.

News:

• MVC 2 Preview 2 Releases

Process Overhead

• The process of keeping internal specs and documentation up to date.
• The process of triaging bug defects for a large project.
• The process of checking code into the repository.
• The process of maintaining a detailed scheduled of work.
• Processes that provide value to the business vs. process that provide value to a person.
• Reinvent a process vs. just throw it away.