BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Moving beyond user interface testing means testing using error logs, database queries, internal system message reviews, services connections and any other back-end processing engines. In other words, it is now about testing the "stuff" behind the safety of the UI.
However, for many testers, it's unclear where to find the information necessary to test beyond the UI. After all, it's unusual in today's software development world to receive detailed specification or design documentation prior to testing, if at all. However, with the growth of external-facing APIs, it's not unusual to find the information you need within the instructions for external developers to connect to public-facing APIs. In order to get the remaining information, spend time with the software and database developer.
Let's review a few areas to consider when going beyond user interface testing, including data trails, service connections, internal messaging and error logs.
The most common way to look beyond user interface testing is by examining and verifying database values. Software applications update data constantly. Changes in the UI can trigger ongoing or multiple database value updates, kick off triggers and be managed through indexes, just to name a few possibilities. Tracking and verifying data value changes triggered from UI actions provides valuable testing data. For example, many QA testers use SQL to create a repository of tests for verifying database values and then execute them before user interface testing. Defects not visible in the UI can frequently be evident in the database, and testing within the database can find defects before user interface testing occurs. Data errors can stop an application in its tracks, hence it's a smart choice if you want to go beyond traditional user interface testing.
I refer to database testing as verifying how data trails or changes based on UI actions. For example, verifying a data value and how it updates along the trail is critical for operations involving complex calculations, such as those used for business analytics, reporting and data transfer. Testing encryption effectiveness is also part of testing the database. More and more data is required to be encrypted when at rest (stored), as well as when it's being actively transferred. It is feasible for QA testers to test encryption by attempting to manipulate data. Before testing secured data, be sure to notify your database developers and IT group. Testing database security is wonderful, but you need to make sure others are aware of your efforts.
Testing services that enable connections and exchange data
Testing API connections both externally and internally is a second option for going above and beyond user interface testing. API connections often allow applications to bring in or exchange data with other systems. For example, healthcare or government data exchanges commonly share data to increase efficiency and data accuracy. The ability to verify data is shared and exchanged securely and accurately, which cannot be accomplished by user interface testing alone. For testing services, a QA professional needs the specific information on the endpoints, the security protocol used and examples of the request and response. With this information, QA can test external and internal connections to find security handling or data transmission defects.
Software development teams frequently automate API-related tests to verify functionality and connectivity. Automated tests will cover the basics, but manual testing needs to be performed under the surface. For example, a QA tester can attempt to manipulate the connection to gain unauthorized entry, send invalid data or even shut down endpoints. Another valuable test is verifying the data cannot be intercepted, altered and then sent out without detection.
Again, if you plan to attempt to thwart the system security, be sure to notify the IT department and work with the development team to ensure testing is done effectively and the system remains both functional and secure.
Data transfer (internal messaging)
Many applications that are a collection of several single applications often use an internal messaging system to transfer data. The transfer occurs between applications or external devices, like medical equipment or a GPS tracking device. The most popular internal messaging systems are Health Level Seven type languages and Extensible Markup Language. Messaging systems have a heavy database impact, so planning to test them in combination with the database is advisable. The QA tester needs to learn to read the message and review message data in order to verify the data being transferred is accurate in both the outbound and inbound message.
Reviewing error logs is a necessity when QA works closely with development. Evidence of the actual error saves development time in figuring out the problem and getting it fixed. Error logs may be generated by the application itself and can also be located in server files. For example, if QA is testing an application running on Windows, the server Event Log viewer is a valuable source of OS-related issues.
As a QA tester, it's important to review error logs frequently. It's daunting at first to read through the logs and get anything useful. However, once QA becomes familiar with the log file language, scanning the logs becomes more effective. Within the log files, QA can see evidence of the application running end to end, including application responses to error messaging. Frequently, errors display in the log file before they are seen in the UI, making it a worthwhile endeavor when going beyond user interface testing.
In the current software business environment, user interface testing isn't enough -- going beyond it is becoming an essential practice. QA testers must pursue defects both within and behind the scenes of the UI. Better quality applications require more in-depth testing, especially as applications and the data they contain become increasingly complex and connected.
Why is automated testing so hard to do?
Software testing is about to change -- radically -- again
Why testers are going to need to love data science