Over a million developers have joined DZone.

7 Types of Tests Every Software Tester Should Know

DZone 's Guide to

7 Types of Tests Every Software Tester Should Know

· DevOps Zone ·
Free Resource

No matter whether you're using automated or manual testing, there are a variety of test cases that can be executed. The trick is to understand what each instance does and how it will benefit a particular project. This knowledge will go a long way toward enabling quality assurance teams to thoroughly evaluate an app and ensure it meets expectations. Here are some of the many different test types and what they entail:

Ad hoc testing

Unlike many other testing methods, ad hoc is traditionally unstructured and informal. Testing Excellence noted that although someone using ad hoc testing will need a good understanding of the workflows and domain of the app, they typically do not need a reference to test design documents. Since the goal is to break the software to identify defects, a large amount of experimentation and exploration is required for this type of testing.

Black box testing

This method doesn't require a tester to know coding or the software's internal structure. It instead tests with various inputs and evaluates the results in comparison to an expected output. These tests are based on requirements and functionality.

White box testing

In direct opposition to black box testing, white box testing is based on the internal logic on a project's code. This method has also been known as structural testing and glass box testing. It uses techniques like path testing and branch testing to assess the coverage of conditions and code statements.

Unit testing

As a class of white box testing, unit testing is often executed by programmers to evaluate the unit he or she has implemented. Software Testing Help noted that this method often requires detailed knowledge of coding and internal program design. Unit testing is leveraged to gauge the functionality and reliability of the program, and helps ensure that components are behaving correctly prior to integration.

End-to-end testing

This type of testing is often performed by a QA team, and mimics real-life scenarios and usage. End-to-end cases evaluate a complete application environment from order creation until item return and other responses. By testing this information flow across the program, QA professionals can have a better idea of how well the app will handle requests and meet user needs.

Stress testing

Similar to end-to-end testing, stress testing measures the performance of the program - except it gauges operations under unfavorable conditions. By going beyond the limits of the app's specifications, QA can see how and when it fails. This will help shore up those areas to better handle adverse situations.

Acceptance testing

Unlike every other test case on this list, acceptance testing is performed by the user. This is often done as a precursor to verify if the program is truly viable for their needs. If users find that it doesn't live up to their specified requirements, they may decide to abandon the app or ask for something to be adjusted. This type of feedback will directly go into the product and help acceptance testing be more successful.

Regression testing

This test case is likely one of the most important instances that QA teams can perform. If a modification is made to a project's component, system or units, regression testing should be done to ensure that all elements are working correctly and that the change hasn't affected other modules to produce unexpected results. This type of black box testing instance will be impactful to the app's success.

There are a wide variety of test cases that can provide crucial insight into an app's viability. QA teams must understand the differences between each instance and how to leverage it effectively in order to ensure the best quality possible for all projects.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}