SQL Server with Mr. Denny

Jan 20 2020   4:00PM GMT

Stop scheduling to go from testing straight to production

Denny Cherry Denny Cherry Profile: Denny Cherry


All too often I see the same basic pattern happening.  Software changes are written in dev, those changes to move QA, then the changes move to production.  The problem with this schedule is that if there’s a problem found in the QA process, there’s no time in the schedule for problems to be found in QA, which requires sending the software back to Dev, the problems fixed and then we try QA again.

If we don’t build time into the schedule to address problems that QA finds then we have one of three options.

  1. Release software with known issues to production
  2. Cancel the release and send everything back to development
  3. Do the release late and send the software package back to development, then QA

None of these are particularly good options as they involve either releasing known bad software (that’s not a good option as users will be mad) or missing the release date (that’s not a good option because users and/or management will be mad).

The better option is to plan into the schedule to have to send the package back to development to have problems adjusted.  Developers are human and make mistakes, it happens.  It takes time to fix the problems that are found. This is why we have QA. It isn’t to sign off that software is perfect, its to find problems in software so that they can be fixed.

Say that we are starting a Dev string on Feb 3rd, 2020 (it’s a Monday).  The sprint goes until Feb 14th, 2020 (it’s a Friday).  Testing in QA is scheduled for a week so it starts on Feb 20, 2020, and ends on Feb 24, 2020.  Then the production release is on Feb 27th, 2020 (the last Monday).

Now, what happens if a problem is found on Feb 24th?  Do we push the release date from Feb 27th, or do we release known bad software?  Neither of those options is going to be particularly popular options.

What we should have between testing and the production release is at least a few days, maybe another week for additional dev work and re-testing after QA happens.  If that time isn’t needed great, then the package sits for a week.  If the time is needed, then we have it. In either case, the release can happen on time and we can release known good software, instead of software with known bugs.

This sort of change will require signoff from above, but it won’t really change the process that the developers go through when building the software.  What it will do is slightly reduce the number of releases that can happen each year as each cycle is now a little bit longer then it was before.  But the end result from this will be more stable software, and a better result from each software release; and this is course the prefered end result.


 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: