Often overlooked in IT departments, QA plays a critical role in getting applications ready for production. At a minimum, QA must check out each application at its “unit” level to ensure that all of its logic works correctly. For online apps, QA makes sure that the data fields are properly filled in and data retrievals and stores to databases execute as intended. However, there is a lot more involved in a thorough QA checkout of an application than a simple unit test–and it often involves QA experts at both the technical programming level and the end-user/business level. To guarantee the quality of performance users are looking for, here are 10 tests that QA should always put apps through before letting them go live.

1: Regression testing

If you’re dealing with an existing app that’s being modified and placed back into production, QA should perform a regression test to ensure that new content that has been introduced into the app continues to work with the other system resources the app uses. A good example is a data field that suddenly changes in the app–only the same field has not been changed in the database that the app accesses. Consequently, when database access is attempted, the app fails. A QA test that backwardly checks for compatibility will identify problems like this.

2: Stress testing

An app that must handle thousands of transactions per second coming from anywhere in the world and at anytime should be put through the stress of “maximum” transaction loads that emulate what the app will have to support in production so QA can verify that the app can handle the load. If the app runs over the internet, the boundaries of the stress test should also extend to internet nodes around the world from which transactions could be executed. Sometimes internet bandwidth or service in different geo areas is constricted. When an app fails a stress test, it could mean that more processing or storage must be allocated for the app–or that alternate internet channels must be opened up to achieve the level of bandwidth and service required to support a particular geographic area. By working with network specialists and app developers in stress test scenarios, QA can identify these potential choke points so that they can be addressed before an app is deployed.

3: Security checkout/stress test

Fundamental user ID/password checkout is routinely performed by QA departments, but checking for backdoor vulnerabilities isn’t. Especially if the app is a highly sensitive one, QA should collaborate with network and security specialists to do as much security bulletproofing in checkout as possible.

4: User friendliness/user test

Even if an app performs the functions it was designed for, it’s not very useful if users can’t understand or use it. This makes it important for QA to work together with end users in app testing to ensure that the app’s human factors and usability check out. If they don’t, the app won’t get used.

5: Completeness of documentation

Documentation is often the first part of app development that gets left behind. This might be fine for a newly deployed app that must be rushed to market. But when it comes time to repair or to enhance the app, anyone who follows the app’s original developer is going to lose time trying to understand the code and all the internal functions the app performs. As part of the QA checklist, QA should review app documentation for completeness.

6: User support

Before an app is deployed, the IT help desk and business users of the app should be thoroughly trained in the app’s functions–and app documentation (see #5) should be complete.

7: Business process flow checkout

If a new app is going to alter a business process flow, the app should be given a dress rehearsal checkout in the end-user department prior to going live. The dress rehearsal run-through ensures that everyone understands how the new app and the business process it changes work. For instance, let’s say that in the past, underwriters in a bank’s loan department made their own decisions about whether to grant a loan. But now a new app is going to evaluate every loan application and return a loan decision that the underwriter can override only with a supervisor’s approval. This is a business process as well as an app change, so those being assigned to do the business must understand the new app and process flow before it is placed in production.

8: Metrics confirmation if tied to key performance indicators (KPIs)

Some new apps and systems are developed expressly to improve revenue flows, reduce costs, or speed time to decisions. If there are measureable KPIs defined for a specific app and it is feasible to do so, QA should test whether the app meets the metrics that the end business and/or IT have defined for it.

9: Code standardization

Most IT departments have standardization guidelines for application code, along with libraries of common objects and routines that all developers should use. Part of the QA checkout should include a code review to ensure that the app’s code conforms to company standards.

10: Multiple user interface (UI) deployment

If the app is to be deployed on an assortment of desktop and mobile devices, the app’s user interface looks and footprints will vary for each device. QA should check out the usability of these different interfaces on their intended devices, as well as checking out factors such as load time.

Also read…

Other QA tips?

What advice would you give for making sure your QA checklist is complete? Share your suggestions with fellow TechRepublic members.