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.
- Release software with known issues to production
- Cancel the release and send everything back to development
- 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.
Denny
The post Stop scheduling to go from testing straight to production appeared first on SQL Server with Mr. Denny.
