QA Prevents Waste from Spoiling Your Budget

Software is a perishable good. While it may not spoil as fast as produce from the grocery store, it certainly has a shelf life. Over the long run, changes to technology and consumer preferences will make even the best software less useful.

In the short term, however, software spoilage can occur much faster. Software development resulting in unused features, bugs, or defects becomes waste. Essentially, waste represents spoiled work that is diminished in value or totally lost.

Even bug-free software can result in waste

It is important to remember that even bug-free software can result in waste. Work that is performed but does not enhance the value of a software application is effectively wasted.

Changing requirements and unclear objectives are some of the conditions that can lead to wasted work. In the world of project management, a great deal of effort has gone into reducing waste, which has gradually led software development away from top-heavy planning methods such as waterfall toward more iterative development methods such as agile and lean software development.

Automated software testing can also contribute to wasted code through:

• Inadequate planning

  • Engineering teams tend to forget that automated software testing is a form of software development, and may not place the same emphasis on planning and engineering resources that product teams often receive.

    • From my experience, achieving reliable test data and stable test environments can be a challenge, as providing these requires collaboration across testing, developer, and DevOps domains.

  • Plan your automated tests to make them easy to maintain

    • Write code that is easy for other people to understand

      • Favor communication over cleverness. Code is meant to explain to other humans what you want a computer to do. If your team members don't clearly understand what a segment of code does, that's a clue to consider rewriting it.

    • Prefer test automation libraries that are well-known

      • You won't always be the one maintaining your code, or be able to recall exactly what you were thinking when you wrote it.

      • Favoring test automation techniques that are time-tested and have lots of examples on the Internet will help other testers learn faster. While not every example on the Internet is good, they can at least serve as a guide. Even a bad plan is usually better than no plan at all!

Like any other code, automated tests are code that you will write once and then have to maintain forever. Over time, the time required to write a test will be eclipsed by the time needed to maintain it, and as you write more tests the overall test maintenance required will also grow.

• Unrealistic expectations

  • If your team is trying to automate 100% of manual test cases, you might want to reconsider. The point of automated testing is to save developer labor by detecting bugs early and preventing waste, whereas saving manual test labor is secondary. In fact, every automated test starts as a manual test!

    • The testers performing the automation will have to investigate and understand the feature being automated, so at least some manual testing has to be performed even if a test will be automated afterward.

• Writing unnecessary tests

  • Automated tests derive more value the more often they are run. An automated test run only once or a few times is likely a waste, as the same test could probably have been done manually without investing time to automate it.

    • While this is purely my opinion, for this reason, I tend to be against creating end-to-end automated tests for specific defects. Automated tests for features related to frequently edited code are a good idea. Most of the time, however, developers aren't fixing the same problem. Usually, developers will fix a defect, QA will test the fix (manually, I might add), and if customers are happy with the results then the underlying code won't be changed again. If the code doesn't change, how many new bugs are likely to emerge?

Catching bugs earlier prevents rework later

Insufficient testing can lead to the detection of bugs late during development or even missing them entirely. In a sprint-driven development cycle, insufficient testing can often occur toward the end of a sprint when development work is rushed to completion.

Since almost every story requires at least some QA after development work finishes, receiving a story late in a sprint compresses the time during which the story can be tested. Even when engineering managers attempt to enforce a "Definition of Done" that includes manual and automated QA testing, there is going to be considerable pressure placed on QAs to reduce testing and finish a story before a sprint is closed.

Once a bug creeps into production resulting in a defect, one can soon expect additional, unplanned work. Who wants another late-night hotfix? Additionally, the longer bugs and defects go undetected, the greater the chance that other code will be written that depends on the erroneous code, increasing the scope of a bug fix.

Time Value of Money: the sooner the better

The concept of Time Value of Money (TVM) suggests that money you receive now is worth more than money you expect to receive later. Money received further into the future is less certain to be received, and is less valuable due to inflation and missed opportunities you could have pursued with the money. As a result, you'd rather have $100 now than $100 twenty years from now.

Assuming a software feature is worth a certain amount of money, delivering that feature faster contributes to software value sooner. Applying the same logic, the same is true of bugs; detecting a bug early in the software development cycle is far more valuable than detecting a defect in production.

To prevent waste, emphasize testing as early as you can. As much as you can, plan your tests (and even start writing automation) before developers have written code, and run automated tests frequently once development begins to provide developers with fast feedback on potential bugs.

QAs have a special role to play in preventing waste by catching bugs early and providing fast feedback for code being developed. Over time, like compound interest, all the time saved from the defects and rework that didn't take place is time that is turned into more stories completed and product features released.

Less waste, more success!