7 QA Terms You Need To Know

According to the app analytics firm Localytics, one in four mobile applications are abandoned after a single use. This often comes about through buggy interfaces, poor user experience, and an attitude that quality is unimportant or something that can be polished later. Software testing and quality assurance (QA) are tools and processes which can help improve the quality of an application by detecting defects in the product before release, which leads to improved outcomes for both users and businesses.

At DevelopmentNow, we take QA seriously. Unlike many consulting firms and small development shops, we have an in-house QA department and put all projects through the paces during all phases of a project. Our developers and our QA engineers work in tandem to establish and document a test plan which will ensure that the product undergoes complete testing. Once a project is in the development phase, the QA team analyzes changing product requirements to build test cases and ensure that each build of the software is up to our quality standards.

I caught up with Adam Leonard, our QA lead, and asked him to boil down his field’s vast terminology to seven essential terms. As a developer or a manager, it’s important to have a handle on these terms before going into discussions with a QA engineer or a QA team. They provide important context to the problems and issues which a well-run QA team can identify.

1. Test Case

  • What the QA engineer references to determine if a feature performs its function as expected.
  • A test case consists of specified preconditions, steps, and expected results.

2. Defect

  • Any deviation from an application’s specifications. Defects not only include bugs, but also any behavior not specified in test cases. These could include problems with the user interface, a poor user experience, spelling or tone errors in written copy, and so on.
  • Defects are logged by a QA professional, sent to the developers as a ticket, and then verified fixed by QA in later builds. A defect log typically contains a summary, description of the environment in which the defect occurred, severity, and detailed steps to reproduce.

3. Negative path testing

  • A test case which assumes a circumstance where the application is supposed to handle an error. For instance, a negative path test of a credit card payment system might assume that the user attempted to use an expired credit card.
  • Negative path testing verifies that the system handles the situation “gracefully”. That is, in the case of the expired credit card, a negative path test might verify that a notification alerts the user that their payment failed due to a bad credit card number and prompts them to enter new information.

4. Exploratory testing

  • A “hands on” testing approach which involves minimal planning on the part of the QA team. Exploratory testing can support more formal test strategies or play an important role in verifying the application by attempting unexpected actions.
  • Exploratory testing is commonly employed in security, where penetration testers play the role of hackers (commonly called the “red team” in security circles) attempting to break into a system.

5. Regression testing

  • A type of test commonly run on a new build which ensures that all previously tested functionality is still working.
  • Because new functionality might accidentally break old functionality in unexpected ways, regression testing is especially important in an environment with constant or continuous delivery of new builds.

6. Smoke tests

  • A minimalistic type of test which is designed to check only the most basic functions of a product.
  • Often performed at the beginning of a testing session to make sure that the application is ready for more advanced testing.

7. Integration (interoperability) testing

  • Integration testing checks how components of an application interact with one another and operate as a group. It can help identify where in the system a bug originates.
  • For example, imagine an application which uses Google Maps to display the user’s current location. If a bug was causing an incorrect location to display, the cause of the bug might be in the application itself — but it might also be an unknown bug in Google Maps. An integration test can help the development team determine this.
3

Written by Adam Leonard -- August 17, 2016

In the past ten years of practicing QA in mobile software along the west coast of the United States, Adam has honed a dizzying array of martial kata for doling out street justice to dirty code. If there's one thing Adam doesn't like, it's software that needs to be taught a lesson. It's a hard way of life but someone has to do it. Adam also happens to be a multi-faceted individual interested in Hi-Fi audio, cars, futurism, art, Industrial Design, the perfect breakfast burrito, EDM, and DIY.