I bet you are wondering what I’m thinking, or even if I’m sane. Who wouldn’t think QA is an invaluable and required facet of any development shop interested in quality? Explaining the origin of this question requires a short trip back in time …
For many years, the development teams I work with followed what I think is a fairly traditional development cycle used by your average small – to – midsized web shop. The cycle included a three week development sprint, followed by one week of Quality Assurance testing and then release to production. On average, new features were released every month. This process served us well for quite some time; however, as time progressed the team grew more and more disenchanted with it. Dev unease and frustration with that process could be summarized with the following points:
- Feature development often spilled into the QA week.
Invariably, this issue culminated with a Thursday-Friday scramble to complete development and the QA process. I can recall several sprints were the teams simply ran out of time and the release was delayed. Naturally, a delayed release doesn’t make the technical team any friends and the scramble negatively impacted quality.
- Developers were annoyed with source control branch management complexities.
This complaint would surface mid-sprint after a dozen or more features were complete, but while waiting for the end of cycle deployment it would not be uncommon to receive an “emergency” bug fix, or feature request. The business would prioritize the request and the team would have to hustle it through the pipeline and immediately deploy it to production.
“Why didn’t you manage that complexity with branches in the source control”, I hear you ask?
Managing the associated complexity with GitHub and branches is precisely what we did. “Yes” it worked, but quite frankly it felt messy and inefficient. Developers were annoyed when the merge required significant conflict resolution time, particularly when the business was impatiently “foot tapping” in anticipation of the urgent release.
- Complete features sitting idle.
The team was never satisfied watching features completed at the start of the sprint sit idle for several weeks before they were deployed. We would have much preferred to get those features into customers’ hands more quickly.
- Bug resolution
Despite our best intentions, bugs happen. Fixing them soon after development – when the feature and related business rules are fresh in the mind – is always easier than doing so weeks after the fact. Additionally, some issues are hard to uncover. Sifting through the code changes of fifty features is an order of magnitude more difficult than troubleshooting an issue caused by the release of a mere handful.
Approximately four to six months ago, frustration turned to action and the development team started to research and experiment with continuous integration methods. Over time, processes and practices were put in place to support a continuous model. These processes include:
- Automated unit tests.
- Automated functional tests.
- Implementation of a test coverage measurement tool.
- A concerted effort to increase test coverage.
- Implementation of a fully automated deployment pipeline that includes code deployment, test execution, as well as the ability to easily roll back any release
- Purposeful effort to keep the deployment time to less than 10 minutes.
Fast forward to today. While we aren’t truly continuous (yet), the team now deploys as soon as features pass QA, which is at least once per week but could be (and sometimes is) more often dependent on need. Deployment to each of our environments is fully automated and is triggered by a GitHub merge. Since implementing these continuous changes, the team is delivering features more quickly and fixing bugs faster with no decrease in quality.
“This is all well and good, Rich, but how does this story book ending apply to your shocking title questioning the usefulness of Quality Assurance?”
It was the culmination of these events along with the outcome of a few tasks running in parallel that turned my thinking towards QA and how it applies to continuous development. I’ll review those outcomes and my final thoughts in a follow-up article.
Stay tuned …
One Response to “Quality Assurance: is it still relevant?”