In Defense of System Test: 3 Benefits You Can’t Ignore

Deploying a system into production without adequate testing is like driving a car without knowing if the brakes work properly.

No system is free of defects, so you’ll need to identify them and determine their impact prior to deployment if you want a successful implementation. All critical defects should be fixed prior to a release, and those that can wait to be fixed post-launch should be communicated out to users. Only once this is done can you make a game plan to ensure a proper release schedule.

Time and money will be saved in the long-run if you thoroughly test a system before it’s released. Some people try to ‘cut corners’ by eliminating the System Test phase of software releases with the assumption that defects will be identified during User Acceptance Testing (UAT). This is a poor, and sometimes catastrophic, philosophy because up to 40% of software implementations will be spent in various testing phases and shortcuts are rarely advisable.

Here are the top 3 reasons for performing System Testing in addition to UAT:

1. Early Identification of System Defects
2. Varied Approach and Objective
3. Second Set of Eyes

Acknowledging these key benefits is crucial to project success. Let’s walk through them:

1. Early Identification of System Defects

In traditional Software Development Lifecycle (SDLC) projects, you’d perform UAT after development, once system and performance testing are complete. It’s difficult to fix major issues identified during UAT because most projects provide minimal time for UAT and then schedule production deployment immediately following it. This leaves your Project Management team with two options:

1. Delay the project launch (this increases cost)
2. Rush a fix (this introduces risk due to insufficient testing time)

Unfortunately, these unappealing options put strain and scrutiny on the project team and implementation process.

2. Varied Approach and Objective

When you get ready to deploy a system, you must first recognize that system testing focuses on verification while UAT focuses on validation. What’s the difference?

• Verification is testing based on specifications and requirements
• Validation is testing based on real-world operational conditions

To put that into context, consider that all business and technical requirements are mapped and tested against sample scenarios during the System Test phase of a project. After that, you can build a detailed test plan to ensure full coverage of the system.

In contrast, UAT focuses on ensuring the system supports “real world” scenarios but won’t validate against all business and technical requirements. Without the inclusion of a System Test, there will be gaps. Also keep in mind that UAT members are typically business owners, not technical by nature, so they’ll focus on validating the GUI instead of database/backend testing.

3. Second Set of Eyes

Your objective for System Testing is to go through at least three testing cycles in order to confirm a “clean” final test (defined as no defects or at least no new defects discovered). The more test cycles you run, the higher the likelihood that all defects will be identified prior to UAT. Additionally, when you find and fix a defect during System Testing, the specific test case and subsequent regression testing will be executed to confirm that the defect has been resolved and the fix did not introduce new issues.

As you might expect, UAT doesn’t always follow the concept of test cycles. Business Users, for example, will only test their business scenarios. If issues are uncovered, they’ll wait for a fix and then retest the same scenario to ensure the fix is valid. They probably won’t go one step further to ensure there aren’t unwanted consequences from a fix. Their focus is to ensure their specific business scenarios are validated.

To sum it up, here are three key takeaways:

• The later you find defects in your software development life cycle, the more time and money is required to implement solutions in production.
• If you only perform UAT, you’re at risk of failing to test components of a system that will result in more production issues, rework, and subsequent bug fixes post-launch. In addition to wasted time and money, this results in a poorer user experience, potentially causing your software to lose some of its customer base.
• More is better. The more test cycles you execute, the better the chances are you’ll uncover most, if not all, defects in your code base.