There Is No Quality Without I: Second Installment

First Time Quality

With the need for a team to move fast while preserving the eminence of the software application, the simplest solution is to ensure quality the first time. The double-edged sword could be turned into an Occam's razor. Occam's razor (also Ockham's razor or Ocham's razor; Latin: lex parsimoniae "law of parsimony") is the problem-solving principle that, when presented with competing hypothetical answers to a problem, one should select the one with the fewest assumptions.

First Time Quality is the notion that all the wheels in the cycle align correctly, at the first attempt. While this sounds great, it's a far stretch from reality.

Assuming a 90% accuracy in each of the five main phases of software development: requirements, design, development, testing, and deployment, it only achieves about 59% overall First Time Quality. A more realistic 65-70% of the time getting everything right means 11.5-16.5 times out of 100 that the feature needs to be assessed and fixed after release.

This release turns the paradigm of "There's no I in TEAM" on its head, leading to the tautology of "There's I in Quality," since every single person is responsible for ensuring the quality of their work.

Swiss Cheese Model


Image Source: Wikipedia

The Swiss cheese model of accident causation is a model used in risk analysis and risk management, including aviation safety, engineering, healthcare, emergency service organizations, and as the principle behind layered security, as used in computer security.

Although many layers of defense lie between hazards and accidents, there are flaws in each layer that can allow the accident to occur. The model was propounded by Dante Orlandella and James T. Reason of the University of Manchester.

In the software development context, this model suggests that the scenario of an issue making it all the way into production is primarily when the requirements fail to capture certain user events, the design does not accommodate it, the developer fails to account for it, and QA fails to test it as well. When you enforce first-time quality as the guiding principle in the team, the chance that bugs get into production reduces significantly.

Given a five-phased software development process, tightening the last three phases (development, testing, deployment) using smart strategies and automation, first-time quality of the overall product improves markedly.

Improving Development Quality

The first step to creating code for a product or project of any value should be setting up a version control system. Such a system allows for saving your work without the fear of losing it when your machine does not wake up, storing snapshots and traceability when an issue arises. It helps with identifying the potential cause of a failure. With the widespread SAAS (Software As A Service) model, the cost initiate this has becomes trivial. There are several options available in this area with their own pros and cons for you to consider for your specific needs.

In addition to using a version control system, leveraging such a system to support collaborative development is key. Following a good branching model and tagging practices like GitFlow enables a fast turnaround for fixing problems.

Once you are done with writing the code, calling forth a code review is highly beneficial, for a second pair of eyes to look at, even before the code is merged. At times it may be difficult to find the people, who can impact the most, for this review. In such cases, offline reviews at their convenience with a deadline would work just as well. Skipping this step would only be at your risk. Github's pull request feature made this step much more achievable, and at one time, the cool thing in development circles. At this stage, I would also encourage mandating tests to go along with the code that's being reviewed. Even if that be one single test, it calls for the developer's attention toward testing what he/she implemented. It also familiarizes the developer on testing frameworks and tools. Over time, this practice facilitates the growth of the test suite that can be used to assess the state of the product.

Improving Testing Quality

Software QA has been the subject of many a research for rightful reasons. This testing is the last gate to catch issues before a product is released. Several models for testing have been proposed like the testing pyramid, the inverted testing pyramid, or the ice cream cone testing and others. What ever be the model your team has adopted, making sure that a good chunk of the tests can be automated is the key. Allocating who is responsible for what kind of tests keeps the waters clear and avoids last minute rush toward meeting a release deadline.

For instance unit tests, which are for the smallest testable units of code, are ideal for developers to build. As noted above, mandating these tests for every feature or fix decreases the chance of missed edge cases. Embracing practices like TDD (test-driven development) and BDD (behavior-driven development) can lead to excellent results. UI tests, system tests, integration tests, and functional tests are best doled out to the QA team.

Frameworks like Robot, Galen, Gauge, and FitNesse are great to add to any QA team's tool belt. They are typically easy to install, facilitate test reuse, flexibility, and maintainability, and more importantly, allow for automation.

Despite using frameworks for the benefits they bring, manual testing is unlikely to be dispensed with. At the end of the day, it is a human interacting with the software and the final judgment is based on a combination of human characteristics—what the human wants, how the human might act, perceive, and react. In some cases, results may even vary, especially when the human has had a bad day!

Writing The Right Tests

While the test pyramids refer to the time taken to set up some of the tests, a critical dimension to evaluate what tests to setup is their value to the user. Having a large volume of tests for a minimally used feature is worse than having no tests at all when the time and resources pumped into such an endeavor are considered. Following the Pareto principle, which states that 80% of the effects come from 20% of the causes, investing testing resources on the 20% of the features that provide 80% value to the user, yields an exception ROI. And having set up the different kinds of tests, running them in an environment as close as possible to the live application rakes in the best results.

Improving Deployment Quality

Many times, deployment is the most ignored phase in the software development cycle. When it comes to releasing a product, it is a wonder why teams do not consider writing a script that automates the different steps of copying files, creating folders, updating databases, etc. Automating this release process opens the door to even better practices. It allows for deploying a new version of the software any time, thus promoting running tests on the latest state of the software leading to the above mentioned Continuous Integration and Continuous Delivery. One noteworthy element of deployment is having the version, of the product currently in use, accessible. Apart from causing a sigh (of relief, hopefully) for the team that worked hard in getting this version out, it carries a psychological weight to the user that they now have their hands on the latest and greatest product.

Seven Deadly Sins of Software Development

Below are the simple practices, not following which can lead the entire team and the product to doomsday sooner than later.

1. Not using Version Control, like SVN, Git, Mercurial, etc.
2. Not writing unit tests
3. Not writing system tests
4. Not running the tests regularly
5. Not involving users
6. Not prioritizing the tests
7. Not having the latest tested build accessible at all times

Without structure, discipline, and accountability, it is unlikely that a software product can succeed. With every person on the team following good development and testing practices, it is possible to achieve the holy grail of software development—fast, bug-free, fault-tolerant software releases.

Usha Guduri is a dynamic, team-spirited, performance-driven engineering professional with a blend of leadership essence and conceptual excellence.

Over twelve years of experience in software design and development of highly distributed, scalable and performance optimized, low-latency systems with an exceptional aptitude for both front-end and back-end technologies.

Over a six year proven record as a team lead, hiring and managing the best engineering talent across time zones and collaborating with Product, Marketing, and QA teams across continents with outstanding results.

Opinions expressed by the author are not necessarily those of WITI.