4 Steps to Great Quality Control

In my nearly 20 years working in IT and Software development I have been asked by IT Leadership to review many failed or struggling software projects. Software projects often fail when they reach the ubiquitous Quality Control (QC) stage of the Software Development Lifecycle (SDLC). This typically occurs because the team did not bake in disciplined quality practices early in the SDLC and are left with what seems an insurmountable number of defects to fix as they enter QC or attempt to leave QC.

You wouldn't bake a batch of cookies and add the sugar after the cookies have entered the oven. Likewise, you shouldn't think about quality only when entering QC.

Fortunately, in recent years there have been a number of advancements in process approach and software tooling that can help resolve these problems.  As IT leaders, we owe it to ourselves to understand what these tools are and how we can embed them into our SDLC process to ensure we catch quality issues early on. It is my belief that there are a number of practices and tools that can be used to ensure that quality principles are considered earlier in the software development process.

1. REVIEW REQUIREMENTS, DESIGN AND CODE

Early reviews are critical to the quality of the final work product. A solid SDLC process should be established to ensure reviews occur at key stages within the lifecycle. Process approach such as CMMI will help guide SDLC definition. Tools such as: Atlassian JIRA, FogBugz and RallyDev can be customized to ensure that reviews are baked into the workflows used to create work products.

2. DEVELOPERS MUST TEST LOCALLY
Developers should write automated functional and unit tests and ensure that the test works locally before committing to the source control repository. Tooling such as JUnit, JMock and NUnit can be used to create unit tests and automated integration tests can be created with tooling such as Gauge or Cucumber.

3. TEST IN AN INTEGRATION ENVIRONMENT
Once the developer has successfully completed local testing they can commit it to the source repository. Code committed to the source repository should be built automatically using tooling such as Jenkins or Bamboo. This automated build gives the developer and team the opportunity to ensure that the code builds properly and that unit tests have passed. The code artifacts should then be automatically installed to the Development Integration Environment (DevInt). Once installed to DevInt, automated security, functional and unit tests are run and the developer has the opportunity to test their code that has been integrated with other developers' work. Tools such as GIT, Gradle, Jenkins, Artifactory, SonarQubeand Ansible can be used to automate this process.

4. BUILD AND INSTALL TO ALL ENVIRONMENTS THE SAME WAY
Automate everything from the creation/provisioning of the environment that the software will run on, to the installation of the software running on the environment. We've all been involved in projects where every environment is different and the chaos that ensues. Environment creation and installation should be part of the software solution development no different than the UI or Database; we should bake this DevOps mentality into the way we think about environments as they relate to software.

Kingland prides itself on the quality of our software solutions. Our solutions have some of the lowest defect densities in the industry and we believe that can be attributed to great people, great platform components and disciplined approach to process. We have applied these principles to our own solution development methodology, which we call the Kingland Platform DevOps components and have seen incredible results. In some cases we have lowered defect density in QC or UAT by up to 300%.

If you're interested in learning more about our QC process, schedule a time to chat with me.