QA is a crucial part of the development cycle that is always easily overlooked. Development teams are not given ample time to develop proper unit tests and quality assurance is not given sufficient time to properly run test cases against the application. This causes defects to rear their ugly face in production after being “tested” by developers and the quality assurance teams.
Because of the “lack of time”, both groups focus their attention on the newest feature. A close second is moving onto the next priority (at the request at the impatient business owners) Long forgotten is the basic regression test of the applications core functionality.
Traditional development says that developers should write unit tests for all code. This allows for maximum confidence that an application is performing correct after new defects/features are introduced into the code base. Ideally, this would happen for all applications. We all know that we do not live in an ideal world.
Writing unit tests take time, especially when the application was not written with unit tests in mind. Refactoring the code with unit tests takes additional time. Both are long term solutions that need to be worked into development to stop the vicious cycle from continuing.
While working on our ideal solution, our application continues to chug away in a production environment. There is still a need to ensure that the application is running defect free. What better way to put an end to this then to go back to the stone ages of check lists? This ensures that no one can “forget” to test basic features such as: reporting, statistics, tracking, billing, customer satisfaction features, etc.
The checklist need to be short, you don’t want your team to spend their entire day regression testing. The core features of an application must easily be testable within 15 minutes. This will allow everyone to confidently say the application will continue to run after the new release is delivered.
Your checklist should be documented on paper and saved for later use. It can be used to show who release which version of the code, track defects that should have been caught by the checklist, provide an audit trail for auditors, etc.
Here is link on how doctors and agile project managers have introduced checklists into their day to day routine.
1 response so far ↓
1 John // Jan 10, 2008 at 6:41 am
Good post, Mike. I totally agree with you. Sometimes you have to go all the way back to the basics to make sure the advanced stuff is working properly.
Leave a Comment