Software testing is becoming a very mature area, even has a formal name - Software Quality Assurance (SQA). SQA is part of the software manufacturing process, and nearly all software manufacturers have this process integrated in their production process. Furthermore, this is advertised as a market strength of the manufacturer.
However, a lot of software manufacturer SQA processes cannot replicate conditions existent at the real user, some may even be unawhare of them. So, if the buyer of the software unconditionally trusts the SQA process of the manufacturer, he may find himself exposed to risk that the software still does not perform according to expectations.
Here is an acceptance testing model that companies can apply to verify what the software they purchased is performing to expectations.
Acceptance testing should not be done only when purchasing a piece of software. Instead, it should be integrated into change and release management as functionality test. This test should prove that the new versions deliver the promised changes, and that all current and used functions are maintained and bug-free.
To perform a proper acceptance test the organization needs to
- Define which functions are tested - all new functions, and ALWAYS include the current business critical functions for re-test. New versions tend to creep-in bug at places that worked perfectly, so re-testing critical functions will just keep you safe.
- Define who performs the tests - The testers should be subject matter experts for the specific functions. These people have seen the shit, and know how it stinks. These people will know best how to create a proper test scenario and preconditions
- Define the scenario of testing each function - Always define what scenarios will test the function. Include both normal operation activities as well as boundary conditions, where the testers will try to break the software. But since SQA should have weeded out the boundary conditions, focus more on normal operation.
- Make a detailed log of the test - the log helps a lot of people: the software manufacturer to recreate the error, the testers in the next round to see what did and didn't work under which conditions, the auditors to review the process. So ALWAYS DO IT.
While the software is different for any organizations, the process is nearly the same.
Here is a template for the Software Acceptance Testing Log the organization can easily adapt for local use
3 Rules to Avoid Problems due to Changes in Development
Talkback and comments are most welcome