AKH Online, Inc

This is important stuff...

Releasing a web application for public use – without performing a complete quality review – will impact your business a bit now. More importantly, productivity on future application development will suffer as well.

Over time, as more and more slightly flawed applications are released, your developers' time will be increasingly consumed with fixing the impact of mistakes, locating and correcting their core cause. Left unchecked, your geeks will eventually be virtually immobilized by bugs, unable to devote quality time to your new projects. Death by a thousand cuts...

Without complete QA testing, your resources will be continually siphoned away to fix bugs

 

In a perfect world, quality review should be performed by paid QA professionals. They have experience in creating test plans that insure every possible combination of data entry and user action is uniquely applied; and can create issue reports that assist developers in isolating and fixing bugs permanently. They can also insure "scalability": that your code is designed to handle a load far greater than your own staff could ever apply.

 

"We test our own work"

This is a foolish notion. While the end-users, business users or managers certainly can test an application; they all have an embedded desire for the application's success - a mental conflict of interest. Also, they lack the time to complete lengthy regression tests, and might skip sections of the application they assume could not possibly have been affected by a recent change.

Lacking a perfect world and QA budget, business users and project managers can perform testing, but must try to avoid the natural application of their business model experience. In other words, “act like a simple user”. Here are a some basic testing methods.

It's a well-established fact that the developers can not reliably test their own work, much as talent show judges could not be expected to reliably score their own children as contestants. Don't expect those in a development role to fill the role of a QA or Business rule tester.

 

When extermination exceeds the cost of the bugs

There's another advantage in having competent QA skills on hand: rapid analysis and extermination. Without a clean bill of health between releases, there's a tendency among users to attribute all bugs to the latest release - rather than their latest sense of awareness. While wearing their temporary "QA" hats, testers may trumpet a brand new bug - that is actually a stale pre-existing problem. This will often send developers looking in the wrong place, which wastes time and money.

In order to properly diagnose and repair a broken application, developers must also know where the problem happened, who it happened with, and what the screen said when it happened. It can be hard to capture all this information - when it's not really your job to do so. Many will simply fire off an email with a terse complaint that something didn't work.

Your enterprise can pay far less - for a QA analyst to track down, verify and reproduce the bug first - than to have a highly-paid developer troll the code for possible problem areas, and then release multiple guesses at a solution.