Discussion on:
View:
Show:
How does your team know when software is ready to release? Are there elements that are on your release checklist that Patrick doesn't mention in his article? Have you ever released software too soon? If so, what did you learn from the experience?
"Have you ever released software too soon?"
Yes! Why? Because of pressure from the business units. What were the results? It took almost five times as long to fix bugs because the true bugs got mixed in with enhancement requests that the client "had to have."
The ultimate cost of the program was 3x more than budgeted.
The sad part is the client didn't learn... they continue to rush product to market that isn't tested thoroughly, (or regression tested in the case of enhancements). So the budgets are almost ALWAY shot before they begin...
Yes! Why? Because of pressure from the business units. What were the results? It took almost five times as long to fix bugs because the true bugs got mixed in with enhancement requests that the client "had to have."
The ultimate cost of the program was 3x more than budgeted.
The sad part is the client didn't learn... they continue to rush product to market that isn't tested thoroughly, (or regression tested in the case of enhancements). So the budgets are almost ALWAY shot before they begin...
"Ready for release" depends on who you ask. The development group may say the release is 'ready'....but are the manufacturing, implementation and support groups prepared....how about training or review of changes that will occur in the release. Thisis critical to not setting up the business for failure. Very rare to find a development group that thinks outside the box to consider how other business units will be affected by new releases. But that's the job of a good product manager.....isn't it??? Are there any out there????
From the article, "...look at how smoothly the different developers' coding elements have been integrated to ensure a professional finish."
What exactly does this mean? Would you really want to use adherence to a coding standard to determine if aproduct is nearing completion? I dont believe so.
I would also add to the checklist examining the measure of the defect find rate. When the find rate drops, that is often an early indication that quality levels are being acheived, and that release is near.
What exactly does this mean? Would you really want to use adherence to a coding standard to determine if aproduct is nearing completion? I dont believe so.
I would also add to the checklist examining the measure of the defect find rate. When the find rate drops, that is often an early indication that quality levels are being acheived, and that release is near.
In the shops where I've worked, a formal process is established that lets the development team turn over the project to QA for testing. The code isn't "done" until the QA people say it works according to specification, on the appropriate platform, and all technical and user-level documentation is in place.
I'm curious about when to hand the code to QA, then. Normally, I'd expect QA to be involved in a continuous parallel process of testing...otherwise, how do you know when it's 'done' enough to pass it to them? If it fails QA, what's the processs you use to correct those shortfalls...?
We develop release milestones and within the milestones, we have Code/Unit/Integration testing. The developer does unit testing on his/her code and when complete, it is handed off to the systems analysts for integration testing. When the analyst is complete, it is then ready to be migrated to the system test environment where the test team does their testing.
QE ideally is a continuous process throughout the development process. The biggest complaint I hear from QE is that they often aren't sure what's completed ready to be tested or are told that areas are completed when they're not.
Depending on theproject scope and development environment I typically use a variation of one of the methods below:
"Phase releases" for larger projects: The team devided the code development phase into roughly thirds. Completion objectives for each phase is a list of features/enhancements that are completely ready to be tested in order to meet the milestone. Exceptions to the phase should be documented via Build Notes to prevent QE from testing areas that are still in development.
"Weekly builds": For smaller projects with a running list of features, an weekly build is done for release to QE. Included with the build are comprehensive "Build Notes" that identify the new features that have been added and are ready for testing. Combine this with aweekly report of bug fixes available in the build, QE has all the information to test new features as well as close resolved bugs.
The theme between both approaches is a clear communication and commitment on behalf of development of "what's ready" as well as some supporting documentation of "what's to be avoided".
Depending on theproject scope and development environment I typically use a variation of one of the methods below:
"Phase releases" for larger projects: The team devided the code development phase into roughly thirds. Completion objectives for each phase is a list of features/enhancements that are completely ready to be tested in order to meet the milestone. Exceptions to the phase should be documented via Build Notes to prevent QE from testing areas that are still in development.
"Weekly builds": For smaller projects with a running list of features, an weekly build is done for release to QE. Included with the build are comprehensive "Build Notes" that identify the new features that have been added and are ready for testing. Combine this with aweekly report of bug fixes available in the build, QE has all the information to test new features as well as close resolved bugs.
The theme between both approaches is a clear communication and commitment on behalf of development of "what's ready" as well as some supporting documentation of "what's to be avoided".
We have a new web app where you can create a release checklist online together with your colleagues: http://expertchecklists.com. You can discuss changes of the checklist and see version history, then print out in different formats. Pretty cool.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
