Testing Parkinson's Law
"But it will take 3 months for testing," was the explanation I received regarding why a design change we just implemented would extend the schedule of the project by a month, even though we were not adding any additional functionality. I wasn't questioning that the testing could take 3 months, rather I was concerned that the testing would take 3 months, regardless of how many bugs were found. We were, after all for the most part retesting functionality that had already been tested once. The words "Parkinson's Law" kept floating thru my head.
Parkinson's law, "work expands so as to fill the time available for its completion" was first stated by C. Northcote Parkinson in The Economist in November 1955. It was originally intended to describe the self perpetuating nature of bureaucracy, but remarkably it has a great deal of relevance in project work. In this case, it applied to the possibility that testing would expand to fill the planned three month time frame, even if the team could have completed it sooner, especially since some of the team members performing the test were not full time testers and were not on the project full time.
It was reasonable to expect that the team had to run some test cases to verify that the design change had the impact to performance we were expecting (the reason we made the design change in the first place) without introducing any functionality bugs, but the trick was figuring out how many to run. Rerunning all of the test cases again would be the less risky approach, but would also add more time to the project than we could afford. Instead we discussed performing a risk analysis and selecting that subset of test cases that specifically were impacted by the design change, we could theoretically come to a conclusion quicker whether the design change was successful and the entire system was running as expected.
- total number of test cases
- Canceled test cases
- Completed test cases
- Open test cases (a bug was found and the team is working on a solution. The test case will remain open until the defect is corrected and the functionality can be retested.)
- In process test cases
- Test cases that have not been started
Then we agreed to examine the metrics on a daily basis to help us adjust our course and to identify if Parkinson's Law was starting to apply itself. We plan to look for early indicators such as the following:
- Are there test cases that have been open for more than a week? Why? What are we doing to close them?
- Are there test cases that have been in process for more than a couple of days? Why?
- Based on the test cases that are closed, are we comfortable that the system is working, or do we need to complete some or all of the remaining test cases?
There's no guarantee taking the above steps will ensure that we complete the testing within the three month time period. After all, you never know when the perfect storm of legitimate problems with the design or development work will occur. What we do know is that we will have kept the team focused and moving forward so that if testing does take three months, it's because we had three month's testing to do, not because members of the team thought they had plenty of time to test and chose to work on other tasks during the early part of the testing period.
