Choosing How to Test: Modes and Automation Types

Effective testing begins long before any test code is written. Before deciding what to test, you need a plan for how to test. This means settling two fundamental questions: whether a human or a computer should run the tests, and whether you want to examine the application’s internals while testing. Once those decisions are made, you can break test automation down into distinct types, each suited to different quality goals.

The Two General Testing Modes

The first and most abstract decision is whether to test manually or automatically. These are not mutually exclusive, and quality assurance usually depends on a mix of both.

  • Manual testing: A person, typically a QA engineer, drives the process. The most common form is exploratory testing, where the engineer follows a checklist or predefined path while probing the application for issues and attempting to break it.
  • Automated testing: A computer executes the tests. This mode is best for replacing repetitive, monotonous test runs, freeing humans to focus on more creative exploratory work, such as validating user experience quality and high-risk business logic.

Another axis to consider is how much you know about the system under test. This choice influences how you derive test cases:

  • Opaque box testing (black box): Tests are derived from functional or non-functional specifications to examine output behavior, ignoring the internal structure entirely.
  • Clear box testing (white box): Tests take the application’s internal architecture and code into account when building and running cases.

Both procedures apply to either manual or automated testing, though some automation types lean more heavily toward one approach than the other.

The Three Primary Types of Automated Tests

Automated tests are generally classified by the scope and granularity of what they verify. Three common types stand out, and most test strategies are built from them.

Unit Testing

Unit tests focus on the smallest testable parts of an application, treating each one as an independent unit. Units can range from a single function or class to a full component. This test type is characterized by fast execution, strict isolation, and easy maintainability. Its job is to confirm that each individual block behaves correctly on its own.

Integration Testing

Integration tests verify that components or systems work well together. Where a unit test might validate a single function’s logic, an integration test ensures two parts—or complete APIs or components—interact correctly. These tests are essential for catching the failure modes hinted at by the classic "drawer" problem: drawers that function alone but collide when combined.

End-to-End Testing

Also called UI tests, end-to-end tests exercise the entire application stack. They simulate genuine user interactions, starting from the UI and running through to the system’s other end. This resembles what software testing theory calls a system test. Because they involve the whole application, end-to-end tests take significant runtime and computing resources, leading to higher maintenance costs.

Visual UI testing

A notable subcategory of end-to-end testing is visual testing. It extends UI tests by capturing a screenshot of the application after a change and comparing it to a "golden file" containing the previous visual state. These screenshots are then provided to a human reviewer to inspect for visual bugs—unexpected differences in page appearance that are not caught by functional assertions.

Static Analysis: A Companion to Tests

Beyond these test types, static analysis plays a distinct role in quality assurance. It does not run the program but scans the source code for potential defects, syntax errors, and style issues in a way similar to a spell check. This preventive measure can mitigate many bugs before a test suite ever executes. While not a testing type in the strict sense, static analysis is a common component of overall testing strategy.

For many projects, the challenge is deciding where the balance between these test types should lie. Common models like the Test Pyramid, Test Diamond, Test Ice Cone, Test Honeycomb, and Test Trophy offer visual frameworks for choosing the appropriate distribution. Each suggests a different proportion of unit, integration, and end-to-end tests based on the system’s unique priorities. The right mix depends on your application’s structure and your quality goals.