What is the best test management software for small teams?

For teams of two to ten: Testpad for plain-text test plans with flat-priced tiers and free guest testers; Tuskr or Testiny for structured test cases with free tiers; TestLodge for content-based pricing with unlimited users; and Qase's free plan for dev-centric teams unifying manual and automated testing. TestRail fits small teams that run formal, regulated QA.

What should a small team look for in a test management tool?

Seat pricing that tolerates part-time and external testers, a fast start with no schema to design, a format light enough that the team keeps it current, and a cheap way to let clients or coworkers outside QA run tests.

When does a small team need a heavyweight tool like TestRail?

When process is the driver rather than team size: regulated releases, per-user permissions, audit history, or formal traceability requirements. Avoid buying the heavy tool for a process you don't run yet.

Testpad | Blog

Testpad vs Qase: test plans, not a unified QA platform

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

The difference between Testpad and Qase is one of scope. Qase is a platform: it stores test cases in a repository, pulls in your automated results and CI runs, and layers AI on top to write and automate cases. Testpad is a lighter tool built around the test plan: a checklist of plain text prompts you write, run and share. This page sets out the difference, where each tool is stronger, and how the costs compare, so you can decide which fits the way your team tests.

The short version

A test in Qase is a case record in a repository: preconditions, steps and expected results, organized into suites, with test plans, runs, environments and shared steps around it. A test in Testpad is a line of plain text in a checklist.
Qase's pitch is unification: CI results, automated test runs and manual runs land in one place, and its AI agent (AIDEN) drafts cases from requirements and converts manual cases into Playwright, Cypress or Selenium code.
Teams choose Testpad for write-speed, no-login guest testing, and reports you can share as a link.
Qase has a free plan for up to 3 users and 2 projects. Testpad has a 30-day trial rather than a free tier, but every paid plan includes all features.
Testpad is from $10/user/month, and guest testers are free. Qase is free for up to 3 users, then from $24/user/month ($19.20 billed annually).
Neither choice is wrong. It depends on whether your testing centers on an automation pipeline or on people working through a plan.

What's the actual difference?

Qase is built around a case repository plus your automation. A test is a case: preconditions, steps, expected results and fields, filed into suites in a repository. Test plans select cases from the repository, test runs execute them, and shared steps cut duplication between cases. Around that core sits the platform: reporters and an API push automated results in from CI, dashboards combine automated and manual outcomes, and AIDEN (Qase's AI agent) generates cases from requirements or converts manual cases into Playwright, Cypress or Selenium code, paid for with monthly AI credits. Qase describes the goal on its homepage: bring "CI results, automated tests, and manual runs into one place".

Testpad is built around the test plan. A test is a line of plain text. Indenting builds the plan's structure: group related tests under a heading, or spell a bigger test out over several lines. Add a column for each test run, and mark each prompt pass or fail as you go. There's no case repository to organize first: you write the way you think, and the structure comes from the outline, not from a form.

If your automation pipeline is the center of your quality picture, Qase is built to sit on top of it. If your testing is mostly people working through checklists, and a case record per check is more admin than the check deserves, that's the gap Testpad fills.

How do Testpad and Qase compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	Qase
Data model	Documents holding test plans: each a nested outline of test prompts that look like a checklist	Repository of test cases with preconditions, steps and expected results, in suites; plans and runs draw from it
Time to first test	Minutes; no case structure to design	Longer; set up projects, suites and case fields first
Writing tests	Type a line, hit enter, repeat; or copy/paste import from AI suggestions	A form per case; AIDEN generates cases from requirements (uses plan's AI credits)
Automated testing	Push results from CI via REST API; results sit alongside manual runs in the same plan	A core strength: reporters for major frameworks, CI integrations, unified dashboards; AI converts manual cases to automation code
Guest / UAT testers	Share a link; no login, no seat	Every user recording results needs a seat; read-only seats are a paid add-on ($2 to $5 per user/month)
Reports	An instant link, shareable with anyone	Dashboards and analytics inside the platform
Free tier	No free tier; 30-day trial includes all features and up to 20 users	Free plan for up to 3 users and 2 projects
Per-user access control	Not today; anyone in an account can edit	Role-based access control on the Business plan
Integrations	Clickable issue links (Jira, GitHub, Trello); REST API and webhooks	35+ integrations across issue trackers, CI/CD and automation frameworks
Pricing	From $10/user/month, guest testers free	Free (3 users, 2 projects); Startup $24/user/month; Business $30/user/month
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up	Dev-centric teams unifying automation and manual QA in one platform

Facts checked against qase.io and its published pricing, July 2026.

Why do teams choose Testpad over Qase?

Guest testing, where guests don't have to log in. When a release needs more eyes, hand a client, a freelancer, or a non-technical coworker a link and they're testing in minutes. No account, no seat, no onboarding call. In Qase, everyone who records a result needs a seat, and even read-only access is a paid add-on. For client UAT rounds, that difference decides the tool.

Write-as-you-think speed. No form per case. Type a prompt, hit enter, type the next. A 30-line regression plan takes minutes to draft, and it reads like the checklist it is. Qase's AI can draft cases for you, but you still end up owning a repository of case records that someone keeps current.

Plans people outside QA actually read. A Testpad plan looks like a document, so a product manager or a client can review what will be tested before a run and see what happened after it, from a shared link. Test reports are links too, not exports.

The whole tool on every plan. Testpad has one feature set; plans differ only by tester count. Qase spreads capability across tiers: role-based access control, case review and traceability arrive on the Business plan, SSO on Enterprise, and AI work draws on a monthly credit allowance with extra credits billed per use.

Less platform than you're paying for. Qase is priced and built as a unified QA platform. If your team isn't feeding automated results in, you're carrying the platform without using the unification. If your testing is checklists, runs and reports, Testpad does all of it for $10/user/month equivalent, and guest testers stay free.

When is Qase the better choice?

When automation is the center of your testing and you want manual QA in the same picture. Qase's reporters, CI integrations and unified dashboards do things Testpad doesn't attempt: automated runs and manual runs in one view, flaky-test tracking, and release-readiness reporting. AIDEN goes further than any AI feature in Testpad, generating cases from requirements and converting manual cases into Playwright, Cypress or Selenium code. The free plan (3 users, 2 projects) is enough for a small dev team to start on, and larger orgs get role-based access control, SSO and requirement traceability on the higher tiers. Qase also holds SOC 2 and ISO 27001 certifications, which matters if your buyers ask for them. If that platform shape fits your team, Qase is a strong modern choice; our guide to the best test management tools covers the wider field.

When is Testpad the better choice?

When your testing is led by people rather than pipelines: you run UAT with clients or stakeholders, do regression and exploratory work, test hardware, or your developers check their own features and a case repository is more machinery than the job needs. Teams of that shape are testing in minutes, keep the plan light enough to stay current, and pull in outside testers without buying seats. Automated results can still land in the same plan through the API, so a mostly-manual team with some automation isn't forced onto a platform for it.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for Qase?

For manual and exploratory testing, yes: UAT, regression, hardware, release checklists. If your team depends on Qase's automation side (reporters, CI dashboards, AI conversion of cases to code), Testpad doesn't do those today; it accepts automated results via its REST API but it isn't an automation platform.

What's the actual difference in the data model?

Qase stores each test as a case (preconditions, steps, expected results) in a repository organized into suites; plans and runs draw cases from that repository. Testpad stores a test plan as a nested outline of plain text prompts, with a column added per test run.

Does Qase have a free plan?

Yes. Free plan for up to 3 users and 2 projects, with 500 MB storage and 30 days of test history (checked July 2026). Testpad doesn't have a free tier; it has a 30-day trial with all features and up to 20 users.

Can non-technical people test in Testpad?

Yes. Share a link and a guest tests with no login, no seat, and very little training. In Qase, recording results takes a seat on a paid plan, and read-only access is a paid add-on.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free. Qase is Startup is $24/user/month month-to-month or $19.20/user/month billed annually; Business is $30/user/month month-to-month or $24/user/month billed annually; a free plan covers up to 3 users and 2 projects. If most of your testers are part-time or external, guest testing is where the difference shows; if you're three people on Qase's free plan, Qase is cheaper until you grow past it.

Does Testpad handle automated tests?

It records their results. Push pass/fail outcomes from CI via the REST API and they sit in the same plan, and the same reports, as your manual runs. Outbound webhooks notify your other tools when runs finish or results change. Testpad doesn't run automation or convert manual tests into automation code; Qase does both.

Does Testpad have AI features like AIDEN?

Not built in. Teams draft tests with their own AI tools (there's a custom GPT for writing Testpad test scripts) and paste the result straight into a plan; the outline format means AI suggestions import as plain text, with no per-use credits. Qase's AIDEN is deeper: it generates cases from requirements and converts them to automation code, metered by monthly AI credits.

Does Testpad have role-based access control or an audit trail?

Not today. Anyone in a Testpad account can edit anything. If your process requires per-user permissions or audit history, Qase's Business and Enterprise plans have them; check before you commit either way.

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install: paste in a chunk of your existing test cases and see how they read as a checklist.

Compare Testpad next to the tools you know; it's all about test plans, not test cases

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

In some ways, comparing Testpad to other test management tools is easy, because Testpad is simply different: a test is a line of plain text in a checklist, not a case record in a database. Most of the choice comes down to which of those shapes fits the way your team tests. The pages below compare Testpad with one tool at a time, cover the alternatives when you're leaving a specific tool, and take the wider view when you're starting fresh.

Head-to-head comparisons

One tool at a time: data model, guest testing, reports, integrations and cost.

Testpad vs TestRail: a database of test cases with deep process and per-seat licensing, next to plain-text plans.
Testpad vs Xray: every Xray test is a Jira issue, with full Jira traceability; Testpad's plans live outside Jira.
Testpad vs Zephyr: Jira-native test cases against test plans that live outside the board.
Testpad vs Qase: a modern unified QA platform with AI and a free tier, next to the lighter plan-led tool.
Testpad vs qTest: an enterprise platform priced by quote, next to lightweight test plans.
Testpad vs PractiTest: an end-to-end QA management platform, next to lightweight plans.
Testpad vs QMetry: enterprise test management with contact-sales pricing, against simple published plans.
Testpad vs TestLink: free, open-source and self-hosted, against hosted and maintained for you.
Testpad vs TestLodge: structured cases priced by content volume, next to plans priced by tester.
Testpad vs Testmo: manual and automated testing unified in one tool, against a manual-first checklist.
Testpad vs Tuskr: a low-priced structured case manager with a free tier, next to plain-text plans with guest testing.

Alternatives roundups

Leaving a specific tool? These roundups cover the field of replacements, Testpad among them, with notes on who each suits.

Best TestRail alternatives: the tools teams move to when TestRail's weight or per-seat cost no longer fits.
Best Xray alternatives: options for teams who want testing out of Jira, or just lighter inside it.
Best Zephyr alternatives: six replacements, Jira-native and standalone.
Best qTest alternatives: eight tools to consider before signing an enterprise quote.
PractiTest alternatives: seven tools compared for teams re-evaluating an end-to-end platform.
Best QMetry alternatives: eight options spanning enterprise suites and lightweight tools.
Best TestLink alternatives: for teams outgrowing self-hosted open source and its upkeep.
Best TestLodge alternatives: six tools for teams that want a different pricing model or a different data model.
Best TestMonitor alternatives: eight pragmatic replacements compared.
Best Testlio alternatives: crowdsourced-testing services and self-serve tools, for teams rethinking managed testing.
Excel alternatives for test management: what to move to when the spreadsheet stops coping.

Buying guides

Starting from the problem rather than a tool you already use.

14 best test management tools for 2026: the wide-angle guide across the whole field.
Best test management software for small teams: picks for teams of two to ten, where seat pricing and setup time matter most.
9 best exploratory testing tools: tools for testing that follows the product rather than a fixed procedure.

Where to start

If you're comparing Testpad against a tool you already run, start with its head-to-head page above. If you're starting from scratch, the buying guides cover the field, and test plans, not test cases explains the data-model difference that runs through every page here. Or skip the reading: Testpad's free 30-day trial includes all features and up to 20 users, and pasting a chunk of your existing test cases into a plan takes about five minutes.

Testing terminology: a pragmatic glossary

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

Testing has lots of terminology that sometimes does and often doesn't help convey what's going on and whether that concept is actually useful. Think of this article as an opinionated glossary, where we try to explain what lots of common testing terminology means, as well as put it in its place – all in an effort to help demystify testing and not make it seem more complicated than it needs to be. Ultimately testing is a simple concept: trying to discover as much as possible about a product so as to inform stakeholders what to do next – essentially helping everyone ask and answer "are we ready yet?".

Jump to a term

Test Case Test Script Test Plan Exploratory Testing Exploratory Testing (Testpad's Pragmatic Approach) Sanity Testing System Testing Regression Testing Mind Maps Test Run User Acceptance Testing Acceptance Testing Functional Testing Issue Tracking Tools Bug Tracking Tools Test Management Tools Manual Testing Edge-case Testing Session-Based Test Management (SBTM) Test Suite Test Data Unit Testing Integration Testing Smoke Testing Performance Testing Load Testing Stress Testing Usability Testing Security Testing Alpha Testing Beta Testing Black Box Testing White Box Testing Gray Box Testing Defect / Bug Defect Life Cycle Root Cause Analysis (RCA) Defect Density Ad-hoc Testing Agile Testing Continuous Integration (CI) Continuous Testing (CT) Test Coverage Test Summary Report Mean Time to Failure (MTTF) Mean Time to Repair (MTTR) Test Environment Test Prompt Severity vs Priority Equivalence Partitioning Boundary Value Analysis Test Harness Test Bed

Test Case

↑ top

A test case is a test instruction. One instruction out of many that needs to be performed as part of the testing process.

That instruction could be just a prompt or idea for something to look at, or it could be more elaborate with formal structure.

When formally structured, test cases typically include:

title
details about the environment
any pre-conditions that need establishing
the specific steps to execute
a list of one or more expected outcomes
and other metadata, such as priority, user roles, affected components, dependencies etc

Whether to use shorter or longer test cases depends on the context the test team is working in. In a process-heavy environment, where teams are using traditional Test Case Management tools, they will probably be required to structure each test case with many of the above elements. In a more agile environment, especially when the testing is more exploratory in nature, test cases can be just brief prompts of aspects of the product to remember to take a look at.

If you're new to testing, and/or don't have to use a Test Case Management tool, then we'd strongly steer you toward keeping your test cases (prompts) as short and simple as possible. They're much faster to write and much easier to maintain.

Test Script

↑ top

A Test Script usually means a collection of test instructions.

These might be instructions for a human to follow as part of manual testing, or might be the code used to define automated tests.

Test Scripts can sometimes be confused with Test Suites, but the distinction doesn't really matter. A Test Suite is usually only used for a collection of Test Cases as part of Test Case Management. Whereas a Test Script is more likely to mean either a piece of the code in an automated test environment or a list of test instructions for a human to follow.

In Testpad, a Script is used to mean the list of instructions for a human to follow – formatted as a checklist with outline structure.

Test Plan

↑ top

A Test Plan is an ambiguous term: it can sometimes refer to the high-level document setting out the approach that a team will be using for the whole testing project, and other times it can just mean a list of test instructions for a team to work through.

As the high-level document, think of it as the strategy document, setting out the bigger picture and answering the "what," "why," and "how" of the testing effort, aligning stakeholders and setting expectations.

As just a list of test instructions, it's essentially the same as a Test Script.

Exploratory Testing

↑ top

Exploratory Testing is a type of (manual) testing where the tester is free to explore the product, inventing tests as they go, hunting for issues and inconsistencies, and crucially, reacting to how the product is behaving.

Exploratory testing can be contrasted with fully-scripted testing where every action to perform is defined by the test instruction (usually a detailed Test Case as part of Test Case Management).

Exploratory testing is easily the best kind of manual testing. It takes advantage of the tester's tenacity and intuition, and their experience of what the product did last time vs is doing this time. Exploratory testing allows for hundreds more test ideas to be carried out in the same time as there's no documentation overhead to write (and maintain) a Test Case per test idea.

A common formalization of Exploratory Testing is Session Based Test Management, characterized by directing test sessions with charters (a list of topics to investigate, along with time allocations for each) and testers documenting their test ideas and the results as free-form notes as they proceed.

See also Testpad's pragmatic approach to exploratory testing that adds a bit more control to the process (and therefore easier to plan, track and report on) without losing the exploratory nature of the testing itself.

Exploratory Testing (Testpad's Pragmatic Approach)

↑ top

Testpad's take on making exploratory testing more manageable by adding just enough structure through detailed (but not too detailed!) test prompts. Rather than "test the login system" as you might find in a high-level charter, prompts break testing down into specific aspects like "check password complexity rules" or "verify account lockout behavior."

Test prompts are therefore more specific ideas of what to investigate but leave the exact approach up to the tester. They avoid the rigid step-by-step instructions of scripted test cases, preserving the tester's freedom to explore while ensuring important functionality isn't overlooked.

Results can be collected as simple pass/fails against each prompt, creating a clear visual overview of what's working and what isn't, while additional comments and bug links capture any specific problems. This structure makes it easier to plan testing scope, track progress, generate clear reports, and reuse test ideas in future releases - all without losing the key benefits of exploratory testing's human-driven discovery process.

Sanity Testing

↑ top

A quick check that the most basic, core functionality of your software works before investing time in deeper testing. If users can't log in, or the main page won't load, there's no point proceeding with more detailed testing of advanced features or edge cases.

While "sanity testing" sounds formal, it's really just common sense - check the obvious things first. Some teams treat it as a distinct phase with its own test plan, but that's usually overkill. Simply having experienced team members quickly verify basic functionality before starting full testing is often enough. The goal is to save time by catching major issues early, not to create extra processes.

System Testing

↑ top

Testing your complete software product as a whole, rather than testing individual components in isolation. System testing looks at how all the pieces work together - from user interfaces through to databases and external integrations. It's about verifying the entire system works correctly in a realistic environment.

Most testing is system testing, even if teams don't call it that. Unless you're specifically testing isolated components (unit testing) or how your system connects with others (integration testing), you're probably doing system testing. Don't get hung up on the term - it's just testing your actual product the way it will be used, which is exactly what most teams need to focus on.

Regression Testing

↑ top

Testing to make sure problems that you've fixed previously stay fixed. Think of it like a growing checklist - every time you find and fix a significant bug, you add a test to catch it if it reoccurs. No product is bug-free, but having the same bugs reappear is embarrassing and suggests a team that doesn't learn from its mistakes.

While often associated with automation, regression testing doesn't have to be automated to be valuable. Some tests are difficult or impractical to automate, and manual regression testing is better than none at all. The key is having these checks in place, whether they're automated or done by hand.

Mind Maps

↑ top

A visual way to organize ideas by creating branching diagrams that expand out from central concepts. In testing, mind maps are particularly valuable for breaking down complex products into testable areas - starting with core features at the center and branching out to explore different aspects that need testing and ensure comprehensive coverage.

A mind map starts with your product's core features or capabilities at the center, then branches out to explore related areas, test scenarios, and potential risks. It's a natural way to develop test plans - you can keep expanding branches as you think of new things to test, and the visual structure helps identify gaps in your testing strategy.

While mind maps are great for brainstorming test ideas, you don't need special diagramming tools to create test plans this way. The same structure works as a simple indented list, with main features as top-level items and related tests nested underneath. As you think of new test ideas, you can add them at any level - just like drawing new branches on a mind map. This makes it practical to turn your test ideas into executable plans.

Test Run

↑ top

A single run-through of a test plan or script, collecting results, bugs, notes and perhaps other evidence (e.g. screenshots) along the way.

If you have a list of tests, think of a test run as one column next to your tests, recording what happened when someone worked through the tests - what passed, what failed, and any observations made along the way.

During the testing of a product, as part of one release cycle, you might make multiple test runs through your tests, covering different:

environments
browsers or devices
testers
builds

Some teams (or indeed tools) build lots of processes around a test run, with effort spent preparing them and getting sign-off when completed etc. Depending on your process requirements and context, this can easily be overkill. What matters is having a clear record of what was tested, when, by whom and with what result.

User Acceptance Testing

↑ top

Testing to verify software meets its intended purpose, typically near the end of development. In a client project, this means the client checking the delivered product matches what they ordered. For end-user products, it means verifying the software works effectively for its target users - either through testing with actual users or by having the test team work through realistic user scenarios.

Neither approach needs complex processes or special tools - what matters is getting meaningful feedback about whether the software truly works for its intended audience before release. This could be as simple as observing users interact with the software or having clients verify their requirements have been met.

Acceptance Testing

↑ top

Usually identical in meaning to User Acceptance Testing, however, can sometimes refer to the more general process of agreeing (through verification checks) that the requirements of a product have been met, whoever is performing those checks.

Functional Testing

↑ top

Testing that verifies your software does what it's supposed to do - the basic "does it work?" testing that most people think of when they hear "testing." It focuses on checking features against their requirements or expected behavior.

While it sounds formal, functional testing is just checking if your software's features work correctly. This could be verifying a login form accepts valid credentials and rejects invalid ones, checking that a shopping cart calculates totals properly, or ensuring a document editor can actually save files.

Most testing is functional testing, even if teams don't call it that. If you're verifying features work as intended, you're doing functional testing.

This differs from non-functional testing like performance testing (is it fast enough?), security testing (is it secure?), or usability testing (is it easy to use?).

Issue Tracking Tools

↑ top

(Also called Bug Tracking Tools)

Tools for recording and managing software issues found during development and testing. Issues are often bugs (defects), but can also be features, roadmap ideas, enhancements and other items of work relating to the development of the software.

They help teams track issues from discovery through to resolution, storing details like severity, steps to reproduce, screenshots, and discussions about the software changes required.

Traditional issue trackers are standalone tools focused solely on issue (defect) management. Modern development platforms often include integrated issue tracking as part of broader project management features - think Jira, GitHub Issues, or GitLab - allowing teams to manage issues alongside code, features and other work items.

Key features typically include assignment to owners, status tracking, and reports showing trends over time. The best tools let teams quickly capture issues without excessive form-filling while still maintaining enough detail for developers to understand and get to work on the issue.

Issue trackers shouldn't be confused with test management. Test management tracks what's being tested in the current release, while issue tracking manages issues throughout their lifecycle - often spanning multiple releases until they're fixed.

Bug Tracking Tools

↑ top

See Issue Tracking Tools

Test Management Tools

↑ top

Tools that help teams organize and track their testing process. They typically store test plans, record results, and generate reports to show testing progress and product quality.

Traditional test management tools are built around formal "test cases" - requiring detailed documentation of steps, expected outcomes, and other metadata for each test. While this structured approach suits some contexts (especially highly regulated industries), it can be unnecessarily rigid and time-consuming for many teams.

Modern alternatives take a more flexible approach, letting teams create simple checklists of what needs testing, add detail where valuable, and generate clear reports showing what works and what doesn't. This lighter approach particularly suits exploratory testing, where testers benefit from the freedom to investigate and react to what they discover rather than following rigid scripts.

The best tool choice depends on your needs. Spreadsheets work well for simple testing. Traditional test case management tools suit process-heavy environments. Lighter tools like Testpad offer middle ground - more capable than spreadsheets but without the complexity of traditional platforms.

Manual Testing

↑ top

Testing performed by humans rather than automated scripts or programs. Testers directly interact with the software by clicking, typing and observing behavior. Manual testing covers a spectrum from fully-scripted test case execution (following precise steps) through to exploratory testing (reacting and adapting to what's found).

The exploratory form of manual testing is particularly valuable as it leverages human intuition and adaptability to discover unexpected issues that would be difficult to find through scripted or automated approaches.

While automation can be more efficient for repetitive checks, manual testing often remains more practical. The effort to automate some tests may outweigh their value, especially for features that change frequently or are difficult to verify programmatically.

Edge-case Testing

↑ top

Testing scenarios that are unusual, extreme, or at the boundaries of normal usage. Edge cases are situations that might be rare but could still occur, like entering the maximum possible value in a field, testing with unusually large files, or trying operations with poor network connectivity.

While it's important to verify edge cases work correctly, don't get carried away trying to test every conceivable unusual scenario. Focus on edge cases that are reasonably likely to occur and would have significant impact if they failed. For example, testing how your e-commerce site handles a shopping cart with 1000 items might be less valuable than testing what happens when a payment transaction times out.

Session-Based Test Management (SBTM)

↑ top

A structured approach to Exploratory Testing where testing is organized into time-boxed sessions guided by a charter. The charter defines what aspects of the product should be explored in each session and how long to spend on each aspect.

During testing, testers maintain a detailed journal of their activities, observations, and any issues discovered. These session notes form the primary output and documentation of the testing performed.

SBTM helps make exploratory testing more manageable by providing a framework for planning sessions and tracking progress. However, the reporting quality depends heavily on testers' note-taking skills, and the session notes don't easily provide quick summaries of testing status or product readiness.

Test Suite

↑ top

A collection of related test cases or test scripts, typically grouped by feature, component, or testing objective. While some tools and processes make formal distinctions between suites, scripts, and plans, these terms often mean similar things in practice - they're just ways to organize collections of tests.

Test Data

↑ top

Data used during testing to verify how software behaves with different inputs. This could be sample customer records, transaction histories, or any other information needed to exercise the software's functionality.

Creating good test data is often overlooked but important - you need enough variety to test different scenarios while keeping it manageable. Rather than creating massive datasets, focus on having representative examples that cover key use cases and edge conditions. For example, an e-commerce site might need just a few orders with different payment methods and shipping options rather than thousands of transactions.

Most teams benefit from maintaining a core set of reusable test data, supplemented as needed for specific test scenarios, and iterated on over time as experience grows from release to release.

Unit Testing

↑ top

Automated testing at the code level, where individual components (functions, classes, modules) are tested in isolation to verify they work as intended. Unit tests are often written by developers alongside their code and can be run automatically whenever code changes, typically as part of continuous integration.

While valuable for catching issues early in development, unit testing only verifies individual pieces work correctly, not how they work together or how the complete product behaves. Additionally, since unit tests are usually written by the same developers writing the code, they may embed the same incorrect assumptions about how components should behave.

Unit tests complement rather than replace system-level testing of the whole product.

Integration Testing

↑ top

Testing how different parts of your software work together, rather than testing them in isolation. While it sounds formal, Integration Testing is really just checking that when you connect different pieces of your system - whether that's different services, APIs, or third-party tools - everything still works as expected.

Where System Testing looks at the complete product working as a whole, Integration Testing focuses more narrowly on the connections between specific components. However, in practice, the distinction often blurs - if you're testing your product as users would actually use it, you're already testing both how components integrate and how the whole system works.

The distinction becomes more relevant when you're specifically focusing on testing components separately (Unit Testing) or when you have complex systems with many external connections that need special attention. For most teams, especially those with straightforward products, you don't need to treat Integration Testing as a separate process. Just make sure your normal testing includes checking any connections between different parts of your system, particularly after making changes that affect how these parts interact.

Smoke Testing

↑ top

A quick check that basic functions work before proceeding with more thorough testing. The term comes from hardware testing - if you turn on a circuit board and it starts smoking, there's no point testing anything else yet.

In software development, smoke testing is essentially the same as Sanity Testing: verifying nothing obviously broken has made it into the build. It's about making sure there aren't any major showstoppers before investing time in detailed testing. Rather than being a formal process, it's about efficiently catching major problems early - if the software is clearly unstable, you can fix those issues before spending time on more nuanced testing.

The term can sometimes be used to mean "soak testing" - running systems for prolonged periods to find stability issues that only emerge over time - but the "sanity testing" interpretation is the more common one.

Performance Testing

↑ top

Testing your software's performance characteristics - for example: speed, responsiveness, stability and scalability. This helps identify how your software behaves under different conditions, from normal loads to peak loads and beyond, to better understand its limits.

In web apps, performance testing might look at factors like how quickly pages load, how many users can be supported simultaneously, and whether the software remains stable during extended use. It helps find issues like slow response times, resource constraints and breaking points before they impact real users.

While dedicated performance testing tools exist for simulating heavy loads and gathering detailed metrics, basic performance issues can often be uncovered through manual testing.

Load Testing

↑ top

Load testing, often used interchangeably with stress testing, is seeing how your software performs under heavy usage. This includes testing expected peak loads (what's typically meant by Load Testing) and testing system limits by deliberately increasing usage until performance degrades or breaks (what's typically meant by Stress Testing).

While specialized tools exist to simulate many users or process large amounts of data, even basic testing with multiple team members can reveal important performance issues. The key is understanding your usage patterns and testing within - and beyond - those boundaries.

Stress Testing

↑ top

Stress testing, often used interchangeably with load testing, is seeing how your software performs under heavy usage. This includes testing system limits by deliberately increasing usage until performance degrades or breaks (what's typically meant by Stress Testing) and testing expected peak loads (what's typically meant by Load Testing).

Usability Testing

↑ top

Testing how easy and intuitive your software is to use, typically by observing users attempting specific tasks. Can be performed at any stage - early in development using prototypes (even paper mockups) to validate design choices before implementation, or later with beta/released versions to identify improvements needed.

The scope can vary from informal observations by coworkers to formal studies with recruited participants representing your target users, complete with video recording and eye tracking. Many companies now outsource this to specialist usability testing services that handle participant recruitment and provide detailed analysis of user behavior.

The key is watching users interact with your software without helping them, noting where they get confused or stuck. These insights help improve the user experience before and after release.

Security Testing

↑ top

Testing to find vulnerabilities in your software that could be exploited by malicious users. This ranges from basic checks like ensuring passwords are properly encrypted and users can only access their own data, to sophisticated penetration testing that actively tries to break into the system.

While specialized security firms offer comprehensive testing services using advanced tools and techniques, development teams should still perform fundamental security checks throughout development. Essential areas include input validation, authentication, access control, and data protection - especially for sensitive information.

The goal is identifying and fixing security holes before attackers find them. This applies not just to obvious entry points like login screens, but to the entire system including APIs, databases, and infrastructure.

Alpha Testing

↑ top

Alpha testing isn't a well-defined concept for many teams. Where a formal definition is attempted, it typically refers to the final phase of testing a product internally, before releasing it for real users to try in a "beta testing" phase. However, some teams use "alpha testing" to simply mean "very early testing" within the development lifecycle, possibly even conducted during ongoing development.

It's not a critical concept or type of testing to worry about per se. What matters more is that you have comprehensive internal testing comprising unit tests, integration/system tests, and exploratory testing. Ideally, the bulk of this testing should happen on stable release candidates just before releasing (either as a general release or during a beta testing phase).

Rather than getting caught up in terminology, focus on ensuring your product works as intended through whatever testing methods make sense for your team and project. The label "alpha testing" is less important than having effective testing processes in place at the appropriate stages of your development cycle.

Beta Testing

↑ top

Beta testing is when you release your product to a limited group of real users before making it generally available. It's essentially a controlled first exposure to actual users in their real environments, allowing you to gather feedback and catch issues that internal testing might have missed.

While many companies make beta testing sound formal with elaborate "beta programs," at its core, it's simply getting your software into the hands of people who aren't part of your development team. These users will inevitably use your product in ways you didn't anticipate and on configurations you hadn't considered.

Beta testing is most valuable for products with large or diverse user bases where internal testing can't realistically cover all usage patterns. For simpler products or those with a small, well-understood user base, an extensive beta phase might be unnecessary. Some teams use "beta" labels primarily as risk management - signaling to users that they should expect some issues.

Black Box Testing

↑ top

Black box testing is testing a product without knowledge of its internal code or structure. You interact with the software purely as a user would, focusing on inputs and outputs rather than how the system processes information. You're essentially treating the software as a "black box" where you can't see inside.

This approach is particularly valuable for finding usability issues, verifying that the software meets requirements from the user's perspective, and catching problems that might occur in real-world usage. Most manual testing is naturally black box testing - testers work through features, trying different inputs and checking if the outputs match expectations.

Black box testing is especially effective when performed by people who weren't involved in development, as they don't have preconceptions about how things should work. This often leads to discovering unexpected bugs that developers might miss because they test according to how they built the system rather than how users might actually use it.

While understanding the code can sometimes help testers be more thorough (see White Box Testing), black box testing remains essential because it mirrors how your actual users will experience the product.

White Box Testing

↑ top

White box testing is testing with full knowledge of the code and internal structure of the software. Instead of just looking at inputs and outputs, testers examine how the software processes information, often with access to the source code, data structures, and algorithms used.

This approach is valuable for ensuring all code paths are tested, finding issues with specific functions or modules, and verifying that internal operations work as intended. Unit testing is a common form of white box testing, where developers test individual components in isolation.

White box testing is typically performed by developers or technical testers who understand the codebase. It's particularly effective at finding issues like memory leaks, security vulnerabilities, and edge cases that might be difficult to trigger through regular usage.

Both white box and black box testing have their place in a comprehensive testing strategy. White box testing helps ensure technical correctness, while black box testing confirms the software actually meets user needs.

Gray Box Testing

↑ top

Gray box testing is a hybrid approach that sits between black box and white box testing. Testers have partial knowledge of the internal workings of the software, but don't need complete access to or understanding of the source code. They understand the general architecture, data flow, and algorithms without necessarily examining the code line-by-line.

This approach is particularly useful when testers need enough structural knowledge to create more effective tests but don't require (or have access to) the full codebase. For example, understanding the database schema can help testers craft better tests for data integrity, even if they can't see the application code that interacts with the database.

Gray box testing often occurs naturally in smaller teams where testers work closely with developers and gain familiarity with the system architecture over time. It's also common in security testing, where testers need to understand system components to identify potential vulnerabilities, but approach the system from an external perspective.

The benefit of gray box testing is that it combines the user-focused perspective of black box testing with enough technical understanding to target likely problem areas more efficiently. This makes it particularly valuable for complex systems where purely external testing might miss important scenarios.

Defect / Bug

↑ top

A flaw in the software: it does something wrong, or fails to do something it should. "Defect" and "bug" mean the same thing - defect is the formal term you'll find in textbooks and process standards, bug is what everyone actually says.

Some methodologies draw fine distinctions between errors (the human mistake), defects (the resulting flaw in the code) and failures (the flaw showing itself when the software runs). It's a tidy chain of causation, and knowing it might help you pass an ISTQB exam, but no working team talks this way.

What matters more than the terminology is a good bug report: what you did, what happened, what you expected to happen. A clear reproduction beats any amount of classification.

Defect Life Cycle

↑ top

The sequence of states a bug moves through from discovery to closure. A typical version: new, confirmed, assigned to a developer, fixed, verified by a tester, closed - with detours available for "won't fix," "can't reproduce" and "duplicate." Every issue tracker implements some flavor of this as a workflow.

The useful part is the reminder that "fixed" isn't the end. Someone should verify the fix actually works before the bug is closed, and skipping that step is how bugs come back.

Beyond that, don't over-engineer the workflow. Small teams do fine with three states (open, fixed, closed), and elaborate ten-state life cycles with strict transition rules mostly generate admin. Use whatever your issue tracker does by default and spend the saved effort on testing.

Root Cause Analysis (RCA)

↑ top

Digging past a bug's symptom to find the underlying cause, and, done properly, asking why the process let that cause through. The classic technique is the "five whys": keep asking why until you hit something fundamental. The report timed out; why? The query was slow; why? The table had no index; why? Nobody reviews query performance before shipping; and so on.

For most bugs, full RCA is overkill: find it, fix it, add a regression test, move on. Save the deeper analysis for the bugs that matter - the outage, the data corruption, the same class of bug appearing for the third time. Those are the ones where fixing only the symptom guarantees a repeat.

When you do it, keep it blameless. The interesting answer is rarely that someone made a mistake; it's whatever made the mistake easy to make and hard to catch.

Defect Density

↑ top

The number of defects found per unit of software size - classically bugs per thousand lines of code, sometimes per module or feature. The idea is to compare components or releases: a module with unusually high defect density might need a rewrite, extra review, or extra testing.

As a rough pointer to where the risky code lives, it has some value. As a quality metric, it falls apart quickly: it counts bugs found (which measures the testing as much as the code), every bug counts equally (a typo and a data-loss bug are each "one"), and lines of code is a poor measure of size to begin with.

For most small teams this is metrics theater. You already know which module everyone's scared to touch; you don't need a ratio to tell you. Unless you're in an organization that requires reporting it, you lose nothing by ignoring it.

Ad-hoc Testing

↑ top

Testing without any plan or documentation - someone sits down and pokes at the software, following their nose. No test cases, no charters, no record of what was tried.

It's often described dismissively, as the unprofessional cousin of exploratory testing, but the two are close relatives. The difference is that exploratory testing works from at least a lightweight plan and leaves a record of what was covered; ad-hoc testing does neither.

Don't let it be the whole strategy forever: with nothing written down, you can't say what was tested. But doing ad-hoc testing is infinitely better than doing zero testing, and it's a fine starting point - the journey of iterating on your test process usually begins here. Write down what you tried as you go and you're already most of the way to a reusable checklist.

Agile Testing

↑ top

Testing done the agile way: continuously through development, inside the team, rather than as a separate phase at the end handled by a separate department. Whoever's testing - dedicated testers, developers, or a mix - works alongside the code being written, testing each slice of functionality as it's built.

The word carries an ambiguity worth knowing about (our agile testing guide unpacks it): capital-A Agile is the formal methodology world of ceremonies, sprints and frameworks; lowercase agile is the broader working style - short cycles, feedback, working software over comprehensive documentation. Agile testing splits the same way: there's a formal school with its own quadrants and vocabulary, and there's the everyday sense of testing continuously with lightweight plans that change as the product does.

Since almost everyone now develops in something they call agile, for most teams agile testing is simply testing. The useful core is the Manifesto's trade applied to testing: time spent learning about the product beats time spent maintaining paperwork about the product.

Continuous Integration (CI)

↑ top

The practice of merging code changes into a shared repository frequently - usually many times a day - with an automated build and test suite run on every change. The point is to catch integration problems within minutes of the code being written, instead of discovering weeks of accumulated divergence when everyone finally merges.

CI is a development practice more than a testing one, but it changes the testing picture: the automated checks (mostly unit tests, perhaps some integration tests) act as a constant safety net, so obviously-broken builds rarely reach human testers.

What CI doesn't do is replace testing the product. The suite only checks what someone thought to automate. New features, usability, and the "does this feel right?" questions still need humans - ideally testing release candidates that CI has already confirmed are stable enough to be worth the time.

Continuous Testing (CT)

↑ top

The idea of testing continuously throughout development, rather than saving it all for a phase at the end. In practice the term usually means running automated tests at every stage of a delivery pipeline - on every commit, every merge, every deployment - so feedback about quality arrives constantly rather than in one late batch.

It's a sensible idea wrapped in an unnecessary label. Testing early and often has been good advice for decades; "continuous testing" mostly restates it in DevOps vocabulary, sometimes in aid of selling tooling.

Take the substance and skip the ceremony: automate the checks that are worth automating, run them often, and keep some human testing in the cycle for each release. Whether you call the result continuous testing doesn't matter.

Test Coverage

↑ top

A measure of how much of something your tests exercise. For automated tests it usually means code coverage: the percentage of lines or branches executed when the suite runs. For manual testing it's fuzzier - coverage of features, requirements, or risks.

The number is seductive and mostly misleading. "85% coverage" sounds like a fact about quality, but it only says those lines were executed, not that anything meaningful was checked - a test can run code and assert nothing. And coverage of what? Lines of code, features, requirements, browsers, user types? Each gives a different number, and none of them is "how tested is this product."

Coverage earns its keep as a gap-finder: a module at 0%, a feature nobody has looked at. Treat it as a way of spotting what you've missed rather than a score to maximize. Chasing a coverage target produces tests that satisfy the metric, which is not the same as tests that find bugs.

Test Summary Report

↑ top

A report at the end of a test cycle summarizing what was tested, what was found, and whether the product looks ready to release. Formal versions (there's an IEEE template) include scope, environments, results by area, outstanding defects, deviations from the plan, and a recommendation.

A good test report answers three questions fast: what's been tested, what's broken, and what happens next. A page of narrative and a results table covers that - and if your test tool can share a live report of results, that beats a document someone compiles by hand a week after the decision was made. (More in our post on simple test reports.)

If nobody ever asks a question about your test summary, it's too long, aimed at the wrong audience, or both. Short and current beats comprehensive and late.

Mean Time to Failure (MTTF)

↑ top

The average time a system or component runs before it fails. It's a reliability-engineering measure at heart: if you make hardware, MTTF (and its repairable-system cousin MTBF, mean time between failures) is how you predict how long units will survive in the field, plan warranty periods, and decide how long a soak test needs to run.

Hardware teams meet these numbers for real: burn-in and soak testing exist precisely to catch the early failures that drag the average down, and results recorded per unit per revision are the raw material the figures get computed from.

Software teams mostly meet MTTF secondhand in SLAs. Software doesn't wear out the way components do - it fails when it hits a state or input nobody tested - so the average time between failures says little about where the next one will come from. Knowing what the term means is usually enough.

Mean Time to Repair (MTTR)

↑ top

The average time it takes to restore a system after a failure - from things-are-broken to things-work-again. Like MTTF and MTBF it comes from reliability engineering, and it shows up in SLAs and DevOps metrics dashboards (it's one of the DORA metrics, as "time to restore service").

Of the mean-time family, this one has the most practical use, because it measures something you can improve: how fast you notice failures, diagnose them, and ship a fix. A team that can recover in minutes can afford to move faster than a team that takes days.

For a small team, though, formally tracking the number is usually metrics theater. You already know whether recovering from problems feels fast or agonizing. Put the effort into the things that improve it - monitoring, deployment speed, the ability to roll back - not into the measuring.

Test Environment

↑ top

The setup your tests run against: hardware, operating systems, browsers, databases, configuration, test data, and any connected services. "Works on my machine" is the classic symptom of a test environment not matching the real one.

The pragmatic goal is an environment that's realistic where it matters and convenient everywhere else. A staging setup resembling production (same versions, sensible data) covers most needs. Perfect production parity is expensive and rarely necessary; what you want to avoid is testing against a setup so unlike production that the results don't transfer.

Two things are worth doing. Record the environment alongside the results, because "passed" means little without knowing where it passed. And keep the environment somewhere near reality as the product evolves - environment drift is a slow leak, where each release the staging setup gets a little less like production until bugs start slipping through.

Test Prompt

↑ top

A short test instruction describing what to test without spelling out how - "password reset with an expired link" rather than ten numbered steps. It is a test case stripped back to the idea itself.

"Prompt" is Testpad's word for the lines in a script: each line is a prompt, and prompts nest in an outline so related ideas sit together. But the concept travels beyond any one tool. Whether you call them prompts, checks, or one-line test cases, terse instructions that trust the tester to fill in the details are faster to write, easier to maintain, and leave room for the exploratory instincts that find real bugs.

Getting the level of detail right takes a little practice. "Test login" is too vague to direct anyone; full numbered steps are too rigid. A good prompt names one specific aspect and implies its expected outcome - specific enough that a competent tester knows what to look at, open enough that they choose how.

Severity vs Priority

↑ top

Severity is how bad a bug is; priority is how soon it should be fixed. They often align but don't have to. A crash in a feature nobody uses is high severity, low priority; a typo in your pricing headline is low severity, high priority.

The distinction is worth keeping in your head because it dissolves a common argument: testers rate impact (severity), whoever owns the product decides order (priority). A tester saying "this is severe" and a product owner saying "not this release" can both be right.

Don't build a bureaucracy around it. Five-point scales for each, matrices mapping one onto the other, mandatory fields on every bug - most teams need nothing more than a plain note of how bad it is and someone deciding what gets fixed first.

Equivalence Partitioning

↑ top

Divide the possible inputs into groups the software should treat the same (valid ages, ages too low, ages too high) and test one value from each group instead of hundreds.

Of the formal test design vocabulary, this describes something experienced testers do by instinct: don't test fifty middling values that all take the same path through the code. You don't need to document which technique each test used; knowing the name mostly helps with exams and with reading other people's test plans.

Its natural partner is Boundary Value Analysis - once you have the groups, the interesting values sit at their edges.

Boundary Value Analysis

↑ top

Test at the edges of your input groups (see Equivalence Partitioning): for an 18-and-over age field, try 17, 18, and the extremes - because bugs cluster at boundaries.

If the terminology reminds you to try zero, negative one, the maximum, the maximum plus one, and the empty input, it has done its job.

Test Harness

↑ top

The framework that runs automated tests and collects their results - the scaffolding around the tests rather than the tests themselves.

If you're not writing the automation yourself, the useful summary: automated tests run inside a harness against partly simulated surroundings, which makes them fast and repeatable - and is also why a passing automated suite doesn't prove the fully assembled product works. Testing the real thing, connected to real things, is still a job.

Test Bed

↑ top

The configured setup automated tests run on - hardware, software versions, data. In practice it means much the same as Test Environment (see that entry), and in automated contexts it overlaps with the Test Harness.

You'll hear all three used loosely; the distinction rarely matters.

How hardware gets tested: bring-up, EVT to PVT, and firmware on real units

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

Hardware testing means working through a physical unit on a bench: powering a new board for the first time, putting prototype builds through drop and thermal and ingress, running firmware against real peripherals. Unlike software, the thing under test is a physical object with its own history: unit #3 can pass a check that unit #5 fails, with the same firmware on both, and much of the discipline in hardware testing exists to tell those two stories apart. This guide covers what hardware and firmware testing involves stage by stage, and how teams keep track of results that multiply across units, board revisions, and firmware builds.

At a glance

Hardware testing runs in stages: board bring-up, validation builds (EVT, DVT, PVT), environmental and reliability testing, compliance, and production test
Results are recorded per unit and per board revision, because a failure can belong to one badly soldered board or to the design itself, and comparing units is how you find out which
Firmware adds another axis: every release candidate needs checking on real devices, against real peripherals, including upgrades from older versions
Automation (HIL rigs, ATE) covers a slice; a person at a bench with a checklist covers the rest
The record matters afterwards: customers, gate reviews, and certification all ask what was tested and what the results were

Here for a tool rather than a guide? See Testpad for hardware teams: bring-up checklists in plain text, results tracked per unit and per build.

What hardware testing involves

A hardware program tests different things at different stages. Early on, the question is whether the design works at all: does the first prototype power up, boot, and do its job on the bench? In the validation builds that follow, the questions become whether the design survives the real world (heat, drops, water, years of use), and whether the factory can build it repeatably. At the end, production test asks the question once per manufactured unit: is this one good?

Fictiv's hardware testing overview groups the same territory into early-stage prototype testing, pre-production testing on EVT/DVT/PVT builds, and ongoing mass production testing, with environmental stress and compliance certification sitting in the middle. The stages below follow that arc, starting where every board starts: first power-on.

Board bring-up

Bring-up is the first careful walk through a new board, and it follows a sequence you don't want to improvise, working outward from power. Before any power is applied at all, the board gets inspected: solder bridges, missing parts, polarized capacitors and diodes the right way around, and each power rail checked to ground for shorts. A dead short found with a multimeter costs a minute; found at power-on, it can cost the board.

First power comes from a current-limited bench supply, so a fault draws a limited current instead of burning something out. Then the rails get verified one by one, with real numbers: apply 5V at the input connector, measure 3.3V within tolerance at the test point, confirm the 1.8V rail comes up after the 3.3V rail if the design sequences them, and check the idle current draw looks sane. Only then does the sequence move outward: clocks running, reset releasing cleanly, the debugger detecting the MCU over JTAG, firmware flashing with a matching checksum, a boot banner on the UART console. After that come the interfaces (USB enumerating, Ethernet negotiating a link), the sensors, and the radios.

Written down, that sequence is a checklist, and that's exactly how experienced teams run it: the same plan for every board, so board #2 gets the same careful pass as board #1, and so does the respin that arrives three weeks later. Improvised bring-up finds most of the same problems; the checklist is how you know which checks a given board actually got.

Why results are per unit, per revision

When a check fails on a software build, the build has a bug. When a check fails on a hardware unit, you don't yet know what has a bug. A board that fails its 3.3V rail check might have a solder defect (that one board, fixable with an iron) or a design problem (every board, fixable only with a respin). The way you tell is by comparing units: one unit failing thermal while three pass points at the unit; all four failing points at the design.

That's why hardware results are recorded per unit, against serial numbers, not per build. It's also why a board revision resets the record: a rev C board is a different board from a rev B, and rev B's passes say nothing about rev C. The same applies along the firmware axis, since a unit that passed on firmware 0.9.2 hasn't passed on 0.9.3 until someone runs the checks again.

In practice this means the natural shape of hardware test records is a grid: the checks down the side, and a column of results per unit, per revision, or per unit-and-firmware combination. The teams that track it this way can answer the questions that matter afterwards ("did EVT-05 get the RF checks before it shipped to the demo?") in seconds. The teams that don't end up reconstructing history from email threads and someone's lab notebook.

EVT, DVT, and PVT

Between prototype and production, most hardware programs run staged validation builds, each bigger and closer to final than the last.

EVT (engineering validation test) is the first integrated build, typically a few dozen units. The question is whether the design meets its functional requirements: everything the product must do, exercised on real boards, often before the final enclosure exists.

DVT (design validation test) builds should represent the production-intent design, and this is where the punishing tests happen. The build gets allocated across the test matrix: these five units to drop testing, those five to the thermal chamber, others to ingress, battery, and RF. Certification efforts (FCC, UL, Bluetooth and the like) typically start on DVT units too, alongside reliability and environmental testing; Embedded Artistry's field manual entry on DVT is a good practitioner's description of the stage.

PVT (production validation test) moves the question to the factory: the first run on the real production line, validating that the process builds good units at acceptable yield, not just that the design is good.

Because each build is a fresh population of units, results from one stage don't transfer to the next; what carries forward is the plan. Teams that keep the same test plan from EVT through PVT, giving each build its own set of result columns, can see at a glance which failures cleared between builds and which followed the design through a respin.

Environmental and soak testing

Environmental testing asks whether the product survives conditions rather than whether it functions on a friendly bench. The standard repertoire includes thermal cycling and thermal shock, sustained operation at high temperature and humidity, vibration, drop, dust and water ingress, and salt spray for anything that will live near a coast or a road. Which of these apply, and how hard, comes from where the product will live; a wall-mounted controller and a handheld scanner earn different lists.

A soak test is the simplest of the family and one of the most revealing: run the unit at full load for a sustained period and watch for resets, brownouts, and hotspots. It catches the class of problem that never shows in a two-minute functional check, like a regulator that drifts as it warms up or a processor that throttles under a heat-soaked enclosure. Soak results vary by unit like everything else: it's routine for one unit to soak clean while its sibling resets at minute 20.

Firmware and hardware, tested together

Firmware testing on a real product is regression testing with a physical dimension. Every release candidate needs a pass on real devices: the configurations customers actually run, the peripherals that only misbehave when they're physically attached, and the upgrade paths from older firmware versions still in the field. Emulators and unit tests catch plenty, but a class of bugs only exists where firmware meets hardware: timing, power states, sensor behavior at temperature, a radio that pairs on the bench and drops in an enclosure.

Some of this gets automated with hardware-in-the-loop rigs, and where HIL fits, it's excellent. But HIL covers a slice and humans cover the rest, because rigs are expensive to build and every product change threatens to invalidate them. The human slice (new features, peripheral quirks, upgrade paths, anything needing judgment) runs off a checklist, release after release.

The bookkeeping consequence is the same grid again, with firmware version as a column axis: unit EVT-03 on 0.9.2, unit EVT-03 on 0.9.3. When something fails, the first diagnostic question is always "board or firmware?", and results tracked per unit and per build are what let you answer it by looking rather than by re-testing.

Compliance and the paper trail

Products with radios, mains power, or a medical or automotive context have to pass certification testing (FCC, CE marking, UL, Bluetooth qualification, and onward depending on the product and market), and much of that testing happens at specialist labs rather than on your bench. Your team's part is preparation and evidence: pre-compliance checks before the expensive lab time, and records showing what was tested when the certification body, a customer, or an internal gate review asks.

A note on what standards actually demand, because teams routinely over-engineer this: regulated-industry standards generally require you to document what you test and keep results traceable to units and versions. They do not, in general, prescribe heavyweight test case formats. A dated, per-unit record of checks and outcomes, with the plan it came from, answers most "show us your testing" questions. What doesn't answer them is a spreadsheet nobody can date or a wiki page that was edited after the fact.

Where a checklist grid fits

Everything above keeps arriving at the same shape: a list of checks, run repeatedly, with results that need recording per unit, per revision, and per firmware build. That shape is why hardware teams that outgrow spreadsheets often don't want a heavyweight test case tool; a bench check doesn't need preconditions, steps, and expected result written out as separate fields. "Apply 5V at J1, measure 3.3V ±5% at TP12" already says what to do and what should happen.

Testpad is built around exactly that: a test is one line of plain text, indented into groups by subsystem, with a column of results per unit, per board rev, or per firmware build. When the next build arrives, you copy the plan and the new build gets clean columns while the old build keeps its results, so EVT and DVT stay comparable. Photos of the setup, the scope trace, or the damage attach to the result they belong to. When testing goes outside the team, to a test lab or a contract manufacturer, a guest link lets them run the checklist in a browser with no login, with their results landing in the same plan. One boundary to know about: Testpad is not ATE or ICT and doesn't control instruments; it manages the checks a person performs, alongside whatever you've automated.

Hardware teams run on it today. NVIDIA uses Testpad for prototype tracking and hardware bring-up:

"We've been using Testpad to track prototypes and execute hardware bring-up tests and are absolutely thrilled with it. The combination of features, reporting, and ease of use make it superior to anything we've used before." – Kyle Roberts, Senior DGX Server Platform Engineer, NVIDIA

And Legrand uses it daily for embedded software testing:

"We use it every day testing embedded software, making light work of our many environments and configurations." – Jason Pritchard, QA Engineer, Legrand

Hardware testing FAQs

What is board bring-up?

Bring-up is the first methodical test of a new board: inspection before power, checking rails for shorts, first power-on through a current-limited supply, then verifying power, clocks, reset, programming, and peripherals in order, working outward from the power supply. The goal is to find problems in a sequence that protects the board, instead of applying full power and hoping.

What order do you test a new board in?

Power first, everything else after. Inspect visually, check each rail to ground for shorts, power up current-limited, verify each rail's voltage and sequencing, check clocks and reset, then flash firmware and confirm boot, then work through interfaces, sensors, and radios. Any step skipped early tends to disguise itself as a confusing failure later.

What are EVT, DVT, and PVT?

Staged validation builds between prototype and mass production. EVT (engineering validation) proves the design meets functional requirements on real boards. DVT (design validation) tests production-intent units against the environment: drop, thermal, ingress, plus certification. PVT (production validation) proves the factory line can build the design at quality and volume. Each stage is a fresh set of units, so each gets fresh results.

How is firmware testing different from software testing?

The test matrix has physical axes. A web app is tested per build; firmware is tested per build per unit, and often per board revision and per attached peripheral, because hardware variation changes the result. Firmware testing also includes things software testing never meets: upgrade paths on devices in the field, behavior at temperature, and bugs that only appear with real components attached.

What is a soak test?

Running a unit at full load for a sustained period (half an hour to days, depending on the product) while watching for resets, overheating, and drift. It exposes problems that short functional checks miss, and it's usually the last gate in a bring-up checklist.

Do compliance standards require formal test cases?

Generally no. Standards and auditors ask you to document what you test and keep results traceable to specific units and versions; the format is yours to choose. A dated checklist with per-unit results and the plan it came from is documentation. Check the specific standard for your industry rather than assuming the heavyweight format is mandatory.

If the next board is arriving soon, put the bring-up plan in Testpad before it does. There's a 30-day free trial, and you'll have a test plan before the boards hit the bench.

Best UAT testing tools in 2026: collecting sign-off without the spreadsheets

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

User acceptance testing is the last check before release: the people who asked for the software confirm it does what was agreed. Search for tools to help, though, and the lists are confusing, because two unrelated kinds of product both call themselves UAT tools. Website feedback widgets like Marker.io and BugHerd are for clients commenting on a website as they browse it. Test plan tools like Testpad and TestMonitor are for acceptance testing any software: the client works through the agreed checks, and the results become the acceptance record. This roundup covers both, and explains when each fits.

At a glance

Two unrelated kinds of product call themselves UAT tools: website feedback widgets, and structured test plan tools
Feedback widgets (Marker.io, BugHerd, Usersnap) let a client comment directly on the pages of a website, and suit design reviews and site builds
Test plan tools (Testpad, TestMonitor, TestRail) work for any software: testers confirm agreed behavior, and the results are the acceptance record
Business testers rarely take to tools they have to learn, so how testers join matters as much as features: a link beats a login
Spreadsheets fail at the collection step, with results scattered across copies, attachments, and email threads

Here for a tool rather than a roundup? See Testpad for user acceptance testing: send testers a guest link to a plain-language checklist, no logins, no training.

What is a UAT tool?

A UAT tool is anything that helps you run user acceptance testing: getting the people who will accept the software (clients, business users, stakeholders) to try it before release, and collecting what they find. If you want the primer on UAT itself, we keep a full guide on the blog. This article is about the tools.

The label covers two product categories that barely overlap. Website feedback widgets grew up in the web agency world, where the client's review of a site build is often called UAT, and commenting on the page itself is exactly what that review needs. Test management tools come from the other direction: acceptance testing as the final stage of structured testing, for any kind of software. Both get called UAT tools, which is why the usual lists read so oddly, with a feedback widget and a test management platform side by side as if they were interchangeable.

Feedback on a page, or results against a plan?

The quickest way to tell them apart is the question each one answers.

A visual feedback tool answers "what's wrong with this page?" The tester browses the site, spots something, and pins a comment to it. The tool captures a screenshot and the technical context automatically, and sends the report to your issue tracker. Nobody writes a plan; the feedback is the output. It follows that these tools are for websites and web apps: in a desktop product, a device, or an API, there is no page to pin a comment to.

A structured test plan tool answers "is this release accepted, and who says so?" You write down what needs to work, testers work through the list recording pass or fail, and the results become your acceptance record. The plan matters as much as the results: it says what was tried, so at the end you know what was covered as well as what broke.

Neither kind replaces the other. Pinned comments can't tell you whether anyone tried the refund flow. A test plan won't catch a stray layout bug on a page no test mentioned. Plenty of teams run a widget during the build, then a plan when it's time for acceptance.

The tools, by kind

Tool	What it's for	How testers join	What you end up with	Price (July 2026)

Marker.io	Visual feedback on websites	Widget on the site; reporters need no account	Annotated bug reports in your issue tracker	From $39/month billed annually; reporters free and unlimited
BugHerd	Visual feedback on websites	Send a link; guests need no account	A kanban board of pinned feedback	From $42/month billed annually ($50 month-to-month); guests free on every plan
Usersnap	Feedback widget plus in-app surveys	Widget in your web app	An organized feedback inbox	Tiered by plan; published on their pricing page
Testpad	Checklist test plans with pass/fail collection	Guest link by email; no login, guest testers free	A results grid per tester, kept as the acceptance record	From $10/user/month, guest testers free
TestMonitor	UAT inside a full test management platform	Tester accounts, with assigned test runs	Test runs, requirement coverage, reports	~$130 to $399 per 10 users/month
TestRail	Formal test case management at QA scale	Tester accounts, with assigned test cases	Test suites, runs, milestone reports	$37/user/month (Professional); Enterprise billed yearly only

Visual feedback tools: point at the page

Marker.io

Marker.io puts a feedback button on your website. A reporter clicks it, marks up a screenshot of the page they're looking at, and the report goes to your issue tracker (two-way sync with Jira, Trello, Asana and others) with browser and session details attached. Session replay shows the clicks that led up to a bug, which saves the "what did you do exactly?" email.

Reporters don't need accounts, and they're free and unlimited; that fits client feedback well. Plans start at $39/month with a free trial (15 days). If your UAT problem is clients emailing you screenshots pasted into Word documents, this is the category that fixes it.

BugHerd

BugHerd pins feedback to the live website: clients point, click, and comment, and each comment becomes a task on a kanban board, with a screenshot and browser details captured automatically. Clients don't need accounts or logins; you send them a link. It's aimed squarely at web agencies collecting client input on site builds, and it integrates with Jira, Asana, Slack and the rest.

Plans start at $42/month billed annually ($50 month-to-month), and guests are free on every plan.

Usersnap

Usersnap began as screenshot-annotation feedback and has grown into a wider platform: feedback widgets with screenshots and metadata, in-app surveys, feature request collection, and AI-assisted categorization of what comes in. The pitch is UAT feedback and ongoing user research handled in one place, and it leans toward product teams rather than agency handovers. Pricing is tiered by plan, published on their pricing page.

All three collect reactions well. What none of them collects is coverage. Twenty pinned comments tell you twenty things are wrong; they can't tell you whether anyone exercised the permissions, checked the invoice math, or tried yesterday's orders in the order history. For that, you hand testers a plan.

Structured test plan tools: results against a plan

Testpad

Testpad (that's us, so we're biased) is built around checklist test plans that a client or business user can work through unaided. You write the plan the way you'd explain it, one line for each thing the business needs to see working, taking lines straight from your acceptance criteria or user stories. No test case forms, no fields, nothing for a business user to decode.

Occasional testers don't need accounts either. You invite them by email, and a guest link opens the checklist in the browser: no login, nothing to install, nothing to learn. Their results go into the same plan as everyone else's, as they test, so you can see who's started, what's failing, and what nobody has touched yet without chasing anyone over email.

At the end, the results grid is the record: what was tested, what each tester accepted, what was outstanding when you shipped. Save the report as HTML or a PDF and attach it to the acceptance email. There's no e-signature workflow, so formal approval stays in whatever process you use today; what Testpad adds is the record behind the approval, which settles the later argument about whether a bug was known or new.

"I was looking at 16 different tools before I stumbled across Testpad. It's simple and quick to use (easy enough to have business people use it with very little training). Reporting is simple and effective, making it clear who has tested what and where the bottlenecks are." – Adrian Wright, Business Process and IT Strategy

Guest testing is included on Team plans and up (from $99/month for 10 testers, and guest testers are free), and every plan starts with a 30-day free trial.

TestMonitor

TestMonitor is a full test management platform: test cases, test runs, milestones, requirements and risk tracking, and reporting, with integrations for Jira, Azure DevOps, Slack and Asana. UAT is one of its headline uses, and their own writing is clear-eyed about the audience: business users "usually aren't thrilled about spending their Tuesday afternoon navigating a complex testing environment" (their words).

The trade-off is weight. If your UAT sits inside a wider QA operation that wants requirements traced to test cases and risk scores on the results, TestMonitor does that properly. Your business testers get a fuller tool to find their way around in exchange. Pricing runs from ~$130 to $399 for 10 users a month depending on tier, with a free trial (14 days).

TestRail

TestRail does formal test case management at QA scale: suites, runs, milestones, and reporting built for full-time QA teams, at $37/user/month on the Professional plan. If your organization already runs TestRail for QA, keeping UAT in the same system means one set of reports and no second tool to administer, and for a regulated or enterprise QA process that weight is often already paid for.

If you're choosing a tool for UAT, though, note that every tester needs a seat, and that business users are being asked to learn software designed for QA professionals. That's the point where UAT tends to stall.

How do I run UAT with external clients?

The mechanics matter more than the tool brand, so here's the shape that works:

Write the plan from the acceptance criteria. One line per thing the client needs to see working, in plain language, grouped by area. If a line needs decoding, rewrite it.
Send a link, not a login. Every account, password, and training video between your client and the first test costs you testers.
Watch results arrive instead of chasing status. Progress should be something you look at, not something you ask for over email.
Collect comments and screenshots next to the item they belong to, not in a separate thread you'll have to merge later.
Keep the report. What was tested, what was accepted, what was outstanding at go-live. Attach it to the acceptance email and the "who approved this?" conversation never needs to happen.

Do you need both kinds of tool?

Sometimes. Agencies in particular get value from a feedback widget while a site is being designed and built, when the question really is "what's wrong with this page?", and then a checklist plan at acceptance, when the question becomes "can we go live, and will you say so in writing?". The two don't compete for the same moment in the project.

Best UAT tool FAQs

Do UAT testers need to create accounts?

Depends on the category. Marker.io and BugHerd let reporters comment with no account. Testpad sends occasional testers a guest link by email, with no login, while your regular team members have accounts. TestMonitor and TestRail are account-based throughout.

Can I run UAT in a spreadsheet?

You can, and plenty of teams start there. The authoring is fine; collection is what fails. Results come back as edited copies, attachments, and "see my comments in column F" emails, and nobody is sure which version is current. The tools in this list exist mostly to fix that collection step. If you're weighing it up, we've written about spreadsheet alternatives for test management separately.

Is Jira a UAT tool?

Jira is where UAT findings usually end up, and it's good at that. As the place business testers work, it struggles: a long bug form full of required fields is exactly what a non-technical tester won't fill in. The usual pattern pairs Jira with a tool from this list; the feedback widgets push issues into Jira automatically, and Testpad links failed tests to Jira issues.

How do I record UAT sign-off?

Keep a record rather than a ritual. A report showing what was tested, what passed, and what was outstanding at the moment you shipped, saved as a PDF and attached to the acceptance email, answers "who approved this, and on what evidence?". If your process needs a formal signature, that stays in your document workflow, backed by the test record.

What's the best free way to do UAT?

A shared document or spreadsheet costs nothing and works for a handful of testers on a one-off project, if you're disciplined about collecting results back. The paid tools make sense when UAT recurs every release, involves more than a few testers, or needs a record you can stand behind afterwards.

If the next release needs acceptance from people with day jobs, put the plan in Testpad and send them a link. There's a 30-day free trial.

Best test management software for small teams (2026)

Stefan Butlin — Thu, 02 Jul 2026 00:00:00 +0000

Small teams need a test tool that starts fast, stays cheap as testers come and go, and doesn't demand a part-time administrator. On those measures the strongest picks in 2026 are Testpad (plain-text test plans, flat-priced tiers, guest testers who don't need seats), Tuskr and Testiny (structured test cases with free tiers), TestLodge (priced by content, not users), and Qase's free plan (a modern platform, free for 3 users). TestRail remains the answer when a small team runs heavyweight, regulated process, and we say so below.

We make Testpad, so read its entry knowing that. The facts for every tool are checked against the vendors' own published pricing and dated, so you can weigh them yourself.

What should a small team look for in a test tool?

Big-team criteria (traceability matrices, role hierarchies, audit trails) mostly don't apply at five people. What does:

Seat pricing that survives reality. Small teams flex: a developer tests this release, a founder tests the next, a client joins for UAT. Per-seat pricing punishes exactly that.
Time to first test. If the tool needs a schema designed before anyone can test, that setup falls on the same person who was going to do the testing.
Upkeep the team will actually do. A case library nobody prunes goes stale in months. Lighter formats stay current because updating them is trivial.
Room for outsiders. Clients, freelancers and non-QA coworkers do a lot of a small team's testing. What does it cost to hand them a test?

How do the tools compare?

A side-by-side comparison of the aspects that matter when choosing.

	Free tier	Paid pricing	Data model	Best for
Testpad	30-day trial (all features, up to 20 users)	$49/month for 3 testers (Essential); $99/month for 10 (Team); guest testers free	Plain-text test plans: a nested checklist with a column per run	Teams that want to write and run tests today, and pull in outsiders
Tuskr	Free plan for up to 5 users	$90/user/year (Team, 5-user minimum)	Structured test cases with steps and IDs	Budget-conscious teams that want classic case structure
Testiny	Free plan for up to 3 users	$18.50/user/month (Starter)	Structured test cases, clean modern UI	Small teams wanting a tidy case tool with a gentle start
TestLodge	30-day trial	From $34/month, unlimited users (priced by content, not seats)	Structured test cases in suites	Teams with many occasional testers and modest content
Qase	Free plan for up to 3 users and 2 projects	$24/user/month (Startup; $19.20/user/month billed annually)	Case repository unifying manual and automated runs	Dev-centric teams that want automation results in the same tool
TestRail	14- to 30-day trial	from $37/user/month	Test case database with deep process features	Small teams running formal, regulated QA

Pricing checked against each vendor's published pricing page, July 2026.

The picks

1. Testpad

Testpad treats a test as a line of plain text in a checklist, not a record in a database. You write a plan the way you'd write a list: type a prompt, hit enter, indent to group related tests. Add a column per test run and mark pass or fail as you go. There's no schema to design and nothing to administer, which for a two-to-ten-person team means testing starts the same morning.

Three things fit small teams specifically. Plans are flat-priced tiers rather than a per-seat meter: Essential is $49/month for 3 testers, Team is $99/month for 10, and every tier includes every feature. Guest testing (Team plan and up) lets clients or coworkers run a test plan from a link, with no account and no seat, which is how small teams staff a UAT round without buying licenses for people who test twice a year. And reports are shareable links, so "how did testing go?" is answered by sending a URL.

What it doesn't have: per-user permissions, audit trails, or built-in automation. Automated results can be pushed in via the REST API, but if automation is the center of your testing, look at Qase below. The free 30-day trial covers all features and up to 20 users.

2. Tuskr

Tuskr is the classic structured model (test cases with numbered steps, expected results and IDs like TC-1234) at a small-team price. The free plan covers up to 5 users, and the paid Team tier is $90/user/year with a 5-user minimum. If your team wants cases referenced by ID in a bug tracker, requirements linked to coverage, and PDF reports, Tuskr does the structured job for less than the big names. The trade is the structure itself: every test is a form to fill in and a record to keep current. Our Testpad vs Tuskr page sets the two models side by side.

3. Testiny

Testiny is a newer structured-case tool with a clean UI and one of the friendlier on-ramps in the category: free for up to 3 users (capped at 1,000 combined cases, plans and runs), then $18.50/user/month on Starter. It integrates with the common issue trackers and keeps its interface simple enough that nobody needs training. Reporting is more basic than the enterprise tools, which at this team size is rarely the constraint.

4. TestLodge

TestLodge prices by content (test plans, cases and runs) rather than by user: every plan has unlimited users, starting at $34/month. That inverts the usual small-team problem. If you have lots of people testing occasionally and a modest body of tests, nobody ever needs a new license. The model is structured test cases in suites, simpler than TestRail's, and the plans cap how much content you can hold rather than who can touch it. Our Testpad vs TestLodge page has the detail.

5. Qase (free tier)

Qase's free plan covers 3 users and 2 projects, with 500 MB of storage and 30 days of test history (checked July 2026), and the product is a modern platform: a test case repository, automated and manual results unified in one dashboard, and an AI agent that drafts cases and converts them to automation code on the paid tiers. For a small dev-centric team that already has automation in CI, it's the strongest free starting point on this list. The things to weigh: everyone recording results needs a seat once you outgrow the free tier ($24/user/month on Startup), read-only access is a paid add-on, and you're adopting a platform's depth whether or not you use it. Our Testpad vs Qase page has the full comparison.

When does a small team need something heavier?

When process, not size, is the driver. If your team ships into a regulated context, needs per-user permissions and audit history, or answers to a QA organization with formal traceability requirements, the heavyweight tools do things none of the picks above do. TestRail is the established choice, at from $37/user/month; our Testpad vs TestRail page covers where its weight is worth paying for. The mistake to avoid is buying the heavy tool for a future process you don't run yet, then carrying its upkeep with two testers.

Which should you pick?

If your testing is people working through checklists (releases, regression, UAT, exploratory sessions), start with Testpad: it's the fastest to first test and the only pick where outside testers are free. If your process needs numbered cases and IDs, Tuskr and Testiny do structure at small-team prices. If you have many occasional testers, TestLodge's content-based pricing fits. If automation is the center of your testing, start on Qase's free tier. Every tool here has a trial or a free tier, so the cheapest way to decide is to write ten real tests in two of them and see which one your team keeps using.

API now includes Webhooks

Stefan Butlin — Wed, 24 Jun 2026 00:00:00 +0000

When we announced the Testpad API, we said webhooks were coming. They're here. The API can now push events to you, so the moment something happens in your Testpad account, your other tools can know about it.

What a webhook does

A webhook is a message Testpad sends to a URL of your choosing whenever a particular event happens. Instead of your tools polling the API to ask "has anything changed?", Testpad tells them as it happens. You register a URL, choose the events you care about, and Testpad posts the details there each time one occurs.

Choosing what to listen for

Webhook events come in two groups: test runs and results. You can subscribe to a whole group, to a single event within it, or to everything at once.

Test runs — a run is started, completed, or reopened
Results — a result is recorded against a test: a pass, a fail, blocked, and so on

So you might take every result as it comes in, or narrow it down to just the failures. The full list of events is in the API documentation.

Connecting without writing code

You don't have to be a developer to use webhooks. Integration platforms like Zapier, Make, and n8n can catch a webhook and turn it into an action in hundreds of other apps. Point a Testpad webhook at one of them, and you can, for example:

post a message to Slack or Teams when a test run finishes
raise an issue in Jira (or another tracker) when results come in
log results to a spreadsheet
send yourself an email or a push notification

Getting started

The Testpad API is currently available on request, and now includes webhooks. To get set up, reach out to us at support@testpad.com. You'll find how to register a webhook, the full list of events, and worked examples in the API documentation.

Testpad now supports two-factor authentication

Stefan Butlin — Wed, 24 Jun 2026 00:00:00 +0000

Testpad now supports two-factor authentication (2FA), an extra layer of security on top of your password. It's optional for any user on any plan, and account owners can require it across their whole account. This one has been on the list for a while, and we're glad to have it in.

Switching it on

Any user can switch on two-factor authentication from their profile page. You scan a QR code with an authenticator app, enter the six-digit code it shows to confirm, and that's it. From then on, signing in asks for your password and the current code from your app, so a password on its own is no longer enough to get into your account.

Requiring it for your whole account

If you own an account, you can go a step further and set two-factor authentication to required. From that point on, every member has to enrol before they can carry on using Testpad, so the protection applies right across the account. This is often where a company security policy or compliance requirement comes in, and now you can meet it.

Which apps you can use

We support the authenticator-app method (also known as TOTP). Any standard authenticator app or password manager that generates six-digit codes will work, including:

Google Authenticator
Microsoft Authenticator
Authy
1Password
Bitwarden

For now, authenticator apps are the only method we support. There's no SMS option, partly because app-generated codes are the more secure choice anyway.

If you lose your authenticator

Switched phones, or lost access to your authenticator app? Use the Forgotten Password link on the sign-in page to reset and get back into your account.

Available now

Two-factor authentication is live today, on every plan. If you hit any trouble setting it up, email us at support@testpad.com and we'll help you get sorted.

Testpad vs Zephyr: test plans, not Jira-native test cases

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

The difference between Testpad and Zephyr is structural, and it's worth understanding before you pick either tool. Zephyr builds test management on top of Jira; Testpad uses a checklist of plain text prompts in a standalone tool. This page sets out that difference, where each tool is stronger, and how the costs compare, so you can decide which fits the way your team tests.

The short version

Zephyr is two Jira-based products. In Zephyr Squad (now Essential), a test is a Jira issue. In Zephyr Scale, tests live in the app's own repository, linked to Jira issues. Either way you work inside Jira. In Testpad, a test is a line of plain text in a checklist, in its own tool, outside Jira.
Teams choose Zephyr to keep testing inside Jira, with traceability from requirements through tests to defects. Teams choose Testpad for fast manual and exploratory testing, a guest-testing feature, and a tool that stands on its own.
Zephyr's strength is being part of Jira. That is also its cost: you work through Jira, it bills on your total Jira user count rather than just your testers, and bringing in someone who isn't in Jira is hard.
Testpad is from $10/user/month, and guest testers are free. Zephyr is priced by how many Atlassian users are on your Jira instance.
Neither choice is wrong. It comes down to whether you want your test tool to run within the Jira ecosystem, or whether you want it light and standalone.

What's the actual difference?

Zephyr is built into Jira. Both editions assume Jira and run inside it. In Zephyr Squad (renamed Zephyr Essential), test cases, test cycles and executions are Jira issue types, stored in Jira itself. In Zephyr Scale, tests sit in a dedicated repository with folders, reusable steps, parameters and versioning, linked back to Jira issues for coverage. Because testing lives in or beside Jira, it shows up against your stories, in your boards and in Jira reporting, and a failing test is one click from a linked defect. Zephyr builds requirement coverage on those links, supports Cucumber and Gherkin for BDD, and pipes automated results in from CI. What you get, and what you maintain, is testing modeled as Jira-linked test cases.

Testpad is built around the test plan, on its own. A test is a line of plain text. Indenting builds the plan's structure: group related tests under a heading, or spell a bigger test out over several lines. Add a column for each test run, and mark each prompt pass or fail as you go. There's no Jira to set up and no issue type to configure. You write the way you think, share the plan with a link, and anyone, in Jira or not, can run it.

If you live in Jira and want your tests to live there too, Zephyr's model is the point. If you'd rather a test stayed a checklist item, and your testers didn't all need Jira accounts, that's the gap Testpad fills.

How do Testpad and Zephyr compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	Zephyr
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	Test cases in Jira: Jira issues in Zephyr Squad, or a linked test repository with reusable steps and parameters in Zephyr Scale
Where it runs	Its own web app; nothing to install	Inside Jira (Cloud or Data Center); no standalone use
Time to first test	Minutes; write a line and you're testing	Longer; set up the Jira project and Zephyr, then define structured test cases
Writing tests	Type a line, hit enter, repeat	Create a structured test case with steps and expected results; BDD via Cucumber and Gherkin in Scale
Guest / UAT testers	Share a link; no login, no seat, not in Jira	Testers work in Jira, so they generally need Jira access
Requirement traceability	Lightweight: clickable issue links	Deep: requirement to test to execution to defect coverage, inside Jira
Automation / BDD	Push results from CI via the REST API; Gherkin syntax supported	First-class: Cucumber and Gherkin, CI hooks, automated results recorded against Jira
Reports	An instant link, shareable with anyone	Jira dashboards plus Zephyr's own reports; advanced and cross-project reporting on higher tiers
Audit trail / permissions	Not today	Via Jira: issue history, permissions, audit logs
Pricing	From $10/user/month, guest testers free	By total Jira user count: free for up to 10 Atlassian users on Zephyr Scale, then about $5.62 per user monthly per extra user
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up, dev-led testing	Jira-centric teams, deep traceability, regulated QA, large structured test suites

Zephyr facts checked against its Atlassian Marketplace listing and SmartBear's product pages, June 2026.

Why do teams choose Testpad over Zephyr?

Testers don't need to be in Jira. In Zephyr, testing happens in Jira, so anyone who runs or records a test works in Jira and generally needs an account. Send a Testpad plan as a link to a client, a freelancer, or a non-technical coworker, and they're testing in minutes: no login, no seat, no Jira account. For UAT and outside testers, that means no Jira seats to buy and no accounts to set up.

It stands on its own. Testpad doesn't assume Jira. If your team isn't all in Jira, or you'd rather your test data didn't live inside it, Testpad is a tool in its own right: write plans, run them, share reports, done.

Less to set up and maintain. No project configuration, issue types or test-case forms before you can write a test. A plan is an outline you add a column to, so it stays light as testing grows.

Write-as-you-think speed. No structured test-case form per test. Type a prompt, hit enter, type the next. One customer described it as "just like writing… feels like you're writing a document".

Cost that follows your testers, not your whole Jira org. Zephyr bills on your total Jira user count, so every developer, product manager and designer on the instance counts toward the price whether they ever run a test or not. Testpad charges for the people testing in Testpad.

Exploratory and ad-hoc, out of the box. Exploratory testing suits a checklist plan: set a scope, then explore within each prompt and record what you find. Zephyr's structured, step-by-step test cases assume you know the test before you run it.

When is Zephyr the better choice?

When your team lives in Jira and you want testing to live there too. Tests linked to Jira give you requirement-to-defect traceability inside the tool your developers already use, coverage you can see on a Jira board, and the audit history that regulated work depends on. It handles manual and automated testing together, with strong Cucumber and BDD support and broad CI integration, and Zephyr Scale's reusable, parameterized, versioned test cases hold up across large suites and multiple projects. If your process depends on that traceability, or on testing being part of Jira rather than beside it, Zephyr is built for the job, and you'd likely be happier there. To see the wider field, our guide to Zephyr alternatives covers it.

When is Testpad the better choice?

When you want testing to be light and fast, and open to people who aren't in Jira. You run UAT with clients or freelancers, do regression and exploratory work, test hardware, or your developers test their own code and a structured test case per check is more ceremony than the testing needs. Teams of that shape get going in minutes, keep the plan light enough to stay current, and don't pay for testing seats they only hand out for a two-week burst.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for Zephyr?

For lightweight, fast manual testing it can be: UAT, regression, exploratory, hardware, dev-led testing, checking AI output. If your testing depends on living inside Jira with deep requirement-to-defect traceability and audit history, that's what Zephyr is for, and Testpad doesn't replace it.

What's the actual difference in the data model?

Zephyr stores test cases in Jira: as Jira issues in Zephyr Squad, or as a linked repository of structured test cases in Zephyr Scale. Testpad stores a test plan as a standalone nested outline of plain text prompts, with a column added per test run.

Does Testpad work without Jira?

Yes. Testpad is its own web app and doesn't need Jira or any tracker. Both Zephyr editions run inside Jira.

Does Testpad integrate with Jira?

Lightly. Set your tracker's URL pattern once and every issue ID you type in Testpad becomes a clickable link to the issue in Jira (or GitHub, Trello, and the like). There's a REST API for pushing automated results from CI. Outbound webhooks notify your other tools when runs finish or results change, directly or through Zapier and the like. There's no two-way sync and no coverage view inside Jira; Zephyr, being part of Jira, has those.

Can clients or non-technical people test in Testpad?

Yes. Share a link and a guest tests with no login, no seat, and no Jira account. Because Zephyr's testing happens in Jira, the same people would generally need Jira access.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free, charged for the people testing in Testpad. Zephyr is priced by your total Atlassian user count: free for up to 10 users on Zephyr Scale, then scaling with every Jira user on the instance, not just your testers.

Does Testpad handle BDD or automated tests?

Testpad supports Gherkin-style syntax for BDD-flavored plans and takes automated results from CI through its REST API. It doesn't run automation itself. Zephyr's Cucumber execution and automation integration go deeper; if that's central to your work, Zephyr does more.

Does Testpad have an audit trail or per-user permissions?

Not today. Zephyr inherits Jira's issue history, permissions and audit logs; if your process requires those, check before you migrate anything.

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. And no Jira required: paste in a chunk of your existing tests and see how they read as a standalone checklist.

Testpad vs TestLodge: test plans, not structured test cases

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

Both Testpad and TestLodge sit at the lightweight end of test management. Neither expects you to be running a formal QA lab, and both get you to a first test plan quickly. The difference is in the data model: what a "test" actually is in each tool. That choice shapes how you write plans, who can run them, and how you scale. This page sets out the difference precisely, covers where each tool is stronger, and compares pricing, so you can decide which fits the way your team works.

The short version

TestLodge stores structured test cases: each case has a title, a description, numbered steps, and one expected result. A Testpad test is a single plain-text prompt line.
Both are lightweight. The distinction is structured forms versus freeform prompts, not heavy versus light.
TestLodge prices by content volume (number of test runs, plans, and cases), with unlimited user accounts. Testpad prices per tester.
TestLodge requires every tester to have an account. Testpad's Guest Testing feature lets you invite people to run a plan with no login required.
TestLodge has a Requirements module for traceability. Testpad does not.
Testpad is from $10/user/month, and guest testers are free. TestLodge starts at $34/month, priced by content (test runs/plans/cases) with unlimited users, not per seat.

What's the actual difference?

TestLodge is a structured test-case manager. The data model runs Project > Test Plan > Test Suite > Test Case > Test Run. Each test case is a form: you fill in a title, a description, numbered steps, and an expected result. Attachments can go on a case. The Requirements module lets you link test cases to documented requirements and generate a traceability matrix. When you start a test run, testers work through the case list step by step and record a result per case. If a test fails, TestLodge can automatically open a bug-tracker ticket. It's cloud SaaS only, focused on manual testing, with no native automation support.

Testpad is built around the test plan as an outline. A test is a line of plain text. You write a prompt that tells the tester what to check: "Login with expired password", "Add ten items to basket, then apply a 20%-off voucher", "Resize window to 320px and check the menu". Indent to group related tests under a heading, or break a scenario into smaller steps. Add a column for each test run and mark each prompt pass or fail as you go. That's the whole model. There are no per-test ID numbers, no structured-step forms, and no per-case expected-result field. You get a column-per-run grid so run history is visible at a glance, and a shareable report link.

The distinction matters most when you're deciding how to write tests. Filling a structured form per test is thorough for formal documentation, and the expected-result field gives reviewers a clear basis for checking whether a case passed. A one-line prompt is faster to write and better suited to cases where the tester already knows what a pass looks like, or where you're exploring a feature rather than verifying a spec.

How do Testpad and TestLodge compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	TestLodge
Data model	A nested outline of plain-text prompt lines; indent for structure; one column per run	Structured test cases: title, description, numbered steps, one expected result per case
Where it runs	Cloud SaaS; nothing to install	Cloud SaaS; nothing to install
Time to first test	Minutes; type a line and you're testing	Quick; fill in a test-case form for each test
Writing tests	Type a prompt, hit enter, repeat	Create a case form: title, description, numbered steps, expected result
Guest / UAT testers	Share a link; no login needed for guests	All testers need an account
Requirement traceability	Not today	Requirements module with a traceability matrix
Run history	Column-per-run grid; history visible at a glance	Separate run instances per execution
Bug-tracker integration	Clickable issue links; REST API for CI results	Auto-create a bug-tracker ticket on a failed test
Reporting	Shareable report link	Built-in reporting per run; CSV and other export
Audit trail / permissions	Not today	Per-test history; per-case versioning
Pricing	From $10/user/month, guest testers free	$34/month to $279/month/month; priced by content (test runs/plans/cases) with unlimited users, not per seat
Best for	UAT, exploratory, regression, ad-hoc, hardware bring-up, dev-led testing	Teams that want structured, formally documented test cases with traceability to requirements

TestLodge facts checked against testlodge.com, June 2026.

Why do teams choose Testpad over TestLodge?

One-line prompts are faster to write. Filling a test-case form for every check adds time before testing can start, and the overhead compounds across a large plan. In Testpad, a line is a test. For UAT, exploratory work, and regression plans where you already know what you're checking, a prompt is enough and the form is ceremony.

Guest Testing doesn't require accounts. TestLodge requires every tester to have an account. Testpad's Guest Testing feature lets you invite clients, freelancers, or non-technical stakeholders to run a plan with no login. They click the link and they're testing. For UAT rounds, that means no TestLodge accounts to create for people outside the team. Most Testpad users log in as normal; Guest Testing is a feature you turn on when you need outside testers.

Run history is visible without navigation. Testpad's column-per-run grid shows every run side by side. You can see at a glance which tests have been passing consistently and which have been flaky across the last five runs. In TestLodge, runs are separate instances you open individually.

Write-as-you-think speed. No form per test, no expected-result field to fill. Write plans the way you'd write a checklist or a script for someone else to follow. One customer described Testpad as "just like writing... feels like you're writing a document".

Two different pricing models. TestLodge charges a flat rate by content volume, with unlimited users. Testpad charges per tester, in tiers, with guest testers free. Which works out cheaper depends on your team size and how many test cases you keep.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

When is TestLodge the better choice?

When structured, formally documented test cases matter. The numbered-steps-plus-expected-result form gives every case a clear documented baseline: anyone reading it knows what was tested, what the expected behavior was, and what result was recorded. That's useful for audit situations, regulated industries, and formal QA processes where a tester's judgment alone isn't enough documentation. The Requirements module and traceability matrix connect test cases back to requirements, which is important for teams that need to show coverage. The auto-create-ticket-on-fail integration opens a bug-tracker ticket for you when a case fails, which saves a step for teams who track bugs in a separate tool. And the flat content-based pricing with unlimited users means a small team with a fixed suite can add testers without the per-seat cost going up.

If your process needs all of that, TestLodge covers it. If you want to explore the wider market, our guide to TestLodge alternatives covers the options.

When is Testpad the better choice?

When you want testing to move fast, and when some of your testers are outside the team. You're running UAT with clients or a freelance QA contractor, doing exploratory or regression testing, testing hardware builds, or your developers test their own features and a structured test-case form per check is more overhead than the work needs. Testpad gets you from "we need to test this" to "we are testing this" in minutes, keeps the plan light enough to stay current, and lets you bring in outside testers without creating accounts for them.

Testpad does not have a requirements module, per-test IDs, or an audit trail. If your process depends on formal traceability or regulated documentation, check those gaps before switching.

Common questions

Is Testpad a replacement for TestLodge?

For fast manual and exploratory testing, UAT, and regression plans where you don't need structured case forms or requirement traceability, yes. If your process depends on numbered test steps, per-case expected results, a requirements module, or formal traceability, TestLodge covers those and Testpad doesn't today.

What's the actual difference in the data model?

TestLodge stores structured test cases: each has a title, description, numbered steps, and one expected result. Testpad stores a test plan as a nested outline of plain-text prompt lines, with one column added per test run.

Does TestLodge require accounts for all testers?

Yes. Every person who runs or records tests in TestLodge needs an account. Testpad's Guest Testing feature lets you invite testers to run a plan with no login; they click a link and test without creating an account.

How does pricing work for each?

TestLodge is priced by content (test runs/plans/cases) with unlimited users, not per seat: $34/month (Personal), $69/month (Basic), $139/month (Plus), or $279/month (Premium) per month. You can add unlimited user accounts at any tier; you pay more as your content volume grows. Testpad is from $10/user/month, and guest testers are free, charged for the people testing in Testpad. Guest testers don't count toward the seat total.

Does Testpad have a requirements or traceability module?

Not today. TestLodge has a Requirements module that links test cases to documented requirements and generates a traceability matrix. If your process depends on requirement-to-test traceability, TestLodge has it and Testpad doesn't.

Can I see test history across multiple runs in Testpad?

Yes. Testpad adds a column per run, so every run sits beside the others in a grid. You can see pass/fail history across runs at a glance. TestLodge opens runs as separate instances.

Does Testpad have an audit trail or per-test history?

Not today. TestLodge keeps per-case history and versioning. If your process requires a documented record of who tested what and when at the case level, TestLodge covers that and Testpad doesn't.

Can Testpad auto-create bug tickets when a test fails?

Not automatically. Testpad lets you set a bug-tracker URL pattern so every issue ID you type becomes a clickable link to your tracker, and there's a REST API for pushing automated results from CI. Outbound webhooks notify your other tools when runs finish or results change, directly or through Zapier and the like. TestLodge can auto-open a ticket in your bug tracker when a test run case is marked failed.

See the difference in five minutes

The fastest way to decide is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. Paste in a chunk of your existing tests and see how they read as a plain-text outline.

Testpad vs TestLink: hosted vs self-hosted, and test plans not test cases

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

The difference between Testpad and TestLink is not just about features; it starts with what kind of software each one is. TestLink is an open-source PHP application you download, install on a server you own, and keep running yourself. Testpad is a hosted web app: sign up, write a test, start. This page sets out that difference, where each tool is stronger, and how the costs actually compare, so you can decide which fits the way your team works.

The short version

TestLink is a structured test-case database you self-host: Test Projects contain Test Suites, which contain Test Cases with numbered steps and expected results. Tests are organized into Test Plans and Builds, which lets you track results build by build. Every tester needs a registered account.
Testpad is a hosted tool where a test is a line of plain text. Indent to build structure. Add a column per test run and mark pass or fail down the list. Share a report as a link. Invite outside testers without giving them a login.
TestLink's license is Free (open-source). The cost is the server you provision, secure, patch, and back up, plus the time to do it, with no official support channel. Testpad is from $10/user/month, and guest testers are free.
Neither choice is wrong. If you need on-premises data control, structured test cases with build-by-build traceability, and zero license fee, TestLink is worth the operational overhead. If you want something you can start using in minutes, open to outside testers, and maintained by someone else, that's what Testpad is for.

What's the actual difference?

TestLink is a structured, self-hosted test-case database. The data model is layered: a Test Project contains Test Suites, which contain Test Cases with a title, preconditions, numbered steps, and expected results. Tests are versioned, carry per-test IDs, and can be linked to requirements for traceability. You assemble Test Plans from selected test cases and run them against named Builds, giving you a pass/fail record per build. Role-based permissions assign different access levels per user: test designer, senior tester, leader, admin. TestLink has been in production since 2003; the open-source project is now in slow maintenance mode, with no formal support outside the SourceForge community forum.

You install and run it yourself: a web server running PHP, a MySQL or MariaDB database, and ongoing backups, security patches, and upgrades. There is no SaaS option.

Testpad is a hosted tool built around the test plan as a document. A test is a line of plain text, a prompt you act on and record. Indenting builds structure: group related tests under a heading, or expand a single test into a few lines of detail. Add a column for each test run and mark each prompt pass, fail, or not run as you go. There is no structured test-case form to fill in, no build matrix to configure before you start. Write the way you think, share the plan or its report as a link, and the people running it don't need accounts if you'd rather they didn't.

The tradeoff is straightforward: TestLink's structured model scales to large, formally organized suites with traceability and per-build records; Testpad's plain-text model gets you testing faster and keeps the plan light enough to stay current.

How do Testpad and TestLink compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	TestLink
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	Test Projects > Test Suites > Test Cases (numbered steps, expected results, versioned) > Test Plans + Builds
Where it runs	Hosted SaaS; nothing to install or maintain	Self-hosted only: PHP + MySQL on a server you own and manage
License cost	From $10/user/month, guest testers free	Free (self-hosted); you absorb the hosting and maintenance cost
Time to first test	Minutes: sign up, write a line, start	Longer: provision a server, install and configure the application, then define structured test cases
Writing tests	Type a line, hit enter, repeat	Create a test case with preconditions, numbered steps, and expected results
Per-test IDs and versioning	No per-test IDs today	Yes: each test case has an ID and version history
Requirement traceability	Lightweight: clickable issue links	Yes: requirements can be linked to test cases and coverage tracked
Guest / UAT testers	Share a link; no login required for external testers	Every tester needs a registered account on your TestLink instance
Build-by-build traceability	Columns per run, not formal Builds	Yes: Test Plans and named Builds let you compare results across releases
Per-user role permissions	Not today	Yes: granular roles (admin, leader, test designer, senior tester, tester) per project
Automation result ingestion	Push results from CI via the REST API	Yes: XML-RPC and REST API for automated result imports
Reports	An instant shareable link or saved HTML	HTML and XML reports; filterable by build, platform, and tester
Official support	Email support included	Community forum only; no commercial support
Best for	UAT, regression, exploratory, hardware bring-up, dev-led testing, fast iteration	Regulated teams with on-prem data requirements, formal test case libraries, and the IT resource to run infrastructure

TestLink facts checked against testlink.org and its SourceForge project, June 2026.

Why do teams choose Testpad over TestLink?

Nothing to install, configure, or maintain. Testpad is a hosted service. There is no server to provision, no PHP stack to configure, no database to back up, and no security patches to apply at inconvenient moments. The running cost of a TestLink deployment is the machine, the time to maintain it, and the risk of gaps. With Testpad, that work disappears.

Guest testing without accounts. Every person who runs a test in TestLink needs a registered account on your instance. Share a Testpad plan as a link, and external testers or clients record their findings with no login and no seat. For UAT with outside testers, that means no TestLink accounts to create.

Write-as-you-think speed. Opening a new TestLink test case means filling in a form: title, preconditions, a numbered step, its expected result, and then the next step. In Testpad, a test is a line. Type it, press Enter, write the next one. For teams doing exploratory, regression, or fast-moving development cycles, that speed compounds over time.

No server cost hidden inside "free". TestLink's license is free; the server it runs on is not. A VPS, keeping it patched and available, and the time of whoever maintains it add up, with downtime risk if the machine goes down before a release.

Shareable reports. A Testpad report is a link anyone can open, or a single saved HTML file. Sending a TestLink report to a stakeholder outside your instance means exporting and attaching a file.

Email support. Testpad includes email support. TestLink's support is the community forum; responses depend on volunteer availability.

When is TestLink the better choice?

When data sovereignty and zero license cost are the requirements that matter most. TestLink runs entirely on infrastructure you control, and the GPL license means you can audit and modify the code. For teams in regulated industries or government environments where test data must stay on-premises and cannot be held by a third-party SaaS provider, that constraint alone settles the choice.

Beyond that: TestLink's per-test IDs and versioning give you a persistent, auditable record of each test case across every change. The requirements-to-tests link provides formal coverage evidence. Named Builds let you compare pass rates across releases or platforms in a way that Testpad's column model does not. Granular per-user roles let you separate who can design tests, who can execute them, and who can approve them. If your process depends on any of those, TestLink handles them and Testpad does not. To see the wider field, a guide to TestLink alternatives covers other options at a similar or lower price point.

When is Testpad the better choice?

When you want a test tool your team can start using today, open to people outside your organization, and maintained by someone else. You run UAT with clients or freelancers, do regression and exploratory testing on a fast release cadence, test hardware in the field, or your developers test their own code and a full structured test-case form per check is more overhead than the testing needs. Teams of that shape get going in minutes and don't carry the operational cost of a self-hosted application.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for TestLink?

For teams moving away from a self-hosted tool toward something hosted and lower-maintenance, often yes. For teams that specifically need on-premises data control, formal per-test IDs and versioning, or granular role permissions, Testpad does not cover those today, and you should check against your requirements before switching.

What's the actual difference in the data model?

TestLink organizes tests as structured test cases: numbered steps, expected results, version history, and per-test IDs, grouped into Test Suites and assembled into Test Plans against named Builds. Testpad stores a test plan as a nested outline of plain text prompts with a column added per test run.

Is Testpad open-source or self-hosted?

No. Testpad is a hosted SaaS product; there is no self-hosted edition or open-source license. TestLink is open-source under the GPL and self-hosted only, with no SaaS option. If on-premises hosting or the ability to inspect and modify the source code is a requirement, TestLink (or another open-source tool) is the option to evaluate.

Can clients or outside testers use Testpad without accounts?

Yes. That is what Guest Testing means: share a Testpad plan as a link, and an external tester records findings with no login, no seat purchase, and no registration on your instance. TestLink requires every tester to have a registered account on the server; there is no guest or link-based access.

How does pricing actually compare?

TestLink's license is Free (open-source), but the tool runs on a server you own and maintain. Depending on your setup, that means a hosting bill, the time of whoever provisions and patches it, and the risk of downtime. Testpad is from $10/user/month, and guest testers are free, covers hosting, email support, and all feature updates, and requires no infrastructure.

Does TestLink have better support for automation?

TestLink accepts automated results via its XML-RPC and REST API, so CI tools can post pass or fail against specific test cases and builds. Testpad has a REST API for pushing results from CI, but TestLink's model is more formal: results attach to a specific test case version in a named build, which gives you structured historical records across releases. Outbound webhooks notify your other tools when runs finish or results change, directly or through Zapier and the like.

Does TestLink have per-user roles and permissions?

Yes, and Testpad does not. TestLink has five built-in roles (admin, leader, test designer, senior tester, tester) that you assign per project, so you can separate who writes tests, who runs them, and who manages the project. Testpad has no per-user permissions today; everyone with access to a project can do the same things. If role separation is a process requirement, TestLink has it and Testpad does not.

Does Testpad have an audit trail?

Not today. TestLink records who created and last modified each test case, and execution history is tied to named builds, giving you a traceable record over time. If your process or compliance regime requires that level of audit history, check Testpad's current feature set before migrating.

See the difference in five minutes

The fastest way to choose is to run a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. If you're currently self-hosting TestLink, paste a chunk of your existing tests into Testpad and see how they read as a plain-text checklist before you decide either way.

Testpad vs qTest: lightweight test plans, not an E2E enterprise platform

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

The difference between Testpad and qTest is a question of scope and scale. qTest, now part of the Tricentis suite, is an enterprise test management platform: structured test cases, automation orchestration across your whole CI pipeline, requirement-to-defect traceability, and compliance reporting, sold through a sales conversation. Testpad is a standalone checklist tool for manual and exploratory testing: write a line of plain text, add a column per test run, share the report as a link, and invite guest testers for UAT without buying them a seat. This page sets out where each tool fits, what the tradeoffs are, and how the costs compare.

The short version

qTest is an enterprise test management platform from Tricentis. Its core identity is structured test cases inside Test Modules, executed through Test Cycles, with two-way Jira integration for requirement-to-defect traceability and an audit trail for compliance. It also orchestrates automation results from Selenium, Jenkins, Tosca and other CI tools.
Testpad is a standalone tool outside Jira. A test is a line of plain text. Indent to build structure; add a column per run; share the report with a link. Invite people to test as guests with no login and no seat required.
Teams choose qTest when they need enterprise scale, deep traceability, automation orchestration, audit history, or on-premise deployment. Teams choose Testpad for fast manual and exploratory testing, UAT with outside testers, and a tool that works without a sales conversation or a significant procurement budget.
qTest is priced by quote: $1,200/user/year is a commonly reported figure for standard access, but enterprise contracts vary and you need a sales conversation to get a number. Testpad is from $10/user/month, and guest testers are free, on the website, without a call.
Neither choice is wrong. It depends on whether your testing needs the depth and compliance infrastructure of an enterprise platform, or whether it needs to start this afternoon.

What's the actual difference?

qTest is built for enterprise test management. Test cases in qTest are structured records: each has steps, expected results, custom fields, a system ID, and a full version history. They sit inside Test Modules (folders), are executed through Test Cycles and Test Suites, and link to requirements imported from Jira for end-to-end coverage (requirement to test to execution run to defect). The platform is modular: qTest Manager handles cases and execution; qTest Launch aggregates automated results from Selenium, Jenkins, Tosca and other CI frameworks alongside manual runs; qTest Insights provides cross-project reporting; qTest Pulse handles event-driven notifications and integrations; qTest Scenario supports Cucumber/BDD. It runs in the cloud and supports on-premise. SOC 2 Type 2 and ISO 27001 certifications are available for compliance teams. This is the architecture of a tool designed for organizations running thousands of test cases across many projects, teams, and automation frameworks, where traceability and audit evidence are requirements, not nice-to-haves.

Testpad is built around the test plan. A test is a line of plain text: write a prompt that tells you what to check, hit enter, write the next. Indent to group related tests under a heading or to spell a bigger test out over several steps. When you're ready to run, add a column; mark each prompt pass or fail as you go. There are no modules to configure, no test-case IDs to assign, no structured fields to fill in before you can write a test. Share the plan as a link; anyone with the link can follow it or run it. Invite people as guests for UAT and they test without creating an account.

If your testing requires the audit trail, automation orchestration, and compliance infrastructure of an enterprise platform, qTest is built for the job. If you want your test to be a prompt on a list, not a structured record in a system, that's what Testpad is for.

How do Testpad and qTest compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	qTest
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	Structured test cases (steps, fields, IDs, version history) inside Test Modules; executed via Test Cycles and Suites
Where it runs	Its own web app; nothing to install	Cloud SaaS or on-premise; part of the Tricentis suite
Time to first test	Minutes; write a line and you're testing	Longer; set up the platform, configure modules and cycles, then define structured test cases
Writing tests	Type a prompt, hit enter, repeat	Create a structured test case with steps, expected results, custom fields, and a system ID
Guest / UAT testers	Share a link; no login, no seat required	Seat-based; every participant needs a licensed account
Requirement traceability	Lightweight: clickable issue links	Deep: requirement to test to execution to defect, with coverage maps, inside Jira
Automation orchestration	Push results from CI via the REST API	First-class: qTest Launch aggregates Selenium, Jenkins, Tosca, and other CI results alongside manual runs
BDD / Gherkin	Gherkin-style syntax supported	qTest Scenario supports Cucumber and Gherkin natively
Reports	An instant link, shareable with anyone	Cross-project dashboards via qTest Insights; advanced reporting across automation and manual
Audit trail / permissions	Not today	Yes: per-test version history, execution records, and audit logs
On-premise	No	Yes
Pricing	From $10/user/month, guest testers free	Quote-based; $1,200/user/year is a commonly reported standard figure, enterprise contracts vary
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up, dev-led testing	Enterprise QA, compliance, automation orchestration, large structured test suites, regulated industries

qTest facts checked against tricentis.com/products/unified-test-management-qtest, June 2026.

Why do teams choose Testpad over qTest?

You know the price before you call anyone. qTest requires a sales conversation; the number you see on a vendor comparison site may not match the contract you sign. Testpad's pricing is on the website: from $10/user/month, and guest testers are free. For teams buying without a procurement process, or smaller teams weighing the cost against the value, that difference matters.

Guest testing for UAT. qTest is seat-based: every person who tests needs a licensed account. Testpad's Guest Testing feature lets you invite clients, freelancers, or non-technical stakeholders to run a test plan with no login, no seat, and no account of their own. For UAT with outside participants, that often settles the choice.

No setup before the first test. qTest's architecture is right for what it does, but setting it up takes time: modules, cycles, fields, and integrations before a test case is written. In Testpad, write a prompt and you're testing. Teams with regular manual testing find this keeps plans current because updating them takes seconds, not a structured edit session.

Write the way you think. No form per test, no required fields, no IDs to track. One customer described writing in Testpad as "just like writing… feels like you're writing a document". When testing moves fast, that low friction matters.

Cost that scales with your testers. qTest's pricing reflects enterprise contract structures. For teams under 20 or 30 people doing manual and exploratory testing without complex automation or compliance requirements, the cost difference is significant, and the features they'd be paying for go unused.

Standalone and Jira-optional. Testpad doesn't assume Jira or any tracker. If part of your team is outside Jira, or you'd rather keep test data in a dedicated tool rather than mixed into your issue tracker, Testpad works on its own.

When is qTest the better choice?

When your testing is enterprise-scale and the infrastructure around it matters. qTest provides requirement-to-defect traceability that you can report on and audit; automation orchestration that brings Selenium, Jenkins, Tosca, and CI results into the same system as your manual runs; reusable, versioned test-case libraries that hold up across hundreds of projects; per-test IDs that let you reference a specific case in a defect or a conversation; SOC 2 Type 2 and ISO 27001 certification for regulated work; and on-premise deployment for organizations that can't run test data in the cloud. If any of those are requirements rather than preferences, qTest is built for them and Testpad is not the right replacement. For the wider landscape, our guide to qTest alternatives covers what else is in that space.

When is Testpad the better choice?

When you need testing to start fast, stay light, and include people who aren't in your toolchain. UAT with clients or freelancers, regression passes, exploratory sessions, hardware bring-up testing, dev-led spot checks: these suit a checklist plan. No modules to maintain, no IDs to assign, no procurement cycle. Teams get going in minutes, the plan stays current because it's easy to update, and the report is a link you send to anyone.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for qTest?

For lightweight manual and exploratory testing it can be: UAT, regression, ad-hoc, hardware, dev-led testing, checking AI output. If your testing depends on enterprise traceability, automation orchestration, compliance certification, or on-premise deployment, those are what qTest is for, and Testpad doesn't replace them.

What's the actual difference in the data model?

qTest stores structured test cases with steps, expected results, custom fields, system IDs, and version history inside Test Modules, executed through Test Cycles and Suites with links to Jira requirements. Testpad stores a test plan as a standalone nested outline of plain text prompts, with a column added per test run.

Does Testpad integrate with Jira?

Can clients or outside testers run tests in Testpad without an account?

Yes. Testpad's Guest Testing feature lets you share a link and have someone test without creating an account or holding a seat. This is a deliberate feature, not the default mode: most users log in. qTest is seat-based, so every person testing needs a licensed account.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free, published on the website. qTest is priced by sales quote: $1,200/user/year is a commonly reported standard figure, but enterprise contracts vary and you need a conversation with Tricentis to get a number for your team.

Does qTest handle automation better than Testpad?

Yes, meaningfully. qTest Launch aggregates results from Selenium, Jenkins, Tosca, and other CI frameworks alongside manual test runs, with full reporting across both. qTest Scenario supports Cucumber and Gherkin natively. Testpad takes automated results from CI through its REST API and supports Gherkin-style syntax for BDD-flavored plans, but it doesn't orchestrate automation or aggregate results across frameworks. If automation orchestration is central to your work, qTest does substantially more.

Does qTest have better audit and compliance support?

qTest carries SOC 2 Type 2 and ISO 27001 certifications, maintains per-test version history and execution records, and offers on-premise deployment. Testpad is itself SOC 2 Type 2, but has no ISO 27001, audit trail, or on-premise option. If your testing has those requirements, check carefully before choosing Testpad.

Does Testpad have per-test IDs?

No. Tests in Testpad are plain text prompts in a plan; there are no system-assigned IDs. qTest assigns each test case a stable ID, which means you can reference a specific case by number in a defect, a conversation, or a traceability report. For teams that need that, Testpad doesn't have it.

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. Write a plan the way you'd think through a test session, share it as a link, and see how that fits the way your team works.

Testpad vs QMetry: just simple test plans, not an enterprise platform

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

The difference between Testpad and QMetry is a question of scope. QMetry is an enterprise test management platform built for structured testing at scale: step-by-step test cases, requirement traceability, AI-assisted test generation, audit trails, and a Jira-native option that makes tests live as Jira issues. Testpad is a standalone checklist tool built for teams that want manual and exploratory testing to be fast and open to people outside the org. This page sets out that difference, where each tool is stronger, and how costs compare.

The short version

QMetry comes in two forms: a standalone cloud platform (QTM) and a Jira Marketplace app (QTM for Jira) where tests are structured as Jira issues. Either way, the data model is step-based test cases with actions and expected results, organized into suites, cycles, and releases.
Testpad's data model is different at the root: a test is one line of plain text, indenting creates structure, and you add a column per run and mark each prompt pass or fail as you go. There are no steps, no expected-result fields, no cycles.
QMetry was acquired by SmartBear in December 2024. Its AI feature ("QMetry Intelligence," powered by HaloAI) generates structured test cases from a user story inside the tool. Testpad has an AI path too: you paste or import plain text from anywhere, including AI output, and it becomes a test plan, with the Testpad customGPT trained to output Testpad's plain-text prompts directly.
Pricing for QMetry isn't publicly listed; you contact sales. Testpad is from $10/user/month, and guest testers are free.
Neither is wrong for the right team. The question is whether your testing needs enterprise structure, in-tool generation of structured cases, Jira integration, and compliance features, or whether it needs to be light, fast, and open to testers without accounts.

What's the actual difference?

QMetry is an enterprise test management platform. Each test case has discrete steps, each with an action field and an expected result. Cases live in test suites, are grouped into test cycles tied to releases, and link to requirements and defects for end-to-end traceability. If you're on QTM for Jira, tests exist as Jira issue types, so traceability lives inside Jira. The standalone QTM platform works independently of Jira but covers the same structure. QMetry Intelligence can draft a test case from a user story, shortcutting the authoring work for large suites. The platform supports BDD, CI integration, and automation ingestion; for regulated industries it covers 21 CFR Part 11, GDPR, EU data residency, e-signatures, and full audit logging.

Testpad is built around the test plan, on its own. A test is a line of plain text. Indenting builds the plan's structure: group related tests under a heading, or spell a bigger test out over several lines. Add a column for each test run, and mark each prompt pass or fail as you go. There's no step-and-expected-result form, no test cycle to configure before you can run, no enterprise infrastructure to carry. You write the way you think, share the plan with a link, and anyone, whether they have an account or not, can run it.

If your team writes and maintains large, structured test suites across releases, with requirement coverage, audit history, and in-tool generation of structured cases from a story, QMetry is designed for that. Both tools have an AI path to authoring: QMetry generates structured cases inside the tool, while Testpad imports AI-written prompts, including from its customGPT. If you want testing to stay at the level of a checklist, fast to write and open to anyone, that's where Testpad fits.

How do Testpad and QMetry compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	QMetry
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	Step-based test cases (action + expected result) organized into suites, cycles, and releases; links to requirements and defects
Where it runs	Its own web app; no Jira needed	Standalone cloud (QTM) or inside Jira as an Atlassian Marketplace app (QTM for Jira)
Time to first test	Minutes; write a line and you're testing	Longer; configure suites, cycles, and case structure before running
Writing tests	Type a line, hit enter, repeat	Create structured test cases with action and expected-result fields per step
AI test authoring	Paste or import AI-written prompts from anywhere, including the Testpad customGPT trained to output Testpad's plain-text prompts	QMetry Intelligence (HaloAI) generates structured test cases from a user story inside the tool
Guest / UAT testers	Share a link; no login, no seat needed	Testers need a provisioned account in QMetry or, for QTM for Jira, in Jira
Requirement traceability	Lightweight: clickable issue links	Deep: requirement to test to execution to defect, with coverage metrics
Automation / BDD / CI	Push results from CI via the REST API; Gherkin syntax supported	First-class: BDD, CI integration, automation ingestion, parameterized execution
Reports	An instant shareable link	Built-in dashboards, charts, and release-level reporting
Audit trail / compliance	Not today	21 CFR Part 11, GDPR, EU data residency, e-signatures, full audit logging
Pricing	From $10/user/month, guest testers free	Contact sales; pricing isn't publicly listed
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up, dev-led testing	Enterprise QA, large structured test suites, regulated industries, Jira-centric teams

QMetry facts checked against SmartBear's QMetry product pages and the Atlassian Marketplace, June 2026.

Why do teams choose Testpad over QMetry?

Minutes to your first test. No suite structure, no cycle setup, no step-and-expected-result form before you can run. Open a project, type a line of plain text, add a column, and you're testing. For regression runs, UAT windows, and exploratory work, that speed matters.

Guest Testing for UAT. Invite someone outside the org and they test via a link with no login and no seat. QMetry requires every tester to be provisioned in the platform. For clients, stakeholders, or contractors running a two-week UAT cycle, not having to create and manage accounts for all of them changes the calculation.

Transparent pricing. Testpad publishes its prices. QMetry's pricing isn't publicly listed, which means a sales conversation before you can evaluate cost. Whether that's a problem depends on where you are in the buying process, but for teams that want to know what they're signing up for before they call anyone, Testpad is the simpler path.

No enterprise overhead if you don't need it. QMetry's depth, suites, cycles, releases, requirement matrices, compliance modules, is exactly what enterprise regulated teams need and exactly what adds friction for teams that just want to keep testing current. Testpad stays light; the plan is the plan.

Write-as-you-think speed. Exploratory testing suits a checklist plan: set a scope, explore within each prompt, record what you find. A step-and-expected-result form assumes you know the test before you run it, which isn't always how exploratory or ad-hoc testing goes.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

When is QMetry the better choice?

When your testing needs the structure it provides. For large, regulated, or compliance-sensitive QA programs, QMetry's step-based test cases, requirement-to-defect traceability, e-signatures, and audit logging are not optional niceties; they're the job. QMetry Intelligence drafts a structured test case from a user story inside the tool, which shortcuts authoring at scale; Testpad's AI path works differently, since you paste or import AI-written prompts (including from the Testpad customGPT) rather than generating cases in the tool. The Jira-native option (QTM for Jira) means tests sit inside Jira alongside the stories they cover, which appeals to teams that want testing and development to live in the same tool. If your process depends on any of these, Testpad won't cover it, and QMetry is the right choice. To see the wider field, our guide to QMetry alternatives covers it.

When is Testpad the better choice?

When testing needs to stay light and open. Teams running UAT with clients, regression passes without the overhead of structured test cases, exploratory sprints, hardware testing, or developer-led checking find Testpad fits how they actually work. You start in minutes, the plan is as simple or as detailed as the work needs, and anyone, inside or outside the org, can run it without an account. For work that doesn't need enterprise structure, carrying that structure doesn't help.

Common questions

Is Testpad a replacement for QMetry?

For lightweight manual and exploratory testing it can be: UAT, regression, ad-hoc checking, hardware bring-up, developer-led testing. If your work depends on step-based test case management, requirement traceability, compliance features, or deep Jira integration, QMetry covers things Testpad doesn't, and replacing it wouldn't make sense.

What's the actual difference in the data model?

QMetry stores step-based test cases: each test has discrete action and expected-result fields per step, organized into suites and cycles, linked to requirements and defects. Testpad stores a test plan as a standalone nested outline of plain text prompts, with one column added per test run.

Does QMetry work without Jira?

Yes. QMetry's standalone cloud platform (QTM) runs independently of Jira. The QTM for Jira edition runs as an Atlassian Marketplace app inside Jira and requires it. Testpad also runs independently; it doesn't need Jira or any tracker.

Can QMetry generate test cases with AI?

Yes, and so can Testpad, by a different route. QMetry Intelligence, powered by HaloAI, generates structured test cases from a user story inside the tool. Testpad lets you paste or import plain text from anywhere, including AI output such as ChatGPT, and turn it into a test plan; the Testpad customGPT is trained to output Testpad's plain-text prompts directly, so AI-written prompts drop straight into a plan.

Can clients or non-technical people test in Testpad?

Yes. Share a link and a guest tests with no login and no provisioned account. In QMetry, every tester needs a provisioned account, whether on the standalone platform or in Jira for QTM for Jira.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free. QMetry's pricing isn't publicly listed; you contact sales for a quote. The QTM for Jira Atlassian Marketplace app has an indicative entry tier of $36.30 total per month for teams over 10 users.

Does Testpad have an audit trail or compliance features?

Not today. Testpad is SOC 2 Type 2, but it has no audit trail, per-user permissions, or e-signatures. QMetry adds 21 CFR Part 11, GDPR, EU data residency, and full audit logging; if your process requires any of those, check before you move anything.

Does Testpad integrate with Jira?

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. Paste in a chunk of your existing tests and see how they read as a standalone checklist, no sales call required.

Testpad vs PractiTest: lightweight test plans, not an E2E enterprise platform

Stefan Butlin — Tue, 16 Jun 2026 00:00:00 +0000

The difference between Testpad and PractiTest is structural, and it shapes almost every comparison between them. PractiTest is a large test management platform: requirements, a test-case library, test runs, issues, and reports, configured and linked together. Testpad is a checklist tool: a test is a line of plain text, and a test plan is an outline of those prompts with a column per run. This page sets out that difference, where each tool is stronger, and how the costs compare.

The short version

PractiTest is a full test management system. You work across five modules: capture requirements, build a test library of reusable cases, assign test sets for execution, track issues, and generate reports. A tag-based filter system links everything in any direction, so you can trace a requirement to the tests that cover it and back again.
Testpad is a test plan tool. Write a line, hit enter, write the next. Add a column for a test run, mark each prompt pass or fail, share the result with a link. No modules to navigate before you can run a test.
Teams choose PractiTest for end-to-end traceability from requirements to defects, structured reusable test libraries, Jira and Azure DevOps integration, and added compliance controls (ISO 27001, audit logs, per-user permissions). Teams choose Testpad for fast manual testing, UAT with outside testers, and a lighter price at small scale.
PractiTest's Team plan is $49/user/month with a minimum of five seats; Testpad is from $10/user/month, and guest testers are free.
Neither choice is wrong. It comes down to whether you need the structure and traceability of a full platform, or whether a checklist is enough.

What's the actual difference?

PractiTest is a structured end-to-end platform. It links requirements to test cases, test cases to runs, runs to the defects they raise, and all of it to reports. The organizing principle is a tag-based filter system: rather than rigid folders, you tag tests and filter across any dimension you define, so you can build a view that shows every test covering a particular requirement, feature, or release in seconds. Test cases are reusable; edit one and every test set that includes it reflects the change. There's a two-way sync with Jira and Azure DevOps, automation ingestion from CI pipelines, and compliance certification (SOC 2 Type II, ISO 27001). What you get is a system designed to give visibility and traceability at scale.

Testpad is built around the test plan. A test is a line of plain text. Indenting builds the plan's structure: group related checks under a heading, or spell a bigger scenario out over several lines. Add a column per test run, mark each prompt pass or fail, share the result with a link. There's no requirements module, no reusable test-case library, no tag taxonomy to design. You write the way you think, and anyone who can read can run the tests.

If your process requires a traceable chain from requirements through tests to defects and reports, PractiTest's model is designed for that job. If you want to write a test plan quickly and share it without onboarding the whole team into a multi-module system, that's the gap Testpad fills.

How do Testpad and PractiTest compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	PractiTest
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	A database of test cases (steps, expected results, custom fields), linked to requirements, runs, and issues
Organizing principle	Indented outline; structure comes from the text itself	Tag-based filter system across unlimited custom dimensions
Time to first test	Minutes; write a line and you're testing	Longer; set up modules, configure tags, and build a test library before the first run
Writing tests	Type a line, hit enter, repeat	Create reusable test cases in the library; assign them to test sets for execution
Requirement traceability	Lightweight: clickable issue links	End-to-end: requirement to test case to run to defect, in both directions
Guest / UAT testers	Share a link; no login required; guests can execute tests and mark pass/fail	Commenter seats give stakeholders read-only view with sign-in required; they cannot execute test runs
Stakeholder visibility	Shareable report link	Dashboards and configurable reports; Commenter seats for sign-in-gated read access
Automation / CI	Push results from CI via REST API	Two-way Jira and Azure DevOps sync; automation ingestion from CI pipelines
Reusable test cases	No dedicated library; copy a plan and edit	Yes: edit one test case and all sets that include it update
Reports	An instant shareable link	Configurable dashboards and reports across modules
Audit trail / permissions	Not today	Yes: user-level permissions, activity logs
Compliance	SOC 2 Type 2	SOC 2 Type 2, ISO 27001
Pricing	From $10/user/month, guest testers free	$49/user/month (Team, minimum 5 seats); Corporate is a custom quote
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up, dev-led testing	Teams needing end-to-end traceability, structured test libraries, compliance, and deep tracker integration

PractiTest facts checked against practitest.com, June 2026.

Why do teams choose Testpad over PractiTest?

Minutes to first test. PractiTest is a large platform that takes configuration and setup before you can run a test: you build a test-case library, design a tag taxonomy, and map test sets to requirements. In Testpad, you type a line and you're testing.

Guest testing for UAT. Testpad's Guest Testing lets you invite testers with no account at all: share a link, and a client, stakeholder, or freelancer can run the tests and mark pass/fail without signing up. PractiTest does offer stakeholder access via Commenter seats, but they're different: Commenters need a login and can view and comment but cannot execute test runs. If you need outside testers to actually run your test plan, that distinction matters.

Lower minimum cost for small teams. PractiTest's Team plan starts at five seats. Testpad sells in tiers too, but its Essential tier starts at three testers, so a two or three-person team starts lower. And Testpad's guest testers are free.

Plain-text authoring. A Testpad test is a sentence, written the way you'd describe the check to a colleague. No step-and-expected-result form, no mandatory fields. For ad-hoc, exploratory, and UAT work, the writing process matches the thinking process.

No mandatory structure. PractiTest's value proposition includes a structured system for traceability and visibility. That structure is also overhead: you maintain the module relationships, the tag taxonomy, the test library, and the mapping from requirements to tests. Testpad's overhead is one outline.

When is PractiTest the better choice?

When you need end-to-end traceability and structured test management. PractiTest's tag-based filter system gives you visibility in any direction across requirements, tests, runs, and defects, at the scale where coverage gaps and release-readiness dashboards matter. Its reusable test cases mean a product change triggers an edit in one place, not a dozen. The two-way Jira and Azure DevOps sync keeps your test and defect data consistent without manual work. And for teams operating under tighter compliance requirements, PractiTest adds ISO 27001, per-user permissions, and audit logs that Testpad doesn't have today (Testpad is itself SOC 2 Type 2).

One thing to plan for: PractiTest is a substantial tool. Getting a team up to speed typically means demos and sandbox time, not a half-hour of clicking around. Its UI is functional but often called dated in customer reviews. And the five-seat floor on the Team plan can feel expensive before you've filled those seats. Those aren't disqualifiers, but they're worth accounting for during evaluation. Note that the Capterra sample for PractiTest is relatively small, so public review averages may not fully represent the range of team experiences.

When is Testpad the better choice?

When you want testing to be light, fast, and open to people who aren't in your test management system. You run UAT with clients or freelancers who shouldn't need to create accounts, do regression and exploratory testing, test hardware, or your developers test their own code and a structured test-case form is more overhead than the check warrants. Teams of that shape get going in minutes, keep plans light enough to stay current, and don't pay for a five-seat minimum when two people do the testing.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for PractiTest?

For lightweight, fast manual testing it can be: UAT, regression, exploratory, hardware, dev-led testing. If your process depends on end-to-end requirement traceability, a reusable structured test library, two-way Jira sync, or compliance certification, those are things PractiTest is built for and Testpad doesn't replicate.

What's the actual difference in the data model?

PractiTest organizes testing across five modules connected by a tag-based filter system: requirements map to test cases, which run in test sets, which generate issues and feed reports. Testpad stores a test plan as a standalone nested outline of plain text prompts, with a column added per test run.

How does guest testing in Testpad compare to PractiTest's Commenter seats?

They're meaningfully different. In Testpad, a guest needs no account: follow a link and they can run tests and mark pass/fail. PractiTest offers Commenter seats, but they require signing in and they're read-only; Commenters can view results and leave comments but cannot execute test runs. If you need outside testers to run your test plan and record results, Testpad's guest testing is designed for that; PractiTest's Commenter seats are not.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free, charged for the people testing in Testpad. PractiTest's Team plan is $49/user/month with a minimum of five seats; for 10 seats that's $5,880 per year. Corporate pricing is a custom quote.

Does Testpad integrate with Jira?

Lightly. Set your tracker's URL pattern once and every issue ID you type in Testpad becomes a clickable link to the issue in Jira (or GitHub, Trello, and similar). There's a REST API for pushing automated results from CI. Outbound webhooks notify your other tools when runs finish or results change, directly or through Zapier and the like. There's no two-way sync and no coverage view inside Jira; PractiTest's Jira integration covers both directions and is considerably deeper.

Does PractiTest handle automation?

Yes. PractiTest supports ingesting automated results from CI pipelines and integrates with Jira and Azure DevOps for two-way sync. Testpad takes CI results via its REST API but doesn't do bidirectional tracker sync. If automation and CI integration are central to your process, PractiTest does substantially more.

Does Testpad have requirement traceability?

Lightly. You can drop issue IDs into any test prompt and they become clickable links to the tracker. There's no built-in requirements module and no bidirectional coverage view. PractiTest's tag-based filter system traces requirements through tests to runs and defects in any direction; Testpad doesn't do that.

Does Testpad have an audit trail or per-user permissions?

Not today. Testpad is SOC 2 Type 2, but it has no audit trail or per-user permissions. PractiTest adds user-level permissions, activity logs, and ISO 27001. If your process or regulatory context requires those, check Testpad's current capabilities before making a switch.

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. Write a plan, add a run column, and share the result with a link: if that's the shape of testing you need, you'll know quickly.

Testpad vs Xray: test plans, not test cases inside Jira

Stefan Butlin — Mon, 15 Jun 2026 00:00:00 +0000

The difference between Testpad and Xray is structural, and it's worth understanding before you pick either tool. Xray builds on Jira issues to model your tests; Testpad uses a checklist of plain text prompts in a standalone tool. This page sets out that difference, where each tool is stronger, and how the costs compare, so you can decide which fits the way your team tests.

The short version

In Xray, a test is a native Jira issue: a configured issue type with fields, a workflow, and links to the requirements it covers. In Testpad, a test is a line of plain text in a checklist, in its own tool, outside Jira.
Teams choose Xray to keep testing inside Jira, with full traceability from requirements through tests to defects. Teams choose Testpad for fast manual and exploratory testing, a guest-testing feature, and a tool that stands on its own.
Xray's strength is being part of Jira. That is also its cost: you work through Jira, it bills on every Jira user rather than just your testers, and bringing in someone who isn't in Jira is hard.
Testpad is from $10/user/month, and guest testers are free. Xray is priced by your total Jira user count.
Neither choice is wrong. It comes down to whether you want your test tool to run within the Jira ecosystem, or whether you want it light and standalone.

What's the actual difference?

Xray is built into Jira. Every testing artifact is a real Jira issue: a Test, a Precondition, a Test Set, a Test Plan, a Test Execution. Because a test is a Jira issue, it shows up on your boards, in JQL, and in Jira reporting, and it links to the story it covers and the bug it found. Xray builds requirement coverage and traceability on top of those links, supports Cucumber and Gherkin for BDD, and pipes automated results in from CI. What you get, and what you maintain, is testing modeled as configured Jira issues.

If you live in Jira and want your tests to live there too, Xray's model is the point. If you'd rather a test stayed a checklist item, and your testers didn't all need Jira accounts, that's the gap Testpad fills.

How do Testpad and Xray compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	Xray
Data model	A test plan: a nested outline of plain-text prompts that read like a checklist, with a column per run	Testing as native Jira issues: Test, Test Set, Test Plan and Test Execution issue types, stored in Jira
Where it runs	Its own web app; nothing to install	Inside Jira (Cloud or Data Center); no standalone use
Time to first test	Minutes; write a line and you're testing	Longer; set up the Jira project, issue types, fields and workflow first
Writing tests	Type a line, hit enter, repeat	Create and configure a Jira issue per test; BDD via Cucumber and Gherkin
Guest / UAT testers	Share a link; no login, no seat, not in Jira	Testers work in Jira, so they generally need Jira access
Requirement traceability	Lightweight: clickable issue links	Deep: requirement to test to execution to defect coverage, built into Jira
Automation / BDD	Push results from CI via the REST API; Gherkin syntax supported	First-class: Cucumber and Gherkin run in Jira, with broad CI and framework integration
Reports	An instant link, shareable with anyone	Jira dashboards and coverage reports; advanced and cross-project reporting on higher tiers
Audit trail / permissions	Not today	Via Jira: issue history, permissions, audit logs
Pricing	From $10/user/month, guest testers free	By total Jira user count: from $10/month for up to 10 Jira users, then about $6.50 each per month per extra user
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up, dev-led testing	Jira-centric teams, deep traceability, regulated QA, large test repositories

Xray facts checked against its Atlassian Marketplace listing, June 2026.

Why do teams choose Testpad over Xray?

Testers don't need to be in Jira. In Xray a test is a Jira issue, so anyone who runs or records a test works in Jira and generally needs an account. Send a Testpad plan as a link to a client, a freelancer, or a non-technical coworker, and they're testing in minutes: no login, no seat, no Jira account. For UAT and outside testers, that often decides the choice.

Less to set up and maintain. No project configuration, issue types or workflows before you can write a test. And because frequent runs in Xray create a lot of Jira issues (Xray's own guidance is to split tests and executions into separate projects to keep things manageable), an outline you just add a column to stays lighter as testing grows.

Write-as-you-think speed. No issue form per test. Type a prompt, hit enter, type the next. One customer described it as "just like writing… feels like you're writing a document".

Cost that follows your testers, not your whole Jira org. Xray bills on your total Jira user count, so every developer, product manager and designer on the instance counts toward the price whether they ever run a test or not. Testpad charges for the people testing in Testpad.

Exploratory and ad-hoc, out of the box. Exploratory testing suits a checklist plan: set a scope, then explore within each prompt and record what you find. In Xray, dedicated exploratory support sits in a higher tier.

When is Xray the better choice?

When your team lives in Jira and you want testing to live there too. Tests as Jira issues give you requirement-to-defect traceability inside the tool your developers already use, coverage you can see on a Jira board, and audit evidence that holds up in regulated work. Its users in medical devices, automotive, aerospace and finance rely on exactly that. It handles manual and automated testing in one place, with strong Cucumber and BDD support and broad CI integration, and it scales to large test repositories. If your process depends on that traceability, or on testing being part of Jira rather than beside it, Xray is built for the job, and you'd likely be happier there. To see the wider field, our guide to Xray alternatives covers it.

When is Testpad the better choice?

When you want testing to be light and fast, and open to people who aren't in Jira. You run UAT with clients or freelancers, do regression and exploratory work, test hardware, or your developers test their own code and a configured Jira issue per test is more ceremony than the testing needs. Teams of that shape get going in minutes, keep the plan light enough to stay current, and don't pay for testing seats they only hand out for a two-week burst.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for Xray?

What's the actual difference in the data model?

Xray stores testing as native Jira issues (Test, Test Set, Test Plan, Test Execution), inside Jira. Testpad stores a test plan as a standalone nested outline of plain text prompts, with a column added per test run.

Does Testpad work without Jira?

Yes. Testpad is its own web app and doesn't need Jira or any tracker. Xray runs only inside Jira.

Does Testpad integrate with Jira?

Can clients or non-technical people test in Testpad?

Yes. Share a link and a guest tests with no login, no seat, and no Jira account. Because Xray's tests are Jira issues, the same people would generally need Jira access.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free, charged for the people testing in Testpad. Xray is priced through the Atlassian Marketplace by your total Jira user count: cheap and flat for up to 10 Jira users, then scaling with every Jira user on the instance, not just your testers.

Does Testpad handle BDD or automated tests?

Testpad supports Gherkin-style syntax for BDD-flavored plans and takes automated results from CI through its REST API. It doesn't run automation itself. Xray's Cucumber execution and automation integration go deeper; if that's central to your work, Xray does more.

Does Testpad have an audit trail or per-user permissions?

Not today. Xray inherits Jira's issue history, permissions and audit logs; if your process requires those, check before you migrate anything.

See the difference in five minutes

Test plans, not test cases

Stefan Butlin — Thu, 11 Jun 2026 00:00:00 +0000

A test plan written as an outline of short prompts does everything a suite of formal test cases does for most teams, at a fraction of the writing and maintenance cost. The detail belongs in your product documentation and your testers' training, not spelled out again and again in every test.

At a glance

Test documentation serves two audiences, testers and managers, and neither needs most of the words in a formal test case
The format fails twice over: too many words, and too much instruction
Much of the word count is product documentation hiding in the wrong place
Step-by-step detail serves a tester's first run; it taxes every run after
The alternative is a test plan written as one-line prompts, adding detail only where a particular test needs it
Counting test cases never measured coverage anyway

What do you actually need from your test documentation?

Testing exists to learn the state of your product, so the people deciding what happens next are deciding on facts. The documentation is there to serve that, and it has two audiences.

Testers need to know what to test next, and somewhere to record what they found and what they actually did. Managers need to plan the work, see progress, judge how much is left, and report what was learned. Both would like the work to be reusable next time.

That short list covers most of what test documentation is for, and it's worth writing out because it gives you a way to judge the format itself: a word that isn't serving someone on the list is costing time for nothing. (If you want the textbook definitions of plan, case, and script first, we have those too. This article is about the format.)

Why does writing test cases take longer than the testing?

The standard advice for writing a test case asks for a title, preconditions, numbered steps, and expected results, and often more: a priority, a requirement link, an environment field. Written out properly, a single test of a login form runs to a hundred words. A competent tester needed seven: login with the wrong password is denied.

The other ninety-three words aren't free. They cost something when they're written, then again every time someone reads the case, again when it's reviewed, and again every time the product changes and the case has to change with it. Multiply by a few hundred cases and you arrive at the complaint testers have been making for years: more time is spent writing and maintaining the tests than actually testing. Joep Schuurkes made the longer version of the argument in It's time to retire our test case management tools back in 2020.

When the plan changes mid-sprint and forty cases need editing before anyone can test the new behavior, the documentation has stopped serving the testing. The testing is serving the documentation.

Do step-by-step instructions make testing better?

There's a second cost, separate from the word count. A test case that prescribes every step is in effect a transcript of a testing session, written before the session happens, and the tester's job becomes performing it. Performed faithfully, it covers what it mentions, and very little else. The bug sitting one field to the left goes unnoticed, because noticing wasn't in the steps.

This isn't a fringe view held only by process skeptics. Martin Fowler calls it a red flag if a team isn't doing exploratory testing at all, even when its automated testing is excellent. James Bach and Michael Bolton recently spent an entire book, Taking Testing Seriously, on the case that testing is a thinking activity rather than a clerical one. The expensive bugs are usually the ones nobody thought to write a step for.

A prompt works differently. Give a tester logging in with bad credentials and they'll try the wrong password, the empty password, the expired account, and the trailing space on a pasted password that you didn't think of. The line tells them where to look and leaves the looking to them. That freedom is exactly what the transcript was suppressing, and you get it back while still having a plan and a record. (We've written more on keeping plans light enough to explore within, and there's a full guide to exploratory testing if you want the deeper treatment.)

None of this makes structure the enemy. The plan is still a plan. What changes is how much each line presumes to direct the person reading it.

Should your test cases double as product documentation?

Read a detailed test case closely and most of it isn't testing instruction at all. It's product documentation: how to reach the settings page, what the export button is called, what the field accepts, what the dialog should say. Restated, slightly differently, in every case that touches that part of the product.

That information belongs somewhere, just not scattered across a few hundred test cases, which is the one place it can't be maintained: when the export dialog changes, every case that described it is now wrong, and nobody knows how many there are.

So document the product once, in the product documentation. Train testers on the product once, when they join. Then let each test say only what's specific to that test. The login example above got shorter because its detail was already somewhere better, not because anything was lost.

Do your testers really need all that detail?

Detail in a test case is written for a reader who barely exists: the tester seeing the product for the very first time. They're only that person once. From the second run onward, the spelled-out steps are something to scroll past, and something to keep correct forever.

There's a real exception. If your testers are new every time, because the work rotates through contractors or an outsourced pool, then per-step detail is doing a real job. But follow that logic to its end. A test that can be performed by a stranger following instructions, identically, time after time, is a test a machine could perform. That's an argument for automating those particular tests when the cost makes sense, not for keeping humans on transcript duty indefinitely. (For the teams in that situation meanwhile, checklists for outsourced testers covers the middle ground, and manual vs automated covers the boundary.)

The manual testing that remains is the kind where a person's own attention does the work. Which is exactly the kind that doesn't want step-by-step instructions in the first place.

What can you use instead of test cases?

Write the plan as an outline of prompts. A prompt is a short line that points at something worth testing. Related prompts sit together under a heading, so each one reads in the context of its neighbors, and the heading does the scene-setting once. Results are recorded against each line, so the plan doubles as the record.

To be precise about the term: "test plan" already means things in testing. Sometimes it's the formal document setting out how testing will be conducted, with what resources and constraints; sometimes it's loose shorthand for a team's whole collection of test cases. We're not coining a third artifact. The argument is that the plan is the more useful level to think at, because "plan" carries none of the form-filling that "test case" has come to imply.

Prompts work at whatever altitude suits the test. Some are a single precise test: "apply 3.3V to TP12, measure 2.7V ±5% on TP14" is a real one from a hardware team. One line, no schema. Others deliberately stay higher: "try to break the date picker" is a fine prompt, and a tester can spend a productive half hour inside it, running dozens of tests of their own devising. And where one particular test does need step-level care, indent beneath it and write the steps. Detail becomes a choice you make per test, not a form the format makes you fill in.

Here are three tests, written both ways:

The formal test case	The same test as a prompt
Title: Verify error message on invalid login attempt Preconditions: A user account exists. The user is logged out. Steps: 1. Navigate to the login page. 2. Enter a valid username. 3. Enter an invalid password. 4. Click Sign in. Expected result: An error message is shown and no session is created. Priority: Medium	login with the wrong password is denied
Title: Verify date picker accepts February 29 in a leap year Preconditions: The booking form is open. Steps: 1. Open the date picker. 2. Navigate to February 2028. 3. Select the 29th. Expected result: The date is accepted and the field shows 02/29/2028. Priority: Low	February 29 in a leap year is accepted
Title: Verify password reset via email link Preconditions: An account exists with a reachable email. The user is logged out. Steps: 1. Click Forgot password on the login page. 2. Enter the account email and submit. 3. Open the reset email and follow the link. 4. Set a new password. 5. Log in with it. Expected result: The email arrives, the link opens the reset form, the new password logs in and the old one doesn't. Priority: High	reset a forgotten password the reset email arrives and the link works the new password logs in, the old one doesn't

What tooling do you need?

Teams have made this trade before. Project managers mostly stopped maintaining Gantt charts and moved to boards. Product teams swapped requirements documents for user stories. Each time, the heavyweight document about the work gave way to a lighter structure for doing the work, and the feared loss of control mostly never arrived. Testing's version of that move is from test cases to an outline.

Testpad is a tool built on exactly this model: a script is an outline of prompts with a column of results per run, and that's most of the idea. But the model doesn't need a product. A text file or a spreadsheet is a perfectly good place to start for a team of one or two; what eventually moves teams to a tool is who else needs to see the plan and its results. How to write a test plan walks through starting one, and checklists vs test cases weighs the same trade-off test by test.

Don't managers need test cases to prove coverage?

Managers need a record of what was tested, with results, progress against the plan, and some sense of how much is left. That's a reasonable requirement.

Exploratory testing, for all its strengths, struggles to meet it. It does produce a record: the notes a tester takes during their sessions. But the completeness and accuracy of those notes depend entirely on that tester's note-taking, a narrative of what was done can't be scanned at a glance, and reusing the notes next time means rewriting them into a list of items, at which point you've written a plan after the fact.

A plan written as an outline of prompts produces the record as a side effect of the testing. The list is the plan, the results against each line are the evidence, progress is how much of the list has results, and the report is the list, annotated. None of it comes from the paragraphs inside formal cases.

The one thing that does go missing is the test case count. But the count was never the measure it appeared to be: a case can bundle a dozen verifications or just one, so "340 test cases, 280 executed" mostly reports how the author sliced up the writing. A report built on the plan says more: what was covered, what was found, and what that means for shipping. Which is the question testing was supposed to answer in the first place. (More on reports that say something in simple test reports and why hiding test results backfires.)

Should you let AI write your test cases?

AI assistants are good at exactly the part of formal test cases that made them painful: the writing. Describe a feature and you'll get plausible cases, formatted fields and all, faster than any human author. If the writing cost were the whole problem, it would now be solved.

It was never the whole cost. Every generated word still has to be read, reviewed, trusted, and kept true as the product changes, and those costs scale with the volume of words, not with how cheaply they were produced. The 2025 DORA report found 90% of developers using AI while only 24% trust its output "a lot". Stack Overflow's 2025 survey put "almost right, but not quite" at the top of the frustration list. Generating more test case text into that situation produces more reviewing, not more testing.

The format question points the other way, though. Ask an AI assistant how to test a feature and what comes back is a plain-text list: one line per test idea, indented for structure, much as markdown is its natural way to structure prose. That list is already in the same shape as the test plan this article has been describing, so the work left is editorial: cut the suggestions that miss, reorder what's left, and you have a usable outline. Turning the same output into formal test cases is real work by comparison: someone has to interpret each suggestion, reword it as a case, add the product detail for how to get there, and spell out the verifications the one-liner left implied. (If you do use AI to draft tests, how to use AI to write better test scripts has the practical version.)

When are formal test cases the right call?

Sometimes the formality is the requirement. Regulated and compliance-driven work can mandate per-case documentation with traceability back to requirements, and if an auditor needs it, you write it. That's a constraint to respect, not a process failure. And as above, tests that must be performed identically by ever-changing hands are better candidates for automation than for documentation.

For everyone else, the better default is a plan written as an outline of short prompts, grouped under headings, with detail added to the particular tests that need it. Traditional test case management covers what the heavyweight tools are like to live with, and checklists vs test cases goes deeper on the compliance angle.

A final word

Testing exists to learn about the state of your product so you can decide what to do next. Every hour your testers spend maintaining paragraphs of case documentation is an hour of looking at the product that never happens. Write the plan as prompts, keep the product detail in your documentation and your training, and spend the difference on testing.

Testpad is built on this model: plans as outlines of prompts, with results, guest testing, and reports on top. Try it free for 30 days.

Testpad vs TestRail: test plans, not a database of test cases

Stefan Butlin — Wed, 10 Jun 2026 00:00:00 +0000

TestRail and Testpad start from different ideas of what a test is. In TestRail, a test is a case: a record with steps and an expected result, filed in a database. In Testpad, a test is a prompt: a single line telling a tester what to check. That sounds like a detail, but it sits upstream of everything else, including how fast you write tests, who can run them, and what each tool costs. This page walks through that difference and where each tool wins.

The short version

A test in TestRail is a record in a case database, by default a form with preconditions, steps and expected result. A test in Testpad is a line of plain text in a checklist.
Teams move to Testpad for write-speed, no-login guest testing, and reports you can share as a link.
Teams stay on TestRail for deep traceability, granular permissions, audit history, and its integration ecosystem (two-way Jira, automation frameworks). Testpad doesn't have those today.
Testpad is from $10/user/month, and guest testers are free. TestRail licenses every user, from $37/user/month.
Neither choice is wrong. It depends on whether your testing is formal process or fast feedback.

What's the actual difference?

TestRail is built around the test case. A test is a record in a database: by default a title, preconditions, steps, and an expected result, often with custom fields on top. There are other templates, including one for exploratory sessions, but they're all case records you file, organize and keep current. That structure is what makes TestRail strong at traceability and formal process, and it's also what you maintain. TestRail has added AI case generation (since 2025), which speeds up the writing. It doesn't change what you end up owning: a database of cases that someone keeps current.

Testpad is built around the test plan. A test is a line of plain text. Indenting builds the plan's structure: group related tests under a heading, or spell a bigger test out over several lines. Add a column for each test run, and mark each prompt pass or fail as you go. There's no case database to design first: you write the way you think, and the structure comes from the outline, not from a form.

If you've ever stared at a preconditions / steps / expected result form for a five-second check and thought "this is more documentation than test", that's the gap. TestRail asks every test to become a structured case. Testpad lets a test stay a prompt.

How do Testpad and TestRail compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	TestRail
Data model	Documents holding test plans: each a nested outline of test prompts that look like a checklist	Database of test cases: each holding title, preconditions, steps, expected outcomes and more
Time to first test	Minutes; no case structure to design	Longer; set up projects, suites and case fields first
Writing tests	Type a line, hit enter, repeat; or copy/paste import from AI suggestions	A form per case; AI generation (2025) speeds it up
Guest / UAT testers	Share a link; no login, no seat	Paid seat per user; no guest or viewer roles
Reports	An instant link, shareable with anyone	A report wizard builds each report; a notification arrives when it's ready to download
Traceability to requirements	Lightweight	Deep, with requirement and defect links
Integrations	Clickable issue links (Jira, GitHub, Trello); REST API for CI/CD results	A platform: two-way Jira, automation frameworks, CI/CD pipelines, extensive API
Audit trail / change history	Not today	Per-case history; full audit log on Enterprise
Per-user access control	Not today; anyone in an account can edit	Yes, granular roles
Pricing	From $10/user/month, guest testers free	$37/user/month (Professional); Enterprise billed yearly only
Best for	UAT, regression, exploratory, ad-hoc, hardware bring-up	Formal QA process, large QA teams, deep traceability

Facts checked against TestRail 10.2 and its published pricing, June 2026.

"…saving 20–30% of my time using Testpad over TestRail."

Mike Gerrie, TestLauncher

Why do teams move from TestRail to Testpad?

Guest testing, where guests don't have to log in. Hand a client, a freelancer, or a non-technical coworker a link and they're testing in minutes. No account, no paid seat, no "can you re-send the spreadsheet". This is the most common reason teams switch, and it's where per-user licensing gets expensive: TestRail has no guest or viewer seats, so everyone who records a result needs a license, and its cloud billing now charges for the month's peak user count. A two-week UAT burst costs a full month of seats. Some teams cope by buying a few licenses and sharing logins, which gives up the per-person test history they're paying for.

Write-as-you-think speed. No form per case. Type a prompt, hit enter, type the next. One customer described it as "just like writing… feels like you're writing a document".

Less library to maintain. The most consistent complaint from long-term TestRail users is upkeep rather than quality: as one 2026 review put it, "maintaining a large test library can feel a bit manual - bulk updates, reorganizing sections, or refactoring lots of cases takes time". An outline is lighter to keep current: drag lines where they go, prune what you no longer run.

Reports anyone can read. TestRail's dashboards live behind a login. A Testpad report is a link you can send to a client or a manager, or a printout you leave on a desk: nobody needs an account to see how testing went.

Cost that matches what you use. The typical leaving-TestRail story is a team noticing they pay for a feature set they barely touch. In one reviewer's words: "it's becoming too expensive, especially since we don't take advantage of most of its features". If your testing is checklists, runs and reports, Testpad does all of it, and you're not paying for the parts you'd never open.

One tool across all your testing. UAT, regression, exploratory, ad-hoc. The same outline flexes to all of them, and your CI/CD can inject automated results through the API, so automated and manual tests sit side by side in the same report.

When is TestRail the better choice?

When your QA is heavyweight and formal: regulated sign-off, deep requirement-to-defect traceability, audit history of who changed what, granular per-user permissions, and a large QA organization that lives in the tool full-time. TestRail is also a platform in a way Testpad isn't: two-way Jira integration with test coverage visible inside Jira, plus connectors for automation frameworks and CI/CD pipelines. If your testing needs to plug into that ecosystem, TestRail is built for it. TestRail's own users praise exactly these things: structure that holds up at scale, progress that's "visible at a glance" to management, and the ability to see who tested each case. If neither tool is quite the shape you need, our guide to the best test management tools covers the wider field.

When is Testpad the better choice?

When you want to spend your time testing rather than maintaining a case database: you run UAT with outside testers, do regression and exploratory work, test hardware, or you're escaping either a spreadsheet or a heavy tool you bought and never used. Teams of that shape get testing in minutes and keep the plan light enough to stay current.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for TestRail?

For most manual testing, yes: UAT, regression, exploratory, hardware, checking AI output. For heavyweight formal QA that depends on audit trails, granular access control, and deep traceability, TestRail does things Testpad doesn't do today.

What's the actual difference in the data model?

TestRail stores each test as a structured case (preconditions, steps, expected result) in a database you design and maintain. Testpad stores a test plan as a nested outline of plain text prompts, with a column added per test run.

Can I migrate my test cases from TestRail to Testpad?

Yes. Export from TestRail to a spreadsheet, then paste or import into Testpad. Case titles become prompts; steps become indented lines underneath. Most teams take the move as a chance to prune the cases nobody runs any more.

Can non-technical people test in Testpad?

Yes. Share a link and a guest tests with no login, no seat, and very little training. This is the most common reason teams switch.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free. TestRail licenses every user: Professional is $35/user/month billed annually ($420/user/year) or $37/user/month month-to-month; Enterprise is $852/user/year, billed annually only. If most of your testers are part-time or external, that's where the difference shows.

Does Testpad integrate with Jira?

Lightly. Set your tracker's URL pattern once and every issue ID you type in Testpad (test results, descriptions, comments) becomes a clickable link straight to the issue in Jira, GitHub, Trello or similar. There's also a REST API for pushing automated results from CI/CD. Outbound webhooks notify your other tools when runs finish or results change, directly or through Zapier and the like. There's no two-way sync and no coverage view inside Jira; if your workflow depends on those, TestRail does them.

Does Testpad have an audit trail or per-user permissions?

Not today. If your process requires those, TestRail has them; check before you migrate anything.

See the difference in five minutes

What is a test plan in testing, and how does it differ from a test case?

Stefan Butlin — Tue, 26 May 2026 00:00:00 +0000

A test plan is the shopping list and a test case is each item on it. The plan sets out everything you intend to test in a release; a test case is one individual check within that plan. Here's what each one is, how the two fit together, and how much detail each needs.

At a glance

A test plan captures everything you intend to test in a release: the scope, the approach, who's testing, and how you'll know when you're done
A test case is a single instruction inside that plan, one thing to check
The plan is the container and the test cases are the content: one sets the scope, the other fills it
A test strategy sits above both, covering how your team approaches testing overall
Test cases need as little detail as possible while still being useful; the most common mistake is cramming several scenarios into one

The rest of this post covers what each term means, how they fit together, where a test strategy fits, and how much detail your test cases need.

The two terms trip up a lot of teams, and the confusion is understandable: plenty of testing guides use them loosely, and some tools blur the line between them entirely. The definitions are the easy part, though. The difference matters more than the labels, and Test plans, not test cases makes the argument in full.

What is a test plan in testing?

A test plan is the bigger picture. It captures everything you intend to test in a given release – the scope, the approach, who's testing, which environments, and how you'll know when you're done. The ISTQB glossary defines it as "documentation that describes test objectives, means and schedule for achieving test coordination", which is the formal way of saying the same thing.

Think of it as the container. It organizes your test cases by feature or area and gives your team a shared view of what needs to happen before a release goes out.

In Testpad, a script is your test plan. It's a structured checklist that organizes everything you want to cover, broken into folders and sub-folders by feature or area. You run tests against it, mark results as you go, and share progress with stakeholders via a report link, all without a separate reporting tool.

What is a test case?

A test case is a single instruction inside that plan. One thing to check.

Formally, a test case includes a title, steps to execute, expected outcomes, and sometimes metadata like priority or environment. The ISTQB glossary goes further still: "a set of preconditions, inputs, actions (where applicable), expected results and postconditions". In practice, for most teams, a test case can be much simpler – a short prompt that points a tester at what to investigate.

That's how Testpad approaches it. Rather than formal test cases with multiple required fields, Testpad uses test prompts: short, outcome-focused instructions that tell testers what to check without prescribing every step. They're faster to write, easier to maintain, and leave room for testers to use their judgment rather than just following instructions to the letter.

For more on writing effective test cases, see our guide on how to write a test case – and test case design for the techniques behind choosing which cases to write.

How do test plans and test cases fit together?

The difference between a test plan and a test case is essentially one of scope. Test cases sit inside a test plan. The plan is the structure; the test cases are the content. A test plan without test cases is just a container. Test cases without a plan are a list with no context. When comparing test plan vs test case, this is the key thing to understand: one sets the scope, the other fills it.

	Test plan	Test case
Level	High: the full scope of a release	Low: one thing to check
Contains	Test cases organized by area	What to check and what a pass looks like
In Testpad	A script	A test prompt (one line of plain text)
Relationship	The container	The content

In Testpad, you get both in the same place: the script is your test plan, and each prompt you add is a test case. Open a new script, add your first test prompt, and you've got both.

Where does a test strategy fit in?

A test strategy sits above both test plans and test cases. If test plans and test cases are the operational layer – what you're testing right now – a test strategy covers how your team approaches testing overall: what types of testing you do, how manual and automated work fits together, and where you focus limited testing time.

Most teams don't write a formal test strategy document. But every team that tests regularly has one, even if it's just a shared understanding of how things work. The strategy informs the plans, and the plans are made up of test cases.

It's also worth noting that some teams use "test plan" and "test strategy" interchangeably, which adds to the confusion. If you hear them used that way, just look at the level of detail involved: a test strategy is the bigger "how we test" picture, a test plan is the "what we're testing this sprint" detail (sprint planning in the agile development lifecycle is test planning in its most natural habitat – see our agile testing guide). For more on how test plans work in practice, see our test planning guide.

How much detail do test cases need?

Simple answer: as little as possible while still being useful.

A test case needs to be clear enough that the right person can act on it – that's the only real requirement. For most tests, a short description of what you're checking and what a passing result looks like is enough. Longer, more detailed test cases make sense in regulated environments or for complex multi-step processes, but for the majority of teams they create more maintenance work than they're worth.

That's how Testpad is built. Test cases in Testpad are called test prompts – short, outcome-focused instructions that sit inside a structured checklist (the script). Anyone on the team can pick them up and run through them: a developer, a product manager, a client doing UAT. No training, no complex tool to navigate.

What is the most common mistake teams make?

Cramming multiple distinct scenarios into a single test case happens all the time. Someone writes a test case called "test the checkout flow" and packs in 15 different things to check – guest checkout, failed payment, discount codes, empty cart. Those aren't steps in one test; they're separate tests that happen to be lumped together.

The fix is keeping each test case focused on one thing. If a test case is really covering five different scenarios, break them out into separate prompts – grouped together under the same area in your script, but each with its own result. Your plan gets cleaner, results become more meaningful, and maintenance is much easier over time.

Getting started with Testpad

Test plans and test cases are simpler than most guides make them sound. One is the map of what needs testing; the other is the individual checks that make it up. Keep both focused and as lean as the work allows, and testing becomes a lot easier to manage.

In Testpad, a script is your test plan and each line is a test prompt – Testpad's version of a test case. Open a new script, add the features and flows you want to cover, and you have both at once. Organize by area using folders, run tests, and track results all in one place.

Why not give Testpad a go with a trial? It's free for 30 days, and you won't need your card details to sign up.

What is test case design, and how do I do it?

Stefan Butlin — Tue, 26 May 2026 00:00:00 +0000

Test case design is the process of deciding which tests to write and how to structure them before you start executing. The five standard techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and use case testing. Together they help you cover the right ground without writing redundant tests.

At a glance

Test case design is the thinking before execution: deciding what to cover, how much detail each test needs, and how to generate tests systematically
The five standard techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and use case testing
Equivalence partitioning and boundary value analysis handle most everyday input testing between them
A test case needs as much detail as the person running it needs, and no more
If tests keep missing bugs, that's a coverage problem; if testing takes far longer than it should, that's a scope or depth problem

The rest of this post covers how design differs from strategy, each technique with examples, and how to judge the right level of detail.

Most teams spend a lot of time writing tests and not enough time thinking about which tests are worth writing. Done well, test case design means your tests stay lean, stay useful, and hold up as the product changes. Done badly, it means a growing backlog of detailed documentation that drifts further from reality with every release. Most testing problems trace back to design rather than execution, so the thinking upfront makes all the difference.

What's the difference between test case design and test strategy?

They sound similar but they operate at different levels. Test strategy is the big picture: what types of testing will you do, who does it, when, and what's in scope. Test case design is the micro level: how do you structure and generate individual tests for a specific feature or input?

Strategy answers "how are we approaching testing for this release?" Design answers "how do I write a good test for this specific thing?" (And the test plan is where the two meet on paper.)

What does test case design involve?

Three decisions, mostly. Most teams are making all of them already, just not always deliberately. The difference between test design that works and test design that creates busywork is about being intentional with scope, detail, and how you generate your tests in the first place.

Scope – what to test at all. Which features, edge cases, and risk areas are worth covering, and which aren't worth the time.
Depth – how much detail each test needs. A short prompt is often enough. A formal test case with steps and expected results is sometimes necessary.
Technique – how you generate the tests themselves. There are established methods for deriving good test cases systematically, rather than guessing.

Most teams handle scope and depth through experience. Technique is where a lot of time gets saved – if you know the options.

What are the standard test case design techniques?

The five standard test case design techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and use case testing.

If you've ever sat down to write tests and found yourself either writing far too many or worrying you've missed something important, that's a design problem. The good news is there are established techniques for solving it.

Four of the five are the black-box techniques taught in the ISTQB Foundation Level syllabus; use case testing completes the classic set (recent syllabus editions moved it to the Advanced level, but it remains the most natural starting point for many teams). Not every team needs all five – understanding them means you can choose deliberately rather than guess. Each one works from what your software is supposed to do, not how it's built, so you don't need to be a developer to apply them.

Technique	What it tests	Best for
Equivalence partitioning	Groups of inputs that behave the same	Reducing test count without losing coverage
Boundary value analysis	Values at the edges of allowed ranges	Finding off-by-one and range bugs
Decision table testing	Combinations of conditions	Branching logic, permission rules, pricing
State transition testing	Moves between system states	Login flows, sessions, workflows
Use case testing	Real user journeys through the product	General coverage and a starting point for new teams

Equivalence Partitioning – can you cut down the number of tests without losing coverage?

If one value in a range behaves the same as another, you only need to test one of them. Split your inputs into groups where the software should behave identically – called partitions – then test one representative value from each.

A form field accepting ages 18–65 doesn't need you to test every number. Test one below 18, one in range, and one above 65. Three tests, not fifty.

It's one of the most effective ways to keep test case count under control without leaving gaps – and it's the technique most teams find useful immediately.

Boundary Value Analysis – where do bugs tend to hide?

Bugs hide at the edges. A field accepting values 1–100 is more likely to break at 0, 1, 100, or 101 than at 47. Boundary value analysis focuses effort on those exact points – the minimum, the maximum, and the values just either side of them.

Used alongside equivalence partitioning, you cover both the valid ranges and the specific values most likely to cause problems. The two techniques complement each other naturally, and between them, they handle most of what everyday testing requires.

Decision Table Testing – what happens when conditions combine?

Take a simple login rule: a user can log in if they have a valid email and a correct password. What happens if the email is valid but the password is wrong? What if both are wrong? What if the account is locked? Each combination produces a different outcome – and testing only the "happy path" leaves the others unchecked.

Decision tables map those combinations out before you start writing tests. Each column is a different scenario, and each row is a condition or outcome. You end up with a clear picture of what your logic should do in every case and a set of tests to verify it actually does. There's solid research behind focusing on combinations: NIST's combinatorial testing project found that most software failures are triggered by one or two parameters interacting, with progressively fewer involving three or more.

This is worth the upfront thinking for anything with branching rules like login flows, pricing tiers, permission levels – but it's overkill for simple features.

State Transition Testing – how does your software move between states?

Some systems behave differently depending on what's happened before. A user who's never logged in sees something different from one who's logged in, whose session has timed out, or whose account has been locked. These are distinct "states" – and the transitions between them (logging in, timing out, getting locked out) are exactly where bugs tend to hide.

State transition testing maps those states, the triggers that move between them, and designs tests around each transition.

Use Case Testing – what does a real user actually do?

This is the most natural starting point for most teams. Map the main routes a user takes through your product, then design tests around them. Use case testing keeps your design grounded in how the software will be used – which is where most real bugs get found.

If you're new to structured test design, start here. It's the easiest to apply and the most immediately useful.

How do you decide how much detail a test case needs?

As much as the person running it needs, and no more.

Formal test cases with preconditions, steps, and expected results are worth the investment when:

Testing is being handed to someone unfamiliar with the product
Traceability back to requirements matters
You're working in a regulated or process-heavy environment

Shorter test prompts work well when:

Your team already knows the product
Testing is exploratory in nature
Speed of execution matters more than documentation

This trade-off is the agile-vs-waterfall question in miniature – agile testing vs traditional testing goes deeper on when each style earns its keep.

The trap is over-designing. Detailed test cases for low-risk functionality take time to write and time to maintain – and if nobody uses them as written, they're not serving anyone.

A useful check: would a new team member understand this test and execute it correctly? If yes, it's probably at the right level. If it takes a paragraph to explain a single step, you've gone too far.

How do you know if your test design is working?

A well-designed set of tests:

Covers the high-risk areas without duplicating effort
Can be executed in the time you actually have
Can be picked up by anyone on the team
Can be updated when the product changes

If tests are regularly missing bugs, that's a coverage problem. If testing takes far longer than it should, that's a scope or depth problem. Reviewing what slipped through after each release (and adjusting accordingly) is one of the most useful habits a team can build. Test design is never really finished – it just gets better every time you ship something and ask what you missed.

How does Testpad support good test case design?

Not every test needs the same level of detail. Some areas need step-by-step instructions whereas others just need a short prompt pointing a tester in the right direction. Testpad handles both in the same script, so you're not forced to pick one approach for everything.

Our Scripts > Folders > Sub-Folders structure lets you organize by feature, risk level, or user journey, and you can mix detailed test cases and lightweight prompts within the same script depending on what each area actually needs. The goal is tests that get used, and Testpad is built around that rather than around documentation for its own sake.

For a broader look at how individual test cases fit in, see test cases vs checklists and how to write a test plan.

Ready to start applying these techniques? Try Testpad free.

Agile testing vs traditional testing

Stefan Butlin — Tue, 12 May 2026 00:00:00 +0000

The core difference between agile testing and traditional testing is timing. Agile testing happens as you build, inside each sprint; traditional testing happens after development finishes, as a separate phase. But agile testing is more than earlier timing: it's continuous, collaborative, and quick to adapt to what you learn, where traditional testing follows a plan fixed up front.

At a glance

Timing: agile tests features as they're built; traditional testing starts after development completes
Mindset: agile treats testing as continuous learning that adapts as you go; traditional verifies against a plan fixed up front
Teams: agile testers work alongside developers; traditional keeps a separate testing phase or team
Documentation: agile runs on lightweight test prompts; traditional on formal test cases
Bug cost: defects cost more to fix the later they're found, sometimes hundreds of times more
Best fit: most software teams lean agile; regulated industries often need traditional's paper trail

Most teams don't follow one approach religiously. They pick and choose based on the project: a startup might test as it builds to move fast, while a medical device company might need traditional testing's documentation trail for regulatory approval. The rest of this post walks through the differences and trade-offs so you can decide what fits. (For agile testing on its own terms, see our agile testing guide.)

What are the key differences between agile testing and traditional testing methodologies?

The fundamental difference is when testing happens and how teams work together.

Think of traditional testing like building a house. You finish all the framing, plumbing, and electrical work, then call in the inspector. If something's wrong, you're ripping out walls. Agile testing is more like having the inspector walk the site every day, catching problems while the wall studs are still exposed.

Agile testing happens continuously throughout development. Testers work alongside developers in short cycles (often called sprints), testing features as soon as they're built. When something breaks, the team fixes it immediately rather than filing it away for later.

Traditional testing separates building from testing into distinct phases. Developers finish everything first, then hand it over to testers who work through a detailed test plan. Bugs found during testing often mean going back to fix things that were "done" weeks ago. This approach is common in waterfall projects, where each phase finishes before the next one starts.

Here's how they differ in practice:

Aspect	Agile testing	Traditional testing
Timing	Continuous throughout development	After development completes
Team structure	Testers work with developers	Separate testing team or phase
Documentation	Lightweight test prompts	Detailed test cases with formal steps
Test planning	Evolves sprint by sprint	Comprehensive upfront plan
Bug fixing	Fixed the same day or week	Logged for later fix cycles
Requirements	Can change between sprints	Fixed at project start

The actual testing – checking if software works – stays the same. What changes is the paperwork, the timing, and how quickly problems get fixed.

What are the benefits of agile testing over traditional testing?

Testing as you build catches problems while developers still remember writing the code. When a tester finds a bug the same day it was created, the developer can fix it immediately while they're still in that headspace. Find that same bug three weeks later, and the developer has to dig through old code trying to remember what they were thinking.

The compound effect matters more than individual catches. When testers check features within hours, developers learn patterns faster. They see what breaks and adjust their approach. After a few sprints, the team writes cleaner code because feedback happened quickly enough to build better habits.

Key advantages:

Faster releases – Testing doesn't hold up launches because it happens throughout, not after
Cheaper bug fixes – NIST's study of the economics of software testing found that the cost of fixing a defect rises steeply through the lifecycle, from trivial at the requirements stage to hundreds of times more once software is in operation
Better collaboration – Testers and developers communicate naturally rather than through formal bug reports
Realistic progress tracking – Stakeholders see working features week by week rather than waiting months for a "testable" version

Testing throughout development requires discipline, though. If testing always gets pushed to Friday afternoon, you're doing mini-waterfall with better branding.

What are the core differences between agile and waterfall testing?

Waterfall is the project management methodology most associated with traditional testing. In a waterfall project, work flows in one direction – you plan, design, build, then test, in that strict order. (For how testing fits into the agile equivalent, see the agile software development lifecycle.) It's where traditional testing gets its reputation for being a separate phase that happens at the end.

Waterfall assumes you can define everything upfront – requirements, design, implementation plan, test cases – before building anything. Testing checks that what got built matches the original plan.

Agile assumes requirements will shift as you learn what users actually need. Testing checks each piece works while staying flexible about what "works" means as understanding evolves.

Waterfall testing focuses on:

Detailed documentation so nothing gets missed
Formal test cases for repeatable checks
Clear pass/fail based on original requirements
Paper trail from requirements through results

Agile testing focuses on:

Quick feedback to enable course corrections
Lightweight test prompts that don't need constant updating
Testing both expected behavior and surprises discovered along the way
Working software that demonstrates quality

Neither is universally better. Regulated industries need waterfall's paper trail for compliance. Consumer software benefits from agile's ability to pivot based on user feedback.

Most teams land somewhere between extremes. Formal test cases for critical stuff (payment processing, security features – where test case design techniques earn their keep) and exploratory testing for everything else. Or detailed tests for complex integrations but lightweight testing for routine features.

Choose consciously based on actual constraints – regulations, team experience, project complexity – rather than defaulting to whatever's fashionable.

What are the challenges of moving from traditional to agile testing?

The biggest hurdle is accepting less upfront certainty. Traditional testing promises a detailed test plan before anything starts. Agile testing (iterative because you repeat cycles of building and testing) means planning just enough for the next sprint and trusting your team to figure out the rest as they go.

Testers used to detailed test cases struggle with shorter test prompts. Instead of "Step 1: Click login button. Step 2: Enter username. Step 3..." you get "verify password complexity rules" or "test expired sessions." This requires testers to think for themselves rather than follow a rigid step-by-step test case.

Teams also need to rethink how they track progress. Traditional test case management tools feel clunky for agile work. Many teams switch to simpler approaches – checklists in tools like Testpad, or just lists in their project management system. Track what needs testing and what's been checked without drowning in documentation.

Common friction points:

Release gates disappear – No "testing phase" where you catch everything. Testing happens continuously, which means living with some uncertainty.
Incomplete features – You're testing half-built functionality, which needs judgment about what's ready versus what's still being worked on.
Regression testing gets messy – Regression testing means re-checking things that worked before to make sure new changes didn't break them. Without formal test cases, teams worry they'll miss something. This is where simple checklists or lightweight test management becomes essential.
Stakeholder confusion – Clients or managers expecting comprehensive test reports need help understanding how continuous testing provides the same confidence.

Start where you are and gradually reduce documentation rather than torching everything overnight.

How do agile and traditional testing work with test management tools?

Test management tools help teams organize their testing – what needs checking, who's doing it, what passed, what failed. But agile and traditional testing need different things from these tools.

On the automated side, agile teams lean on test frameworks (pytest, Jest, JUnit) that run when code gets committed, giving developers feedback within their existing routine. On the manual side, they want lightweight test management that keeps up sprint to sprint. Either way, testing becomes part of the development process rather than a separate activity.

Traditional test management tools (OpenText ALM, formerly HP Quality Center; older TestRail versions) were built for different workflows. They're great at organizing formal test cases and tracking them across releases but weren't designed to run automatically. Connecting them to automated pipelines usually needs custom integration code to bridge the gap.

Think of it like email versus postal mail. Agile testing tools work like email – integrated into your communication flow, instant feedback. Traditional testing tools work like postal mail – fine for what they do, but require deliberate trips to check and sort through different systems.

The practical difference shows up daily. With agile tools, a developer pushes code, automated tests run, and testers get notified that the latest build is ready. They test it, find something, and the developer fixes it that afternoon – all in one system (GitHub, GitLab, similar).

With traditional tools, everything fragments. Automated tests run in one place, manual testing happens in a test management system, bugs go in yet another tool (Jira, Bugzilla). Results need manual stitching together for reports, which creates delays.

Modern agile-friendly approaches:

Tools that talk to each other – Results flow into project management automatically without manual copying
Early testing – Tests run on developers' machines before code even gets committed
Multiple environments at once – Run tests in parallel so nothing bottlenecks
Visible progress – Testing status anyone can check whenever they look, rather than waiting for scheduled reports

The key is treating testing as part of the code rather than a separate activity. Automated tests live in version control with application code. When requirements change, tests update in the same commit. Only works when tools support it.

Why does agile testing pair better with continuous integration?

Continuous integration (CI) is the practice of merging code changes frequently – at least daily, often several times a day – with each merge verified by an automated build and tests. Think of it as a quality checkpoint that runs every time someone adds code, catching problems immediately rather than discovering them weeks later.

Agile testing and CI are natural partners because both focus on quick feedback. When developers commit code several times a day, automated tests run immediately to catch problems before they snowball. Bugs get fixed within hours, not weeks. Google's DORA research finds the same pattern: running tests continuously as part of the pipeline gives developers quick feedback, shortens the lead time from check-in to release, and lowers the error rate in production.

Traditional testing doesn't mesh as smoothly with CI. When testing happens in a separate phase after development, there's less point in running tests on every code commit – you're not actually testing yet, just making sure developers haven't accidentally broken something.

In agile environments, testing and coding blur together. A developer might write code in the morning, a tester verifies it that afternoon, and any problems get fixed before lunch the next day. CI tools like Jenkins or GitHub Actions run automated checks on each commit, while manual testing happens at the same time on the latest build.

A typical agile CI pipeline includes:

Unit tests (small automated checks that developers run on individual pieces of code) that run on their own machines before committing
Integration tests (checks that different parts work together) that run on every commit
Manual exploratory testing on the latest stable build
Quick regression checks before each sprint ends

Traditional approaches batch testing into longer cycles. Instead of testing every commit, teams might test weekly builds or wait until features are completely done. Fewer test runs, but longer gaps between creating a bug and finding it – which makes bugs more expensive to fix.

How do you keep test coverage when switching to agile testing?

The fear is that shorter cycles mean less thorough testing. Reality often flips that – testing as you build finds more bugs because testers engage with features while they're fresh rather than coming back to them weeks later.

The trick is replacing detailed test cases with smarter organization. Instead of documenting every scenario upfront, maintain a test backlog that grows as you learn. Each sprint adds test ideas based on what broke, what users struggled with, or what integrations proved fragile.

Practical strategies:

Start with test charters for each feature. A test charter is just a brief guide for what to test. Write something like "verify authentication handles expired tokens, rate limiting, and concurrent sessions." Testers explore these areas without step-by-step instructions, drawing on their expertise while making sure the important scenarios get checked.

Track at the feature level, not test case level. Use a checklist where each feature has test prompts. Tools like Testpad make this manageable – see what's been tested at a glance without maintaining formal documentation. Add prompts as features get built, mark them done as testing completes. New to agile testing? See our guide on how to get started with agile testing.

Build regression testing gradually. Each significant bug becomes a regression check. Over time this creates a living document of things that have broken before. This organic approach usually beats trying to document everything upfront.

Use risk-based testing. Payment processing and authentication need thorough testing every sprint, whereas minor UI tweaks might just need a quick check. Agile works when teams consciously allocate effort based on risk rather than testing everything equally.

Pair testers with developers. When testers work alongside developers during features, they catch issues before code commits. Testing earlier in the process prevents bugs rather than just finding them, improving quality while reducing testing burden.

The transition often reveals that traditional test cases documented things that never broke. Teams maintained hundreds of test cases but ran the same critical 20% repeatedly. Agile testing makes this prioritization explicit rather than hidden in which tests actually get run.

Manage your testing without a truckload of documentation

Testpad makes agile testing manageable by organizing tests as simple checklists with just enough structure. Whether you're doing exploratory testing or structured regression checks, you get clear progress tracking without rigid test case frameworks.

See how Testpad helps teams test smarter with lightweight test management – start your free trial.

Agile testing: the complete guide

Stefan Butlin — Tue, 12 May 2026 00:00:00 +0000

Agile testing is testing that keeps pace with development: continuous, collaborative, and quick to adapt to what you learn. The term carries two valid meanings – testing within a formal Agile framework like Scrum, and simply testing with agility – and this guide covers both, from methods and lifecycle to tools and common challenges.

Agile testing is one of the most misunderstood terms in software development. For some, it means following Scrum ceremonies and writing acceptance criteria. For others, it simply means testing with speed and flexibility. Both interpretations are right – what matters is understanding which approach fits your team and why.

Key takeaways

Agile testing has two valid definitions: testing inside formal Agile frameworks (Scrum, Kanban, XP), and testing with agility – a lightweight, adaptive way of working.
Both share one philosophy: testing is how you learn what your product actually does, fast enough to act on it.
Test early and often, keep tests maintainable, prioritize by risk, and let plans change.
Heavy tooling works against agile testing – pick tools the whole team can use.

What is agile testing?

There are two interpretations of agile testing, and both are correct. The term has evolved to mean different things to different people.

Formal Agile testing (capital 'A')

When most people search for "agile testing," they encounter the formal definition: testing within established Agile software development methodologies like Scrum, Kanban, or Extreme Programming (XP). This approach includes:

Sprint-based testing cycles that align with development iterations
Defined roles and ceremonies like daily standups and sprint retrospectives
Specific methodologies such as Test-Driven Development (TDD) and Behavior-Driven Development (BDD)
Agile testing quadrants that categorize different types of testing
Acceptance criteria and "definition of done" frameworks

This formal approach has real value, especially for teams already working within Agile development frameworks. It offers structure, common terminology, and proven practices that many successful teams have adopted.

Testing with agility (the literal interpretation)

But there's another way to think about agile testing and that's literally. Testing with agility means:

Adapting quickly to what you discover during testing
Not being weighed down by heavy processes or rigid documentation
Tweaking your strategy based on what you learn about the product
Being reactive to the issues and opportunities you encounter

In short, it's about staying curious, adjusting on the fly, and learning as much as possible from every test run. It's less about following a specific methodology and more about maintaining a mindset that prioritizes learning and adaptation.

What does testing with agility look like in practice?

Imagine you're testing a new feature and discover that a particular module seems unusually problematic. With an agile approach, you can:

Dig deeper immediately rather than sticking to a predetermined script
Explore the issue thoroughly to understand its scope and impact
Adjust your testing focus to spend more time on high-risk areas
Communicate findings quickly to help stakeholders make informed decisions

This reactive, exploratory approach often uncovers issues that rigid test case execution might miss. It's a faster way to learn what's really going on, especially when supported by the right tools and mindset.

The rest of this guide covers both interpretations. Whether you're following Scrum sprints or just testing with speed and flexibility, the core principles, benefits, and challenges remain surprisingly similar. We'll call out where the approaches differ, but mostly, what works for one works for the other.

What's the core philosophy behind agile testing?

The idea that testing is ultimately about learning – not just checking – is true across most types of software testing. But in agile testing, this mindset becomes central. Whether you follow a formal Agile methodology or simply work with agility, testing is how you learn what the product actually does, so your team can make better decisions, faster.

It's the same trade the Agile Manifesto makes – working software over comprehensive documentation – applied to testing: time spent learning about the product beats time spent maintaining paperwork about the product.

This shifts testing from being a final quality gate to an ongoing process of discovery. It's not just about verifying requirements, it's about exploring how the product behaves, where it might fall short, and what users actually need.

Testing becomes collaborative. It's how teams uncover risk early, share knowledge quickly, and adapt with confidence. The goal isn't just to pass or fail tests – it's to understand the product deeply, so the whole team can move forward in the right direction.

How does agile testing fit in your QA strategy?

Agile QA testing doesn't work in isolation – it's just one part of how you test overall. A solid testing approach mixes exploratory testing, regression checks, unit tests, integration testing, and acceptance testing. Agile methods support all of these through speed, teamwork, and constant feedback.

The trick isn't getting everything perfect from the start – it's learning quickly enough to fix things while you still can. Testing becomes a team effort, catching problems early and helping everyone stay informed and adaptable. For more on this, see our guide on test strategy.

What are the main agile testing methods?

There are lots of ways to test in agile environments. Teams often blend or adapt these depending on what works best for them. They split roughly down the same line as the two definitions: methods that belong to formal Agile frameworks, and methods that simply embody agility.

Formal Agile methods

Test-Driven Development (TDD) – Write the test first, then the code. It's a red–green–refactor loop that helps keep development tight and focused. TDD is common in frameworks like Scrum or Extreme Programming.

Acceptance Test-Driven Development (ATDD) – Work with stakeholders to agree on what "done" really means before writing a single line of code. It's about building the right thing from the start – often baked into sprint planning or Agile rituals.

Behavior-Driven Development (BDD) – Start with examples of how the software should behave from a user's point of view, then build tests around those. It's a handy bridge between business goals and what developers actually build.

Formal Agile teams also lean on the agile testing quadrants – a model for categorizing tests by whether they guide development or critique the product, popularized by Lisa Crispin and Janet Gregory's book Agile Testing.

Methods for testing with agility

Exploratory testing – Skip the script. You test by exploring – following your instincts, poking at what looks risky, and adapting on the fly. It's fast, flexible, and often uncovers the bugs that rigid test cases miss.

Session-based testing – Take the freedom of exploratory testing and add a bit of structure. You set a timebox, give the session a clear goal, and write up what you found. It's a lightweight way to stay focused without locking things down.

How the methods compare

Method	Camp	What it is	Reach for it when
TDD	Formal Agile	Write the test, then the code that passes it	Developers want tight, focused code with built-in checks
ATDD	Formal Agile	Agree acceptance tests with stakeholders before building	"Done" keeps meaning different things to different people
BDD	Formal Agile	Tests built from examples of user-visible behavior	Business and developers need a shared language
Exploratory testing	Testing with agility	Unscripted investigation guided by what you find	You need to learn fast or hunt down the unexpected
Session-based testing	Testing with agility	Timeboxed exploratory sessions with a goal and a write-up	You want exploration plus a record of what was covered

The key difference is that formal methods give structure to teams working within Agile frameworks, while agile approaches emphasize speed and adaptability when finding unexpected issues.

What does the agile testing lifecycle look like?

Agile development and testing happen in short iterations or sprints, typically one to four weeks long. Each iteration includes planning, development, testing, and review. Testing happens throughout, often starting before code is even written, rather than being saved for the end.

Whether you're following formal Agile methodology or simply testing with agility, the process tends to follow a similar pattern within each cycle:

1. Planning and preparation

Understand user stories and requirements
Identify testing objectives and scope
Set up testing environments
Plan your testing based on what's most effective – manual, automated, or a mix

2. Continuous testing

Test new features as they're developed
Explore the product to uncover issues that scripted tests might not catch
Run regression tests to ensure existing functionality remains intact
Conduct integration testing as components are combined

3. Feedback and adaptation

Provide rapid feedback to developers and stakeholders
Adapt your testing approach as you learn, like what you test and how often
Prioritize testing efforts based on risk and impact
Collaborate with the development team to resolve issues quickly

4. Release preparation

Conduct final acceptance testing
Verify that the software meets business requirements
Ensure all critical issues have been addressed
Prepare for deployment and monitoring

This rhythm means faster feedback, less rework, better collaboration, and clearer priorities. It also requires testing to be more collaborative and less siloed than traditional approaches – everyone shares responsibility for quality.

Why does agile testing work?

Whether you follow formal Agile frameworks or just test with flexibility, the benefits are the same:

Faster feedback – find problems sooner and fix them before they turn into bigger issues
Better quality – when testing happens early and often, fewer bugs slip through
Stronger collaboration – developers, product managers, and testers work closer together
Lower risk – frequent checks mean fewer nasty surprises later on

How do you make agile testing work in practice?

The agile software testing process comes down to a few core principles:

Test early and often – don't wait until the end of a sprint to start checking things
Keep tests maintainable – use lightweight prompts instead of detailed cases that need constant updating
Prioritize ruthlessly – focus effort on the highest-risk areas first
Communicate findings immediately – don't file bugs away, surface them right away
Automate what makes sense – free up manual testing time for the things automation can't catch
Embrace change – when requirements shift, your tests should too

There's a people side to this too. Testing isn't just for QA teams: developers test their own work, PMs poke at new features, and even stakeholders or customers can get stuck in. More eyes means better coverage – and a team that shares responsibility for quality instead of throwing builds over a wall.

And expect plans to move. Priorities shift, features evolve, bugs pop up. Your test plans should be able to flex and refocus without grinding everything to a halt.

You need to stay organized enough to track what's been tested without spending more time managing tests than executing them.

What are the common agile testing challenges?

Teams often hit the same obstacles. Here's how to deal with them:

Everything keeps changing

That's normal – it's what agile development does. Build test plans that can change too. Keep comms open, adjust as you go, and treat a reshuffled plan as the process working, not failing.

There's never enough time

You won't test it all, so test what matters and tackle risky stuff first. A sprint's worth of focused testing on the areas that could break badly beats thin coverage of everything.

Small team, big job

Pick a testing tool that anyone on the team can use – not just testers. Keep it simple and get everyone involved; the developers and PMs around you are testing capacity hiding in plain sight.

Tools that slow you down

Heavy test management tools can have many features you don't use, and demand documentation you don't need. Pick something that works how you work and not the other way around.

The key is spotting these challenges early and adjusting before they become serious problems. Agile testing requires different thinking than traditional approaches, and that takes practice.

What tools support agile testing?

You can test in agile ways with spreadsheets forever if they work for you. But when coordination gets messy or tracking becomes a pain, certain tools can help. The right tools support fast iteration, enable collaboration, provide visibility, stay lightweight, and scale reasonably.

Traditional test case management tools often work against agile principles by demanding detailed documentation upfront. Lightweight alternatives let teams track coverage, progress, and results without the paperwork overhead.

That's the approach Testpad takes: checklists you build as you go, room to jot down new test ideas mid-session, and results that capture what you found rather than just pass/fail. Plans flex without breaking, nobody needs training to pitch in, and when something looks weird you go explore it – then turn what you discover into future test ideas.

Agile testing FAQs

Is agile testing manual or automated?

Both, and the blend matters. Automation earns its keep on the repetitive checks – regression suites, builds, the things you verify the same way every time. Manual testing supplies what automation can't: exploration, judgment, and the ability to chase something that looks off the moment you spot it. An agile team that's all automation misses the unexpected bugs; one that's all manual drowns in repetitive checks. Most teams automate the stable, deterministic stuff and keep humans on everything new or risky.

What's the difference between agile testing and waterfall testing?

Timing. Waterfall saves testing for a dedicated phase after development finishes, so bugs are found late, when they're most expensive to fix. Agile testing runs continuously alongside development, so problems surface while the code is still fresh and cheap to change. The trade-off: waterfall produces a thorough documentation trail, agile produces faster feedback. Our agile vs traditional testing comparison covers when each fits.

Who does the testing on an agile team?

Everyone, to some degree. A tester or QA lead might steer the effort, but developers test their own work, product managers poke at new features, and stakeholders or customers join in for acceptance testing. That's not corner-cutting – shared testing is one of the practices that makes agile teams fast, because feedback doesn't queue behind a single bottleneck.

Want to go deeper into agile testing?

Here are some useful next steps:

Agile testing vs traditional testing
How to get started with agile testing
Test case design – for the times formal test cases are the right call

Agile testing is about learning what your product actually does, fast enough to do something about it. Whether you follow formal Agile methodologies or simply test with agility, the principles remain the same: adapt quickly, collaborate constantly, and stay focused on what matters.

Good agile testing makes releasing software less stressful. Start simple, focus on what adds value, and remember – the goal is better software.

Looking for a simple test management tool that supports agile testing? Testpad offers a pragmatic approach – enough structure to stay organized, enough flexibility to move fast. Try Testpad free for 30 days and see if it fits your team's agile workflow.

How to write a test case

Stefan Butlin — Tue, 28 Apr 2026 00:00:00 +0000

A test case is an instruction for what to test, written clearly enough that the right person can act on it. Writing one can be as simple as a line of plain text – "verify password reset email sends correctly" is a perfectly good test case. Often, though, test cases are understood as something more formal: multiple lines structured into sections like title, steps, and expected outcomes.

At a glance

At minimum, a test case needs a clear title, any necessary context, and what "pass" looks like
Write for outcomes ("valid credentials log in successfully"), not click-by-click steps
Match detail to the tester: one line for someone who knows the product, fuller steps for a client doing UAT
Detailed formats make sense in regulated environments, client sign-off, and complex multi-step processes
In Testpad, a test is one line of plain text; indentation groups related tests into a hierarchy
Maintain as you go: review after each release, add a test for every bug fixed, delete what's stale

Most guides push formal formats with multiple required fields, elaborate metadata, and step-by-step instructions for every possible action. At Testpad, we think that level of detail creates more work than it saves for most teams; this guide covers what test cases need and what they don't.

What is a test case?

A test case is a single test instruction. One thing to check as part of testing your software.

That instruction might be a brief prompt – "check login with valid credentials" – or a more detailed set of steps with expected outcomes. Both are test cases. The format depends on who's testing, how well they know the product, and how much guidance they need.

Cem Kaner's classic paper What Is a Good Test Case? quotes the IEEE standard definition ("a set of test inputs, execution conditions, and expected results developed for a particular objective") and then makes the more useful point: test cases help us discover information. The format only matters as far as it serves that.

At Testpad, we use the term test prompts rather than test cases. The idea is the same – an instruction for what to test – but the emphasis is on keeping things outcome-focused rather than prescriptive. Instead of spelling out every step, a test prompt points testers at what to investigate and trusts them to use their judgment. It's a deliberately lighter approach, and it works well for teams doing regular release testing or exploratory work.

Read the Testpad guide on how to write effective test prompts.

What should a test case include?

At minimum, a test case needs to be clear enough that the right person can act on it.

In practice, most test cases benefit from three things:

A clear title – what is being tested, in plain language
Any necessary context – preconditions, environment, or user role if relevant
The expected outcome – what "pass" looks like

The more formal version also includes steps to execute, test data, priority, and metadata like affected components or linked requirements. In Testpad, you can add all of that when a test calls for it: use indentation to build groups of rows that define your test cases – a title row, some rows for each step, some rows for expected outcomes, and more if you need to give preconditions. For most tests, you won't need any of it. A short prompt with a clear outcome is enough to direct a tester's attention and record a meaningful result.

How detailed should a test case be?

As detailed as it needs to be, and no more. The instinct to add detail comes from a good place. More detail feels safer. But detailed test cases take longer to write, longer to read, and significantly longer to maintain. When your product changes, every overly specific step becomes something to update.

If your tester knows the product, keep test cases short. A one-line prompt is enough. If your tester is unfamiliar with the product – a new joiner, a client doing UAT, a guest tester – more detail helps them know what to do.

In Testpad, you adjust detail test by test within the same script. A test is one line of plain text; where one needs spelling out, indent a few rows beneath it for the steps and expected outcomes. Most lines stay brief.

How do you write test cases in practice?

Test case creation doesn't need a template or a formal process. Five steps cover it.

1. Get the ideas down first

Before worrying about format, get the ideas down. What are the most important things to check? Start with the main features and core user flows – login, key actions, anything that would be embarrassing to break.

In Testpad, this usually means opening a new script and typing out a rough list. A rough list that exists is more useful than a polished template waiting to be filled in.

2. Write for outcomes, not actions

The most common test case mistake is describing every click rather than the outcome you're checking.

Instead of: "Click the login button, enter username 'test@example.com', enter password '12345', click submit, verify you see the dashboard"

Write: "Valid credentials log in successfully"

The second version trusts the tester to know how to log in. It focuses on what matters – does it work? – and stays useful even if the UI changes. This is the thinking behind Testpad's test prompt approach: point testers at the outcome, let them figure out the path.

3. Pick the edge cases worth testing

Edge cases matter, but you don't need to test every conceivable one. Focus on edges that are reasonably likely to happen and would cause real problems if they failed – invalid inputs, empty states, boundary values, things that have broken before.

4. Group tests logically

Organize test cases by feature, user flow, or area of the product – whatever makes it easy to see what's covered and what isn't. In Testpad, indenting a line nests it under the one above, so related tests group under a heading, and folders and scripts handle the bigger divisions. You get a clear hierarchy without any extra configuration.

5. Review and trim

Once you have a draft list, read back through it. Are there duplicates? Tests so obvious they add no value? Steps that are really one test written twice? Cut them. A shorter list that gets used is more valuable than a long one that doesn't.

When do more detailed test cases make sense?

Testpad isn't against detailed test cases. Some situations call for them:

Regulated environments like healthcare and finance often require detailed test documentation for compliance. The FDA's General Principles of Software Validation, for instance, expects documented test plans and test cases covering inputs, procedures, and expected results
UAT with clients – when a client is signing off on a deliverable, a detailed test case gives them a clear path to follow
Complex multi-step processes that are hard to describe without step-by-step instructions

Outside of these situations, shorter is usually better. The goal is to find problems before users do.

What's the difference between a test case and a test prompt?

A traditional test case is a formal document with prescribed fields – title, preconditions, steps, expected outcomes, and metadata. It's built for completeness and traceability.

A test prompt is Testpad's lighter version: a specific instruction that points testers at what to investigate without prescribing every step. The tester brings judgment to how they check it – the stance James Bach and Michael Bolton take in Exploratory Testing 3.0, where testing means evaluating a product by learning about it through exploration and experimentation.

	Traditional test case	Testpad test prompt
Format	A form: preconditions, steps, expected results	One line of plain text
Detail	Every field filled in for every test	Added only where a test needs it
When the UI changes	Every affected step needs updating	Outcome-focused prompts mostly still apply
Best for	Compliance, client UAT sign-off, unfamiliar testers	Teams who know their product and release often

The practical difference is speed. Prompts are faster to write, easier to maintain, and leave more room for testers to find things a step-by-step approach would miss. For teams without a formal QA function – developers, product managers, or small teams sharing testing responsibilities – that difference matters.

How many test cases do you need?

Enough to cover the things that matter. There's no target number. A focused set of 30 test cases covering your critical paths is more valuable than 300 that include things nobody reads. Quality of coverage matters more than quantity.

Testpad's starting point: every important user journey, every area that's changed in the current release, and every bug that's been fixed and could plausibly come back.

How do you maintain test cases over time?

Test cases age. Features change, the UI changes, and test cases written six months ago start pointing at things that no longer exist.

A few habits that help:

Review after each release – flag anything that felt out of date during testing
Add as you go – when you find a bug, add a test for it before you forget
Delete without guilt – if a test case is no longer useful, remove it
Keep them short – the shorter the test case, the less there is to update

In Testpad, duplicating a script for a new release copies the tests but not the results. Your test library stays current without starting from scratch each time. See how Testpad handles retesting from build to build.

Write your first test cases in Testpad

In Testpad, a script is your test plan: a checklist of everything you want to cover in a release. You open one, write down the first few things you want to check, and go from there. Testpad works just as well with a short list as it does with a detailed, organized test plan – you add structure as you need it.

Try Testpad for free.

How to get started with agile testing in Testpad

Stefan Butlin — Mon, 27 Apr 2026 00:00:00 +0000

Test tools are often too rigid for agile, but Testpad gives you just enough structure to track what matters without restricting how you test or slowing down the sprint.

Agile testing is continuous – testing runs alongside development, sprint by sprint. If your team is already sold on the approach, this guide covers exactly how to get started with agile testing in Testpad: the practical setup, the sprint-by-sprint rhythm, and how to avoid the friction points that trip most teams up. (Still weighing it up? Start with the agile testing guide, or the comparison of agile vs traditional testing.)

Here's how to get started with agile testing in Testpad – it comes down to five things:

Create one project per product or team
Add a folder for each sprint and duplicate it at the start of every cycle
Build a separate regression script for the core functionality you retest every sprint
Use exploratory testing sessions to cover what scripted tests miss
Share the report link with your team – no logins needed

Each of these is covered in detail below – along with the common mistakes that trip agile teams up and how to avoid them.

How do you set up a sprint test plan in Testpad?

The cleanest approach is to create one project per product or team, then use a Folder per sprint to collect all the scripts you need for that sprint's testing.

Each sprint, duplicate the previous Folder. The tests copy across; the results don't. That gives you a clean starting point every time, without rewriting anything – and keeps a full history of what was tested and when in the folders behind it.

Name folders clearly – "Sprint 12" or "Sprint 12 – checkout flow" – so it's obvious what each one covers at a glance.

Inside the script, keep test prompts short and specific. How detailed you go is a matter of preference – some teams prefer broader areas to roam. But if you're new to this, specific prompts are a good starting point, such as:

Apply a valid discount code at checkout
Checkout with an expired card
Order confirmation email is triggered
Cart items persist after session timeout

These aren't rigid step-by-step instructions, but prompts – specific enough to keep testing focused, but open enough for the tester to explore and react to what they find. That's intentional, and is what makes Testpad work well for agile teams: you get structure without losing the ability to think on your feet.

How do you handle regression testing between sprints?

Regression is where agile testing gets messy for a lot of teams. The question is always: how much do we retest, and how often? In Testpad, the answer is a dedicated regression script (or a set of them, depending on the size of your product) – a separate, persistent checklist of the core functionality you re-verify every sprint. Simply put, a practical list of the things that have broken before, and the things that can't break.

Keep the regression script lean. Review it regularly (monthly or quarterly works for most teams) and cut tests where the risk has genuinely shrunk: functionality that hasn't changed, hasn't caused problems, and isn't likely to. What you want is a tight, fast-to-run set of checks that give the team real confidence before a release.

Each sprint, duplicate the regression script – or the folder containing your regression scripts – the same way you would for your sprint scripts. That resets the columns, gives you a clean run to work with, and means you can prune or adjust tests between sprints without touching the historical record of what happened last time.

How does exploratory testing fit into an agile sprint?

Scripted tests cover what you planned for, whereas exploratory testing covers what you didn't.

Exploratory testing doesn't have to wait until the end of a sprint. It can run throughout alongside development, on the latest additions to the product, or revisiting what was built last sprint. The question is less "when" and more "how."

If you want to bring exploratory testing into your sprints, Testpad works well with a charter-style approach: a loose script of areas to investigate, with time allocated per topic. Something like:

Checkout flow breaks with unexpected inputs
Checkout flow works with correct inputs

Results get logged as you go – pass, fail, or a note – and any bugs can be linked directly in Testpad. At the end of the session, you have a record of what was tested, even if the approach was freeform.

This is Testpad's sweet spot for agile teams: more structured than a blank page but less rigid than a formal test case.

Who should be doing the testing?

In agile, quality isn't just a testing problem. It comes from good design, clear specs, solid product decisions, good UX, and careful implementation. Testing is one part of that picture rather than a safety net at the end. In practice, the more perspectives involved, the better. Developers test differently to product managers, and clients use the product in ways neither would anticipate. Getting all of them involved just gets more useful eyes on the thing.

Testpad makes this easy. Guest testers can access a test run without needing an account or any training. That's particularly useful for user acceptance testing (UAT) at the end of a sprint, where a client or stakeholder needs to verify a feature before it ships.

A typical testing split might look like this:

Developers write automated unit tests for new work where feasible, extend automated system tests to cover new features, and manually verify anything that can't be automated
Testers or PMs run the sprint's scripts – a mix of manual regression, test prompts, and exploratory sessions
Clients or stakeholders, where involved in the sprint, run the UAT checklist or their own sanity checks before sign-off

Nobody needs to understand test case management to participate. They just need a link.

How do you track testing progress during a sprint?

Progress tracking in agile testing should answer one question quickly: are we ready to ship?

In Testpad, the report page gives you an up-to-date picture of where things stand – reload it at any point to see how many tests have passed, failed, or are still pending.

At the end of a sprint, Testpad's report gives the team a clear record of what was tested and what wasn't, which bugs were found, and whether any failed tests were resolved before release. You can share it as a link without the need for a Testpad account to view it. That's usually all a team needs for a sprint retrospective or a stakeholder update.

What about integrating with the tools your team already uses?

Yes. Testpad has lightweight integration with issue trackers like Jira and GitHub. When a test fails, you record the issue number against the result and it becomes a clickable link – so anyone reviewing the run can jump straight to the issue without switching tabs and hunting for it.

It's not a deep two-way sync. Testpad doesn't automatically create issues on test fails or pull status updates back from your tracker. But for most agile teams, that's exactly the right level of connection – your test results stay clean, and your issue tracker handles the rest.

A few things that trip up agile teams early on

The most common mistakes are easy to avoid:

Testing too late in the sprint. If testing only starts once development is "done," you've lost the agile benefit. Start testing features as soon as they're stable enough to poke at.
Writing test cases for everything. Detailed test cases take time to write and maintain. Short prompts are faster to create and good enough for most agile contexts.
Letting the regression suite grow unchecked. A regression script that takes three hours to run will get skipped. Keep it focused on what matters most.
Skipping exploratory testing. Scripted checks catch what you planned for. Exploratory testing finds the gaps. You need both.

Ready to try it?

Testpad is built for exactly this kind of testing – fast-moving, practical, and light on process. You can set up your first sprint test plan in minutes, invite your team without any onboarding, and start tracking results right away.

Not a Testpad user yet, but have got this far down and want to give it a go? Test us free for 30 days – no credit card required.

Agile software development lifecycle: the stages of a sprint

Stefan Butlin — Sat, 18 Apr 2026 00:00:00 +0000

The agile software development lifecycle is a repeating cycle where teams move work through planning, development, testing, review, and retrospective stages in short iterations called sprints. Each sprint lasts one to four weeks: the team plans what to build, builds and tests it, shows it to stakeholders, reflects on what went well (or didn't), then starts again.

At a glance

Five stages per sprint: sprint planning, daily standups, development and testing, sprint review, sprint retrospective
Sprints last one to four weeks, run back-to-back or with a short gap between them
Testing happens throughout the sprint, as features are completed, not in a phase at the end
Meetings stay short: for a two-week sprint, planning takes 2-4 hours, standups 15 minutes a day, review and retrospective 1-2 hours each
Unfinished work doesn't roll over automatically; the next sprint's planning decides whether to continue it

Traditional development works like an assembly line – finish all planning, then all development, then all testing. By which point the requirements have probably changed anyway. Agile runs these activities in parallel across short cycles. While you're building this sprint's features, you're already planning the next sprint and testing what was just completed yesterday.

Here's what happens at each stage and where testing fits in.

Is agile a programming language?

No. Agile is an approach to organizing software development work, not a programming language or specific technology. You can write agile code in Python, Java, JavaScript, or any other language. "Agile code" just means code developed using the agile approach – typically with practices like continuous testing, frequent releases, and collaborative development.

The confusion likely comes from seeing agile mentioned alongside technical terms. But agile describes how teams work together, not what they use to build software.

What is the agile approach?

The agile approach values adapting to change over following fixed plans. Instead of spending months on detailed planning before writing any code, agile teams work in short cycles and adjust based on what they learn.

The term comes from the Agile Manifesto, written in 2001 by 17 software developers who wanted an alternative to documentation-heavy, slow-moving processes. They outlined four core values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In practice, this means working in short cycles (sprints), staying in constant communication, and changing direction when you learn something new instead of being locked into plans created months ago.

You can read more about what agile testing is in our dedicated guide.

What are the stages of the agile development lifecycle?

Every sprint follows the same five stages:

Sprint planning
Daily standup
Development and testing
Sprint review
Sprint retrospective

Stage	Typical duration (two-week sprint)	Key output	Where testing fits
Sprint planning	2-4 hours	Sprint backlog	Testers raise "how will we know this works?" questions
Daily standup	15 minutes per day	Blockers surfaced	Testers hear what's ready to test
Development and testing	Most of the sprint	Working, tested features	Continuously, as each feature is completed
Sprint review	1-2 hours	Stakeholder feedback	Test results back up the demo
Sprint retrospective	1-2 hours	One or two process improvements	Testing timing and gaps get discussed

Here's what happens at each one.

Stage 1: Sprint planning

Sprint planning is when the team decides what to build during the upcoming sprint. This usually takes two to four hours at the start of each sprint.

The product owner (or whoever represents user needs) brings a prioritized list of features and fixes. The team discusses each item, estimates effort, and commits to a realistic amount of work they can finish before the sprint ends.

This is where testing considerations start. Testers ask questions like "How will we know this works correctly?" and "What scenarios should we check?" These questions often reveal that requirements aren't clear enough to start building yet – which is much better to discover now than three days before the sprint ends.

The output is a sprint backlog – the specific list of work the team committed to finishing by the end of the sprint. Some teams create test plans during sprint planning, others prefer lighter approaches like test checklists that can be built up as testing progresses throughout the sprint.

Stage 2: Daily standup

Daily standups happen every day during the sprint. The entire team meets for 15 minutes, usually at the same time each day. Each person answers three questions: What did I complete yesterday? What am I working on today? Is anything blocking my progress?

These quick check-ins keep everyone on the same page without long meetings – testers find out what's ready to test, developers learn what bugs need fixing urgently, and product owners track whether features are progressing as expected.

If someone raises a blocking issue, the team doesn't solve it during standup – they'd blow past 15 minutes and defeat the whole purpose. They schedule a separate discussion with whoever needs to be involved.

Stage 3: Development and testing

This is where most of the sprint happens. Developers write code, testers test features as they're completed, and everyone works toward finishing the sprint's committed work.

Testing doesn't wait until the end of the sprint. As soon as a developer finishes a piece of functionality – even something small – testers can start checking it. Bugs get found and fixed while the code is fresh in the developer's mind, not three weeks later when they've moved on to something completely different.

Developers also write automated tests during this stage, often at the unit level to verify individual functions work correctly. Some teams practice test-driven development, writing tests before writing the code that makes those tests pass.

Testers might do exploratory testing, work through test checklists, or run automated regression suites. The specific approach depends on what the feature needs and how much time exists before the sprint ends. Many agile teams use test prompts rather than detailed test cases – short reminders like "check password complexity rules" or "verify account lockout behavior" that guide testing without dictating every step.

This stage isn't a neat assembly line. A developer might finish feature A on Tuesday, the tester finds bugs on Wednesday, and the developer fixes them on Thursday while also starting feature B. Work overlaps and flows based on what's ready at any given moment.

Stage 4: Sprint review

Sprint review happens at the end of the sprint. The team demonstrates completed work to stakeholders – product owners, managers, customers, or anyone interested in seeing what got built before gathering feedback. Stakeholders ask questions, point out problems, and suggest changes. Sometimes this feedback gets added to the backlog for future sprints.

Only completed work gets demonstrated. If a feature is 90% done but still has known bugs, it doesn't get shown. The sprint review focuses on what's actually ready to release or very close to it.

Testers often help present during sprint reviews, especially when stakeholders ask detailed questions about how something works or what testing was done. Having clear test results – what passed, what failed, what still needs checking – makes these conversations much easier.

The sprint review helps everyone understand progress toward larger goals and catch problems before they become expensive to fix.

Stage 5: Sprint retrospective

The sprint retrospective is when the team discusses how the sprint went and what to improve. This happens after the sprint review, usually the same day or the next day.

The team asks three questions: What went well? What didn't go well? What should we change for the next sprint? This might surface issues like "Testing started too late in the sprint" or "Requirements weren't clear enough" or "We committed to too much work." The team picks one or two specific improvements to try in the next sprint.

Retrospectives aren't complaint sessions where everyone vents about problems and nothing changes. The goal is identifying concrete improvements that will make the next sprint more effective – adjusting how much work gets committed, improving communication between developers and testers, or changing when certain activities happen.

After the retrospective, the cycle starts again with planning the next sprint.

How does work flow through the agile lifecycle?

Individual pieces of work move through the lifecycle at different speeds, but they follow a similar path. Think of it like a kitchen during dinner service. Some dishes take 10 minutes to prepare, others take 45. But they all go through the same stations – prep, cook, plate, serve. Features work the same way through sprints.

A feature starts as an idea in the product backlog. During sprint planning, the team pulls it into the sprint backlog and commits to completing it. During development, a developer builds it. During testing, a tester checks it. If bugs are found, the developer fixes them and the tester retests. Once testing passes, the feature is done for that sprint.

Some features are small enough to move through this flow in a day or two. Others take the entire sprint or span multiple sprints if they're large and get broken into smaller pieces. The key is that testing happens close to development. In a two-week sprint, a feature built in the first few days gets tested in the first week, not the last day of the sprint. This gives developers time to fix any problems found.

Where does testing fit in the agile lifecycle?

Testing happens continuously throughout the sprint, not just at the end. As soon as something is ready to test, testing starts. (Our agile testing guide covers this side of the lifecycle in full.) Google's DORA research backs this up: teams that test continuously throughout delivery, instead of in a separate phase, ship more stable software with less burnout and less painful deployments.

This creates a different rhythm than traditional development. Instead of having weeks or months for testing at the end of a project, testers have days or sometimes just hours to verify a feature works before the sprint ends.

Testers need to be efficient. They can't test every possible scenario for every feature. They focus on the most important checks – does the basic functionality work? Are there obvious bugs? Does it match what was agreed during planning?

More thorough testing might happen in later sprints when the feature is more stable. But every sprint, the goal is catching major problems quickly so they can be fixed before the code gets buried under new work. Teams need a way to track what's been tested and what still needs checking. This could be a simple checklist, a spreadsheet, or one of the many agile testing tools designed for sprint-based teams, like Testpad – lightweight enough to keep up with sprint pace but structured enough to show progress clearly. In Testpad, teams copy last sprint's folder of scripts into the new sprint, add tests covering whatever's new or changed, and test in the fresh copy, so the old copy stays a faithful record of what was tested that sprint, and with what results.

What happens between sprints?

Between sprints, teams either take a short break to handle loose ends or run the next sprint back-to-back.

Some teams take a day or two between sprints to handle loose ends – fixing small bugs that didn't get completed, preparing the environment for the next sprint, or doing planning work. Other teams run sprints back-to-back with no gap. As soon as one sprint's retrospective ends, the next sprint's planning begins. There's no single right answer. It depends on how much cleanup typically needs doing and whether the team feels rushed without a buffer.

How long should each stage take?

There are no specific rules. The Scrum Guide only sets maximums: eight hours for sprint planning, four for the review, and three for the retrospective on a one-month sprint, with shorter events for shorter sprints. These are typical time allocations for a two-week sprint:

Sprint planning: 2-4 hours
Daily standups: 15 minutes per day (about 2.5 hours over the sprint)
Development and testing: Most of the sprint – roughly 70-75 hours per person
Sprint review: 1-2 hours
Sprint retrospective: 1-2 hours

For a one-week sprint, you'd compress these proportionally. For a four-week sprint, you'd likely keep the meeting times similar but have more development and testing time. The danger is letting meetings consume too much of the sprint. If the team spends 10 hours in meetings during a two-week sprint, that's a lot of time not building and testing features.

What happens to work that doesn't finish?

Sometimes the team commits to more work than they can finish in a sprint, or a feature turns out more complicated than expected, or critical bugs eat up time that should've gone to new features.

Unfinished work doesn't just roll into the next sprint automatically. During sprint planning for the next sprint, the team decides whether to continue that work or prioritize other things. Sometimes partially completed features get abandoned if priorities shift.

The goal isn't to finish everything every sprint. The goal is to finish the most important things and maintain a sustainable pace. If a team routinely completes only 60% of their committed work, that's a signal to commit to less work per sprint.

How does regression testing fit into the agile lifecycle?

Every sprint adds features that need checking in future sprints to verify they still work after new changes. This is regression testing. Some teams automate regression checks so they can run them quickly every sprint without consuming tester time. Other teams take a manual approach with checks they work through periodically.

The regression suite grows with every sprint. Early in a product's life, regression testing takes minutes. After a year of development, it might take hours or days. Teams need a plan for this – either through automation, efficient manual checking, or accepting they'll only regression test the most critical features each sprint. Without some strategy, you eventually spend entire sprints just checking that old features still work.

What are agile software development best practices?

While every team adapts agile differently, some practices consistently help teams succeed:

Test early and often – Don't save testing for the last day of the sprint. Instead, test features as soon as they're built so developers can fix problems while the code is fresh.

Keep sprint commitments realistic – It's better to consistently finish what you commit to than to overcommit and routinely leave work incomplete.

Make retrospectives actionable – Rather than only discussing what went wrong, pick one or two concrete changes to try in the next sprint.

Maintain good communication – Daily standups, direct conversations between developers and testers, and quick problem-solving keep work flowing smoothly.

Track testing without slowing down – You need visibility into what's been tested, what's working, and what problems exist. Heavyweight test case management tools often create more work than value in agile environments. Teams do better with approaches that balance structure and flexibility – whether that's simple checklists for small teams, spreadsheets for medium teams, or tools like Testpad that provide clear tracking without the documentation overhead of traditional test management.

Adapt the process – The lifecycle provides structure, but teams adapt it. Some combine sprint review and retrospective into one meeting, others split sprint planning into two sessions days apart, and some skip daily standups when everyone sits together and talks all day anyway.

The core pattern remains: plan work, build it, test it, show it, reflect on it, repeat. The specific implementation depends on what works for each team's context.

What's different about the first and last sprints?

The first sprint of a project often includes setup work that doesn't happen in later sprints – configuring development environments, establishing testing approaches, creating initial documentation structures. Think of it as the sprint where everyone figures out how they're actually going to work together.

The last sprint before a major release might include extra testing, documentation, or deployment preparation that doesn't happen in normal sprints. But mostly, every sprint follows the same lifecycle. That consistency is one of agile's strengths – teams get into a rhythm and become efficient at moving work through the stages.

How do you know if the agile lifecycle is working?

Signs the agile lifecycle is working well:

Features get tested soon after being built, not days later
Bugs found during a sprint get fixed before that sprint ends
The team completes roughly the same amount of work each sprint (velocity is stable)
Retrospectives identify real improvements, not just complaints
Stakeholders see steady progress at sprint reviews

Signs the lifecycle isn't working:

Testing happens only in the last day or two of the sprint
Bugs pile up across sprints without getting fixed
The team's velocity fluctuates wildly sprint to sprint
Retrospectives produce no actual changes
Sprint reviews reveal surprises about what was built

When the lifecycle isn't working, the retrospective is the place to discuss why and what to change.

Does the agile lifecycle change for different team sizes?

Smaller teams (three to five people) often move through the lifecycle more informally – they might skip formal sprint reviews if everyone already knows what got built, and their daily standups might take five minutes.

Larger teams (eight to 12 people) need more structure to stay coordinated. Sprint planning takes longer because more people need to understand the work, daily standups take the full 15 minutes, and sprint reviews are more formal because more stakeholders attend.

Very large projects might split into multiple teams, each running their own sprint lifecycle. This creates coordination challenges – teams need to align on shared dependencies and integration points.

What's the key difference between agile and traditional development?

The main difference is when testing happens. In traditional development, teams complete all planning, then all development, then all testing. This sequential approach means testers don't see features until months after they were designed, and bugs aren't found until it's expensive to fix them.

Agile compresses these activities into short repeating cycles. Testing happens continuously alongside development throughout every sprint. This catches problems early when they're cheap to fix and gives teams flexibility to adjust based on what they learn. Testing isn't saved for the end but built into how features get developed, which is the core difference between agile and traditional. For a fuller comparison, see agile testing vs traditional testing.

Keep your agile software development lifecycle on track with Testpad

New to this way of working? Start with our guide on how to get started with agile testing.

The agile lifecycle only works when testing keeps up with development. If you're spending more time managing test documentation than actually testing, or if stakeholders can't see what's been tested at a glance, you need a lighter approach.

Testpad gives agile teams just enough structure with test checklists that are quick to create and easy to update, clear visual progress tracking, and simple reports that show what's working and what isn't.

Try Testpad free for 30 days – no credit card required.

Agile testing tools: how to choose the right one for your team

Stefan Butlin — Tue, 14 Apr 2026 00:00:00 +0000

Agile teams tend to shortlist the same six testing tools: spreadsheets, Qase, Testmo, Zephyr, TestRail and Testpad. The right choice depends less on features and more on fit: who does the testing, how often you release, and how much process overhead you can stand. This guide compares all six and shows how to choose.

At a glance

Lightweight: Testpad (checklist-style plans, guest testers, no training needed, from $10/user/month)
Jira-native: Zephyr (built for QA specialists, pricing tied to your Jira user count)
Most feature-complete: TestRail (steep learning curve, from $35/user/month)
Just starting out: a spreadsheet is fine until several people need to test at once
What matters when choosing: ease of entry, exploratory testing support, concurrent testing, and progress everyone can see

The rest of this guide explains the reasoning: what agile testing demands from a tool, what to look for, and the mistakes teams make when choosing.

What makes a tool suitable for agile testing?

Agile testing is fundamentally different from traditional software testing (our agile testing guide covers the full approach, and this comparison sets it against the traditional way). Instead of a separate testing phase after development finishes, testing happens continuously as features are built – sprint by sprint, through the agile development lifecycle. Testers work alongside developers, product managers contribute to test planning, and everyone on the team shares responsibility for quality. Google's DORA research finds that teams who test continuously throughout delivery, rather than in a separate phase, ship more stable software with less team burnout and less painful deployments.

This collaborative, iterative approach needs tools that:

Don't get in the way – Your team doesn't need lengthy setups, mandatory fields, or enforced workflow when it comes to agile.

Anyone can use – Not just QA specialists. If a developer or product manager needs to run through tests, they shouldn't need training.

Keep up with change – Requirements shift mid-sprint. Your testing tools need to adapt just as fast, not lock you into rigid structures.

Show progress clearly – The whole team needs visibility into what's been tested and what hasn't, without digging through detailed reports.

The problem is that many "agile testing tools" were built for waterfall processes and just got an agile label slapped on. They still expect detailed test cases written upfront, formal sign-offs, and separate testing phases – exactly what agile teams are trying to avoid.

What should you look for in an agile testing tool?

Four things matter most: how quickly anyone on the team can start using it, whether it supports exploratory as well as scripted testing, whether several people can test at once, and whether progress is visible at a glance.

Lightweight beats feature-heavy

Traditional test management systems make you document everything upfront: preconditions, detailed steps, expected results, priorities, requirements traceability. This creates massive overhead for teams that just need to track "here's what we should check, here's what we found."

Agile teams benefit more from checklist-based approaches. Write down the things worth testing, run through them, and record what you discovered. You can always add detail where you need it, but you're not forced to document everything like you're preparing for an audit.

This is why many teams start with spreadsheets, because they're simple and fast. The problem with spreadsheets isn't the lightweight approach; it's that they become hard to manage when you're testing across multiple configurations, tracking results over time, or need several people testing simultaneously. Tools like Testpad sit in that sweet spot – lightweight like a spreadsheet, but built specifically for testing so you don't hit those collaboration and tracking limitations.

Concurrent testing

Agile emphasizes whole-team quality. That means developers, product managers, and other team members all contribute to testing – not just dedicated QA people.

Your testing tool needs to support this. Can multiple people test at the same time? Can developers quickly see what's already been checked before they start testing their feature? Can product managers review test results without needing a walkthrough of the system? If your tool requires everyone to become a testing expert just to participate, you've added a bottleneck that slows down the collaborative feedback loop agile depends on.

Progress everyone can see

Agile teams run on quick status: what's been tested, what's failing, what's left before release. If answering that means compiling a report, the information arrives too late to act on. Look for a tool where anyone can see progress at a glance, without a walkthrough. A quick way to send a bug to Jira or GitHub is still worth having, but that's a given; the visibility is what changes how the team works.

Flexibility for exploratory testing

Here's a crucial difference between agile and traditional testing: in agile, you're often testing features that are still evolving. Exploratory testing is central to this – requirements change based on what you learn. You discover edge cases you didn't anticipate. You need to explore, not just execute predefined test cases. Tools that force fixed test case structures make this harder. You want something where you can quickly jot down ideas, reorganize your testing approach mid-session, and capture discoveries without fighting the tool's expectations of how testing "should" work.

Which agile testing tools are worth using?

All of these tools support agile testing in some form, but they suit different team sizes, budgets, and ways of working. Here's how they compare.

Tool	Easy to get started	Whole-team friendly	Exploratory testing	Concurrent testing	Integrations	Pricing
Spreadsheets	Yes	Yes	Possible but messy	No	No	Free
Qase	Yes	Some training needed	Yes	Yes	35+ integrations	Free (up to 3 users), paid from $24/user/month
Testmo	Yes	Some training needed	Dedicated sessions	Yes	CI/CD, Jira, GitHub	From $99/month (10 users)
Zephyr	Jira users only	QA-specialist focus	Limited	Yes	Jira-native	Depends on Jira user count
TestRail	Steep learning curve	QA-specialist focus	Possible but rigid	Yes	Extensive	From $35/user/month
Testpad	Yes	No training needed	Yes	Yes	API + integrations	From $10/user/month

What mistakes do teams make when choosing agile testing tools?

Most teams make at least one of these mistakes when choosing a testing tool. Here's what to watch out for.

Choosing based on features rather than fit

The tool with the most impressive feature list isn't necessarily the best choice. What matters is whether it supports your team's real-life workflow. A simpler tool that everyone uses is far more valuable than a powerful system that's too cumbersome for quick testing cycles.

Assuming more process equals better quality

Agile testing is about continuous feedback, not comprehensive documentation. Tools that enforce heavyweight processes – detailed test cases, formal review cycles, mandatory fields – often work against agile principles rather than supporting them. You end up spending more time managing tests than actually testing.

Trying to automate everything immediately

Yes, test automation is valuable for regression testing. But in agile, you're continuously building new features that are still changing. Automating tests for features that aren't stable yet means you'll spend more time maintaining broken automation than you save.

Start with manual testing using lightweight tools. Automate the stable, repetitive tests worth automating. This matches the agile principle of responding to change rather than following a plan.

Ignoring who actually does the testing

If your testing approach in agile means the whole team contributes, but your tool requires specialized training, you've created a problem. The barrier to entry matters – can a developer quickly run through a checklist before merging their pull request? Can a product manager verify the happy path without needing to understand test case management systems?

What tools do agile teams actually use?

Most agile teams run a mix: a lightweight test tool or spreadsheet for manual checks, a unit-test framework, their issue tracker for bugs, and CI to run what's automated.

Small teams often start with the absolute basics:

Spreadsheets or simple checklists for manual testing
Unit tests written in whatever framework their developers know (Jest, pytest, JUnit)
Their existing issue tracker for bugs (GitHub Issues, Jira, Linear)
Maybe basic CI/CD to run automated tests

This works fine until collaboration becomes messy (multiple people editing spreadsheets), tracking gets difficult (can't see what passed/failed across multiple test runs), or visibility suffers (stakeholders asking for status updates you can't easily provide).

That's typically when teams move to a dedicated test management tool – but they're usually looking for something that maintains that lightweight simplicity while solving those specific pain points.

Testpad works this way. It's structured enough that you can track testing across configurations and test runs, collaborative so multiple people can test simultaneously, and visual so anyone can see progress at a glance.

As teams grow or face more complexity, they might add:

UI automation frameworks (Cypress, Playwright) for critical user journeys
API testing tools (Postman, REST Assured) for backend verification
More sophisticated CI/CD orchestration
Better reporting and test analytics

But the core principle stays the same: tools should support agile testing practices, not force teams to adapt their approach to fit the tools.

Start simple, expand when you need to

Begin with whatever lets you test immediately. A spreadsheet and your existing bug tracker might be perfectly adequate. Don't invest in elaborate tooling before you understand what problems you're actually solving.

Here's what typically drives teams to look for better test management:

Testing across multiple browsers or devices and spreadsheets can't track all those results clearly
Multiple people need to test simultaneously and basic tools get messy
You need to show sprint-over-sprint progress and your current setup doesn't make that visible
Stakeholders want quick status updates and it takes too long to pull that information together

These are the pain points Testpad was built to solve – giving you structure and visibility without the overhead of traditional test case management.

Add specialized tools when simpler approaches create problems, not because you think you should have them. Testing tools should make testing easier. If they don't, you've chosen the wrong tools or brought them in too early. This iterative, respond-to-real-needs approach is exactly what agile methodology is about – which is why the best agile testing tools are the ones that support that philosophy rather than fight against it.

Start managing your agile testing with Testpad

Testpad gives you structured test management that works at agile speed – simple checklists, clear progress tracking, and visibility for the whole team. Start your free trial – no credit card required.

How to write new test scripts with our custom GPT

Stefan Butlin — Wed, 01 Apr 2026 00:00:00 +0000

Testpad's custom GPT is a free tool that turns a simple feature description into a ready-to-use test script in minutes. Writing test scripts for a new feature from scratch doesn't need to take over your day any more – just describe what you're testing to our custom GPT, review the output, and paste into Testpad.

Here's the process:

Go to our custom GPT
Describe what you're testing (can be brief: "login system" or detailed with feature lists)
Get back organized test prompts in Testpad's format
Review and adjust for your product – iterate and repeat as needed
Paste into Testpad

The custom GPT handles brainstorming test scenarios and formatting them properly. You focus on making them relevant to your specific product.

What should I tell the custom GPT?

More detail gets better output, but even minimal descriptions work.

Minimal: "I want to test a login page of a web app"

Gets you basic coverage:

Credentials
  Valid username and password signs in successfully
  Invalid password is rejected
  Unknown username is rejected
  Blank username is rejected
  Blank password is rejected
  Blank username and password are rejected
  Leading and trailing spaces are handled correctly
  Username is treated with expected case sensitivity
Session and navigation
  Successful login lands on the correct page
  Authenticated user can access protected pages
  Unauthenticated user is redirected to login for protected pages
  Back navigation does not reopen login after successful sign in when already authenticated
  Session starts only after successful authentication
Error handling
  Error message is shown for invalid credentials
  Error message is clear without exposing sensitive details
  Error state clears after correcting input
  Multiple failed attempts are handled correctly
  Login remains available after a failed attempt

By adding more detail you can get more useful and comprehensive test prompts.

Feature-focused: "Create a Testpad-formatted test plan for a restaurant booking web app"

Gets you testing organized by feature:

Restaurant booking
  Reservation creation
    Select date and time
    Choose party size
    Receive confirmation
  Reservation management
    View existing reservations
    Modify reservation details
    Cancel reservation
Menu viewing
  Browse menu
    Filter by category
    Search for specific items
    View item details and prices
Reviews
  Write reviews
    Submit rating and text
    Upload photos
  Browse reviews
    Filter by rating
    Sort by date

The more information you give, the more specific your test prompts will be.

Detailed: "Create a Testpad-formatted test plan for a shopping cart for an e-commerce site. Users should be able to: add/remove items, update quantities, apply discount codes, see shipping estimates, save cart for later"

Gets you targeted testing covering your specific requirements:

Shopping cart
  Cart management
    Add items from product pages
    Remove items from cart
    Update item quantities
    Clear entire cart
  Discount codes
    Valid code applies discount
    Invalid code shows error
    Expired code displays warning
    Multiple codes handled correctly
  Shipping estimates
    Estimates update with cart changes
    Different shipping methods display
    International shipping calculates correctly
  Save for later
    Save cart when logged in
    Restore saved cart
    Saved cart persists across sessions

What needs reviewing after generation?

Every generated script needs human review before use:

Cut the irrelevant – The custom GPT gives you a solid starting point. Remove anything that doesn't apply to your product. Testing a web app? Delete suggestions about physical packaging.

Add product specifics – The GPT doesn't know your edge cases, integration points, or bug-prone areas. Add tests based on your experience with the software.

Adjust detail level – The GPT aims for brief prompts, but you might want shorter or longer depending on who's testing and your process.

Check organization – Sometimes logical structure doesn't match testing workflow. Reorder sections to match how you actually test.

Five minutes of review transforms generic output into a focused script for your product.

Can I give it existing requirements?

Yes, and it's often the fastest way to generate relevant tests.

Paste in:

User stories from your backlog
Feature specifications
API documentation
Design mockups (describe them)
Acceptance criteria

The custom GPT extracts what's testable and generates appropriate prompts.

Example – paste this user story, adding an instruction such as "please keep test prompts refined":

As a user, I want to filter search results by price range, category, and availability so I can find products that match my needs.

Already have test cases in another tool? You can also use our custom GPT to import and reformat them into Testpad instead of writing from scratch.

Get back:

Price range
  Min and max sliders adjust within allowed limits and update results
  Min cannot exceed max and max cannot go below min
  Results include products within range including boundary values
Category selection
  Selecting one or more categories filters results to those categories
  Adding categories expands results and removing categories narrows results
  Clearing all categories removes category filtering
Availability
  In stock only checkbox toggles filtering of out of stock products
  Enabled shows only in stock and disabled shows all products
Filter combinations
  Price, category, and availability filters can be combined in any way
  Results always match all active filters
  Changing any filter updates results while preserving others
Clear filters
  Clear filters resets sliders, categories, and availability selection
  Clear filters restores unfiltered results from any state
Usability and edge cases
  No results state is shown when filters return no matches and can be cleared
  Filter results remain consistent regardless of application order
  Filter selections persist correctly after results update
  Applying filters does not change the search term

What if I just have a vague idea?

That works too. The custom GPT fills in common test scenarios.

Tell it "I need to test a messaging feature" and get back tests for sending messages, receiving notifications, message history, attachments, read receipts, group messaging, and more. You'll need to remove suggestions that don't apply, but it's faster than brainstorming from scratch.

How detailed should test prompts be?

The custom GPT generates brief, exploratory-style prompts that tell testers what to investigate without prescribing exact steps.

Default style: "Invalid email format rejected"

This gives testers freedom to try different invalid formats and explore edge cases.

If you need more detail, tell the custom GPT: "Make the prompts more specific" and you'll get:

More detailed: "Entering an email without '@' symbol shows validation error"

If you need less detail, say "Make the prompts briefer" and get:

Minimal: "Email validation works"

Most teams find the default style hits the right balance between guidance and exploration.

Can I generate tests for technical testing?

Yes. The custom GPT handles:

API testing: "Test the /users endpoint – supports GET, POST, PUT, DELETE with authentication required"

Gets you tests for each HTTP method, authentication checks, request validation, response codes, error handling.

Database testing: "Test the user registration database operations"

Gets you tests for record creation, data validation, uniqueness constraints, relationships, queries.

Integration testing: "Test integration between payment gateway and order system"

Gets you tests for successful payments, failures, timeouts, refunds, order state updates.

Describe the technical aspect you're testing and what it needs to do. The custom GPT generates relevant prompts.

Should I trust the custom GPT's coverage?

Trust it as a starting point, not a finished product. It handles the heavy lifting: breaking features into testable pieces, suggesting common scenarios, and formatting everything properly. What it can't do is know your product.

It doesn't know:

Your product's actual behavior
Which features are stable versus buggy
Your users' real workflows
Technical constraints
Business rules specific to your domain

You handle the product-specific edge cases, tests informed by historical bugs, and prioritizing what actually matters. The risk is pasting and running without review. You'll test things that don't matter while missing things that do.

Can I use it for different testing types?

Yes. Tell it what type of testing you need:

"Generate security tests for login system" – Authentication checks, password requirements, session handling, access controls
"Generate performance tests for search feature" – Response time checks, concurrent user handling, large dataset tests
"Generate accessibility tests for checkout flow" – Keyboard navigation, screen reader compatibility, color contrast
"Generate mobile-specific tests for profile page" – Touch interactions, orientation changes, different screen sizes

The custom GPT adjusts its suggestions based on the testing type.

What about edge cases?

The custom GPT suggests common edge cases, but it doesn't know your product's specific quirks.

It'll suggest generic edge cases:

Empty inputs
Maximum values
Special characters
Null/undefined values
Boundary conditions

You add product-specific ones:

That integration that breaks when the third-party API returns unexpected formats
The calculation that fails for negative numbers even though it shouldn't accept them
The race condition that happens when two users edit the same record
The performance issue that only shows with your largest customer's dataset

Your product knowledge is what makes edge case testing valuable.

How does pasting into Testpad work?

Testpad reads indented text automatically:

Copy the custom GPT output
Open Testpad, create a new script or open an existing one
Open the Import Dialog (found in the Edit menu) and paste
Testpad converts indentation into structure

Lines without indentation become sections, indented lines become subsections, lines with "-" become test prompts.

Tips for clean imports:

Keep test prompts on single lines
Use consistent spacing (2-4 spaces per indent level)
Section headers don't need bullets

Do I need a ChatGPT account?

Yes, but free accounts work fine. The custom GPT is available here once you're logged in.

Paid accounts process faster and handle longer inputs, but the free tier works fine for typical feature testing.

Can I use other AI tools?

Yes, but you need to explain Testpad's format each time.

With custom GPT: "Generate test script for login system"

With generic AI: "Generate a test script for a login system. Format as an outline using indentation (2-4 spaces per level). Top-level items are feature sections, indented items are subsections, and individual test prompts start with '-'. Keep prompts brief and exploratory rather than step-by-step instructions."

The custom GPT saves you from repeating those formatting instructions.

You may need a few rounds of back-and-forth to get the formatting right. Generic AI tools can be unpredictable around spacing, bullets, and blank lines.

Quick tips for better output

Be specific: the more detail you give, the better the prompts
Paste in user stories or acceptance criteria for the most relevant results
Ask for adjustments: "make prompts briefer" or "make prompts more specific"
Review before running: cut irrelevant tests, add your product's edge cases
Test with a small section first before importing a large script

Testpad's custom GPT takes the slow part out of writing test scripts. Describe what you're testing, review the output, and you're ready to go in minutes. Start your free 30-day trial and try it for yourself. No credit card needed.

Sanity testing: why you shouldn’t skip it and how to do it right

Stefan Butlin — Tue, 31 Mar 2026 00:00:00 +0000

Sanity testing is a quick check that your software's core features still work before you commit to a full test cycle. Spend 15 minutes confirming the basics, and you avoid wasting days testing a build that was never ready. If your full test run takes more than an hour, a sanity check beforehand is worth it.

At a glance

A sanity test is a short checklist: can users log in, does the main page load, does the new feature appear at all
Sanity and smoke testing mean the same thing in most teams; where teams do distinguish them, sanity is narrower and focused on recent changes
Sanity testing is not regression testing: a sanity check asks "is this build worth testing?", regression asks "has anything previously fixed broken again?"
Scale it to your test cycle: 15 to 20 minutes before a multi-hour run, longer for cycles that take weeks
If the sanity check fails, stop. Flag the build and save the full test run for when the basics work

The rest of this post covers the details: what sanity testing is, how it compares to smoke and regression testing, and how to run one as a simple checklist.

What is sanity testing?

Sanity testing is a quick check that your software's basic functions are working before you commit to a full test run. It's not about running all your tests or diving into extensive regression testing – it's about efficiently assessing whether it's worth proceeding at all.

Think of it as a quick temperature check for your software. Before you call in the full medical team (your comprehensive testing process), you want to make sure there's actually a fever to treat. This approach is all about being time-efficient, catching obvious issues with minimal effort before you invest more resources.

Consider this scenario: Your development team has been working on a new feature for your web app. Before you unleash your QA team for a week-long testing marathon, wouldn't it make sense to spend 15 minutes checking if the basics still work? Can users log in? Does the main page load? Does the new feature do anything at all? That's sanity testing in action.

The goal is to go wide before you go deep. You're looking for obvious issues that might derail more extensive testing efforts. It's far better to discover a major problem in a 15-minute sanity test than five days into a comprehensive test run.

Remember, sanity testing helps by being pragmatic. It's not about perfection – it's about quickly gathering the information you need to make smart choices about your testing process. If you're not doing some sanity testing already, and your full test run takes non-trivial effort, then it'd be a good idea to start with some simple quick checks.

For example, imagine a CSS deployment breaks the login page. A two-minute sanity check catches it before your QA team starts a week-long test cycle – saving days of wasted effort.

Sanity testing vs. smoke testing

Sanity testing and smoke testing mean the same thing in most teams: a quick check of basic functionality before a full test run. Where teams do make a distinction, sanity testing tends to focus on specific areas that have recently changed, while smoke testing covers a broader range of core functionality. Either way, the core concept is the same.

The ISTQB glossary defines a smoke test as "a test suite that covers the main functionality of a component or system to determine whether it works properly before planned testing begins", and has no separate entry for sanity testing at all. That tells you how much weight to give the distinction.

Sanity testing vs. regression testing

A sanity check should not be confused with regression testing – the two are quite different. Sanity testing is a quick pre-cycle check; regression testing is a thorough process to ensure previously fixed issues haven't reappeared.

As we've mentioned, sanity testing is a quick check that all the obvious stuff is working before committing to a longer, more expensive full test. It's about quickly assessing the current state of the software, particularly after recent changes or bug fixes.

Regression testing, on the other hand, is the rigorous testing to ensure that everything that has been broken and fixed in the past isn't broken again this time. It's about ensuring that existing functionality hasn't been compromised by new changes.

The automated part of your regression tests will probably have already been run before you're considering a sanity test, as they're typically quick and easy to run once written. But the manual part of your regression testing (and yes, regression testing can be manual) will be part of the very "full test run" that you want to protect with a quick sanity check first.

In some cases, sanity testing might overlap with a subset of regression testing. For instance, if automated regression tests flag several issues, a quick sanity test might be used to verify these problems and assess their impact before diving into more detailed testing.

Remember, the goal isn't to rigidly categorize every test you perform. The key is to use these different testing approaches pragmatically, choosing the right tool for the job at hand.

Whether you're performing sanity testing or running a full regression suite, the ultimate aim is the same: to gather valuable information about your software's current state and make informed decisions about your development process.

	Sanity Testing	Smoke Testing	Regression Testing
Scope	Narrow – specific changed areas	Broad – core functionalities	Comprehensive – all previously tested areas
When	After a specific fix or change	After a new build	Before a release
Speed	Very quick (minutes)	Quick (minutes–hour)	Slow (hours–days)
Goal	Is this fix working?	Is the build stable?	Has anything broken?

Why is sanity testing important?

A sanity check is all about efficiency in the software testing process. It recognizes that testing happens within the constraints of limited resources, and we're always trying to find as many issues as possible with the least effort.

The importance of sanity testing lies in its ability to catch obvious problems quickly before investing time in more thorough testing phases. It's a smart way to allocate your resources and potentially save significant time and effort down the line. The idea has decades of practice behind it: Steve McConnell's 1996 IEEE Software article Daily Build and Smoke Test describes how Microsoft built its products every day and ran a quick check on each build, bringing the system "to a known, good state" and keeping quality problems from taking control of the project.

However, the scope of sanity testing should be proportional to your overall testing process:

If your full test run only takes an hour, you might not need a separate sanity check.
If your full test run takes several hours, a quick 20-minute sanity test might make sense.
For test cycles that take days or weeks, a more extensive "quick" test lasting a day or two could be beneficial.

The key is to keep things in perspective and tailor your approach to your specific needs. Sanity testing is about making sure it's worth proceeding with more comprehensive testing, not adding unnecessary complexity to your process.

If this kind of check fails, it often indicates a fundamental issue that needs addressing before further testing. This early detection can save your team valuable time and resources, ensuring you're not investing effort in testing a build that's fundamentally flawed.

How do you apply sanity testing?

Sanity testing can be carried out by anyone about to start a test cycle – a QA engineer, a developer, or anyone responsible for signing off a build.

When it comes to applying sanity testing, remember this: IT DEPENDS. Your specific project, team structure, and development process will all influence how you implement your sanity testing.

You perform sanity testing any time you're about to embark on a longer test cycle.

This could be after receiving a new build, following significant code changes, or when you need quick feedback on the software's state. The key is to use sanity testing as a quick check before investing time and resources into more comprehensive testing.

Practical steps:

Keep it simple: Don't overcomplicate it, just work out a small collection of simple checks that test if the main features are working.
Use checklists: Checklists are an obvious and simple way to document your sanity tests. They help ensure you don't forget anything, and give you consistency from release to release. A tool like Testpad makes this easy, letting you manage sanity tests as simple checklists without the overhead of traditional test management tools.
Focus on what's new or changed: Yes, include quick checks for all the main features of your software, but it can often be worth a few extra quick checks on what's new or changed since last time (as that's the most likely areas for new and obvious bugs)
Consider a subset of regression tests: If you have an established set of regression tests, consider using a small subset for your sanity testing.
Incorporate exploratory testing: A few minutes of freeform exploration around your checklist can uncover issues the planned checks alone would miss.

Sanity testing really doesn't have to be complicated. Your checklist could look as simple as:

Can customers log in?
Does the product catalog load?
Can a product be added to the cart?
Does the checkout process work?
Is the new "Recommended Products" feature visible?

The exact contents of your sanity test will depend on your specific application. Focus on the core functionalities and any recent changes or additions.

By applying sanity testing, you quickly assess whether your software is ready for more thorough testing. This simple approach can save your team valuable time and resources, catching major issues before you invest in more comprehensive testing.

What tools do you need for sanity testing?

Choosing tools for sanity testing isn't hard. In fact, you don't need complicated tools at all.

A pen and paper or whiteboard can work, but they're easy to lose or accidentally erase. Many teams find starting with a list in a spreadsheet is the best approach. It's simple, shareable, and gets the job done.

When spreadsheets start becoming unwieldy due to formatting issues or growing complexity, you might consider upgrading to Testpad – an easy to use test management tool built around checklists. It offers more power than a spreadsheet without the complexity of traditional test management tools.

Remember, it's about quick, efficient checks. Avoid over-engineering your process with complex systems. The key is to keep it simple and choose a tool that aligns with your team's needs and workflow.

As for automation tools like Selenium, Cypress, or LoadRunner – these are primarily for regression testing, not sanity testing. While they're valuable in their own right, they're typically overkill for the quick, manual checks that characterize sanity testing.

Start simple, use what works for your team, and only add complexity when it truly adds value to your sanity testing process.

How to run sanity tests in Testpad

Testpad is designed around checklists, which makes it a natural fit for sanity testing. There's no complicated setup, no test frameworks to configure. Just a list of checks you can run through quickly before committing to a full test cycle.

Here's how to get started:

Create a new script for your sanity tests. Keep it short. Just the core checks that tell you if the build is worth testing further.
Add your checks as simple lines. Things like "Can users log in?", "Does the main page load?", "Does the new feature appear?" No need for formal test case structure.
Run it before every test cycle. Work through the checklist, marking each item pass or fail as you go.
If something fails, stop. Flag the issue to the dev team and save your full test run for when the basics are working.

A sanity test passes when all your core checks complete without issues and the build feels stable enough to test further. It fails when any critical check breaks – a page won't load, a key feature is missing, or something fundamental isn't working. You don't need a perfect score. You just need enough confidence to proceed.

That's it. The whole point of sanity testing is speed and simplicity, and Testpad keeps it that way.

Keep your sanity tests simple

The best sanity tests are the ones that actually get done. Keep yours simple, focused, and repeatable. A short checklist is all you need to run before every major test cycle and avoid wasting days on a build that was never ready for testing.

If you're looking for a better way to manage your sanity tests, Testpad is built for exactly this. Lightweight checklists that are quick to run and easy to share. Start your 30-day free trial and see how it fits your team.

Frequently asked questions

What is the difference between sanity testing and smoke testing?

The terms are often used interchangeably, and in most cases they mean the same thing. Some teams make a distinction: sanity testing focuses on specific areas that have recently changed, while smoke testing covers a broader range of core functionality. The key concept is the same either way. Run a quick check before committing to a full test cycle.

When should you do sanity testing?

Any time you are about to start a longer test cycle. That could be after receiving a new build, following a bug fix, or after significant code changes. If a full test run takes more than an hour, a quick sanity check beforehand is worth it.

How long should a sanity test take?

It depends on the size of your test cycle, but as a rule of thumb: if your full test run takes a few hours, your sanity test should take 15 to 20 minutes. If your full test run takes days, a sanity check of a few hours is reasonable. The goal is to catch obvious issues quickly, not to run a mini version of your full test.

Does sanity testing need to be automated?

Not necessarily. Sanity testing is often manual, especially when it is a quick check before a test cycle. That said, if you already have automated tests, running a small subset of them as a sanity check is a perfectly valid approach. The goal is speed and simplicity, so use whatever gets you a quick answer fastest.

What is exploratory testing?

Stefan Butlin — Thu, 26 Mar 2026 00:00:00 +0000

Exploratory testing is a hands-on approach where testers actively explore software, using their knowledge and intuition to decide what to try next based on what they just learned. It finds the bugs that rigid, predefined test cases miss, because a thinking tester follows hunches no test author anticipated.

At a glance

Exploratory testing means designing and running tests at the same time, guided by what you find
It adds the most value on new features, user-facing products, and high-risk areas
Pure freestyle testing finds bugs but is hard to track, report on, or repeat
SBTM adds time-boxed sessions and charters, but its notes make poor reports
The pragmatic fix: a plan of test ideas detailed enough to track, loose enough to explore within
Testpad is built for this: each test is one line of plain text, with results recorded in a grid

The rest of this guide fills in the detail: what exploratory testing is, why teams shy away from it, and how a lightweight plan makes it manageable.

Exploratory testing is one of the best ways to find real issues fast. But instead of embracing it, a lot of teams stick with automation or rigid, predefined test cases because they seem faster, easier to track, and better for reporting. In the process, they miss the bugs only human intuition can catch.

Which is a shame, as the value of exploratory testing is undeniable. It fosters a deep understanding of the application, encourages creative problem-solving, and adapts to the evolving context of the project.

A big part of the problem is not knowing how to implement exploratory testing in real-world projects; projects that have managers who want to know answers to very unreasonable questions like “how much have you tested so far?”, or the outrageous “how much longer do you need?”. While there are some formalizations to exploratory testing, in our experience they’re not widely used.

So we present instead a simplified approach: keeping the benefits of human-driven testing but with some pragmatism thrown in to make it predictable, trackable and re-usable the next time. So let’s back up a bit: what is exploratory testing, and how does it work in practice?

What is exploratory testing?

Before we get into how to better approach exploratory testing, let’s first look at what it is.

The ISTQB glossary defines exploratory testing as:

“An approach to testing in which the testers dynamically design and execute tests based on their knowledge, exploration of the test item and the results of previous tests.”

Er…ok. Let’s try James Bach, whose classic essay Exploratory Testing Explained goes for the rather more concise:

“Simultaneous learning, test design and test execution”

(The same essay credits Cem Kaner with first putting the term in print, in his book Testing Computer Software.)

Better, but still not great. What exploratory testing is all boils down to:

“Making it up as you go along – with your brain engaged.”

This allows testers to choose what they do next based on what's just happened, to be reactive to what’s happening, to try test ideas inspired by their interaction with the product.

Exploratory testing is just making it up as you go along, with your brain engaged.

When does exploratory testing deliver the most value?

Exploratory testing doesn’t need to be everywhere. It works best when risk is high or user behavior is unpredictable.

Where exploratory testing adds the most value:

New features where it’s still unclear how people will use them
Products that customers interact with directly, where the experience matters most
Systems where mistakes could lead to real costs or damage your reputation
Complex setups that don’t follow simple step-by-step processes
Agile teams working quickly with lots of changes

Where it’s less critical:

Established products with predictable use
Internal tools used by trained staff
Low-risk updates or areas already covered by thorough automated tests

This isn’t about skipping steps but about focusing your time and energy where it will pay off.

To control or not to control?

To understand where exploratory testing fits in, it helps to consider the degree of control your testers have over their actions during testing.

Zero control is testing that is ad-hoc, purely freestyle, basically just using the software and trying to break it. On the other hand, full control is when every action and every expected outcome is spelled out in exacting detail.

Exploratory testing definitely includes zero control, purely freestyle testing. Exploratory testing definitely does not include the fully controlled extreme of rigid, spelled-out test cases.

So, how much in between these extremes counts as exploratory testing?

Well, it doesn’t really matter!

You can rightly argue that all testing is exploratory because it’s impossible to control every micro-action of a tester, removing all agency and independent thought. But that’s getting away from the point. If you’re leaving your testers free, let’s say somewhat free, then it’s exploratory.

If you’re controlling your testers to the point where anyone could do it, it’s not exploratory. In fact, at that point, you absolutely should be automating it (assuming it’s cost-effective to implement).

What are the advantages of exploratory testing?

It’s easiest to see the value of exploratory testing (a.k.a. not controlling your testers) when you contrast it with rigid, fully prescribed test cases at the other end of the spectrum.

Fully prescribed testing, whether carried out by humans or automated, can only find problems on the path the tester is taken down, the problems the test authors anticipated. Your known unknowns, if you like.

But if you want confidence you’ve found all the problems there are to find, you need to predict a lot of problems, which equates to a massive collection of test instructions. It’s like trying to color in a drawing with a thin pen. You need a lot of lines scratching back and forth before it begins to look at all filled in.

If you think this sounds sub-optimal, you’d be right.

What you need is an approach that makes it more likely you’ll find problems off the beaten track, more likely to uncover your unknown unknowns. And that’s exactly where exploratory testing comes in.

Exploratory testing is more likely to find your unknown unknowns

Exploratory-style testing achieves this precisely because it doesn’t try to define every step of the way. Instead, it leaves your testers free to use their intuition. To try out your product in the way real users might in the real world. To explore patterns of use and user behaviors the developers never even thought of. Even if they were embarrassingly obvious in hindsight. Doh!

In other words, exploratory testing is like doing that color fill with a marker pen.

Without getting qualitative, consider the likelihood of types of problems. Exploratory testing allows for (good) testers to dose their test effort looking for the more probable new bugs, than the less probable reoccurrence of old bugs. That’s not to say testing shouldn’t include checking the whole system, but testers will rightly intuit the new stuff that’s going to have the new problems and will invest more time and be more inventive in their tests of those features.

There’s also a human win…because your testers have a degree of agency and self-direction (along with active brains making active choices) they will inevitably be more engaged with the whole process. And who doesn’t want a more engaged team?

Side note: We should perhaps allow that there are specific situations where fully prescribed testing is in fact useful or even required. Regression testing would be a good example of building a growing collection of very specific (preferably automated) tests to ensure you don't break the same thing twice. Or in more regulated environments, controlling and recording exactly what was tested can be a matter of standards conformance – even if this means less effective testing in terms of maximizing how you learn about the state (readiness) of your product.

The disadvantages of exploratory testing

Exploratory testing is valuable and it’s simple to do. So why isn’t everyone doing it? Basically, it’s too simple.

Exploratory testing is often performed with no structure at all, the zero-control, purely freestyle approach discussed above. Just pick it up and get testing. And yes, this approach is better than no testing! It will certainly find a lot of bugs. But when your manager walks over, it’s hard to answer questions like “Are you done yet?”

This obviously doesn’t fly for real-world teams with little room or patience for unplanned activities that can’t be tracked or reported on.

Of course, managing exploratory testing isn’t a new problem, and formalizations exist to address the problems with controlling the uncontrolled.

What is Session-Based Test Management (SBTM)?

The most well-known is probably Session-Based Test Management (SBTM), introduced by Jonathan and James Bach at Hewlett-Packard in 2000. SBTM codifies some control on what would otherwise be a freeform process with the ideas of breaking testing up into time-limited sessions, with guides (charters) to define scope. Testers use the instructions to journal and take notes of the testing activity as it proceeds.

If we extend the flippant definition of exploratory testing from above, it becomes:

“For each of the following topics, spend X minutes making it up as you go along – with your brain engaged…and taking notes.”

Thinking back to the degree of control idea, SBTM comes in fairly low. There’s a charter with high-level items in it to guide the process, but within those items and within the time limits, testers can be very exploratory and are free to put their efforts where they see fit.

Thus, SBTM begins to help with at least the planning and tracking part. The charter (and time bounds) is a reasonable plan. And the notes taken against that plan certainly count as tracking.

However, this is often not enough from a project management point of view.

The notes that count as tracking also form the basis of reports on how testing went. The quality of such reports therefore depends heavily on the ability of the tester's note-taking skills. It’s quite tricky to be both complete and keep a lid on the verbosity.

Testers tend to either go all-in and make boring, long-winded records of every test idea performed, or they miss important information in an effort to economize (or through natural human laziness!)

These reports also only work as reports when they’re read through thoroughly. Without additional effort to paraphrase and condense the essential content, there’s no quick summary available as to what’s working and what’s not.

SBTM isn’t ideal for the testing team either. Teams like to evolve their process through time, learning from release to release, from sprint to sprint. With notes as the chief output, the next test cycle can only improve on the previous one if a tester re-reads all the notes from last time or if there’s a separate process to re-read notes and summarize key findings to be aware of next time.

The bottom line on SBTM is it’s a definite step up in making exploratory testing more useful from a management point of view. But still, no cigar when it comes to at-a-glance reporting and simple reuse for next time.

How do you make exploratory testing trackable?

So, how do you balance the value of exploratory testing against the reasonable needs of project management?

It’s actually not that hard. You just have to let go of the idea of leaving the tester completely free. Put some structure around the exploratory testing process but stop short of being too rigid in your control. Essentially, be more pragmatic about it.

Rather than leaving testers completely to their own devices, construct test plans that have significantly more detail in them than SBTM’s high-level charters. Aim for test plans that go into sufficient detail such that a “pass” is enough information to indicate a test idea is working.

At the same time, you need to make sure plans don’t have so much detail that testers have zero freedom. Testers need to be free to come up with their own ways to investigate the correctness of each test idea. Treat “tests” not as steps and expected outcomes but as ideas; ideas for experiments that the tester should explore.

Here’s how the approaches compare across the control spectrum:

Approach	What guides the testing	Tracking and reporting	Reuse next cycle
Freestyle (ad-hoc)	Tester instinct alone	None; bug reports are the only output	Nothing to reuse
SBTM	Time-boxed sessions with charters	Session notes; thorough but slow to read	Re-read last cycle’s notes
Pragmatic test plans	A list of test ideas to explore within	Pass/fail against each idea, visible at a glance	Reuse and extend the plan
Rigid test cases	Prescribed steps and expected results	Precise, but heavy to write and maintain	Reusable, at the cost of upkeep

To build this kind of test plan, you might wonder where to start. But, again, it’s not so hard. A good place to start is a simple list or mind-map of the high-level features, user stories, backlog items, or just the broad capabilities.

From there, embellish each item with further aspects, sub-features if you like, that you want testers to look into. And then iterate again, embellishing at more and more detail until you’re happy with the coverage but without spelling it all out in so much detail that you might as well automate it.

There’s no doubt this loses out to the idealistic value of a tester deciding on-the-fly where to invest the most time. On the other hand, because no instructions have been given about how to test within each item, it still benefits from the investigative intuition of the brain-powered tester.

So, like with SBTM, we have a decent plan of what's to do, of how big the test task ahead is. But now we also have a really nice and simple way of tracking progress.

As testing progresses, testers collect simple pass/fail (with optional comments) against each test idea. The output is a simple yet comprehensive list of items that have been looked at and whether or not problems were found.

Good test reports show what works as well as what doesn’t

Scanning a list of tests with pass/fail results makes it really obvious how much has been tested, and any problems will draw the eye – especially if you color them in red!

It’s important to highlight not just the issues but also what’s working. Too often, testing feedback comes only as bug reports, leaving you wondering if the rest of the system was tested at all or just problem areas.

Good test reports make clear which tests passed and which didn’t, so there’s no doubt about coverage or quality.

Building on your test plan as you go

This kind of test plan is easy to update. If more test ideas come up, you can just add them to the list. This even happens during testing itself: exploring within one item often sparks ideas for another, so you add the odd new line while you’re in the zone.

With this pragmatic testing approach, you keep those ideas not just for the current round but for future test cycles, improving coverage continuously.

What tools work best for exploratory testing?

Another benefit to the pragmatic strategy is that it doesn’t take a lot to get started. Testers just need a place to write down their results, observations, and new test ideas.

Finding the right exploratory testing tool will depend on your team, but there are plenty of options – especially as a pragmatic strategy doesn’t need much to get going.

Of course, some tools are better than others.

Post-its will do the job, but they’re easy to lose and don’t give the most professional impression.

Whiteboards are harder to lose but difficult to share. And if someone walks too close to the board, you’ll lose months of work on their shirt…

Word processors are good for building and iterating tests over time, showing what has been tested and what has yet to be tested.

Google Sheets or Excel are a bit cleaner, with columns to show exactly what was tested, what passed, and what failed. They also make it easier to total up the number of tests and their success. But they’re problematic when you want to create an outline or hierarchy, and it’s easy to pour several hours into making them look presentable. If spreadsheets are your current setup, we’ve covered how to use them for exploratory testing, and when to upgrade.

Then there is Testpad…(with, ahem, obvious bias)...we think it is the best tool for a pragmatic approach to exploratory testing.

It’s easy to use. Testpad has the same simple listing facility that documents or spreadsheets do. Anyone who’s used Google Sheets or Excel gets the hang of it in minutes.

It’s easy to add hierarchical information. Unlike spreadsheets, Testpad lets you outline tests and group them logically, making it much easier to appreciate how comprehensive a test cycle is. Instead of reading every cell in a worksheet, you can just scan a collection of headings and subheadings.

It’s easy to edit and add new tests. Testers don’t need to right-click and ‘insert new row’ – they can just type in new tests as they go, being as verbose or concise as required.

It’s easy to report. Testpad’s Report view shows a spreadsheet-inspired grid of results, with checks and crosses that make it easy to see where testing stands. Share the link during testing and anyone can see how far things have got whenever they look; the same view makes an elegant final report when testing is complete.

It’s easy to collaborate. Assign test runs to coworkers, invite guest testers for extra help – it's all cloud-based, making it easy to share plans and progress anytime, anywhere.

How to get started with exploratory testing

So...exploratory testing brings a lot to the table. It’s an approach that uses human creativity and intuition, uncovering issues that automated or fully prescribed testing can miss. While it may seem too unstructured at first glance, adding a layer of pragmatism can turn it into a highly effective process: balancing flexibility with a bit of structure helps in making exploratory testing trackable and repeatable.

Two natural next steps from here: the types of exploratory testing for choosing how to structure your sessions, and exploratory testing techniques for what to do inside them.

To get the most out of this approach, having the right tools makes a difference. A tool like Testpad makes it easier to organize, execute, and report on your testing. With Testpad, you can maintain the creativity and flexibility of exploratory testing while also meeting the practical demands of project management.

If you’re ready to see how Testpad can support your testing efforts, sign up for a 30-day free trial.

Migrate Your Test Cases to Testpad in Minutes with Our Custom GPT

Stefan Butlin — Wed, 25 Mar 2026 00:00:00 +0000

Getting your test cases into Testpad is simple, but if you've exported them from a different tool or spreadsheet, they might need a little reformatting first. Our custom GPT handles that in about five minutes – just paste your tests in, review the output, and import.

Here's what you do:

Copy your existing test cases
Paste them into our custom GPT
Tell it "Convert to Testpad format" – and optionally give it hints about what you'd like to keep, discard, or change
Review the output (takes about five minutes)
Paste into Testpad
If it's not quite right, tell the GPT what to do differently and repeat

The custom GPT handles the formatting grunt work. You just check it makes sense and adjust anything that doesn't.

Quick reference: Import workflow

Copy test cases from your current tool
Paste into custom GPT
Say "Convert to Testpad format"
Review output (5 minutes: cut irrelevant, add missing tests)
Paste into Testpad
Verify the structure imported correctly

The custom GPT handles formatting. You handle making sure the tests are actually useful for your product.

What happens when you import test cases?

The custom GPT takes your existing tests and converts them into Testpad's outline structure.

Your spreadsheet might have:

Test ID	Feature	Steps	Expected result	Priority
TC–001	Login	1. Navigate to login page 2. Enter valid credentials 3. Click submit	User successfully logs in	High

Here's one example, though the output will vary depending on your input and what you ask for:

Login
  Valid credentials log user in successfully
  Invalid password shows error message
  Locked account displays warning

By default, it focuses on what to check – stripping out metadata like test IDs, dates, and priorities. If you want to keep any of that, just ask.

What you need to review

The custom GPT gets you about 90% there, but you still need to:

Cut irrelevant tests – It converts everything from your spreadsheet. Remove tests that don't apply to your current testing needs.

Add missing details – Your old tests might not cover edge cases you've discovered since. Add them now.

Adjust prompt style – The GPT creates brief, exploratory-style prompts. Make them more or less detailed based on who's testing.

Check grouping – Sometimes the logical structure doesn't match how you test. Reorder to match your workflow.

This takes about five minutes per script. Compare that to manually reformatting tests (20–40 minutes per script).

How does importing actually work?

Testpad reads indented text and converts it automatically. When you paste the custom GPT's output:

Lines without indented lines beneath them are test rows
Lines that have indented lines beneath them become section headers
Double hyphens (--) or double slashes (//) mark comment rows – useful for notes, example values, or requirements IDs
Further indentation creates nested structure

The custom GPT already knows this format, so the output pastes cleanly.

Import tips

Test with a small section first for large scripts
Keep test prompts on single lines
Nothing needs bullets – just plain text and indentation
Consistent spacing matters (2–4 spaces per level)

What if I'm converting from detailed test cases?

The custom GPT takes its cue from your input. If your existing tests look like formal test cases – preconditions, steps, expected results, metadata – the output will reflect that structure, just converted into Testpad's lighter outline format.

If you'd rather end up with shorter, exploratory-style prompts, you need to ask for that specifically. Something like "convert these to brief Testpad prompts and strip the formal structure" works well.

Don't assume it'll simplify everything by default. Give it direction and it'll follow.

Can I import from multiple formats?

Yes. The custom GPT handles:

Excel or Google Sheets (copy the cells, paste them in)
CSV files (paste the raw content)
Test case management tools like TestRail or Zephyr (export to text, paste)
Word documents (copy the tests, paste)
Even screenshots of tests (though text works better)

Just copy what you have and let the GPT figure it out. If it doesn't do exactly what you wanted, add a few instructions and try again.

What if my tests are organized into groups and subgroups?

The custom GPT preserves logical grouping while simplifying format. If your tests are organized by feature → user story → test cases, that structure survives the conversion.

Your tool has test cases organized as:

Feature: User Profile
Story: Update Email Address
TC–100: Valid email format accepted
TC–101: Invalid email format rejected
TC–102: Duplicate email shows error
Story: Change Password
TC–200: Strong password accepted
TC–201: Weak password rejected

Custom GPT converts to:

User Profile
  Update email address
    Valid email format accepted
    Invalid email format rejected
    Duplicate email shows error
  Change password
    Strong password accepted
    Weak password rejected

Same logical structure, just cleaner.

Do I need a ChatGPT account?

Yes, but free accounts work fine. The custom GPT is available here once you're logged in.

If you've got a paid ChatGPT account, it'll process faster and handle longer inputs, but the free tier handles typical test script imports without issues.

Can I use other AI tools instead?

You can use regular ChatGPT, Claude, or any AI tool, but you'll need to explain Testpad's format every time.

With the custom GPT: "Convert these to Testpad format" + paste your tests

With generic AI: "Convert these test cases to an outline format suitable for Testpad. Use indentation to show hierarchy, with top-level sections unindented, subsections indented with 2–4 spaces, and individual test prompts marked with '-'. Keep prompts brief and exploratory rather than detailed step-by-step instructions. Here are my tests: [paste]"

The custom GPT saves you from repeating those instructions each time.

Bear in mind you may need a few rounds of back-and-forth to get the formatting right – generic AI tools can be unpredictable around spacing, bullets, and blank lines.

What if the import doesn't look right?

Two things usually cause issues: the formatting of the output, or how the GPT interpreted your input.

If it's a formatting problem, check that:

Spacing is consistent (all indents use the same number of spaces)
No tabs mixed with spaces
Nothing has bullets

If the structure or content isn't what you wanted – wrong grouping, wrong level of detail, tests that miss the point – paste the problem section back into the custom GPT and give it more specific instructions. That usually sorts it.

Should I import everything from my old tool?

Migration is a good moment to think about what you actually use. Tests for deprecated features, scripts no one ever runs, duplicates that built up over years – none of that needs to follow you into a new tool.

Bring forward what's useful and leave the rest behind.

Wait – do you even have Testpad?

If you're reading about importing test cases to a tool you don't have yet, maybe try us? Start your free 30-day trial – no credit card needed.

Guest Testing: Anyone Can Help When the Pressure is On

Stefan Butlin — Wed, 18 Mar 2026 00:00:00 +0000

Invite guest testers to help you run your tests. Perfect for asking clients to perform User Acceptance Testing, as well as just roping in more help when you're late for a release.

This article explores Guest Testing, one of Testpad's most powerful features for expanding your user testing capacity quickly and easily. Before diving into how it works, let's briefly look at what makes Testpad different from traditional UAT testing tools.

Why choose Testpad for software testing?

Testing doesn't have to be complicated. At its core, testing is about learning what state your product is in so you can make informed decisions. Testpad embraces this simplicity with a pragmatic approach built around intuitive checklists rather than rigid test cases.

Think of Testpad as a streamlined alternative to traditional software test management tools. Instead of forcing you to create detailed test cases with formal steps and expected outcomes, Testpad lets you work with simple test prompts and test scripts that guide exploration. This makes it incredibly quick to write test plans and even quicker to execute them.

The result? More time actually testing your software, less time wrestling with documentation and process.

This philosophy of simplicity extends to all of Testpad's features, including Guest Testing.

What is Guest Testing in UAT?

Guest testing is the heart of how Testpad handles UAT: the people accepting the software just open a link.

Guest Testing does what it says on the tin: you can invite guest users to help make test runs, testing your software as prompted by your test plan and recording results – but the key point is that guest testers don't need logins to your Testpad workspace. You invite them by email and a special link gives them time-limited read-only access to just the test plan or test script that you've invited them to help test.

Why Guest Testing Matters

Guest Testing is helpful in many scenarios, including:

Getting extra help at release time from outside the test team: developers, managers, business stakeholders, friends...
Involving clients in testing - fantastic for de-risking delivery and building trust
User acceptance testing - involving clients again, but the more formal (or not) version where the test plan is being used explicitly to prove (or not!) the software is ready
Restricting visibility of test plans containing sensitive content, because guests can only access the one test plan (script) they were invited in for

Preparing for Guest Testing

1. Test Runs

Test results in Testpad are recorded in columns to the right of test prompts. Each column is to record a different set of results against the same prompts (although filters could be used to vary the subset that's actually tested). Columns are mostly used to establish test runs against different environments such as different browsers for webapps, or different phones for mobile apps. Columns can also be used for the same environment but for different testers (you get a higher chance of finding bugs if different brains can look at the same test ideas).

2. Assigning to Guest

For guest testing then, you initiate the process by assigning a Test Run (column) to "Guest".

Test Run assigment is managed in the Test Run details dialog which you open by any of:
- creating a new test run (which auto opens the dialog for the new test run)
- right clicking on the header of a test run column and selecting edit details
- hovering over the header of a test run and clicking on the pencil icon (edit)

Test Run assigment is only available for Test Runs that are still "IN PROGRESS" (as opposed to "COMPLETED"). So if you can't see the assignment drop-down box, that'll be because the test run is already completed! In which case, why would you be trying to assign it to someone else? :)

When the dropdown box is used to select "Guest" as the assignee, a button below appears for composing and sending an email. Use this button to address, and optionally edit the contents of, an invitation email that will give the recipient a link they can click on to make the test run.

3. Email Invitation

The recipient of the email will get a link, like a document sharing link, that gives them some restricted access into your testpad account. Specifically, they get read-only access to that one test plan (script) to record results against that one test run (column).

For practice, you can send guest test invitations to yourself to see what the experience is like. Though note that clicking on a guest link will log you in as Guest... which means logging you out as your normal user.

Top tip: for practicing with guest testing, open the guest test links in a different browser. That way you can stay logged in in your usual browser.

4. Performing guest test runs

This doesn't really need description - which is the whole point!

1. Click on the link you received.
2. Follow the test prompts.
3. Record appropriate comments and the pass/fail status.

Simples.

Well, OK. The simplicity here will depend on your test prompts and the complexity of your software under test. Testpad does it's bit to not add to the complexity however, reducing the task to prompting and recording results.

If your prompts are more exploratory in style, i.e. they're not full of detailed instructions to do this, then that, then that, then expect exactly this and that; but instead suggest looking at e.g. unicode input in the login page, or forgotten passwords for returning users, then they will need the Guest Testers to engage brain and be imaginative in what they actually test.

UAT Testing for Mobile

Lastly, don't miss that Guest Testing links can be opened on mobile devices as well as desktop devices. On most tablets and mobile phones, you get a mobile version of the testing interface. Being prompted for and collecting results on a separate device can be very practical; it saves the tester from constant context switching on their main screen between the app under test and the test mgmt tool.

Any questions about how any of this works, please don't hesitate to contact support@testpad.com.

Happy (guest) testing.

PS. Guest Testing is a premium feature available from the Team Plan and upwards. However, it is available in the Free Trial, so give it a go and see for yourself how convenient it is to bring in extra, or even external, help when the pressure is on to make a release. And while you're trying it out, experience firsthand how Testpad's practical approach to test management can make your entire testing process more efficient and effective.

Manual testing: the complete guide

Stefan Butlin — Tue, 17 Mar 2026 00:00:00 +0000

All manual testing means is that a human interacts directly with software to check it works. There are no automation frameworks involved, just a tester, the product, and a list of things to check. This guide covers the types of manual testing, when to use each one, how to plan your sessions, and which tools help.

At a glance

Manual testing is a human checking software directly: a tester, the product, and a list of things to check
The main types: exploratory testing, regression testing, user acceptance testing (UAT), and smoke testing
Manual wins where judgment matters: new features, user experience, and anything that changes too often to automate cheaply
A checklist of test prompts usually beats detailed test cases: faster to write, and it covers more ground
A useful test report shows what was tested, what passed and failed, any issues found, and who ran the tests

Most teams already do manual testing without calling it anything formal: if you've ever clicked through a new feature to see if it behaves as expected, you've done it. This guide is about doing it deliberately. (For a step-by-step intro, see how to get started with manual testing.)

What are the different types of manual testing?

Most of the testing your team does probably falls into one of four categories. Understanding the difference helps you use each one at the right time.

Exploratory testing

Exploratory testing is the most valuable kind of manual testing. James Bach describes it as performing tests while learning things that may influence the testing: testers interact with the product freely, inventing test ideas as they go, reacting to what they find, and following interesting leads. There's no rigid test case telling you exactly what to click, just a set of areas to investigate and a tester using their judgment to poke around.

This is where the bugs that automated checks miss tend to show up. Automation only catches what it's programmed to look for. A human tester will spot the thing that just feels wrong, or notice that two features interact in a way no one considered.

Regression testing

Regression testing checks that things which worked before still work now. Every time your team fixes a bug or ships a feature, there's a risk that something else breaks unnoticed. Regression tests are your safety net.

The common assumption is that regression testing has to be automated. Automating the stable, frequently-run checks is worth it, but a manual regression list has one advantage automation can't match: immediacy. The moment you fix a bug, you add a test for it, and that test protects the very next release with no automation project to wait for. In Testpad, you start with a handful of prompts and add a line every time you fix a bug. The list builds itself over time.

User acceptance testing (UAT)

UAT verifies that software does what it was supposed to do for the people it was built for. In client projects, that usually means the client checking the product before signing off. For product teams, it means testing against real user scenarios.

UAT doesn't require an elaborate setup. It requires clear test scenarios and a straightforward way for testers or clients to record what they find. Testpad's guest access lets clients log results without needing an account; you just give them a link.

Smoke and sanity testing

Before investing time in detailed testing, it's worth checking that the basics work. Can you log in? Does the main page load? If the answer is no, there's no point running anything else yet.

Smoke testing and sanity testing mean essentially the same thing (the ISTQB glossary lists them as synonyms): a quick check of the main functionality before planned testing begins. A short checklist of critical paths, run in a few minutes at the start of each session, is enough.

When does manual testing outperform automation?

The short answer: more often than most teams expect.

Automation is good at repetitive checks. It can run the same test a thousand times and never get tired. But it can only test what it's been explicitly told to look for. It has no intuition, no curiosity, and no ability to notice that something feels off even if it technically passes.

Manual testing is the better choice when:

You're testing something new and don't yet know what "correct" looks like
The interface or user experience is what's being evaluated
You're doing exploratory work to understand the product's real state
The feature changes often, making automation expensive to maintain
You need a human to verify something works in context, not just technically

The two approaches work together rather than compete. Even Google's DORA research, which makes the case for automating your regression suite, recommends that teams keep doing exploratory, usability, and acceptance testing manually throughout delivery. And if the question on your mind is AI rather than automation, we take that one on in why manual testing matters.

How do you plan manual testing effectively?

A test plan for manual testing is essentially a list of things to check. The goal is to capture enough detail that testers know what areas to cover, without prescribing exactly how to test each one.

The most practical format is a checklist of test prompts: short, specific ideas that direct a tester's attention without turning testing into a box-checking exercise. "Check password complexity rules" is a better test prompt than either "test login" (too vague) or a five-step test case with expected outputs (too rigid).

Good test plans:

Use prompts rather than step-by-step instructions
Group related tests together in a hierarchy
Go into more detail in risky or complex areas
Evolve over time as you find and fix new issues

Checklists or test cases: which should you use?

Test cases are detailed: steps, expected outcomes, preconditions. Checklists are lightweight: a list of things to investigate. Neither is universally better.

	Checklist of prompts	Detailed test cases
Best for	Exploratory work, fast-moving features, testers who know the product	Compliance work, precise verification, testers new to the product
Speed to write	Minutes per area	Hours per feature
When the product changes	Edit a line	Rework steps and expected results
What gets recorded	What was checked, results, comments	The same, plus the prescribed steps
In Testpad	One test per line of plain text	Indent under a title row: steps, expected results, preconditions if needed

Use test cases when you need a record of exactly what steps were performed, or when you're testing something with precise compliance requirements. Use checklists when you're moving fast, testing exploratively, or working with testers who know the product well enough not to need hand-holding.

Most teams default to test cases out of habit rather than necessity. For the majority of manual testing, a well-written checklist covers more ground in less time.

How do you track and report on manual testing?

Testing without records isn't testing; it's hoping. Even a simple pass/fail note against each test prompt tells you something useful: what was checked, what worked, and what didn't.

Good manual test reporting doesn't need a lengthy summary document after the fact. A shared report that shows where testing has got to whenever someone looks beats any post-mortem write-up. Stakeholders can check progress for themselves, and issues surface during testing rather than days later.

What a test report needs to show:

What was tested
What passed and what failed
Any issues or comments captured during testing
Who ran the tests and when

That's it. The rest is optional. Testpad's Report view shows exactly this: a grid of pass/fail results against every test, with comments and issue numbers captured inline, shareable with stakeholders as a link.

What tools do manual testers need?

Manual testing doesn't really need much. A way to record what you're going to test, a way to capture results, and a way to share findings with the rest of the team.

Most teams start in spreadsheets. They work for simple setups, but they get unwieldy as test plans grow and teams need to track results across multiple releases or testers. Managing multiple test runs, filtering by environment, and sharing progress all require workarounds that waste time.

The traditional alternative is heavyweight test case management tools: formal, database-centric, and designed for teams with dedicated QA departments. For many teams, they're more process than necessary.

Tools like Testpad sit in the middle: a checklist-based approach that maps directly to how manual testing actually works. You have a list of things to check, you work through them, you mark pass or fail, and you capture any issues as you go. Anyone on the team can join as a guest tester without needing an account.

Key things to look for in a manual testing tool:

Quick to write and edit test prompts
Clear visual progress tracking
Easy to share results with stakeholders
Support for guest testers (for UAT or outsourced testing)
Reusable tests across releases

Make manual testing a habit with Testpad

Manual testing works best when it becomes a habit rather than a last-minute scramble. Start with the things most likely to break, build up your test prompts over time, and share results as you go.

If you want a tool that makes all of that easier without adding process for the sake of it, try Testpad free for 30 days.

Test planning: a practical guide

Stefan Butlin — Fri, 06 Mar 2026 00:00:00 +0000

Test planning is deciding what to test, how to test it, and who's doing it before a release. A good plan helps your team stay focused, catch the right problems, and ship with confidence – without needing weeks of documentation before anyone tests a thing. For most teams, that means a checklist, not a formal document.

At a glance

A test plan answers three questions: what are we testing, how are we testing it, and who's doing it by when?
A test plan covers this release; a test strategy is the ongoing approach. Many teams blend the two, and that's fine.
Useful plans cover scope, approach, what to test, environment, who's testing when, and exit criteria.
For most teams a checklist of test prompts beats a formal document. Detail pays off in regulated industries, on large teams, and for client sign-off.
The most common mistake is writing a plan nobody uses. Keep it short enough to shape what gets tested.

Most guides make test planning sound like a formal discipline; the rest of this one works through the practical version: what to include, how much detail you need, the approaches to cover, and a simple process to follow. See Test plans, not test cases for why we seem so biased for short prompts over formal cases.

What is test planning?

Test planning is the process of figuring out what needs testing before a release, and making sure it actually gets tested.

At its most basic, a test plan answers three questions:

What are we testing?
How are we going to test it?
Who's doing it, and when?

The answer to those questions might fit on half a page, or it might fill a detailed document – depending on what you're building and the stakes involved. The format matters much less than the thinking behind it. James Bach's Test Plan Evaluation Model makes the same point: a test plan is "the set of ideas that guide or represent the intended test process", and those ideas are often only partially documented. In Testpad, that thinking lives in a checklist: a structured list of what to cover, organized however makes sense for your product.

What's the difference between a test plan and a test strategy?

These two terms get confused a lot, and the distinction is worth knowing – but it's not something to stress over.

A test strategy is the big-picture approach: what testing philosophy your team follows, what types of testing you do, and how testing fits into your development process overall. It tends to stay relatively stable across projects. A test plan is release-specific. It covers what needs testing right now, for this version of the product. It's operational, not philosophical.

In practice, many teams blend these together – especially smaller teams without a formal QA function. If you're writing one document that covers both how you approach testing and what you're testing this sprint, that's fine. The label doesn't matter. What matters is that someone on the team has thought it through.

	Test plan	Test strategy
Scope	This release	The product or team, ongoing
How often it changes	Every release	Rarely
Who writes it	Whoever owns the release: a QA lead, PM, or developer	A QA manager or test lead
Typical length	Half a page to a few pages	Can be a formal document
Typical content	What to test, who's testing, by when	Testing approach, types of testing, tools

What should a test plan include?

There's no universally required format, and anyone telling you otherwise is probably selling heavyweight, traditional test management software with features you may not even need.

That said, a useful test plan generally covers:

Scope – What features, workflows, or areas of the product are in scope for this release? What's explicitly out of scope? Being clear about this prevents both under-testing and wasted effort.

Approach – Are you doing exploratory testing, working from detailed test cases, or a mix? Will any of it be automated? Are you doing regression checks on previously tested areas?

What to test – The actual list of things to check. In Testpad, this is a checklist of test prompts – specific enough to direct attention, loose enough to leave room for testers to use their judgment. You can add as much or as little detail as the situation calls for.

Environment – Which browsers, devices, or configurations do you need to cover? What's your test environment, and is it set up before testing begins?

Who's testing and when – Not every team needs formal assignments, but someone needs to know they're responsible for testing before a release happens.

Exit criteria – When is testing done? "When all tests pass" isn't always realistic. A clearer threshold might be: all critical paths pass, no high-severity bugs are open, and the known issues have been assessed and accepted.

How detailed does a test plan need to be?

It depends on the context but generally speaking, probably less detailed than you think.

For most teams releasing software regularly, an exhaustive test plan document is overkill. The time spent writing it is time not spent testing. A checklist-style plan covering the most important areas, updated between releases, is often far more useful than a carefully formatted document that nobody reads. That's the approach Testpad is built around – plans your team will maintain and use, rather than ones that exist for their own sake.

The cases where more detailed plans help:

Regulated industries like healthcare and finance often require formal test documentation for compliance purposes – there's even an international standard, ISO/IEC/IEEE 29119-3, that specifies the templates
Large teams when testers need to divide work precisely and more structure prevents duplication and gaps
Teams that release rarely and test extensively benefit from detailed plans because the testing window is long
When a client needs to verify and sign off that testing was completed before accepting a deliverable

For everyone else – especially agile teams shipping regularly – a lighter touch works better. The goal is clarity, not comprehensiveness.

What testing approaches should your plan cover?

Most test plans should account for at least some combination of the following.

Exploratory testing

Exploratory testing is where testers investigate the product freely, inventing tests as they go based on what they're seeing. It's not unstructured – good exploratory testing is focused and deliberate – but it doesn't lock testers into a fixed set of steps.

This is often the most useful form of manual testing. An experienced tester using exploratory testing techniques can cover more meaningful ground in two hours than a day spent stepping through rigid test cases.

Testpad is particularly well-suited to exploratory testing. Rather than forcing testers through step-by-step instructions, it uses test prompts – specific areas to investigate, without dictating exactly how. Testers record pass/fail against each prompt and add notes where needed. You get a clear picture of what was covered without losing the freedom to react to what you find.

Regression testing

Every time you fix a bug or ship a new feature, you risk breaking something that worked before. Regression testing is checking that previously working functionality still works. You don't need to re-test everything every release – that's rarely practical. A focused regression suite covering critical paths and historically buggy areas is usually enough. In Testpad, you can build that suite up gradually over time, reusing tests across releases rather than starting from scratch each time.

Detailed test cases

Some testing calls for detailed test cases with specific steps and expected outcomes. They're slower to write and maintain, but useful when precision matters – verifying a specific acceptance criterion, documenting compliance testing, or onboarding new testers who need more guidance. In Testpad, you use indentation to build them: a title row, some rows for each step, some rows for expected outcomes.

Automated testing

If you have automated tests, your test plan should account for what they cover, and what they don't. Automation doesn't replace manual testing. It's good at checking the same things repeatedly, quickly. It's poor at catching unexpected behavior, usability problems, and anything that requires human judgment. Google's DORA research draws the same line: even teams with mature automation still perform manual activities like exploratory and usability testing throughout delivery. Testpad covers the manual side of that picture.

What does the test planning process look like?

Here's a practical process for teams that don't have a formal QA function, or for those who just want to keep things simple.

Start with what's changed

A test plan doesn't need to cover your entire product every release. Start by listing everything that's new or different since you last tested: new features, modified functionality, bug fixes that could have side effects. That's your starting point.

Add the critical paths

On top of changes, every plan should include the flows that matter most to users – login, checkout, core workflows – regardless of whether they changed. These are the areas where a bug has the highest impact.

Use a mind map to think through coverage

Before writing test cases or prompts, sketch out the testing areas as a mind map. Start with the main features, branch out to edge cases, integrations, and user roles. It's a fast way to spot gaps before you commit to a list. Testpad's outline structure maps naturally to this. It’s the same branching structure as a mind map, just in a format you can run tests against.

Decide on your format

Will you use detailed test cases, test prompts, or a simple checklist? The right answer depends on who's testing and how much guidance they need. Developers testing their own work probably need a checklist. Guest testers or UAT participants might need more detailed instructions. Testpad handles both – you can keep it brief or add detail where it's useful, without changing tools.

Assign and schedule

Who's testing, in which environment, and by when? Even a quick note against each testing area helps. It prevents the classic scenario where everyone assumed someone else was testing the payment flow.

What tools do you need for test planning?

The tool that works is better than the theoretically correct one you never finish setting up.

Spreadsheets work for simple testing. Google Sheets or Excel can handle a checklist of test cases and a column for results. The limitations show up fast though. There’s no easy way to run the same tests across multiple environments and no clear reporting on what passed and what didn't – but for a small team doing occasional releases, they're fine.

Test management tools are worth it once you're doing regular releases and spreadsheets get messy. Traditional test case management tools – built around formal test cases with extensive metadata – suit process-heavy environments, but can be more than most teams need.

Testpad sits in the middle. The checklist-based approach means anyone on the team can jump in and start testing without training or setup. You can run the same tests across different browsers, devices, or builds, with each run a new column against the same list of tests. The grid that builds up shows anyone who looks what's been covered and what's still to do – all without needing a QA specialist to configure things first.

What are the most common test planning mistakes?

Even straightforward test plans go wrong in predictable ways. Knowing what to watch out for is half the battle.

Testing everything equally – Not all features carry the same risk. Spending as much time testing a minor UI tweak as a payment integration is a poor use of testing time. Prioritize based on impact.
Writing test plans nobody uses – A detailed document that lives in a folder and doesn't guide actual testing isn't a test plan, it's busywork. If your plan isn't shaping what gets tested, simplify it until it does.
Treating the plan as fixed – Testing often reveals things that change priorities mid-session. Good test planning leaves room for testers to react to what they find, not just step through a fixed list.
Skipping regression testing – It's easy to focus entirely on new features and forget to check whether existing functionality still works. Even a brief regression pass catches the most embarrassing kind of bug.
Not defining done – Without exit criteria, testing just…stops when time runs out. Decide upfront what "ready to ship" looks like.

Testpad was built for easy test planning

Test planning doesn't need to be a project in itself. A clear list of what to test, the right level of detail for your context, and someone responsible for doing it – that's most of what you need. Testpad makes it easy to build and run test plans without the setup time of traditional tools. You can start with a checklist and add structure as you need it. Try it free for 30 days.

What is the software testing process?

Stefan Butlin — Thu, 05 Mar 2026 00:00:00 +0000

The software testing process is the sequence of activities your team uses to check that software works correctly before shipping. It typically covers five phases: planning, preparation, execution, reporting, and closure. The level of formality varies by team size and industry, but the core activities are the same whether you have three people or thirty.

At a glance

The software testing process covers five phases: planning, preparation, execution, reporting, and closure
Not every team needs all five; small teams often collapse planning and preparation into a quick discussion
Every team does the same essential tasks: decide what to test, write test prompts, track results, log bugs, retest fixes
Match the formality to your context: startups stay lightweight, regulated industries need documented evidence
Start simple and add structure only when its absence causes real problems

The rest of this post covers each phase, the essential tasks behind them, the mistakes to avoid, and how formal your process needs to be.

Typical software testing explanations rely on complex diagrams, formal phases, and lengthy approvals, making the process seem rigid and linear. That might suit large, regulated projects, but for many teams it’s overkill. In reality, testing adapts to the team. Small teams test continuously as features are built. Larger teams may have defined phases but still adjust as they go. Startups often keep things informal, while enterprises rely on detailed strategies. What matters isn’t the methodology. It’s consistently answering “does this work?” and “are we ready to ship?”

What is the software testing process?

The testing process is the sequence of activities your team does to confirm software works correctly. The core activities involved often get broken down into phases: planning, preparation, execution, reporting, and closure. Not every team needs all five. Even the ISTQB Foundation syllabus, the industry's formal reference, says these activities are "often implemented iteratively or in parallel" and that the process "can be tailored to a given situation".

Think of it like checking a house before moving in. You walk through rooms looking for problems, make a list of what's broken, prioritize what needs fixing immediately versus what can wait, and decide whether it's livable or needs more work. The testing process works the same way: you're systematically checking your software, documenting problems, and helping stakeholders decide if it's ready.

The complexity varies wildly between teams. A three-person startup testing a web app has a very different process than a hundred-person team building medical software. But the core activities remain similar.

What are the main phases of software testing?

The main phases of software testing are test planning, preparation, execution, reporting, and closure. Even though testing processes vary from team to team, the work itself usually follows this basic flow. Teams just apply it differently depending on their situation.

Test planning

Deciding what needs testing and how you'll approach it. For simple projects, this might just be a quick discussion about priority areas. For complex projects, it might involve formal test plans documenting strategy, scope, and resource allocation.

Key activities:

Identify what needs testing (features, workflows, integrations)
Decide testing approach (exploratory, scripted, automated)
Determine who's testing and when
Plan the necessary test environments

Some teams skip formal test planning entirely and just discuss priorities before each release. That works fine if everyone understands what matters most.

Test preparation

Getting ready to actually test. This means setting up environments, creating test data, writing test instructions if needed, and making sure testers have access to what they need.

Key activities:

Set up test environments
Create or refresh test data
Write test cases or test prompts if using them
Configure any tools or tracking systems

How much preparation you need depends on your testing approach. Teams doing exploratory testing need less upfront work than teams following detailed test scripts.

Test execution

Actually testing the software. Testers work through features, try different scenarios, document what they find, and log bugs when things break.

Key activities:

Run through test cases or explore features
Try normal use cases and edge cases
Document what works and what doesn't
Log bugs with enough detail for developers to fix them
Retest fixes to verify they work

This is where most testing time gets spent. The goal is discovering problems while there's still time to fix them.

Test reporting

Communicating what testing found so stakeholders can make decisions. At minimum, this means showing what's been tested, what's broken, and how serious the problems are.

Key activities:

Summarize testing progress (what's covered, what's left)
Report bugs found and their severity
Highlight blockers preventing further testing
Provide overall quality assessment

Good test reports answer the question "are we ready to ship?" without asking stakeholders to dig through raw test results.

Here’s how to carry out simple test reporting that actually works.

Test closure

Wrapping up testing for the current release. This means double-checking that the big bugs are fixed, saving results for later, and noting what worked (and what didn’t).

Key activities:

Verify all critical bugs are resolved
Archive test results
Document what worked and what didn't
Update regression tests with new checks

Many teams skip a formal closure, and that's fine if you're tracking the important stuff (fixed bugs stay fixed, lessons get applied next time).

What does every team's testing process include?

Every team's testing process includes the same essential tasks: deciding what to test, creating test instructions, tracking coverage, logging bugs, retesting fixes, and building regression checks. The phases above give a flexible outline, but these are the steps teams always take to make sure the software works:

Deciding what to test

You can't test everything, so you need to focus on what matters most. This usually means:

Core functionality users depend on
New features in the current release
Areas with history of problems
Integrations with other systems
Critical user workflows

Small teams often do this through quick discussions. Larger teams might maintain formal test plans or requirement traceability matrices.

Creating test instructions

Teams handle test instructions in different ways: some write detailed test cases, some give short prompts, and some just trust testers to know what to do. The right approach depends on your context. Teams with experienced testers doing exploratory work need less documentation, whereas teams with less experienced testers or more compliance requirements need more structure.

Tracking what you've tested

Knowing what's been checked and what hasn't prevents gaps in coverage. That could be via a test management tool, a spreadsheet, or just checkboxes, whatever works for your team. Many teams find that tools like Testpad give them a good balance of simple and structured. The important thing is being able to answer "what have we tested?" and "what's left to test?"

Logging bugs

When you find a problem, record it so developers can fix it. A solid bug report covers what you were doing, what broke, how to reproduce it, and why it matters. You can track bugs in Jira, GitHub, a spreadsheet – basically whatever fits your team.

Retesting fixes

After developers fix bugs, verify the fixes actually work and didn't break anything else. This prevents the embarrassment of shipping software with "fixed" bugs that still occur.

Building regression checks

Every time you fix a significant bug, add a test to catch it if it resurfaces. Over time, this builds a safety net preventing old problems from reappearing. Regression testing doesn't have to be automated to be valuable. Manual regression checks work fine, especially for tests that are difficult to automate.

What mistakes do teams make with their testing process?

The most common testing process mistakes are adding too much process too early, testing everything equally, skipping basic checks, neglecting regression tests, and communicating results poorly. Understanding these helps you catch problems sooner and spend your time testing smarter, not harder.

Too much process too early

Teams new to testing often implement heavyweight processes before they need them. Formal test plans, detailed test cases and complex workflows slow things down without adding value for small projects. Start simple and structure only when you actually need it.

Testing everything equally

Not all features deserve equal testing attention. The login system matters more than the rarely-used admin panel. Recent changes need more scrutiny than stable code. Focus testing effort where problems would hurt most.

Skipping basic checks

Teams sometimes jump straight to testing new features without verifying basic functionality works. If core features are broken, there's no point testing anything else. Always do sanity testing first.

No regression testing

Fixing bugs without adding checks to prevent reoccurrence means the same bugs keep coming back. Every time you fix something significant, add a test for it.

Poor communication

Testing finds problems so they can be fixed. If test results don't reach the people who need them, or bug reports lack detail developers need, testing effort gets wasted. Clear, concise reporting matters as much as thorough testing.

How formal should your testing process be?

The right amount of process depends on your situation:

Context	Recommended formality	Key focus
Startups and small teams	Minimal	Quick planning discussions, light documentation, simple bug tracking
Growing teams	Moderate	Written test instructions, clearer roles, better tracking
Regulated industries	High	Documented test plans, traceability, audit evidence
Mature products	Moderate to high	Strong regression testing, stability over new-feature exploration

Startups usually get by with quick planning discussions and exploratory testing with light documentation. Growing teams benefit from more structure as coordination becomes harder, since written test instructions and better tracking prevent things falling through gaps. Healthcare, finance, and other regulated sectors need documented evidence that testing happened. And mature products with established user bases need strong regression testing to avoid breaking existing functionality.

Start with what you need and add structure when specific problems crop up, rather than trying to use certain processes just because other teams use them.

Getting started with a testing process

If you’re new to structured testing, start simple:

For your next release:

List the three most important features to test
Decide who’s testing and when
Create a simple checklist of what needs checking
Work through it and document what breaks
After shipping, review what worked and what didn’t

That’s a testing process. Everything else is just refinement.

As your team grows:

Add more detail to test instructions when needed
Improve tracking when you can’t answer “what’s been tested?”
Formalize planning as coordination gets trickier
Build regression checks for recurring bugs
Introduce automation when manual testing slows you down

Forget perfect processes at the start and just focus on catching problems before your users do.

Tools for managing the testing process

The right tools depend on your needs:

Starting out: Spreadsheets work fine for simple testing. They're familiar, flexible, and free.

Growing teams: Dedicated test management tools help organize testing at scale. Traditional test case management tools suit process-heavy environments. Lighter tools like Testpad offer middle ground: more capable than spreadsheets but without heavyweight complexity.

Development platforms: Many teams use integrated tools (Jira, GitHub, GitLab) that combine test tracking with bug management and project planning.

Choose tools that fit how your team actually works, not how you think testing should work.

Remember to start simple

The software testing process isn't about following a specific methodology or using particular tools. It's about consistently answering "does this work?" and "are we ready to ship?" in a way that fits your team and situation.

Start simple, test the important stuff first and add structure only when you actually need it. Everything else is details.

Want practical testing advice delivered to your inbox? Subscribe for straightforward tips on making testing work better.

Types of software testing: Which one do you need?

Stefan Butlin — Fri, 27 Feb 2026 00:00:00 +0000

Software testing falls into a handful of main types: functional testing (does it work?), exploratory testing (human investigation), regression testing (does it stay working?), and non-functional testing (performance, security, usability). Most teams need just three to five of these, and which ones depends on your product's risks and your team's size.

At a glance

Every team needs basic functional testing, exploratory testing, and regression checks
Add performance, security, or UAT when your product's risks call for them
Unit testing and integration testing are mostly written and run by developers
Different teams need different combinations: a three-person startup has different needs than a regulated healthcare company
You don't need every type. Choosing a few and doing them well beats doing all of them poorly

The rest of this post covers what each type does, when it's useful, and how to choose the combination that fits your team.

New to testing? It might be worth checking out our overview of testing basics, first.

What is software testing?

Ask ten people what software testing is and you'll get ten different answers. But essentially, software testing is about discovering what state your product is in so stakeholders can make informed decisions. You're fundamentally answering two questions: "does this work?" and "are we ready to launch?"

What are the main testing approaches?

The main testing approaches are exploratory, regression, and sanity testing. These aren't features to check so much as strategies for organizing the work, and most teams use several.

Exploratory testing

Testers investigate the product guided by a lightweight plan or charter, using judgment to decide what to try within each area and reacting to what they discover. It's human investigation, not working through rigid, pre-written test cases.

Exploratory testing is usually the most effective kind of manual testing. Testers follow hunches, notice patterns and dig into suspicious behavior.

Regression testing

Checking that previously-fixed bugs stay fixed and working features keep working. Every time you fix a significant bug, add a test to catch it if it resurfaces.

Sanity testing

A quick check that basic functionality works before deeper testing. If users can't log in or the main page won't load, there's no point testing advanced features.

This is really just about using your common sense and checking the obvious things first.

What are the main functional testing types?

The main functional testing types are system testing, user acceptance testing, unit testing, and integration testing. Functional testing verifies your software's features work correctly. The ISTQB Foundation syllabus describes it as testing "what" the software should do, the basic "does it do what it's supposed to do?" testing.

System testing

Testing your complete product as users would actually use it. You're verifying the entire system works correctly in realistic conditions. Most testing is system testing even if teams don't call it that.

User acceptance testing (UAT)

Getting actual users or clients to verify the software meets their needs before you ship. Real users interact differently than your team does, use different environments and have different expectations. UAT catches issues internal testing misses.

Unit testing

Developers write automated tests for individual pieces of code to verify they work correctly. These tests catch bugs early but only check isolated pieces, not how they work together or how the complete product behaves. Martin Fowler's test pyramid recommends lots of these small, fast tests and far fewer whole-system ones, while noting that "even the most diligent test automation efforts are not perfect" and manual testing still belongs in the mix. Unit tests complement but don't replace testing the whole product.

Integration testing

Testing that different parts of your software work together properly: checking connections between services, APIs, or third-party tools. Most teams already do this as part of normal testing. If you're testing your product the way users actually use it, you're checking how parts integrate. Just make sure your testing covers connections between different parts of your system.

What is non-functional testing?

Non-functional testing checks qualities beyond whether it works, like whether your software is fast enough, secure enough, or easy enough to use. Where functional testing asks "what" the software does, the ISTQB syllabus sums up non-functional testing as checking "how well the system behaves".

Performance testing checks if your software is fast enough and stays stable under normal use.

Load and stress testing checks if your system can handle lots of users at once and finds the point where it breaks down.

Security testing looks for ways attackers could break in, from basic checks like encrypted passwords to advanced attempts at hacking the system.

Usability testing checks if people can use your software. Watch users try to complete tasks and note where they get stuck or confused.

Compatibility testing checks that your software works across the browsers, devices, operating systems, and hardware your users actually have.

Here's how the main types compare side by side:

Testing type	What it checks	Who usually runs it
Exploratory	Whatever human judgment says needs investigating	Testers
Regression	Fixed bugs stay fixed, working features keep working	Testers or automation
Sanity	The basics work before deeper testing starts	Whoever picks up the build
System	The complete product in realistic conditions	QA testers
UAT	The product meets real users' needs	End users or clients
Unit	Individual pieces of code in isolation	Developers
Integration	Different parts work together	Developers or QA
Non-functional	Speed, stability, security, usability	Specialists or tools

Which testing types does your team need?

Every team needs functional testing, exploratory testing, and regression checks; everything else depends on your product's risks. Testing types aren't a menu where you order everything. Instead, you just need to choose what will help you solve your actual problems.

Every team needs:

Basic functional testing (does it work?)
Exploratory testing (human investigation)
Regression checks (does it stay working?)

Add when relevant:

Automation for repetitive checks
Performance testing if speed matters
Security testing for sensitive data
UAT if delivering to clients

Consider skipping:

Formal methodologies for small teams
Extensive documentation nobody reads
Any testing type because "everyone does it"

The goal isn't testing everything. It's catching problems before your users do.

Getting started with software testing

Pick three features users care about most and make a simple checklist of what needs checking. Then work through it, write down what broke and fix it. That's testing. Everything else builds from there.

Want more practical testing advice? Subscribe to get straightforward tips on all things testing sent straight to your inbox.

Testpad now has an API

Stefan Butlin — Tue, 17 Feb 2026 00:00:00 +0000

Your automated tests are passing (200 checks, green lights everywhere), but your stakeholders are still asking "is it ready yet?" Your CI pipeline gives you a pass/fail summary. Your manual results are already in Testpad. But getting both into one clear view still means tool-switching, exports, or just…not bothering.

The Testpad API changes that. Now you can push your automated test results straight into Testpad, where they show up in the same format as your manual tests. More than just a "200/200 passed" in a text file, but actual visibility into what's working and what isn't, all in one place.

What's an API?

An API (Application Programming Interface) is essentially a way for different software tools to talk to each other automatically. Think of it as a bridge that lets you write simple scripts to move data between Testpad and your other tools with no manual downloading, uploading, or copy-pasting needed.

What the API does (and doesn’t try to do)

With the Testpad API, you can script in Python, JavaScript, or whatever language makes you happy to:

Push results in – feed your automated test outcomes straight into Testpad, right alongside manual runs.
Pull results out – extract real-time progress and outcomes to power your own dashboards or reports.

~~Coming soon: webhooks.~~ Webhooks now supported too. Fire off events from Testpad into Slack, Teams, or anything else that listens – perfect for notifying the team when test runs complete or triggering downstream processes.

Two big use cases we see already

1. Unified reporting
Your CI/CD pipeline runs automated tests. Your team runs manual ones in Testpad. Now you can pull both together into one view – push your key automated runs (release candidates, nightly builds, whatever matters to your process) straight into Testpad alongside your manual testing. There’s no need to juggle tools just to figure out whether you're ready to ship.

2. Custom dashboards
Need a big-picture exec summary? Want to track QA throughput week by week? Care about quality metrics over time? Use the API to pipe Testpad data into whatever reporting stack you already use.

How to get started with the API

For now, the Testpad API is available on request. If you want to try it out, reach out to us via support and we'll get you set up.

Once you have access, you'll need to generate an API token for authentication. Currently, only account owners can generate these tokens (we may expand this to account admins down the line, but for now we're keeping it limited to owners).

You'll find the full documentation at api-docs.testpad.com, where we walk through authentication, endpoints, and examples in Python and JavaScript.

Why this matters

The Testpad API is straightforward – a few clean endpoints that let you push results in and pull data out. It's built around how Testpad works, so if you understand Testpad's structure (projects, scripts, test runs), the API should feel pretty intuitive.

This is especially useful if your testing is already spread across multiple tools: unit tests in CI, manual checks in Testpad, managers asking for dashboards. Instead of forcing everything into one platform or manually cobbling reports together, you can now connect the pieces programmatically.

A shift for Testpad

The API documentation walks through authentication, endpoints, and examples in Python and JavaScript. It's a starting point – we'll add more capabilities as we see how teams use it and what's actually useful.

Want more practical testing advice? Subscribe to get straightforward tips on all things testing sent straight to your inbox.

14 Best test management tools for 2026

Stefan Butlin — Mon, 16 Feb 2026 00:00:00 +0000

Spreadsheets are a good place to start when you first get into testing, and for some projects it works perfectly fine. But as testing grows, spreadsheets quickly become a source of frustration. For instance, tracking a critical release across multiple spreadsheets often leads to overlooked bugs, miscommunication, and duplicated efforts. Collaboration suffers, progress tracking becomes difficult, and valuable information slips through the cracks.

That's when you switch to something simpler: a straightforward test management tool. The best tools bring order without headaches, offering just enough structure to keep tests organized and results easy to share – without forcing complicated processes on your team.

What is a test management tool?

A test management tool organizes and tracks your software testing efforts in one place. Instead of scattered spreadsheets, you get a single, reliable overview that everyone can trust. At a glance, your whole team knows what's been tested, what needs attention, and what's coming next.

Good test management tools become your team’s command center. They clearly document test cases, consistently track results, and answer essential questions:

What's been tested?
What passed?
What failed?
What still needs attention?

But it’s not just about managing tests. The real benefit is turning messy test data into straightforward, actionable insights. This helps your team quickly understand risks, identify gaps, and confidently prioritize what to tackle next.

Best test management tools for 2026

Every team has a unique way of testing. Below you'll find a rundown of popular tools, highlighting their strengths, pricing, and trade-offs. Choose one that fits your workflow without getting distracted by advanced features you'll never use.

Tool	Best for	Key features	Price per 10 users per month

TestMonitor	Structured issue tracking	Structured tests, robust defect reporting, integrations	$399
TestRail	Enterprise-grade test management	Advanced test cases, automation integration, detailed analytics	$370
Tuskr	AI-powered test management for agile teams	Unified testing, AI test case creation, CI/CD integrations	$75
PractiTest	Teams needing detailed analytics	Advanced dashboards, customizable workflows, deep insights	$390
Testmo	Agile teams with CI/CD integration	Unified test types, real-time reporting, agile workflows	$99
QMetry	Enterprises needing automation & scalability	Automation support, scalable test management, AI analytics	Contact sales
QAComplete	Full-cycle test & release management	End-to-end QA management, visual reporting, release tracking	Custom pricing; contact sales
Testiny	Small teams needing intuitive test tracking	User-friendly design, quick test creation, clear reporting	$185
qTest	Agile-Waterfall hybrid teams	Agile integrations, scalable test execution, flexible deployments	$1,000
Kualitee	Integrated defect & test management	Integrated defect tracking, reusable tests, clear reports	$120
Xray	Jira-centric teams	Deep Jira integration, traceability, automation support	$200+
Aqua Cloud	Comprehensive lifecycle & compliance management	Lifecycle visibility, compliance reporting, automation tools	Custom pricing; contact sales
Testomat	Automation-driven teams	Automation-centric workflows, simplified reports, CI integration	$300
Testpad	Teams seeking simplicity & pragmatism	Checklist-style tests, intuitive interface, lightweight execution	$99

TestMonitor

Best for: Teams needing structured issue tracking and test execution reports and insights.

TestMonitor emphasizes structured issue tracking and reporting, providing straightforward visibility into testing progress. It simplifies manual testing, allowing testers to clearly document results and share critical findings with stakeholders.

Key features:

Structured test case management: Manage and execute structured test cases.
Robust issue tracking: Track and report defects clearly, with detailed reporting.
Intuitive interface: Quick onboarding without extensive training.
Integration: Connects easily with Jira, GitHub, and Slack.

Pricing: From ~$130/10 users/month

Pros: Clear defect prioritization, strong communication capabilities

Cons: Interface and workflows may feel rigid for teams accustomed to exploratory testing

TestRail

Best for: Larger teams needing comprehensive test case management capabilities.

TestRail provides advanced, enterprise-level test case management and in-depth reporting capabilities. Designed for robust environments, it integrates seamlessly with automation frameworks and offers detailed analytics to keep large testing efforts organized. For how it stacks up against Testpad specifically, see Testpad vs TestRail.

Key features:

Advanced test case management & reporting: Detailed analytics, progress tracking, and reporting dashboards.
Integrations with automation tools: Supports Selenium, Cypress, and CI/CD tools.
Jira integration: Tight integration with Jira for streamlined workflows.

Pricing: From $370/10 users/month

Pros: Excellent support for large-scale projects, strong data-driven reporting capabilities

Cons: Higher complexity for smaller or less experienced teams

Tuskr

Best for: Teams looking for a capable, affordable alternative to TestRail – with AI features built in.

Tuskr is a cloud-based test management platform with a clean interface and a genuinely useful free plan. It's aimed at teams who want to bring manual and automated testing together without paying enterprise prices – and its use of generative AI to draft test cases from requirements sets it apart from most tools at this price point. For how it stacks up against Testpad specifically, see Testpad vs Tuskr.

The free plan covers all the core test management features for up to five users, five projects, and 1,000 test cases. API access, webhooks, and custom run statuses are available on paid plans.

Key features:

Unified view: Manage manual test cases, automated results, with real-time dashboards
Integrations: Integrations with Jira, GitHub, Slack, and major CI/CD pipelines
Simple text editor: WYSIWYG rich text editor with an intuitive interface
Generative AI Use AI for test creation and automatic workload balancing

Pricing: Paid plans from $9/user/month.

Pros: Affordable pricing, generous free plan, AI-assisted test case creation, clean and intuitive UI

Cons: Fewer native integrations than larger enterprise suites, API access and webhooks are paid-only

PractiTest

Best for: Teams requiring detailed visibility and extensive analytics.

PractiTest offers end-to-end visibility into testing processes, along with advanced analytics and customizable workflows. Ideal for teams needing detailed insights and structured reporting. For how it stacks up against Testpad specifically, see Testpad vs PractiTest.

Key features:

End-to-end visibility: Comprehensive tracking of testing activities and results.
Advanced dashboards & analytics: Customizable reporting, detailed insights, and trend analysis.
Customizable workflows: Adapt the platform to match your testing process.

Pricing: From $390/10 users/month

Pros: Advanced insights suitable for regulated or compliance-heavy environments, powerful tracking of detailed test histories

Cons: Learning curve can be steep for casual or occasional testers

Testmo

Best for: Agile teams seeking rich reporting and CI/CD integration.

Testmo blends manual, exploratory, and automated testing into a unified platform. It emphasizes real-time reporting, powerful integrations with automation tools, and continuous integration workflows. For how it stacks up against Testpad specifically, see Testpad vs Testmo.

Key features:

Unified testing platform: Combine manual, exploratory, and automation testing effortlessly.
CI/CD integrations: Works smoothly within agile workflows.
Rich reporting: Provides real-time status and historical insights.

Pricing: From $99/10 users/month

Pros: Single platform for all test types, effective visibility into agile workflows

Cons: May offer more complexity than smaller teams require

QMetry

Best for: Enterprises looking for AI-driven test management.

QMetry is built for agile and DevOps teams seeking enterprise-grade scalability. It leverages AI to support comprehensive test case management, automation integration, and detailed analytics. For how it stacks up against Testpad specifically, see Testpad vs QMetry.

Key features:

Full support for automation tools: Deep integration with popular automation frameworks like Selenium, Jenkins, and CI/CD tools.
Scalable test management: Robust handling of complex and enterprise-scale testing processes.
Intelligent analytics: Enhanced by AI-driven insights and recommendations.

Pricing: Custom pricing; contact sales.

Pros: Advanced capabilities powered by AI, handles complex enterprise scenarios well

Cons: May feel unnecessarily complex for smaller, simpler projects

QAComplete

Best for: Comprehensive test and release management.

QAComplete covers the entire testing lifecycle from test planning to defect tracking and release management. Ideal for teams needing a structured, comprehensive testing framework.

Key features:

Complete QA management: Covers test planning, defect tracking, and releases.
Visual reporting: Offers clear progress dashboards and metrics.
Robust integrations: Works well with other development and CI tools.

Pricing: Custom pricing; contact sales.

Pros: Strong support for comprehensive lifecycle management, integrates seamlessly into larger software projects

Cons: User interface can feel dated and overwhelming at times

Testiny

Best for: Small teams looking for intuitive test tracking.

Testiny is a user-friendly test management tool designed specifically to keep small teams organized. It prioritizes simplicity, enabling teams to document tests efficiently and share results without friction.

Key features:

Intuitive interface: Easy onboarding without complexity.
Fast test creation: Quickly define and document test cases.
Clear reporting: Straightforward progress tracking and reporting.

Pricing: From ~$185/10 users/month

Pros: Affordable entry point, Minimal learning curve

Cons: Reporting may lack depth for advanced needs

qTest

Best for: Teams managing complex agile projects and detailed test tracking.

qTest is an agile-focused test management platform that focuses on managing test suites, projects, and bug tracking. It provides comprehensive visibility throughout the testing lifecycle, which is helpful for teams dealing with frequent changes in requirements and complex project structures. For how it stacks up against Testpad specifically, see Testpad vs qTest.

Key features:

Agile integration: Seamless connection to Jira and agile workflows.
Scalable architecture: Supports larger teams and complex testing scenarios.
Flexible deployment: Cloud or on-premises solutions.

Pricing: Custom pricing; contact sales.

Pros: Adapts well to changing project methodologies, suitable for larger and more complex team structures

Cons: Requires more training for full adoption

Kualitee

Best for: Integrated test and defect management.

Kualitee blends test management with defect tracking in one accessible platform. It’s designed for smaller teams needing straightforward functionality without sacrificing detail.

Key features:

Integrated defect management: Track tests and defects side by side.
Reusable test repositories: Maintain consistency and reuse across projects.
Customizable reporting: Flexible insights and analytics.

Pricing: From $120/10 users/month

Pros: Budget-friendly for small teams, easy adoption without extensive training

Cons: Reporting may lack the depth required by larger teams

Xray

Best for: Teams deeply embedded within Jira.

Xray is a Jira-native test management tool ideal for teams already familiar with Jira workflows. It offers robust Jira integration and traceability within the Jira environment. For how it stacks up against Testpad specifically, see Testpad vs Xray.

Key features:

Jira-native: Deep integration and familiarity for Jira users.
Traceability: Complete tracking of requirements, tests, and issues.
Automation support: Strong links with automation frameworks.

Pricing: From $10/month/up to 10 users/month

Pros: Efficient for teams already familiar with Jira, Well-suited for agile workflows

Cons: Not ideal for teams outside the Jira ecosystem

Aqua Cloud

Best for: Comprehensive lifecycle management.

Aqua Cloud delivers end-to-end application lifecycle management with strong support for testing workflows, automated integration, and detailed compliance reporting.

Key features:

Lifecycle management: Full visibility into the testing lifecycle – from planning to deployment.
Compliance-ready reporting: Detailed audit trails and reporting.
Automation integration: Supports leading automation tools.

Pricing: Custom pricing; contact sales.

Pros: Ideal for industries with strict compliance, strong oversight of complex testing cycles

Cons: Complexity may overwhelm smaller or less structured teams

Testomat

Best for: Automation-driven teams looking for simplified management.

Testomat is geared toward teams that heavily automate tests and need a straightforward platform to track, manage, and report automated test results.

Key features:

Automation-centric: Optimized for automation workflows.
Simplified test reporting: Clear results tracking and communication.
CI integrations: Works smoothly with popular CI pipelines.

Pricing: From $27/user/month billed annually ($30/user/month billed monthly)

Pros: Highly effective for managing automated test suites, streamlined interface simplifies automation tracking

Cons: Lacks depth for manual testing needs

Testpad

Best for: Teams wanting a pragmatic alternative to spreadsheets and those incorporating exploratory testing.

Testpad is a modern test management tool built around straightforward checklist-style test plans. Instead of complicated workflows or rigid structures, Testpad scales naturally from spreadsheets without sacrificing simplicity. It’s especially suitable for exploratory testing, allowing testers to adapt quickly without unnecessary overhead.

Key features:

Checklist-style test plans: Execute tests through intuitive, easy-to-follow checklists.
Guest testing: Invite external stakeholders or clients for testing without additional hassle.
Simple, intuitive interface: Minimal setup; testers can begin immediately.
Fast test execution: Optimized for speed, letting testers document findings without interrupting their workflow.
Lightweight integrations: Easily connect results with issue trackers like Jira or GitHub, with an API and webhooks for building your own.

Pricing: From $99/month/10 users/month

Pros: Low learning curve, scales smoothly as your testing needs grow, ideal for flexible and exploratory approaches

Cons: Not ideal for environments needing extensive compliance documentation or detailed audit trails

Why are test management tools important?

Testing is ultimately an information service – it uncovers the state of your software and communicates that clearly to everyone involved. While specialized tools aren't mandatory from day one, once your testing outgrows spreadsheets, a dedicated test management tool becomes invaluable.

We've all experienced it – an important issue buried somewhere in scattered notes or hidden in an overlooked spreadsheet tab. A good tool prevents exactly that kind of oversight.

Here's what makes test management tools valuable:

Improved collaboration: Replace scattered notes and spreadsheets with a one-stop reference everyone can trust. Your entire team stays informed about what’s done, what's pending, and what's required next.
Consistency and repeatability: Clearly structured and reusable tests eliminate guesswork and repeated effort. Your team knows exactly what’s being tested, making expectations straightforward and outcomes predictable.
Greater productivity: Less administrative busywork means testers spend more time actually testing. Integrations with tools your team already uses – like Jira or GitHub – streamline your workflows.
Smarter choices: Easy-to-read reports transform raw results into useful insights. Stakeholders get a clear view of software quality, enabling confident choices about what's ready to launch and what needs attention.

How to choose the right test management tool

Selecting a test management tool doesn't need to be complicated. Keep it straightforward by considering these questions first:

What's your team size? Solo testers might do fine with spreadsheets. But once your team expands beyond a few people, a structured, practical tool becomes necessary.
What's your testing style? Do you focus mostly on exploratory, manual, or automated testing? Choose a tool that supports your approach without adding unnecessary hassle.
How detailed must your reporting be? Detailed analytics or strict compliance might demand a more robust tool. But if those aren't a priority, pick something simpler – avoid complexity you don’t need.
What's your budget and adoption timeline? Be realistic. Choose something practical your team can quickly adopt without major headaches or big upfront costs.

Most importantly, take advantage of free trials or demos – try before you buy. Hands-on experience with the tools will help your team quickly identify which solution aligns best with your workflow and preferences.

Common pitfalls when moving away from spreadsheets

When teams transition from simple spreadsheets to dedicated test management tools, a few common mistakes often arise:

Overestimating the need for features: Choosing a tool packed with unnecessary features can create complexity your team doesn't need – and might even slow you down.
Underestimating onboarding effort: Even straightforward tools require some effort upfront – don’t underestimate the onboarding. Plan realistically to ensure everyone gets comfortable quickly.
Choosing tools misaligned with actual practices: Pick a solution that matches your team’s existing workflow. If your team thrives on exploratory testing, avoid rigid, automation-centric tools.

Being mindful of these pitfalls makes the transition smoother and helps you choose a tool that genuinely fits your team’s needs.

Choosing clarity over complexity

Testing tools don’t guarantee flawless software – they simply help your team clearly see where things stand. Choosing clarity over complexity typically makes testing simpler. Go for a tool that aligns with your actual needs – nothing more, nothing less. Often, the simplest approach delivers the greatest value.

We might be a bit biased, but we think Testpad is a great place to start. To see how Testpad can support your test management efforts, sign up for a free, 30-day trial today.

What is system integration testing?

Stefan Butlin — Sun, 15 Feb 2026 00:00:00 +0000

System integration testing checks that different modules or components of your software work together correctly. Individual pieces can pass every unit test and still fail when connected: data gets lost, APIs miscommunicate, or interfaces turn out to be incompatible. Integration testing tells you whether your software works as a complete system, not just as separate parts.

At a glance

Integration testing checks that components work together, not just that they work alone
It sits between unit testing (individual code checks) and system testing (end-to-end)
The main approaches are big bang (everything at once) or incremental (top-down, bottom-up, or sandwich)
Run it after unit testing, before each release, and as part of continuous integration
Manual integration testing with simple checklists is a valid and practical approach

The rest of this post covers why integration testing matters, the main approaches, when to run it, and how to handle the common challenges.

Why is integration testing important?

Parts that work perfectly alone can fail badly when combined. Your login module might be perfect by itself, but if it can't talk to your authentication service, users can't get into your product. Not ideal.

System integration problems are hard to track down once they reach production. Finding these issues during development saves time and stops failures from spreading across your system. It’s like checking that your LEGO bricks actually snap together as you build – not discovering at the end that your work of art collapses the moment someone touches it because the connections were never solid.

The benefits of catching integration problems early:

Early bug detection – Issues found during integration testing cost much less to fix than those found after release
Better reliability – Checking that parts work together builds confidence that your system works as a whole
Clearer interfaces – Testing forces you to define how parts should talk to each other, which improves your setup
Reduced risk – Catching problems before system testing stops issues from piling up later

How is integration testing different from other testing?

Integration testing sits between unit testing and system testing. Each does something different:

Unit testing checks that individual functions or classes work correctly alone. You're testing the smallest parts of your code, often with fake versions of other parts. Read more about unit testing here.

Integration testing checks that multiple parts work together when connected. You're testing the connections and data flow between parts that already passed unit tests. Martin Fowler defines it the same way: integration tests "determine if independently developed units of software work correctly when they are connected to each other."

System testing checks your complete application from end to end, making sure everything works together in a realistic setup. Read more about system testing here.

Think of building a car. Unit testing checks each part – the engine runs, the brakes grip, the transmission shifts. Integration testing checks that the engine connects properly to the transmission and power actually transfers, or that the brake pedal mechanism connects correctly to the brake lines. System testing takes the finished car for a drive to make sure it works.

What does system integration testing actually check?

Integration testing focuses on the conversations between your components. Not whether they can talk at all, but whether they're actually saying sensible things to each other and getting useful responses back.

You're checking:

Data flow – Does information make it from A to B without getting mangled, lost, or mysteriously transformed into something else entirely?
API communication – Can your services call each other without hanging up mid-conversation or crashing when they don't get the response they expect?
Interface compatibility – Components expecting data in a certain format actually receive it that way, without type mismatches or broken structures.
Timing issues – Does everything still work when responses take longer than expected, or does your system assume everything happens instantly and fall over when it doesn't?
Error handling – When something breaks (and something always breaks), do the other parts handle it gracefully or does one failure cascade into five more?

In short: integration testing checks that your system behaves like a coherent whole, not just a collection of individually "working" parts that have never actually met.

How do you approach integration testing?

Different projects call for different strategies. The goal is the same – test how parts work together – but how you get there depends on the size and complexity of your system.

The two main approaches are:

Big bang integration

All parts are combined at once and tested together. This can work for smaller systems where everything is ready at the same time. The downside is that when something breaks, it’s hard to pinpoint the cause because so many things changed at once.

Incremental integration

Parts are integrated gradually, with testing at each step. This makes failures easier to isolate, since you're only adding one piece at a time. When something breaks, you know it's probably the thing you just added, not any of the 15 things you added yesterday. Most teams use one of these incremental patterns:

Top-down – Start with high-level components and work down, using temporary placeholders (stubs) for lower-level parts that aren't ready yet. Good when your architecture is top-heavy or you want to show progress to stakeholders early.
Bottom-up – Start with low-level components and work up, using temporary drivers to simulate higher-level behavior. Works well when your core functionality is complex and needs validation first.
Sandwich – Combine both approaches, testing from the top down and bottom up at the same time, meeting in the middle. Sounds fancy, but mostly just means you're testing what's ready when it's ready.

Here's how the approaches compare:

Approach	When to use it	Main advantage	Main risk
Big bang	Small systems where everything is ready at once	Simple to set up	Hard to isolate failures
Top-down	Top-heavy architecture	Shows progress early	Lower components need stubs
Bottom-up	Complex core logic	Validates foundations first	No end-to-end flow until late
Sandwich	Large, complex systems	Covers both directions	Most setup effort

In practice, the right choice comes down to risk and complexity. Small systems might be fine with big bang testing. Larger or more interconnected applications usually benefit from incremental approaches that surface problems earlier and make them easier to fix.

When should you do integration testing?

Integration testing is an ongoing activity throughout development, but it typically first happens after unit testing – once individual parts pass their tests, you can start connecting them.

You'll run integration tests:

After finishing new connections between parts
When updating APIs or interfaces that other parts depend on
Before each release to catch problems
As part of your continuous integration pipeline for quick feedback on every change

The goal is continuous feedback. Small, frequent integration tests catch problems faster than big, infrequent testing sessions.

What makes good integration test cases?

Good integration tests focus on realistic scenarios where parts interact. Rather than testing everything, focus on:

Critical paths – Test the most important user flows that cross multiple parts, like placing an order that touches inventory, payment, and shipping systems.

Known problem areas – Focus on connections that have caused issues before or involve complex data changes.

Error conditions – Check that parts handle failures properly when their connections have problems, like timeouts or invalid responses.

Boundary cases – Test edge conditions at connection points, such as maximum data sizes or unusual input formats.

For example, testing an e-commerce platform might include checking that when a user completes checkout, the payment gateway processes correctly, inventory updates in real-time, and the order management system triggers the right actions.

We cover more about how to make test cases simple and straightforward in our blog, What is a Test Case?

Can integration testing be automated?

Yes, and automation works well for repetitive integration checks. If you're running the same tests after every code change, automation saves time and catches problems quickly.

Common tools for automating integration tests:

Postman and RestAssured for API testing
JUnit and TestNG for Java applications
Selenium for web application testing
Jenkins and GitHub Actions for continuous integration

That said, automation isn't always the answer. Some integration testing works better manually, especially for exploratory testing or when the setup and maintenance effort for automation outweighs the benefits.

What about manual integration testing?

Manual integration testing remains valuable for many teams, especially when:

Testing complex user interactions across multiple systems
Doing exploratory testing to find unexpected integration issues
Connections involve external services that are expensive or hard to fake
You need flexibility to investigate problems as you find them

For manual integration testing, simple checklists work well. Rather than detailed step-by-step instructions, use prompts that remind you what connection points to look at. Something like "shopping cart syncs with inventory system" gives enough direction without rigid step-by-step test cases.

Tools like Testpad work well here – quick to set up, easy for anyone on the team to use, and you get clear visual tracking of what's been tested without heavy processes.

What are the common challenges of integration testing?

The usual challenges are test data, environment complexity, external dependencies, and flaky tests. Integration testing looks simple on paper, but in reality it gets messy fast – you're dealing with multiple systems, shared data, and parts that have strong opinions about how things should work (which never quite match up). Here's what tends to go wrong:

Managing test data – Integration tests need realistic data across multiple systems, which means coordinating usernames, IDs, and states that all have to line up perfectly. Keep a core set of test data that covers key scenarios rather than trying to test every possible combination. Nobody has time for that.

Environment complexity – Integration tests need setups that closely match production, which gets expensive and complicated fast. Tools like Docker can help by packaging your application with its dependencies, making it easier to spin up consistent test environments without manually configuring servers every time.

External dependencies – Third-party services might not be available for testing, or they charge per API call and you'd rather not bankrupt the company running tests. Use fakes when appropriate, but remember they don't catch real integration problems. A fake payment gateway that always returns "success" is great for testing happy paths, terrible for finding out your error handling is completely broken.

Flaky tests – Tests that sometimes pass and sometimes fail waste everyone's time and kill confidence in your test suite. Usually this happens with timing issues (one part finishes before another is ready) or tests that don't run independently (test B only works if test A ran first and left data in a specific state).

Start simple. Don't try to test every possible integration scenario. Focus on critical paths and build out from there as you learn what actually breaks.

Integration testing in practice

Here's how integration testing typically fits into the development process:

Integration testing is ongoing throughout development, not a one-time thing. Each time you add features or change existing ones, integration tests check nothing broke. For teams doing continuous integration, automated integration tests run with every code change. This gives quick feedback and stops integration problems from piling up.

Where to start with integration testing

If you're new to integration testing, start simple:

Find your critical connection points – where do different parts of your system need to work together?
Write tests for your most important flows that cross these connection points
Run these tests regularly, ideally as part of your build process
Add more tests as you find integration problems or add new features

Don't feel pressure to get perfect coverage right away. A few well-chosen integration tests for critical paths give you far more value than testing everything. Testing that your shopping cart talks to your payment processor matters. Testing that your logging module writes to a log file? Probably fine to skip.

Integration testing works alongside other testing approaches, not instead of them. You still need unit tests to check individual parts and system tests to check the complete application. Integration testing just fills the gap between them, catching the problems that only show up when components start talking to each other – and inevitably discover they had very different ideas about how that conversation was supposed to go.

The goal is building confidence that your software works reliably when all the pieces come together. Not just in isolation where everything's perfect, but as the messy, interconnected system your users depend on.

Want more practical testing advice?

Subscribe to get straightforward tips on all things testing sent straight to your inbox.

Best QA Testing Tools

Stefan Butlin — Tue, 03 Feb 2026 00:00:00 +0000

Quality assurance – otherwise known as QA – is a key part of software development. It helps you to make sure that your product does what it’s supposed to before it reaches users.

And the way to do this? Through testing – but there are a lot of different things to test. And that means there are a lot of tools on the market. So how do you know which QA testing tools are worth it?

We’ve searched far and wide to bring you six of the very best QA tools on the market, narrowing down the choice for you to help you decide which tools suit your needs, team and budget.

Types of QA testing tools

When it comes to QA testing tools, it’s not one size fits all. Different types of tools test different things – so if you want to thoroughly check your software, you’ll probably need to get your hands on a few different tools.

There are three broad categories of QA tools for testing. These are:

Test management tools
Functional testing tools
Performance testing tools

Test management tools

These are tools that help you to keep on top of the entire testing process. They can support you to do things like:

Create and manage detailed test plans and scenarios
Plan and schedule tests
Execute tests
Record results against expected outcomes
Generates reports based on test outcomes
Help to maintain traceability between test versions

In short, they ensure that tests are performed systematically and the results are captured for further analysis.

Functional testing tools

Functional testing tools make sure that software works according to your specified requirements. It’s a broad term, and functional testing could be broken down even further into different sub-categories of testing, such as:

Unit testing : When you test the smallest functional unit of code to make sure it works as expected
Integration testing: To make sure that different modules or components of the application work together correctly
System testing: When you test the complete system as a whole to check that all components work together as expected
Regression testing: If you update any code or fix a bug, you then need to test to make sure that nothing has broken due to the changes
User interface (UI) testing: Checking that the UI behaves as expected across different browsers, devices and screen sizes
API testing: Validating the functionality of APIs by sending requests and checking the responses to make sure that the backend functions as it should.

Functional testing, then, does what it says on the tin: makes sure that the features and functionalities of an application or software work as expected, and does the tasks it was designed to do.

Performance testing tools

Performance testing looks at how your software performs under different conditions, looking at things like speed, responsiveness and stability. This type of testing can help you to figure out if there are any bottlenecks and makes sure that your application or software can handle user demands.

The types of things performance testing tools look at includes:

Load testing: To ensure that the software or application performs as expected under normal user loads
Stress testing: To see what happens when there’s a higher load
Spike testing: To understand how it deals with sudden increases in traffic

In a nutshell, performance testing is all about how well your software performs under different conditions, to help you make sure that it can handle expected traffic and usage as well as unexpected spikes in load.

Six great quality assurance testing tools

Now you know about some of the main types of QA testing, let’s dive right in and look at the best QA tools out there. To make it easier to find the type of software quality assurance testing tools you need, we’ve broken it down by the three categories outlined above: test management, functional testing, and performance testing tools.

Test management tools

There’s a huge range of test management tools out there – so it can be hard to know which ones are the best, especially when they all seem to do the same thing.

TestRail and Tuskr are among the most popular choices, offering a range of features like test case management, real-time reporting, and seamless integrations with other development tools. For how TestRail stacks up against Testpad specifically, see Testpad vs TestRail.

Testrail

TestRail is a web-based test management tool that’s marketed as an end-to-end tool for the entire QA process, helping QA teams to test everything from test management to analytics. Some of the things you can do with TestRail include:

Test case management: You can create and manage test cases in an organized way, using one centralized test repository to organize, manage and track manual and automated test cases.
Real-time reporting and dashboard: TestRail offers customizable dashboards that display real-time data on the testing process.
Integration: Integrates with other tools, such as bug tracking tools (including Jira, GitHub, and Bugzilla) and CI/CD tools (like Jenkins, and GitLab), allowing testers to link test results with bugs or tasks automatically.

There are several options, catering to all team sizes. Prices start from $35/user/month.

Best features:

User-friendly: TestRail has an intuitive layout and customizable views, meaning it’s easy for both technical and non-technical users to use.
Version control: It tracks changes in test cases over time, making it easier to manage and update tests during the software development lifecycle.
Reporting: TestRail generates real-time reports that track key testing metrics like pass/fail rates, test case execution status, and defect trends so users can see at a glance how things are progressing.

Limitations:

Cost: Subscription costs are fairly high, particularly for enterprise teams.
Missing features: No tool can do it all, but there are some features absent from TestRail, such as defect tracking and management.

Tuskr

Like TestRail, Tuskr pitches itself as a complete test management tool. It’s a cloud-based test management tool that aims to streamline the testing process with a simple-to-use interface. Some of the features include:

Centralized hub: Tuskr offers a single platform from which you can manage both manual and automated tests from a single platform, helping teams to organize test cases and track progress without switching between tools or platforms.
Test case writing: The tool tries to simplify test case creation, allowing Spreadsheet import of test cases including custom fields, bulk edits, and the addition of images.
Visual progress monitoring: Tuskr includes visual charts and dashboards to to track progress at a glance.
Resource optimization: The tool encourages transparency between team members, data on over- and under-utilized testers, and planned versus actual workload.

Best features:

User friendly: The UI is intuitive and easy to use, even for the less technical members of your team.
WYSIWYG editor: A test case editor with rich-text formatting, it’s quick and easy to use.
Parallel testing: This feature allows the team to run different tests at the same time.

Limitations:

Subscription restrictions: Tuskr offers a free version but some features are limited. And with the paid versions, there’s a minimum number of users, which could be a problem for small teams.
Lack of customization: There are limitations in customizing the system to fit specific workflows.

Functional testing tools

The best QA tools when it comes to functional testing are easy to use and encourage collaboration between team members. Two popular choices are Selenium and Cucumber, detailed below. But if you have a good test management tool, you may not need a separate functional testing tool – many can support both kinds of testing.

Selenium

Selenium is one of the most widely used testing tools. It’s an open-source automation tool that automates browsers. It’s commonly used for testing web applications, such as user workflows, form submissions, and UI behaviors across different platforms.

There are three different options to choose from when it comes to Selenium:

Selenium WebDriver: This is best for people who want to create scripts to test functions or make sure that old features still work (regression tests). These scripts can run on different operating systems and browsers, like Chrome and Firefox, making it easy for anyone to use.
Selenium IDE: This is a browser plugin that makes it easy to create automated tests through a record and playback feature, helping users to record, edit and debug test cases without the need for coding skills.
Selenium Grid: If you want to run tests across multiple machines and browsers at the same time, then Selenium Grid is the one for you.

Best features:

Cross-browser compatibility: Supports multiple browsers (Chrome, Firefox, Safari, Edge, etc.) for more comprehensive testing.
Language flexibility: Supports multiple programming languages, including Java, Python, C#, and JavaScript.
Open-source and free: Selenium is free to use, making it a cost-effective solution for automation.

Limitations:

Steep learning curve: Other than Selenium IDE, it requires programming knowledge, making it less beginner-friendly.
No built-in reporting: Selenium lacks integrated reporting features.

Cucumber

Cucumber is a popular tool for Behavior-Driven Development (BDD). We know, that’s a mouthful, but the whole point of BDD is to make things easier. It’s a software development methodology that improves collaboration between developers, testers and business stakeholders, and it encourages the use of simple, clear language to describe software behavior. That means that everyone can understand and feed into the development process, no matter their level of technical knowledge.

So, back to Cucumber. It’s mostly used for checking that software behaves as expected from the user's perspective. That could include things like testing whether a user can successfully log in, or what happens when you use the search function on the site.

There are two versions available: Open Source and Pro. The open source version is the basic framework for Cucumber, while Cucumber Pro includes collaboration and reporting features, which can make it easier to track and visualize test results.

Best features:

Improved collaboration: Encourages team-wide involvement in the development process.
Anyone can write scripts: Cucumber uses its own simple language, Gherkin, which can be written by anyone, with any level of technical expertise.
Supports various programming languages: However, it also supports multiple languages.
Clear reporting: It’s easy to track test coverage and ensure that all requirements are met, particularly with the Pro version.

Limitations

Given-When-Then framework: The specific framework Cucumber uses can be verbose, especially in large projects with many complex scenarios, making it hard to read.
Can be slow: Cucumber tests can be slow to run – frustrating when you want to run tests and get results quickly.

Performance testing tools

Performance testing tools help evaluate how well applications, systems, and networks perform under various levels of user traffic. LoadRunner and Percy are two widely used tools, each designed to address different aspects of performance testing.

LoadRunner

LoadRunner is popular QA testing software that’s used to check how an application performs under load – in other words, it measures how well applications, systems, and networks perform when a lot of people use them at once.

It does that by simulating fake users (known as ‘virtual users’) to see how the system handles different levels of traffic. It’s usually used by developers and QA teams for load testing – which is when performance during normal traffic levels are checked – and stress testing, which is a test to see how the system behaves when there is a huge amount of traffic.

This type of testing using LoadRunners can help QA teams to spot problems like slow page load times, system lags and crashes. There are several different options available:

LoadRunner Cloud: A cloud-based performance testing tool that allows teams to simulate millions of virtual users.
LoadRunner Professional: An on-premises version, designed for businesses where the test team is in the same location as the application being tested.
LoadRunner Enterprise: This can be deployed on both on-premises infrastructure or in the cloud, depending on your needs/

Best features:

Comprehensive testing ability: It can test a wide variety of application types, including web, mobile, and enterprise applications.
Real-time monitoring: This feature helps teams track the performance of their system during tests.
Huge scalability: LoadRunner Cloud allows you to simulate up to 5,000,000 users to thoroughly test loads.

Limitations

Cost: LoadRunner is an enterprise tool, so the cost isn’t insignificant, which may be prohibitive for smaller teams.
Steep learning curve: The system can be difficult to learn, as users need scripting knowledge to create, update, and tune scripts.

Percy by BrowserStack

Percy is a visual testing and review platform that’s designed to help teams spot any visual changes in web applications, across different browsers and devices – helping QA teams to find and fix any visual bugs before their users.

Key features of Percy include:

Automated visual testing: The tool captures screenshots of web pages and compares them to baseline images to highlight any differences between the two.
Cross-browser and cross-device testing: You can test across different browsers and devices to ensure they’re all consistent and there’s no mistake when switching between screen sizes.
Dynamic content testing: Percy tests for dynamic components as well as static elements.
Automatic diff matching: Percy automatically matches and groups screenshots that have the same visual change, saving you time and effort while reviewing builds.

Best features:

Improve collaboration: Percy can help improve collaboration between developers, designers, and QA teams.
AI-powered: Percy uses advanced algorithms to detect even the smallest visual differences, improving the accuracy of tests.
Fast feedback loops: Percy automatically tests your UI across browsers and screens, so you can work at pace to correct mistakes.

Limitations:

Cost: Percy offers a free plan, but for larger teams or those with lots to test, the paid subscription can be pricey.
Slower for complex pages: Percy can be slower when it comes to testing dynamic content or complex elements.
Slow Processing for Complex Pages: For web applications that contain complex UI elements or extensive dynamic content (like SPAs), Percy can have slower rendering and processing times.

How to choose the QA testing tool for you

So that’s our QA tools list – now it’s over to you. How do you know which of the many tools out there are the right ones for you?

Consider your testing needs

First things first, what type of testing do you need to do? Do you need to organize and run test cases? Do you want to check how your software performs under heavy traffic? Getting clear on your testing requirements is the first step to choosing a tool that’s right for the job.

Think about your team’s skills

Some tools are easier to use than others. Are your team good at coding – or do you need a tool that’s designed with non-technical team members in mind?

Integration with other tools

Many QA tools integrate with other software such as Jira, GitHub, or CI/CD pipelines. If that’s something you need, make sure the tool you choose will easily connect with your existing tools to make everything more efficient.

Scalability

Is your team going to grow in the future, or do you need to be able to run large-scale tests? Look at how much each tool can handle before making a decision.

Budget

What can you afford? Testing tools can be expensive, so you may want to look for free subscriptions as well as lower-cost options if you’re working with a small budget.

Manual or automated

Do you want to run manual tests only, or do your tools need to be able to handle automated tests? That’ll affect your decision as to whether you go for QA manual testing tools or ones that can run automated tests too.

Community and support

Does the tool come with robust support? This is especially important if your team is non-technical, as you may need more help and support.

Customization and flexibility

Some tools offer more flexibility in how they can be adapted to your specific workflows. Think about whether you need to be able to tailor your experience or if you’re happy to use an out-of-the-box package.

Collaboration features

Many modern testing platforms allow for easier communication between different roles. This can lead to faster problem-solving and more efficient workflows so it’s worth considering whether it’s something you need.

Trial periods and demos

Many tools offer free trials or product demos. Don’t buy blind – test out different tools to get a feel for how they work before you commit.

Testpad for speedy test management and functional testing

There are a lot of different QA testing tools out there, doing every type of testing under the sun. But there is one more QA testing tool we haven’t mentioned yet: our tool, Testpad. It’s a modern functional testing and test management tool that uses a simple checklist approach – perfect for teams who want to test, and test quickly.

Key features include:

Intuitive interface: Testpad uses a checklist-based system that’s easy to learn – even for non-technical users.
Guest users: You can invite guests to run tests without a login – and without the need to pay for extra licenses.
Fast reporting: Instant reports that are easy to read and understand at a glance.

You may need a suite of other QA tools depending on your testing needs, but if you want to make your test case management and functional testing quick and easy, Testpad could be the tool for you. Why not try the 30-day free trial to see if it fits your test case needs?

Testpad vs Testmo: test plans, not a test-case database

Stefan Butlin — Tue, 03 Feb 2026 00:00:00 +0000

The difference between Testpad and Testmo is structural. Testmo is a database-driven test case management tool: structured test cases stored as records, plus formal exploratory sessions, automation result ingestion, detailed reporting, and integrations with Jira, GitHub, and CI pipelines. Testpad is a plain-text checklist: each test is a line of text, and anyone, including people without an account, can run it. This page sets out that difference, where each tool is stronger, and how the costs compare, so you can decide which fits your team.

The short version

Testmo is a database-driven test case management tool. Structured test cases live as records in project repositories; exploratory testing gets its own formal sessions with timed scope, screenshots, and workflow; automation results flow in from any framework via CLI or REST; a Reporting Center tracks QA metrics across projects.
Testpad is built around the test plan as a document: a nested outline of plain text prompts, a column added per test run, pass or fail marked down the list, a shareable report link at the end. No test case forms, no IDs, no formal structure required.
Teams choose Testmo when they need automation ingestion, per-test IDs and history, structured exploratory sessions, Jira integration, or detailed QA metrics. Teams choose Testpad when they want the lightest possible checklist, need to invite UAT testers with no account, or are a small team where Testmo's entry tier is sized larger than they need.
Testpad is from $10/user/month, and guest testers are free. Testmo starts at $99/month for up to 10 users, with a 21 days trial and no free tier.
Neither choice is wrong. It comes down to whether you need the unified platform and its depth, or whether a fast, lightweight checklist with open guest access is what the work actually calls for.

What's the actual difference?

Testmo is a database-driven test case management tool. Each test is a record in a project repository with customizable fields and templates, a persistent ID, and a history of every run. Test runs execute those cases with pass/fail recording. Exploratory testing gets dedicated sessions with a defined scope, a time box, screenshot attachment, assignees, and a session workflow separate from structured execution. Automation results from any framework flow in through Testmo's CLI or REST API, so automated and manual results sit in the same view. A Reporting Center aggregates metrics across projects. It integrates with Jira, GitHub, GitLab, and CI pipelines at the data level, not just issue links.

Testpad is built around the test plan as a document. A test is a line of plain text. Indenting builds structure: group related tests under a heading, or spell a longer test across several lines. Add a column for each test run and mark each prompt pass or fail as you work through it. There are no test case IDs, no per-run history per test, no formal exploratory sessions, and no automation ingestion. What Testpad has instead: you write the way you think, the plan stays as light as the testing needs, and you can invite testers, clients, or stakeholders to run a plan with no login and no seat through Guest Testing.

If you need automation results alongside your manual runs, per-test history, formal exploratory session records, or deep Jira integration, Testmo is built for that. If you want a fast checklist that anyone, inside or outside your org, can run without setting up an account, that's the gap Testpad fills.

How do Testpad and Testmo compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	Testmo
Data model	A standalone document: a nested outline of plain text prompts, a column per run	Structured test cases in project repositories; persistent IDs, fields, history, templates
Exploratory testing	Any checklist can be used for exploratory work; no formal session structure	Dedicated exploratory sessions: timed, scoped, screenshots, assignees, structured workflow (SBTM)
Automation ingestion	Not available	Via CLI or REST from any framework; automated and manual results in the same view
Guest / UAT testers	Share a link; no login, no seat, no account needed	Every tester needs a Testmo seat
Per-test IDs and history	Not today	Yes; each test case has a persistent ID and a full run history
Audit trail / permissions	Not today	Yes; audit log and per-user role permissions
Integrations	Jira, GitHub, Trello (light: issue IDs become links); REST API for automation results	Jira, GitHub, GitLab, CI pipelines; deep, not link-level
Reporting	Instant shareable report link	Reporting Center with QA metrics, dashboards, cross-project views
Pricing	From $10/user/month, guest testers free	$99/month for up to 10 users; $399/month for 1-25 users; $599/month per 25 users
Trial	30 days, all features, up to 20 users	21 days trial; no free tier
Best for	UAT, fast manual/exploratory, dev-led testing, small teams, open stakeholder access	Teams needing automation ingestion, formal exploratory sessions, Jira integration, QA metrics depth

Testmo facts checked against testmo.com, June 2026.

Why do teams choose Testpad over Testmo?

Guest Testing opens UAT to people without an account. In Testmo, every tester needs a seat. Send a Testpad plan as a link to a client, a business analyst, a freelancer, or a stakeholder, and they're testing in minutes: no login, no account, no seat purchased. For UAT rounds where extra hands come in for a sprint and then leave, that means no Testmo seats to buy for them.

Less to set up before you can write a test. No project configuration, no test case form to fill out, no template to define. A Testpad plan is an outline you start typing. One customer described it as "just like writing... feels like you're writing a document." For teams who want to start testing on day one, that matters.

Lighter and faster for pure manual checklists. Testmo's structure is an asset when you need it, and extra weight when you don't. If your work is a mix of ad-hoc regression, UAT, and exploratory checking, and you don't need per-test IDs or session records, Testpad stays out of the way.

Cheaper for a very small team. Testmo's entry tier is sized for up to 10 users, at $99/month. A two or three-person team pays for that whole block. Testpad's Essential tier starts at three testers, so a small team starts lower than Testmo's ten-user block.

Write-as-you-think speed. Each test is a line of text: type a prompt, hit enter, type the next. The structure comes from indentation, not from filling in fields. That keeps the plan editable and lets you add, reorder, or cut tests mid-sprint without touching a case repository.

When is Testmo the better choice?

When your team needs the things a database-driven platform does and a plain-text checklist doesn't. Testmo ingests automation results from any framework via CLI or REST, so automated and manual testing sit in the same view; Testpad does not. Its exploratory sessions follow a formal SBTM structure, with timed scope, screenshot capture, assignees, and workflow, which records exploratory work in a way a plain checklist does not. Every test case has an ID, every run is recorded, and every permission is tracked, which a regulated or large-scale QA process may require. The Jira, GitHub, GitLab, and CI integrations are deep rather than link-level. And the Reporting Center and QA dashboards aggregate metrics across projects over time.

If your QA practice depends on any of those, Testmo covers them and Testpad does not. Our guide to TestRail alternatives covers tools in a similar space if you're still evaluating broadly.

When is Testpad the better choice?

When you want testing to be fast and open, and formal structure would be more overhead than the work needs. You run UAT with clients or stakeholders who aren't getting Testmo accounts. Your team is small enough that a tier sized for ten users is too big. You do regression, exploratory, hardware, or dev-led testing where a checklist is the right level of formalism. You want to invite someone in for a two-week sprint and then not worry about their seat afterward.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for Testmo?

For lightweight manual and UAT testing it can be. If your team depends on automation result ingestion, formal exploratory sessions with structured records, per-test history and audit, or deep Jira integration, Testmo is built for those things, and Testpad isn't today. The choice depends on which of those capabilities your work actually needs.

What's the actual difference in the data model?

Testmo stores structured test cases in project repositories: customizable fields, templates, persistent IDs, a full run history per case. Testpad stores a test plan as a standalone nested outline of plain text prompts, with a column added per test run. No IDs, no per-test history, no repository.

Does Testpad handle automation testing?

Testpad does not ingest automation results today. Testmo does: results from any framework flow in via CLI or REST API and appear alongside manual results. If automation ingestion is central to your work, Testmo covers it and Testpad does not.

Can clients or outside testers run tests in Testpad?

Yes. Share a plan link and a guest tests with no login and no Testpad account. Guest testers don't count toward your user seats. In Testmo, every tester needs a seat on the account.

How does pricing compare?

Testpad is from $10/user/month, and guest testers are free, charged per person testing in Testpad. Testmo's Team plan is $99/month for up to 10 users; Business is $399/month for 1-25 users; Enterprise is $599/month per 25 users. There is no free Testmo tier; both tools offer trials.

Does Testmo have an audit log and per-user permissions?

Yes. Testmo includes an audit log and role-based per-user permissions. Testpad has neither today; if your process or compliance requirements depend on those, check before choosing Testpad.

How does exploratory testing differ between the two?

Testmo has dedicated exploratory testing sessions: formal SBTM-style sessions with a timed scope, screenshot capture, assignees, and session workflow. A session is a structured record, separate from a structured test run. Testpad lets you use any checklist for exploratory work: scope a plan, explore within each prompt, and record what you find. Faster to start, but no formal session record or timed scope.

What trial does each tool offer?

Testpad offers a 30 days free trial with all features and up to 20 users, no credit card required. Testmo offers a 21 days trial; there is no ongoing free tier.

See the difference in five minutes

The fastest way to choose is to write a real test plan in each. Testpad's free 30-day trial includes all features and up to 20 users, with no credit card and nothing to install. Paste in a set of your existing tests and see how they read as a plain-text checklist, with a shareable report link waiting the moment you finish the run.

Getting the most out of Testpad: Features to make your life easier

Stefan Butlin — Mon, 02 Feb 2026 00:00:00 +0000

You've signed up for Testpad and you're staring at the interface. Now what? Testpad is pretty straightforward once you get going. There’s no mandatory training courses or complex setup needed. But like any tool, knowing which features exist (and when to reach for them) makes the difference between fumbling around and actually feeling like it’s a tool worth having.

This isn't an exhaustive manual of everything Testpad can do (we aren’t THAT big headed). It's just the features that'll save you time once you know they're there, like keyboard shortcuts, filters that let you test selectively and our guest access feature that gets stakeholders involved minus the usual friction.

Think of this as the stuff you'd want someone to show you on day two, once you've poked around a bit and are ready to test properly.

Getting your tests in and organized

Think of Testpad as a checklist. Write your test prompts, indent related ones together, and drag rows around when you need to reprioritize. It's closer to how you'd organize tests in a document than how traditional test case management tools get you to work.

If you've used spreadsheets for testing before, you already know 80% of what you need. Testpad just makes that experience faster and more practical.

Two things to sort out first: getting your tests in, and keeping them organized.

Start by importing what you already have

Got tests in a spreadsheet? Copy and paste them into Testpad's import dialog. Make sure to select the "Spreadsheets" formatting option (not "Plain text") so Testpad properly handles quoted cells and tab separators.

The import expects tests in the first column. If you have multi-column spreadsheets (maybe title, steps, expected results), you'll need to combine those into a single column first, using indentation or formatting that works as a single test description. Optionally, column 2 can contain tags, and column 3 can contain notes.

CSV files work the same way, just with commas instead of tabs. If you need help formatting existing tests for import, we have set up a Testpad Script Writer custom GPT that can help you format tests in seconds.

If you're starting fresh, just type your test prompts as a list. You can add structure and detail later – it's faster to iterate than to build everything perfectly upfront.

Organize with hierarchical outlines

Indent tests under parent rows to create structure (use Tab or drag-and-drop to indent). Parent rows work as section headers, and you can collapse/expand them to focus on what matters. This makes long test plans readable and lets you work on one section at a time.

Tags on parent rows automatically apply to all their children, which saves time when you want to include or exclude entire sections from a test run.

Keyboard shortcuts

Testpad's keyboard shortcuts are designed for one thing: keeping your hands on the keyboard while you're testing. Once you learn them, you'll move through test runs faster than you can say, “wait, where’s my mouse?”

During testing

When you're running through tests, these shortcuts set results instantly:

p - Pass
f - Fail
b - Blocked
q - Query
x - Exclude
Spacebar - Pass (the fastest option for hammering through tests)

If you need to add comments or issue numbers, hit Tab to cycle through the input fields, then use the shortcuts above to set the result and auto-advance to the next test.

Managing tests

Alt-X - Start or continue a test run
Alt-T - Open the tags dialog
Alt-M - Open test details
Enter - Start editing the selected test row
Escape - Close dialogs and save changes
Space (when not editing) - Expand or collapse a test group

These shortcuts stop you clicking around in dialogs and keeps testing flowing smoothly.

Tags and filters

Tags let you selectively include or exclude tests from specific test runs. This is useful when you're testing in different environments, on different devices, or when you only need to run smoke tests rather than the full suite.

How tagging works

Open the test details dialog (double-click the row ID or type Alt-T) and add tags. Tags can be anything you find useful – browser names, priorities, test types, whatever makes sense for your testing.

Common tagging patterns:

Browsers/platforms: WINDOWS, MAC, CHROME, FIREFOX, MOBILE
Priority: HI, MED, LO, CRITICAL
Test types: SMOKE, REGRESSION, SANITY, UAT
Features: LOGIN, CHECKOUT, ADMIN, REPORTING

Filtering test runs

Each test run has a tag filter field that defaults to "ALL" (meaning it includes every test). Change this to filter which tests appear in that run.

AND logic (space or comma):

Filter: WIN HI includes only tests tagged with both WIN and HI

OR logic (+ character):

Filter: WIN + MAC includes tests tagged with either WIN or MAC

Negation (- prefix):

Filter: -MOBILE includes all tests except those tagged MOBILE

Combined example:

Filter: CHROME HI + FIREFOX HI includes high-priority tests for either Chrome or Firefox

The real power is tagging parent rows – all their children inherit those tags automatically. Tag an entire section once rather than tagging individual tests.

Test runs and retesting

Testpad shows test runs as columns next to your test list. Each column represents one pass through your tests – maybe testing on different browsers, in different environments, or with different builds.

Multiple test runs

Create multiple runs to test the same script in different contexts. Each run gets custom fields at the top where you can record details like:

Environment (staging, production, local)
Browser or device
Build number
Tester name
Date

Progress bars show at a glance how many tests passed, failed, are blocked, or haven't been tested yet. This makes it obvious where you stand without digging through details.

Retesting after fixes

When you fix bugs and need to retest, create a retest column. Retests replace the previous results in the display but preserve the old results in the background (they're hidden by default to reduce clutter). This keeps your view focused on current status while maintaining a record of what happened before.

Combined with tag filters, this means you can quickly rerun just the failed tests or just the smoke tests without manually tracking which ones to repeat.

Get anyone involved with guest testing

Guest testing is one of Testpad's most practical features, especially when you need input from people who don't live in your test management tool.

Clients who need to sign off on UAT? External contractors? Product managers who want to verify specific scenarios? Get them all testing without the usual rigmarole of creating accounts, assigning licenses, and explaining how everything works.

When creating a test run, select "Guest" as the assignee. This opens an email composer where you can send an invitation link. The recipient gets a time-limited link (like a document sharing link) that gives them access to just that one script and test run – nothing else in your account.

Guests can record results, add comments, log issue numbers, and work through tests just like regular users. They can even attach screenshots and files (on Team plans and above) to document what they're seeing. The difference is they see a focused view of only what they need to test, and the link expires after a set time. You maintain control of the test plan while they focus on testing.

Bonus: guest links work on mobile too. You can even generate a QR code for quick handoff to tablets or phones, which is handy when you want the test instructions on a separate screen from the app you're testing.

Projects and folders

When you're testing multiple releases or products, Projects and Folders keep everything organized.

Typical workflow

Most teams organize by release:

Create a Project for each release (e.g., "Product 2.1", "Product 2.2")
Inside each Project, create folders for different features or testing phases
Add scripts (your test lists) to the appropriate folders

When a release is complete, archive the whole Project or just specific scripts within it.

Copying tests between releases

When you start testing a new release, you probably want to start with tests from the previous release. Drag a script to a new Project while holding Ctrl (or Cmd on Mac) to copy it. This copies the test prompts and structure but not the results – exactly what you want for a fresh test pass.

Templates and libraries

If you have standard test patterns you reuse across products or releases, save them as templates in a Library. Drag templates onto Projects to create new scripts from those patterns. This is useful for teams with modular products where different releases might need different combinations of test suites.

Link to your bug tracker

Testpad doesn't try to be your issue tracker – you already have Jira, GitHub, or something else for that. Instead, it makes it easy to connect test results to issues.

Set up a bug link pattern (either at the account level or per-project). When you record an issue number in a test result, Testpad automatically makes it a clickable link that opens directly to that issue in your bug tracker.

This keeps testing focused on testing while maintaining clear connections to the work that needs doing. You're not duplicating data or switching contexts unnecessarily.

Image attachments for visual context

On Team plans and above, you can attach images and files to both test descriptions and test results. This includes screenshots, audio files, short videos, spreadsheets, text files, and PDFs.

The workflow is straightforward: drag files onto the Attachments area in the Test Details dialog (for test descriptions) or the Test Run dialog (when recording results). If you're using Chrome, you can paste images directly from your clipboard (Ctrl-V), which pairs nicely with screenshot tools.

Files are limited to 6MB each, and images attached to results appear as clickable thumbnails in reports. This makes it easy to capture what you saw during testing without interrupting your flow or switching to separate documentation tools.

Forget emailing status updates

Testpad makes it straightforward to share testing status with people who don't need full access to your test plans.

Reports are instantly available. Share them via guest-access links (URLs with access tokens) at either the script or folder level. These read-only reports show test results, progress bars, pass/fail/blocked/query counts, comments, issue numbers, and attached images as clickable thumbnails.

For stakeholders who just need visibility into testing progress, this beats emailing status updates or scheduling meetings. Share the link once, and they can check progress whenever they want. If you prefer old-school audit trails, you can save or print the HTML reports.

For custom reporting or further analysis, export your results as CSV. This gives you the raw data to create whatever reports or metrics your team needs.

Here if you need us

Testpad has more features than what's covered here, but these are the ones that make the biggest practical difference when you're getting started. Learn these, and you'll spend more time actually testing and less time managing your test tool.

Ready to put these into practice? You're already set up – just start testing and reach for these features when you need them. Or if you need something not listed here, drop us an email support@testpad.com and we’ll help you out.

Excel alternatives for Test Management

Stefan Butlin — Mon, 02 Feb 2026 00:00:00 +0000

Looking for alternatives to Microsoft Excel for your test management? You're not alone. While Excel is almost always the common starting point for test teams, many find themselves searching for Excel substitutes as their testing needs grow.

Teams often find that Excel's quirks make it hard to use for collaborative, iterative testing.

Let's talk about why Excel is a popular choice initially, and what alternatives to Excel make sense when your team outgrows spreadsheets and is ready to upgrade.

Why Excel is a natural starting point

When you're first getting started with test management, Microsoft Excel isn't just a convenient choice – it's often the most practical one.

Think about what a test plan really is at its core: it's essentially a list of test prompts where you need to record results. The table format of a spreadsheet naturally fits this need, providing an intuitive way to organize your testing effort without any additional investment or learning curve.

This natural fit becomes clear when you look at how test cases are structured in Excel.

Your rows become individual test cases, each with its own steps and expected results. Columns can easily track essential information like pass/fail status, test dates, assigned testers, and comments. You can add new columns as needed for different test runs or to capture additional data points. This flexibility is particularly valuable when you're still figuring out exactly what information your team needs to track.

If you're just beginning to document your tests and don't have any specialized tools yet, Excel usually makes the most sense. Almost everyone has access to Excel or something similar, so you can get started right away. Plus, it's convenient, it's familiar, and your company has probably already paid for it.

However, Excel is often just the first chapter in your test management journey. As your test suite grows into a large Excel file for testing, you'll likely start experiencing limitations that signal it's time to look for an Excel replacement that better suits your testing goals.

When teams start feeling Excel's limitations

Ask QA teams what finally pushed them off spreadsheets and you tend to hear the same thing: they were spending more time maintaining the spreadsheet than actually testing. As the suite grows, these are the pain points that drive teams to look for something else.

The formatting struggle

One of the most common frustrations teams face is the constant battle with formatting.

Take something as seemingly simple as creating sections in your test cases - you'd think pressing 'tab' to indent would work just like in any text editor, right?

Excel makes this surprisingly difficult, forcing you to find workarounds just to maintain a clean hierarchical structure.

Teams often find themselves spending countless hours trying to make their test documentation look professional, only to have to repeatedly fix and maintain that formatting as different team members make changes. Thus, what should be a simple matter of organizing your tests becomes a time-consuming exercise in spreadsheet formatting.

The collaboration challenge

Collaboration can quickly become a headache when managing tests in Excel.

In the past, Excel's fundamental limitation of having only one person able to edit at a time meant team members either had to wait their turn or create their own copies to add changes, which led to version control chaos. Now that we have shared drives, that's slightly less of an issue, but you may still run into a "too many cooks in the kitchen" problem if you have multiple people collaborating in a document.

Over time teams can find themselves drowning in a sea of spreadsheet versions with names like "Test_Plan_Final_V2_FINAL_Rev3.xlsx", making it nearly impossible to track who made what changes and when. Test scripts that started clean slowly turn into something that barely resembles the original.

Your test case management transforms into a complex juggling act of file versions, rather than a smooth, collaborative process. If you're not even sure which sheet to use to track your results, odds are something will be missed in your testing.

The resource attachment headache

Modern testing rarely exists in isolation - you need to reference requirements, attach screenshots, link to bug reports, and maintain connections to external documentation.

Unfortunately, Excel wasn't designed with this in mind. Links often end up looking messy and break easily, especially when files are moved or renamed. There's no efficient way to handle screenshots or other test resources, forcing teams to maintain separate folders of assets that can morph into complex naming conventions.

Maintaining references to external documentation becomes a constant struggle, with teams often resorting to complicated workarounds just to keep everything connected and accessible.

Finding the best excel alternative for your team

Luckily there is no shortage of alternatives to Excel if you're looking to upgrade. The only tough part is finding a solution that fits your needs in your current testing setup. So where to start?

Other spreadsheet tools

You could switch to Google Sheets or Apple Numbers, but they're still spreadsheets with the same underlying limits. They fix the sharing problem, not the formatting, the structure, or the test-specific gaps.

The core challenges of formatting, organization, and test-specific functionality remain unchanged, making this more of a lateral move than a true upgrade if you've outgrown Excel.

Modern workspace tools

Tools like ClickUp and Notion offer an interesting middle ground as alternatives to Excel.

These platforms are better at handling structured data and provide improved collaboration features that far surpass traditional spreadsheets.

Their flexibility allows for customization that can be specifically built for test management, like creating workflows that match your team's precise needs.

However, this flexibility comes with a trade-off: you'll need to invest significant time in setting up and maintaining your testing framework within these tools. While they can be solid alternatives to Excel in the short term, they require careful thought and ongoing maintenance to work effectively for testing purposes. In the long term, it's possible that these tools may be challenging when testing needs grow and may not be able to meet the growing scope of a project.

Traditional Test Case Management tools

Traditional Test Case Management tools (TCM) tools represent the most comprehensive approach to test management, coming with extensive feature sets and capabilities for enterprise-scale testing operations from day one.

However, they often come with significant drawbacks: they're usually expensive, require substantial training to use effectively, and include complex features that many teams may never need.

For some testing teams, implementing a traditional TCM tool feels like using a sledgehammer to crack a nut – it's more power than you need and in some cases can actually slow down your testing process.

Pragmatic alternatives to Excel

Tools like Testpad keep the part of spreadsheets that worked, the plain table you can read at a glance, without the parts that didn't.

A test is a single line of plain text; indent to group related tests into a structure. Add a column for each test run, and record pass or fail down the list as you go. Tests down the side, runs across the top: it's the grid you were trying to build in Excel, but made for testing, so there's no hierarchy to fake and no formatting to maintain by hand.

It also answers the version problem. Instead of a folder of Test_Plan_Final_V2.xlsx files, you copy last time's plan and edit the copy. The old one stays as a faithful record of what was tested and how it did. And when you need outside testers for a round of UAT, Testpad's Guest Testing lets you invite them with no login.

Moving your tests over isn't a raw copy and paste: a multi-column spreadsheet needs reshaping into an outline first. The quick route is to hand the sheet to our custom AI helper, which knows the Testpad format and drafts the outlined version for you.

Making the decision: choosing your excel replacement

Here is an easy way to sum up all the pros and cons we previously mentioned about Excel and its alternatives. When you're considering moving beyond Excel, ask yourself:

Are you spending too much time fighting with formatting?
Does your team struggle with collaboration and file organization?
Do you need better ways to organize and structure your tests?
Are you after something lighter than a full test-case tool, but more structured than a spreadsheet?

The key is finding a tool that captures what you actually like about spreadsheets (the simplicity, the familiar table format) while solving the problems that are making you look for alternatives to Microsoft Excel in the first place.

Getting started with your new tool

If you recognize these pain points and feel ready to explore Excel competitors:

Start by listing what specifically frustrates you about your current Excel setup
Counter this by listing out what does work for your team, so you know what features are a "must" for your testing setup (and if your set up doesn't work now, thinking about what you would want or might need as your testing process grows will help)
Consider whether you need a full TCM solution or just a smart upgrade from spreadsheets
Try out a few alternatives to Excel with a small subset of your tests.
Consider using alternative tool's free trials to sample their workflows.
Include your team in the evaluation - they'll be using it too!

Remember, moving away from Excel doesn't mean you need to jump straight to the most complex solution out there. Sometimes the best Excel alternative is the one that feels familiar enough to get started with right away, but sophisticated enough to grow with your team.

The goal isn't to completely revolutionize how you manage tests - it's to keep what works about spreadsheets while making your life easier. After all, you should be focusing on testing your software, not fighting with your test management tool.

Whether you're dealing with a large Excel file for testing or just starting to feel the limitations of spreadsheets, we (obviously) suggest Testpad as an alternative to Excel that could be right for your team. You can try Testpad for 30 days completely free - no credit card is needed to sign up.

Whether it's Excel or an alternative, the key is finding the balance between functionality and simplicity that matches your team's needs. If you're interested in resources to make testing easier, check out our blogs for information on how to get started or change your testing set up.

6 best TestLink alternatives for more efficient test management

Stefan Butlin — Sun, 01 Feb 2026 00:00:00 +0000

If you’re looking for a new test case management tool, it’s likely that TestLink has come onto your radar. It’s been around for more than two decades and is still going strong – although there are many other (newer and shinier) tools on the market these days.

But which one is right for you? Let’s take a look at TestLink, along with six of the best alternatives, to help you make your decision based on your team's size, budget, existing workflows, and specific testing needs.

What is TestLink?

TestLink is an open source test management tool that – like other testing tools – helps teams to organize and manage their software testing processes.

It can be used to keep the testing process organized, allowing users to:

Create and manage test cases (the specific tests that teams want to run): Teams can create, edit and organize test cases within test plans.
Test reporting: Teams can record test results and create reports on testing outcomes. With all tests and results in one place, it’s easier to see if there are any areas that need more attention or have ongoing issues.
Track testing progress, allowing teams to see which tests have been completed, which are in progress, and which ones are outstanding.
Manage requirements, allowing teams to connect test cases to project requirements so that all parts of the software are tested.
Assign tests to team members, ensuring that everyone knows their responsibilities.

Open source software

One of the key differentiating features is that TestLink is open source. There’s no license needed to use the tool, and it’s freely available for download from either GitHub or SourceForge. That makes it particularly attractive to small teams and businesses on a budget.

The fact that TestLink is open source also means that businesses can modify the code to fit their specific needs, such as:

Adding custom fields: Teams can add new fields depending on their project needs and testing processes.
Creating new integrations: It's possible to integrate TestLink with other tools used, including Jira (to automatically sync test cases and defects), continuous integration tools like Jenkins, and test automation tools like Selenium.
Automating workflows: It’s possible to create automation scripts in TestLink to streamline repetitive tasks.
Adding custom reports: Users can design custom reports, focusing on the metrics that matter most to their projects. This could include things like test coverage, trends analysis and user activity.

Many teams like this flexibility offered by TestLink, allowing them to create a more tailored experience that suits the needs of their project or organization.

User roles and permissions

TestLink supports different user roles and permissions, meaning that teams can manage access and control what different users can do within the tool. This feature may be handy for larger teams with lots of team members, where it’s important to restrict who can access what within the testing environment.

Bug tracking tools

TestLink can connect with popular defect-tracking tools like Jira and Bugzilla. This streamlines the process of identifying and resolving bugs, allowing for better collaboration between testing and development teams. If a user discovers any issues while executing test cases, they can quickly log these defects directly into the connected bug tracking system without leaving TestLink – which also makes it easier for developers to see and follow up on those issues.

Manual and automated testing

TestLink mostly supports manual testing, but it can also be used for automated testing through integration with other tools. That means that teams can track results from both manual and automated tests, all in one central location.

TestLink pricing

Because TestLink is open source, it’s free to download, use and modify. That makes it an appealing choice for teams of all sizes.

Limitations of TestLink

While it offers standard test management and organization features for free, users may find that it doesn’t quite meet all of their needs, leading them to look for TestLink alternatives.

Some of the limitations of TestLink include:

User interface: TestLink has been a popular tool since the early 2000s – and its age is reflected in its look, feel and user-friendliness. TestLink is functional but some teams may find it to be dated compared to newer tools.
Dependence on third party integrations: TestLink is easy to integrate with other tools, but users may prefer to have features like defect tracking all in one place, without the need for multiple tools.
Customization complexity: The customization offered by TestLink is one of its strengths – but it requires someone with a technical background to implement. Teams without a development background may struggle to implement specific changes to the tool.
Support: TestLink is an open source tool – which means that users rely on community support for troubleshooting and feature requests. While there are forums, videos and documentation available, users may find that responses to issues can be slower compared to paid tools with dedicated customer support.

Six TestLink alternatives to consider

Finding the right tool to suit your testing needs can be a bit of a headache. Not sure that TestLink is the right one for you? We’ve done the hard work for you, searching high and low to find the best TestLink alternatives.

TestRail

TestRail is a web-based test management tool that’s designed to help software development and QA teams manage and streamline their testing processes. It markets itself as an end-to-end tool for the entire QA process, from test management through to analytics.

Key features of TestRail

Some of the main features of the tool include:

Centralized test repository: Allowing users to organize, manage and track both automated and manual test cases all in one place.
Integration: TestRail can be integrated with most tools, including CI/CD platforms, issue management tools and test automation frameworks.
Analytics and reporting: A suite of reports is available, including live dashboards offering real-time reports, cross-project reporting, and customizable charts.
Security: There are several security features built-in to the tool (depending on your subscription level), including single sign-on, multi-factor authentication and custom roles.

TestRail pricing

TestRail offers a few options, depending on the size of your team:

Professional Cloud

This is for standard test management, and includes:

Traceability and coverage reporting
Test cases and suites
Test runs, plans, and milestones
Defect and requirements integrations
Traceability and coverage reporting
TestRail API

The cost starts from $35/user/month billed annually

Enterprise Cloud

This includes everything offered in Professional Cloud, plus:

Automatic daily backups
Single sign-on (SSO)
Advanced auditing
Test case version control & approvals
Test parameterization
Project admin permissions
Priority support

The cost starts from $71/user/month billed annually.

Enterprise Server

This includes everything in Professional Cloud, plus:

On-premise hosting
Single sign-on (SSO)
Advanced auditing
Test case version control & approvals
Test parameterization
Project admin permissions
Priority support

For larger teams, volume pricing and quotes are available on the TestRail site.

TestLink vs TestRail

TestLink has been well-loved and well-used for the last couple of decades, but it doesn’t come with the most user-friendly design and requires technical know-how to use. TestRail offers a more modern, intuitive user interface and experience which may make it more appealing to less tech savvy users.

Pros:

User-friendly interface
Robust reporting features, including customizable reports
Integrations with various tools

Cons:

TestLink is free vs subscription costs for TestRail, which are notably higher for enterprise teams
Limited workflow customization
Relies on integrations for defect tracking and management

Testmo

Testmo is another unified test management tool that promises to help teams manage their testing more efficiently. It aims to streamline workflows by providing a platform where teams can collaborate on testing tasks, track progress and generate reports.

Key features of Testmo

Some of the main features of Testmo include:

Test case management: All test cases are managed in a central place, and organized with folders, tags and custom fields.
Exploratory testing: Supports ad-hoc testing sessions for more flexible testing approaches.
Reporting: Testmo offers various reporting options, including extensive QA reports, metrics and charts, with actionable insights.
Integration: It can be integrated with a wide variety of tools already used by your team, such as GitHub, Jira, Asana, Trello, Jenkins and more. It can also integrate with any test automation tool or CI/CD workflow, enabling users to submit results quickly and efficiently.

Testmo pricing

Testmo offers multiple pricing options for teams of various sizes:

Team: $99/month for up to 10 users
Business: $399/month for 1-25 users (add more as needed)
Enterprise: $599/month, per 25 users
- The Enterprise option includes everything in the Business plan plus two-factor authentication, SSO, complete user audit log and sandbox account.

TestLink vs Testmo

Like TestRail, Testmo offers a more user-friendly alternative to TestLink. They promote easy integration with test automation platforms for full test automation management, integration and reporting may make it an appealing option for teams that want both manual and automated testing.

Pros:

User-friendly interface
Rich reporting
Strong integration capabilities

Cons:

No in-bult bug tracking
Limited customization
Learning curve: there are a wide range of features which may take a while to get to grips with

Tuskr

Again, like most other TestLink alternatives, Tuskr pitches itself as modern, do-it-all test management software. It provides users with a platform to manage test cases, track execution results, and collaborate effectively within teams.

Key features of Tuskr

Tuskr aims to offer lots of features within its simple interface. Some of the main ones you’ll want to know about include:

Test case writing: Supporting images, HTML tables, custom fields and bulk edits.
Flexible test run management: You can easily create test runs that include all test cases in a project, specific ones, or those matching a complex filter.
Resource optimization: Charts and reports to encourage transparency between team members, including data on over and under utilized testers, and planned versus actual workload.
Charts and dashboards: To visualize testing progress and results.
Integration: Integration with CI/CD and DevOps tools.

Tuskr pricing

As with other tools, Tusker offers various subscription levels for different sizes of teams:

Free: For teams of up to five users, Tusker is completely free – although there are limitations, such as a maximum of 5 projects and 1,000 test cases.
Team: $90/user/year (five users minimum), with a limitation of 50 projects and 50,000 test cases.
Business: $150/user/year (five users minimum), with a limitation of 100 projects and 100,000 test cases.
Enterprise: $290/user/year (five users minimum), with a limitation of 250 projects and 250,000 test cases.

TestLink vs Tuskr

TestLink is fully free and open source – but it does require technical knowledge, and the user interface isn’t particularly intuitive. Tuskr is designed to be user-friendly and while there are limitations, its free subscription may be tempting for budget-conscious teams.

Pros:

User-friendly interface making it easy to navigate and manage tests
Parallel testing, allowing teams to run tests simultaneously
Free option for teams on a budget

Cons:

Some limitations to the free tier
Minimum number of users for paid plans could be a barrier for small teams
Limitations in customizing the system to fit specific workflows

PractiTest

PractiTest aims to simplify test management. Like other tools within this space, it offers a robust suite of features including dashboards and reports and integration with other platforms.

Key features of PractiTest

Some of the major features of PractiTest include:

Customizable reports and dashboards: Configure these to focus on the metrics that matter most to your business – with real-time data.
Centralized QA hub: Manage any type of testing in one shared platform.
AI-driven capabilities: Streamline time-consuming tasks with AI, such as writing test cases, reusing test steps and prioritization to perform the most important tests first.
Customization: Highly customizable, including custom fields, flexible reporting and integration capabilities.

PractiTest pricing

PractiTest’s Team plans include unlimited projects and end to end test modules:

5 tester licenses: $2,940 billed annually
10 tester licenses: $5,880 billed annually
15 tester licenses: $8,820 billed annually

There’s also a corporate plan, which includes an advanced security pack, multilingual support and a control and compliance pack. Corporate plans are available for 10+ users and prices are available on request.

TestLink vs PractiTest

PractiTest is more intuitive with a user-friendly interface, while TestLink can be seen as less modern and sometimes challenging to navigate. Its real-time reporting is a positive for fast-paced start-ups, while the AI features may be tempting to teams looking to save time and streamline processes.

Pros:

Real-time data with customizable reporting
Time-saving AI features
Highly customizable

Cons:

Steep learning curve for unfamiliar users
Cost: pricing may be on the higher side for smaller teams

qTest

Like most modern test management tools, qTest pitches itself as a modern, scalable test case management tool that helps users to streamline the testing process across various phases of the development lifecycle. It supports agile methodologies, with its capabilities including test case creation, test execution, defect tracking and reporting.

Key features of qTest

Some of the main features to know about include:

Real time reporting and dashboards: With customization to display graphs and charts the way you want.
Defect tracking: Unlike many other platforms which require integration with third party tools for bug tracking, qTest offers in-built defect tracking, reporting and resolution.
Generative AI: qTest helps you to speed up the process with automatic draft test cases and test case regeneration.
Integrations: qTest integrates with popular software development lifecycle (SDLC) tools like Jira and Azure DevOps.
Automated testing: qTest offers the flexibility for both automated and manual tests within the platform.

qTest pricing

Pricing starts at $1,200/user/year, billed annually – contact qTest for a quote based on your individual requirements.

TestLink vs qTest

One of qTest’s key differentiators is defect tracking within the platform. Other tools, including TestLink, require third party integrations in order to track bugs, but qTest allows it all to be done within one central location – which could streamline processes.

Pros:

Defect management
Customizable reports and dashboards
Comprehensive lifecycle management

Cons:

Higher costs, especially for small teams
Some users have reported a complex UI

Testpad: the best TestLink alternative for speedy testing

Testpad takes a fresh approach to test management. Many traditional test case management tools are complex with a steep learning curve – and unfortunately, often they come with a lot of bugs and glitches, too.

Instead of a traditional database-driven approach, Testpad uses a simple checklist approach – it’s a lightweight tool that helps you test more, faster. For a full side-by-side, see Testpad vs TestLink.

Key features of Testpad

The key features of Testpad include:

Intuitive interface: Testpad uses a checklist-based system that's quick to set up and easy to learn.
Exploratory testing: Testpad supports exploratory testing natively, without the need for additional add-ons.
Guest users: Invite guests to run tests, no login needed – and no need to pay for extra licenses.
Fast reporting: Instant reports that are easy to decipher at a glance.

Testpad pricing

Like other tools, Testpad offers a range of pricing options to suit teams of all sizes:

Essential: 3 testers, $49/month, billed annually
Team: 10 testers, $99/month, billed annually
Team 15: 15 testers, $149/month, billed annually
Department: 25 testers, $249/month, billed annually

TestLink vs Testpad

TestLink has been around for a long time, and has been popular for a reason – but it is clunky to use with a difficult interface. Testpad offers a straightforward, lightweight and flexible approach to testing, making it a good choice for teams that want to jump right into testing without having to first learn how to use a complex tool.

Final thoughts

There are many different test management tools out there, so we get it – picking the right one can be tricky.

It’s important to think about what you need from your tool before making your decision. TestLink is one of the oldest testing tools out there – but legacy tools are often not as user-friendly as modern tools, and TestLink does take a lot of training and research to learn how to use it.

Many of the other test management tools on the market are fairly similar. They offer a range of features across the product testing lifecycle and various integrations with other tools – but you don’t always need the complexity that comes with this. Sometimes you need to keep things simple, and that’s where Testpad comes in.

If you value speed and simplicity, Testpad could be the tool for you. To see if Testpad fits your needs, try the 30-day free trial. It's the best way to figure out if Testpad's streamlined method can kick your testing process up a notch.

6 Best TestLodge Alternatives for QA Teams

Stefan Butlin — Sat, 31 Jan 2026 00:00:00 +0000

When launching an update or new functionality, running tests is essential to your go-to-market strategy. However, managing these testing efforts can become challenging, especially when speed and accuracy are top priorities.

We’ll take a look at TestLodge, a leading complete test case management tool, alongside other strong alternatives. By understanding price, features, pros, and cons, you’ll get a clearer view of which tool might best support your testing goals.

What is TestLodge?

TestLodge is a complete test case management tool that enables QA teams to plan, run, and organize software testing, including support for test automation. Designed to streamline workflows, TestLodge allows teams to handle tests efficiently and offers a range of integrations for reporting and analysis.

Features

TestLodge core features:

Test planning with customizable templates or your unique design
Inputting and verifying requirements to ensure thorough test coverage
Importing test cases directly from spreadsheets to streamline setup
Guided test cycles for straightforward execution
Dashboards that provide insights on progress, commonly failed/skipped tests, and user workload
Remote syncing for real-time collaboration
An extensive list of issue tracker integrations, from Asana to Basecamp and more

Benefits

TestLodge promotes itself as a tool that’s easy to adopt team-wide, aiming to simplify test management without overwhelming users. It offers customizable options and collaboration features, which help teams – whether local or remote – stay aligned on manual and automated tests. While TestLodge emphasizes ease of use, it’s worth exploring how well it actually fits your team’s workflow.

Limitations

Despite its advantages, TestLodge has some limitations. The tool lacks certain features needed for full test automation, and guest testing requires guests to make their own accounts. Additionally, pricing plans are limited by the number of test plans, cases, and runs, which can become costly for small QA teams that require a more flexible, unified testing platform.

Pricing

There are four tiers of pricing at TestLodge:

Personal: $34/month for:
- 50 test plans
- 200 test cases
- 100 test runs
- Unlimited users
Basic: $69/month for:
- 150 test plans
- 600 test cases
- 300 test runs
- Unlimited users
Plus: $139/month for:
- 500 test plans
- 3,000 test cases
- 1,000 test runs
- Unlimited users
Premium: $279/month for:
- 1,500 test plans
- 10,000 test cases
- 3,000 test runs
- Unlimited users

TestLodge’s pricing is structured around limits on plans, test cases, and test runs, which reset monthly, rather than by the number of users. This setup means that as your testing needs grow, you may need to adjust to a higher-tier plan. For teams opting for annual subscriptions, a 10% discount is available.

6 best TestLodge alternatives

While TestLodge does a great job of serving its customers, it’s not the only reputable test management tool on the market. These are 6 of the best TestLodge alternatives for QA teams and a price breakdown of each tool for a QA team of 10 users:

Tool	Free trial	Basic plan price per year	Business plan price per year	Price per 10 users per month
TestLodge	30 days	N/A (priced by content, not per user)	N/A	N/A (priced by content, not per user)
Testlio	No free trial	Contact sales	Contact sales	Contact sales
TestMonitor	14 days	$396 (Personal)	$4,788	$399
Tuskr	30 days	$900	$1,500	$75
Testmo	21 days	$1,010 (Team)	$4,070 (up to 25 users)	$99
TestRail	30 days	$4,200 (Professional)	$8,520 (Enterprise)	$370
Testpad	30 days	$588 (Essential, 3 testers)	$1,188 (Team, 10 testers)	$99

Testlio

Key features

Testlio combines test automation with manual testing, supported by a network of freelance testers who help teams achieve targeted test results. The platform integrates with project management and automation tools, aiming to streamline workflows for teams focused on optimizing their testing processes.

Pros

Testlio is known for flexibility in software test management, with key benefits such as:

Service support in addition to the SaaS platform
Broad integrations with various automation tools
Flexible management for a range of testing requirements

Cons

Users note some areas where Testlio could improve:

The platform can feel complex for new users
Limited expertise across certain industries in its service offerings
Concerns about vendor lock, with limited compatibility for transferring data to in-house tools

How it compares to TestLodge

Testlio combines a service element with its tool, offering more than standard test management. However, for teams seeking straightforward test management, TestLodge’s user-friendly interface may be a better fit. Testlio’s additional services and integrations may be helpful for teams with specific support needs.

TestMonitor

Key features

TestMonitor promotes itself as a user-friendly platform designed to streamline testing processes. It offers features like risk management, milestone planning, issue tracking, and test case management, supporting a range of testing needs. The platform also includes custom fields for more detailed test tracking, helping teams gather specific insights.

Pros

TestMonitor has several strengths, including:

Responsive customer support
Dashboards for keeping team members aligned on project progress
Scalability for teams managing small or large testing sessions

Cons

Some users report limitations with TestMonitor:

Fewer integrations than other test automation tools
Limited options for collaboration between testers
Pricing can be a challenge for smaller teams

How it compares to TestLodge

While TestMonitor promotes ease of use, setup and initial training can present challenges. Both TestMonitor and TestLodge may require additional time to implement effectively. For teams focused on affordability, TestLodge often provides a more budget-friendly alternative.

Tuskr

Key features

Tuskr is a test management tool offering a range of capabilities for writing test cases, conducting test runs, and tracking test results. The platform integrates with project management and automation tools, allowing users to incorporate it into existing workflows. Custom fields are available for teams needing tailored test tracking options.

Pros

Tuskr has notable advantages, including:

Competitive pricing for its range of features
Integrations that support broader workflows
Reliable performance across different testing sessions and team sizes

Cons

Users report some limitations with Tuskr, such as:

Limited customization for test cases and suites
Slower response times for customer support
Navigation can be cumbersome when organizing cases and suites

How it compares to TestLodge

Tuskr and TestLodge both aim to offer accessible test management solutions, with Tuskr potentially being more affordable based on the plan. TestLodge’s focus on team collaboration might make it more suitable for larger QA teams needing coordinated workflows.

Testmo

Key features

Testmo is a test automation tool designed to support both manual and automated testing. It provides a structured approach to test case creation, tracking, and reporting, with integrations that help teams monitor test results efficiently. Testmo is geared toward clear reporting, making it suitable for teams focused on achieving expected results.

Pros

Some of Testmo’s practical features include:

Organized test case setup and management
Navigation that supports efficient test tracking
An interface designed for straightforward reporting

Cons

Testmo has a few limitations users note, such as:

Limited customization options in test reports
Customer support response times could be improved
Challenges in linking manual and automated tests

How it compares to TestLodge

Testmo offers robust reporting and a well-structured interface, but TestLodge is often cited as a more cost-effective option, with analytics that some users find easier to navigate for basic test management needs.

TestRail

Key features

TestRail is a test case management tool that supports both manual and automated testing. It includes features for setting up test cases, tracking test results, and offers dashboards and integrations aimed at streamlining project management tasks.

Pros

TestRail has several strengths, including:

Integration with JIRA for smoother project workflows
Effective tracking of test failures and successes
Support for both manual and automation tests

Cons

Some areas where TestRail users experience limitations include:

Slower load times with a high volume of test cases
Basic reporting options for tracking test results
An interface that some users find outdated

How it compares to TestLodge

While TestRail is feature-rich, TestLodge is often considered to have a more budget-friendly price and a user interface that may be easier for some teams to navigate. (For TestRail against Testpad, see our Testpad vs TestRail comparison.)

Testpad as an Alternative to TestLodge

It’s worth considering Testpad as a strong alternative to TestLodge. Testpad is designed with usability in mind, focusing on practical features that keep testing straightforward and accessible for teams of all sizes. For a full side-by-side, see Testpad vs TestLodge.

How Testpad compares to TestLodge

When it comes to test management, both Testpad and TestLodge are designed to keep things straightforward. While each tool has a similar focus, they differ in how they approach team collaboration and user accessibility.

Features

Testpad is designed to offer a straightforward solution for test management, making it accessible for both technical and non-technical teams. Its approach allows anyone in the office to easily participate in software testing.

While both TestLodge and Testpad focus on streamlined test management, Testpad places a particular emphasis on exploratory and guest testing. Guests can test without needing to create an account, and exploratory testing is intuitive with Testpad’s easy-to-use test-building framework.

Use cases

Testpad is a strong option for:

Small to medium-sized teams: As one of the most affordable test management tools on the market, Testpad is great for small, budget-conscious teams.
Exploratory testing: Testpad’s simple platform makes it easy to run exploratory tests.
User acceptance testing: Invite guests and stakeholders to test without the hassle of creating profiles and watching hours-long tutorials.
Tight turnarounds: Testpad is simple to learn, manage, and track – so if your projects need to move fast, you can get things from the starting line to the finish line with very little friction.

Both TestLodge and Testpad emphasize usability, though TestLodge includes additional features geared toward team collaboration. Each tool brings a streamlined approach to test management, with distinct strengths based on team needs.

Pricing

Like TestLodge, Testpad offers four tiers of pricing.

Essential: $49/month for 3 testers with core features
Team: $99/month for 10 testers with full features
Team 15: $149/month for 15 testers with full features
Department: $249/month for 25 testers with full features

For larger teams or organizations with specific needs, custom pricing options are available – contact us to discuss.

For teams of 10+ looking for full-featured test management for their business, Testpad is cheaper than TestLodge. TestLodge’s plans are limited not by users, but rather test run, plans, and case. For businesses running small numbers of tests, they may get away with using the basic plan, which is $69/month. However, it’s likely they’ll need the Plus or Premium plans, which are $139/month and $279/month, respectively.

In most cases, Testpad provides a cost-effective alternative.

Get started with Testpad

Many test management tools, including TestLodge and its alternatives, emphasize simplicity – yet it’s worth considering how simple a tool can truly be when packed with complex features and functions. For teams who prefer a more straightforward approach without the lengthy setup or steep learning curve, Testpad offers a practical solution.

Budget-conscious, non-technical teams can easily get started with Testpad for traditional, exploratory, and guest testing. To see how Testpad might fit into your workflow, sign up for a free, 30-day trial today.

What is automated testing?

Stefan Butlin — Fri, 30 Jan 2026 00:00:00 +0000

Automated testing means software runs your tests instead of a person. Scripts execute predefined steps, check the results, and report pass or fail, all without human involvement. It handles repetitive regression checks faster and more consistently than manual testing, but it isn't a replacement for it: each approach handles different problems well.

At a glance

Automated testing uses scripts to run checks without human involvement, so it's fast and consistent for repetitive scenarios
It doesn't replace manual testing: automation only finds problems you anticipated, humans find the rest
Automate when the time investment pays back: regression checks you run many times, cross-browser checks, stable API flows
Manual testing is the better choice for new features, exploratory work, and visual or usability judgment
Start small: automate one test you repeat often before building a full suite

The rest of this post covers how automated testing works, how it compares with manual testing, and when each one is worth using.

How does automated testing work?

Automated testing runs pre-written test scripts that interact with your software and check the results.

Here's a typical automated test in action:

Setup: The script launches your application and sets up any necessary test data
Execute: It performs specific actions – clicking buttons, entering text, navigating pages
Verify: It checks if the actual results match what you expected
Report: It logs what passed, what failed, and any errors encountered

Take a login test as an example. An automated script might open your login page, enter a username and password, click submit, then verify the user lands on the dashboard. Run that script, and you'll know within seconds if login still works. Run it across ten different browsers simultaneously, and you've just saved hours of checking.

The script executes the exact same steps every time. That consistency means it catches regressions reliably, but it also means the test only checks what you explicitly told it to check.

Automated testing vs manual testing: what's the difference?

The difference between automated testing and manual testing comes down to execution. Manual testing relies on human testers clicking, typing, and observing. Automated testing uses scripts to do the same work without human involvement.

Each approach has distinct strengths:

Manual testing handles	Automated testing handles
Exploring new features without a predetermined path	Running hundreds of tests in minutes instead of days
Catching visual issues like misaligned buttons or odd color choices	Testing the same scenarios repeatedly without variation
Adapting on the fly when something unexpected happens	Checking multiple browsers and devices simultaneously
Judging whether something feels right to users	Catching regressions every time code changes
Complex scenarios requiring judgment calls	Processing large volumes of data combinations

Automated tests will never notice that surprising edge case a manual tester might stumble across. But manual testers can't match automation's speed for repetitive regression checks. DORA's research points out that manual regression testing is slow and expensive enough to become a bottleneck in delivery, and finds that teams whose developers create and maintain their own automated test suites deliver software better.

Most teams use both. The question is less automated vs manual testing and more about what approach fits which situation. We talk more about manual vs automated testing here if you’re interested.

When should you use automated testing?

Use automated testing for tests that run frequently, follow predictable patterns, and would be tedious to repeat manually. Automation needs significant upfront time investment: writing automated tests takes much longer than writing a manual checklist, and maintaining them as your software changes takes ongoing effort. It only pays off when you'll run those tests often enough to make back that investment. The best candidates for automation:

Regression tests: When you fix a bug or add a feature, you need to know existing functionality still works. Automated regression tests catch problems efficiently, and they can run continuously during development so the release process keeps moving.
Repetitive scenarios: If you're testing the same login flow, search function, or checkout process for the twentieth time, automation saves considerable effort.
Cross-browser and cross-device testing: Manually testing on Chrome, Firefox, Safari, Edge, plus various mobile devices takes days. Automated testing runs these checks in parallel.
Performance and load testing: Simulating thousands of concurrent users isn't feasible manually. Automation reveals how your system behaves under pressure.
API testing: APIs need testing with numerous parameter combinations. Automated testing handles this more efficiently than making manual API calls.
Data-driven tests: When you need to run the same test with multiple data sets – different user types, payment methods, or input variations – automation makes sense.

When should you use manual testing?

Manual testing works better for tests that change frequently, require human judgment, or involve exploration and discovery.

Choose manual testing for:

New or unstable features: Features under active development change too quickly for automation. Manual testing provides faster feedback without the overhead of maintaining brittle scripts.
Exploratory testing: Testing without a predetermined script lets you follow interesting paths as you discover them. If clicking a button produces an odd result, you can immediately investigate why – something automated tests can't do. This adaptability helps uncover problems you didn't know to look for.
Visual and usability checks: Does the page look right? Does the workflow make sense? These subjective evaluations need human eyes and judgment.
Complex user workflows: Some scenarios involve too many variables and decision points to script effectively. Manual testers can adapt as they go.
One-off tests: If you'll only run a test once or twice, manual testing is faster than writing and maintaining automation.
Initial verification: Before investing in automation, manually test new functionality to ensure it's stable and worth the automation effort.

A useful rule of thumb: if maintaining automated tests takes more effort than just running the tests manually, you're automating the wrong things.

What are the benefits of automated testing?

Automated testing saves time on repetitive tasks, gives faster feedback, and allows for more thorough coverage for regression checks. The main advantages of automated testing:

Speed for repetitive checks: Automated tests run in minutes instead of hours or days. Computers can run tests 24 hours a day, seven days a week, transforming the scale at which testing operates. What takes a manual tester a week might finish overnight.
Consistency: Scripts execute identically every time. No variation from tester fatigue, distraction, or forgetfulness. This reliability catches regressions systematically.
Broader coverage for stable features: Automation lets you test scenarios that would be impractical manually – 50 different data combinations, 20 browser versions, overnight regression runs.
Faster feedback on code changes: Automated tests integrated into your development pipeline give immediate feedback. Developers learn about problems within minutes, not days.
Better resource allocation: Automation handles repetitive regression checks, freeing your testing team for exploratory testing, complex scenarios, and cases requiring human judgment.
Cost efficiency over time: The upfront investment in automation tools and script development pays off when you run tests repeatedly.

What are the limitations of automated testing?

Automated testing solves specific problems well, but it has real limitations including:

High upfront investment: Writing automated tests takes considerably longer than creating manual test scripts. You'll spend weeks or months building a test suite before seeing returns.
Maintenance burden: Every time your software changes, your automated tests need updating. Features that change frequently means constant test maintenance.
Can't evaluate user experience: Automated tests check if functionality works, but can't judge whether something feels right to use or if the interface makes sense. They miss unclear error messages, confusing workflows, and visual inconsistencies.
Lacks human intuition: Automated tests only find problems you anticipated. They can't explore interesting paths, react to unexpected behavior, or spot the kinds of issues that make a tester say "that's weird."
Technical skills required: Building and maintaining automated tests often needs some level of technical or even development expertise. Not everyone on your team can contribute.

The pragmatic approach to automated testing

Automated testing has its place, but it's only as effective as the time and money you put into setting it up – and it won't help you find the problems you didn't anticipate.

Our advice is to automate when it's cost-effective. Don't treat automation as the goal. Use it strategically where the time investment actually pays off, and keep manual testing as your primary tool for discovering the unexpected.

If you're going to automate, focus your efforts on:

Core business functionality that absolutely can't break
Tests you'll run dozens of times per release
Checks requiring multiple configurations or large datasets
Stable features that follow predictable patterns

This is the same reasoning behind Martin Fowler's test pyramid: write lots of cheap, low-level automated tests, and far fewer of the slow, brittle end-to-end kind that break every time the UI changes.

Start small. Pick one repetitive test and see if automation saves you time. Don't build an automation suite because you think you should – build one because the math makes sense.

Want more practical testing advice? Subscribe to get straightforward tips on all things testing sent straight to your inbox.

Practitest vs 7 Alternative Tools: Which is Right for You?

Stefan Butlin — Fri, 30 Jan 2026 00:00:00 +0000

As companies scale and software development becomes more complex, managing testing across teams can quickly become overwhelming.

Testing tools come with their own pros, cons, and pricing models. Have an enterprise company but need a straightforward testing solution? Or are you a growing startup in need of a tool that scales with your projects? Figuring out what you need and the testing tool that will fit your exact goals can be tough.

PractiTest is one option in the testing tool world - and we break down its main features, pricing, and what actual users are saying about it, as well as how it compares to other alternatives on the market.

PractiTest: An Overview

PractiTest markets itself as a tool for QA teams and developers who want to collaborate on testing. Teams can assign tasks to users and share test runs with fellow team members and generally simplify project management across multiple projects by managing the entire testing process in one place.

Here are a few of the key capabilities of PractiTest:

Automation and Manual Testing Management: Supports automated and manual testing within one platform for greater testing coverage.
Customizable Reporting: Report dashboards are customizable to fit project goals and can be shared with anyone without a login.
Incorporates AI: Practitest uses Smart Fox AI assistant to speed up test creation by automatically generating steps and processes to fit testing needs.
Security: SOC 2 Type 2, ISO 27001, GDPR compliant, and an AWS Advanced Technology Partner.

Pricing

Team Plan - $49/user/month
Corporate Plan - Pricing is available upon request. Starts at 10 Tester Licenses

Integrations

Bug Trackers: Jira, Azure DevOps, ClickUp, Pivotal Tracker, YouTrack
Automation Tools: Selenium, Cucumber, Appium, FireCracker, xBot, LambdaTest
CI/CD Pipelines: CircleCI, Jenkins
Communication Tools: Slack
APIs: REST API for custom integrations

According to user reviews, here’s what Practitest’s users report as their likes and dislikes of the platform:

Pros ✅	Cons ❌
User-Friendly Reporting: Detailed and customizable reporting features	Outdated User Interface: Less intuitive and somewhat outdated UI
Collaboration Features : Task assignments and shared test runs improve teamwork and communication	User Difficulties: Users report difficulties editing dashboards or features that are slightly clunky to use
Support for Various Testing Types: Manages manual, automated, exploratory, and session-based testing	Filtering Issues: Users report that in general the filtering function could improve and be modeled off of other tools with successful filtering functions
Customer Support: Users say customer support responses are timely and comprehensive	Pricing: Higher cost can be a barrier for teams with limited budgets
Dashboard Functionality: Users report that Practitest’s dashboards allow better organization of testing.The ability to share results without project access ultimately helps team collaboration	Learning Curve: Steep learning curve for new users requiring additional training

PractiTest advertises itself as a solid testing option for large organizations with complex testing operations, but also offers a team plan with scaled back functionality. It is a comprehensive TCM tool, but smaller organizations (or those who simply want a straightforward testing solution) may not fit with what PractiTest offers.

Practitest Alternatives to Consider

1. TestRail

TestRail is a test case management platform that helps QA teams manage and track both manual and automated test results. It offers dashboards and reporting tools to monitor test cycle progress, pass/fail rates, and release risks.

Pricing

Professional Cloud: Starts at $37/user/month
Enterprise Cloud: Only available for annual billing of $852/user/year

Integrations

Defect and Requirements Integrations: Jira, GitHub Issues, Azure DevOps and more

CI/CD Integrations: Jenkins, GitHub, GitLab, Azure DevOps, Bitbucket, and more

Test Automation Integrations: Selenium, Cypress, JUnit, Playwright, TestNG, Sauce Labs, and others

Pros ✅	Cons ❌
Ideal for large organizations with complex testing needs and large QA teams	Testrail can be relatively expensive, especially for small teams
Detailed reporting features to track the entire lifecycle of testing	Customization options for fields and configurations can be limited
Extensive integration capabilities with a myriad of platforms	The user interface, while powerful, can be difficult for new users or those unfamiliar with testing tools to learn

2. Zephyr

Zephyr is a Jira plug-in, meaning that with Zephyr, you do all your test planning, management and execution within Jira – and not by using a separate application.

Teams already working closely with Jira can use Zephyr to blend into their established Jira projects while using the tool to collaborate with team members and unify testing data. It supports both manual and automated testing and offers different versions (Zephyr Scale, Zephyr Squad, and Zephyr Enterprise) to cater to various team sizes and needs.

Pricing

Zephyr Squad

1-10 users: $10 total per month
11+ users: $57.31 total per month, with an additional $5.21 per user monthly

Zephyr Scale:

1-10 users: Free
11+ users: $61.82 total per month, with an additional $5.62 per user monthly

Zephyr Enterprise

20+ users: Price available upon request

Integrations

CI/CD Tools: Jenkins, Atlassian Bamboo

Issue Tracking: Jira

Automation Frameworks: Selenium, Cucumber, Test Complete

Others: TestComplete, ReadyAPI, CrossBrowserTesting

Pros ✅	Cons ❌
Allows teams to work within their established Jira environments	Limited integrations compared to competitors due to being a Jira plugin
Collaborative features for teams enable better project management during testing cycles	Customers report a decline in speed of customer service responses
Zephyr can scale with teams and projects that grow in complexity	Exploratory testing cannot be done natively within Zephyr and is only possible with an additional external add-on
Customizable workflows can be built around project’s needs	Difficult to migrate from non-JIRA systems
Automation integrations allow users to report on automated test cases	Steep learning curve for new users

3. Tricentis qTest

Tricentis qTest is a test management platform focused on supporting Agile and DevOps practices. It integrates well with tools like Selenium and Cucumber, while also promoting its own automation tool, Tricentis Tosca. qTest mainly favors Tricentis ecosystem integrations, making it a good option for teams already using their products.

Pricing

Standard Plan: Custom pricing available upon request (however, pricing is generally quoted at $1,200/user/year)

Integrations

Issue Tracking and Project Management: Jira, CA Agile Central Rally, Tricentis Vera

CI/CD and Version Control: Jenkins

Testing Frameworks and Automation: Selenium, VersionOne

Pros ✅	Cons ❌
Suitable for Enterprise Companies: Capable of supporting large-scale enterprise environments	Cost: qTest’s pricing is comparably much higher than other tools
Flexible Reporting: Offers customizable dashboards and real-time reports	Complex Setup: Initial setup and configuration can be complex and time-consuming
Agile Support: qTest is set up to support teams using Agile methodologies	Limited Integrations: qTest prioritizes integration with the Tricentis platform over other tools, so integrations are limited compared to other tools

4. QAComplete

QA Complete is a comprehensive test management tool designed to support QA teams in managing their test cases, plans, runs, and defects. It offers a range of features for both manual and automated testing and includes document sharing, team calendars and customizable dashboards to better help teams collaborate in one central location.

Pricing

On premises plan - $999/year per concurrent user
Cloud based plan - $599/year per concurrent user

Integrations

Issue Tracking and Project Management: Jira, Rally, Bugzilla

Testing Frameworks and Automation: QTP, TestComplete

Pros ✅	Cons ❌
Flexible Customization: customizable to fit specific team workflows and testing requirements	Complex Setup: Initial setup and configuration can be complex and time-consuming for new users
Test Automation: Some users report QA Complete’s test automation integrations are easy to use	Learning Curve: Steep learning curve for users unfamiliar with test management tools
Enables Team Communication: QA Complete features sharing tools for teams that need to collaborate on testing	Customer support: Some users report that customer service could be improved

5. BrowserStack

BrowserStack is a cloud-based testing platform that allows QA teams to test their websites and mobile applications across various browsers, operating systems, and real devices. It enables access to 3000+ browsers and real iOS and Android devices, helping QA teams ensure cross-browser and cross-device compatibility.

Pricing

Live Desktop Plan

$29/month (billed annually)
$39/month (billed monthly)

Live Desktop & Mobile Plan

$39/month (billed annually)
$49/month (billed monthly)

Live Team Plan

$25/user/month (billed annually)
$30/user/month (billed monthly)

Live Enterprise Plan

Custom pricing

Integrations

Automation Frameworks : Selenium, Appium, Cypress, Playwright, Puppeteer, XCUITest, Espresso, et

CI/CD Tools: Jenkins, Travis CI, CircleCI, GitLab, Azure Pipelines, Bitbucket Pipelines, GitHub Actions, etc

Project Management : Jira, Trello, GitHub, Slack, Microsoft Teams

JavaScript Testing: Karma, TestCafe, Mocha, Jest

Cloud Providers: AWS, Azure, Google Cloud

IDE Extensions: Visual Studio

CMS: WordPress, Shopify

Pros ✅	Cons ❌
Real Device Testing: Provides access to a wide array of real devices and browsers for accurate testing	Cost: The pricing can be high for small teams or startups, especially for advanced features
Wide Set of Integrations: Browserstack has a varied list of integrations to meet most team’s needs with their existing tool stack.	Slow Performance: Users have occasionally reported slow performance and lag during testing
Scalability: Scales to meet the needs of large enterprises with high testing demands	Device Limitations: Testing on multiple devices is limited on free plan and some users report multiple device testing slows performance

6. Qase

Qase is a test management tool designed to help QA teams manage their test cases, plans, runs, and defects. It offers built-in AI to allow users to convert manual tests to automated test runs in multiple languages and frameworks.

Pricing

Free Plan: $0

Startup Plan: $19.20/user/month (billed annually)

Business Plan: $30/user/month (billed annually)

Enterprise Plan: Custom pricing

Integrations

Issue Tracking and Project Management: Jira, Asana, Monday, ClickUp, Trello, Azure DevOps, YouTrack, Redmine

CI/CD and Version Control: Jenkins, GitHub, GitLab, BitBucket

Communication Tools: Slack

Pros ✅	Cons ❌
Built in AI allows users to streamline automated testing	Users have occasionally encountered bugs or issues with integrations, particularly with Jira and other external tools
Users report that Qase customer support is quick and comprehensive in their responses	While Qase offers extensive customization options, some users find these features complex and challenging to set up initially
Qase has a clear and intuitive user interface, making it easier to navigate and use	Qase is relatively new compared to competitors and users say they are waiting for some of Qase’s features to match some other competing tools

7. Testpad

Testpad offers a straightforward, checklist-based approach to testing, perfect for agile teams that need to iterate quickly. It allows guest testers to participate without requiring logins, making it easy for non-testers to contribute. Testpad’s flexible design lets users adjust mid-test and run tests on mobile or tablet devices. With no need for extensive training or onboarding, it’s ideal for teams seeking an efficient and accessible testing solution. For a full side-by-side, see Testpad vs PractiTest.

Pricing

Essential: $59/month (or $49/month billed annually) for up to 3 testers

Team: $119/month (or $99/month billed annually) for up to 10 testers

Team 15: $179/month (or $149/month billed annually) for up to 15 testers

Department: $299/month (or $249/month billed annually) for up to 25 testers

Integrations

Lightweight integrations with Pivotal, Jira, and Github

Pros ✅	Cons ❌
Instant Reports: Quick access to progress reports with guest access for stakeholders	No automation integrations: Testpad does not support automated testing
Guest Testing: Invite testers without needing logins, ideal for non-technical participants	Lightweight integrations: May be less preferential to other tool’s full integration stack
Mindmap Style Test Planning: Native support for outline structure to build comprehensive test coverage	Likely not the right fit for enterprise organizations already using traditional TCM tools

Next Steps

Choosing the right test management tool ultimately depends on your team's specific needs, project scale, and budget.

PractiTest notably features automation support, customizable reporting, and strong security, making it a strong choice for large enterprises.

However, for those who don’t quite fit with what Practitest offers, Testpad's lightweight integrations and ease of use make it an excellent choice for teams looking for efficiency without sacrificing functionality.

Curious to try out Testpad? You can do so risk-free for 30 days, no credit card needed to sign up. You can test us out risk free and see if our unique approach to testing fits your testing goals.

Testpad is now SOC 2 Type 2 certified

Stefan Butlin — Mon, 26 Jan 2026 00:00:00 +0000

You may remember us announcing our SOC 2 Type 1 certification which verified our security controls were in place and working. Type 2 simply extends that verification over a longer monitoring period. Prescient Assurance audited our security practices over several months and confirmed everything works reliably – access management, vulnerability handling, infrastructure maintenance, incident response. Your data has been protected by these controls all along; Type 2 just documents it.

What's the difference between Type 1 and Type 2?

Type 1 examines your security controls at a single point in time and confirms they're properly designed and working on audit day. Type 2 examines both the design and the ongoing performance of those controls over an extended period. Essentially, auditors assessed whether our controls work in practice.

What this means for you

It means that your data has been protected by our controls all along. Type 2 is independent verification that our security processes work consistently over time. If your company requires vendor security certifications, Type 2 gives you that verification.

Beyond the certification

SOC 2 Type 2 is a significant certification, but security doesn't stop here. We manage security with a layered approach that reflects our Software as a Service (SaaS) framework.

We use highly respected cloud-service providers to manage data and provide our service – primarily AWS for infrastructure. We've implemented regular automated vulnerability scans, annual penetration tests, and regular software updates. Our SOC 2 Type 2 certification provides third-party verification that these security processes work consistently.

We're continuing to:

Monitor systems proactively for potential issues
Keep infrastructure updated and patched
Review access controls regularly
Respond quickly to incidents
Improve processes based on what we learn

You can see our full security approach on our Security page, including details on encryption, access controls, vulnerability management, and incident response.

What's next

We'll maintain Type 2 certification through annual audits. SOC 2 reports are valid for 12 months, so we'll undergo a new audit each year to verify our security controls continue operating effectively.

Have questions about our SOC 2 Type 2 certification or want to discuss our security practices? Email us at support@testpad.com – we’re always happy to chat.

6 Best Alternatives to Zephyr

Stefan Butlin — Fri, 23 Jan 2026 00:00:00 +0000

As a tester, finding a test case management (TCM) tool that your team really clicks with can take a lot of trial and error with different tools before you find the right one.

Zephyr has long been a favorite for many, especially for its close integration with Jira, making it a strong contender for teams already established in the Jira ecosystem. But, as we all know, no tool is one-size-fits-all. Depending on your team's unique needs, Zephyr's close ties with Jira and a few user-reported quirks might not always hit the mark.

Thankfully, there are several smart alternatives to Zephyr – whether you're after something lean and fast, packed with integrations, or just a bit less locked into Jira.

Quick answer: Best Zephyr alternatives

Testpad - Best for easy, checklist-based testing
Xray - Best JIRA alternative with advanced preconditions
QMetry - Best for AI-powered test management
PractiTest - Best for enterprise collaboration
Testiny - Best for reducing testing timelines
QA Touch - Best for mind mapping and planning
TestRail - Best standalone solution

What is Zephyr?

Zephyr is a Jira plug-in, a notable difference to most traditional test case management tools.

This means that, with Zephyr, you do all your test planning, management and execution within Jira – and not by using a separate application.

Teams already working closely with Jira can use Zephyr to blend into their established Jira projects while using the tool to collaborate with team members and unify testing data.

It has three levels of test management subscriptions and services aimed at teams of different sizes: Zephyr Enterprise, Zephyr Scale, and Zephyr Squad.

Zephyr Squad: Geared toward smaller agile teams, Zephyr Sqaud allows teams to use any existing Jira boards and utilize functionalities like “Components”, “Labels”, and “Priority”. Zephyr Squad is extendable via integrations with Jenkins, Selenium, JUnit, and Cucumber.
Zephyr Scale: The “scale” in Zephyr Scale implies its ability to handle multiple Jira projects and more extensive test libraries. Zephyr Scale is designed for teams who need better management features, traceability and reusability for larger test case libraries. In addition to the integrations of Squad, Scale also integrates with Babmboo, REST API, Qualio, and JUnit.
Zephyr Enterprise: Designed with enterprises in mind, this level of Zephyr can host up to 10,000 users and support up to 200,000 test cases. Zephyr Enterprise supports the widest selection of integrations including TestComplete, Ready API, Atlassian Jira, Jenkins, and Selenium.

Generally the following pros and cons are applicable to Zephyr as a tool overall, however, some features may be more applicable to Zephyr Scale or Enterprise.

Pros ✅	Cons ❌
Allows teams to work within their established Jira environments	Limited integrations compared to competitors due to being a Jira plugin
Collaborative features for teams enable better project management during testing cycles	Customers report a decline in speed of customer service responses
Zephyr can scale with teams and projects that grow in complexity	Exploratory testing cannot be done natively within Zephyr and is only possible with an additional external addon
Customizable workflows can be built around project’s needs	Difficult to migrate from non-JIRA systems
Automation integrations allow users to report on automated test cases	Steep learning curve for new users

Zephyr Pricing

Zephyr Squad:
1-10 users: $10 total per month.
11+ users: $57.31 total per month, with an additional $5.21 per user monthly.

Zephyr Scale:
1-10 users: Free.
11+ users: $61.82 total per month, with an additional $5.62 per user monthly.

Zephyr Enterprise:
20+ users: Price available upon request.

Why look for a Zephyr alternative?

Common reasons include:

Too complex for small or agile teams
Heavily tied to Jira
Expensive at scale
Clunky UI
Poor support for exploratory testing

So if you're looking for something that fits your workflow better, there are some great Zephyr testing tool alternatives around today.

Best Zephr alternatives (2025)

After reading through the description above, you may be asking: “What other alternatives to Zephyr might work for me?”

Finding the right testing tool is all about knowing what is a dealbreaker or an absolute must feature for you and your team. We understand finding the right tool can be a headache so we’ve compiled the following breakdown of alternative options to Zephyr to make comparing your options easier (and Ibuprofen-free).

TestRail

TestRail is a standalone test management tool (not a Jira plugin) that offers a full-featured platform for planning, tracking, and organizing software tests. It’s well suited to teams that want detailed control over their test cases, structured test plans, and in-depth reporting – without being locked into Jira.

Here are some of the key features that TestRail offers that Zephyr Squad and Zephyr Scale do not:

A fully standalone test management environment, independent of Jira
A customizable UI with built-in support for milestones, test runs, and suites
Rich reporting tools, including activity reports, coverage reports, and progress tracking
Advanced user permissions and audit logging
Powerful API access for integrations and automation

If your team is looking to level up from Zephyr and wants more flexibility, deeper reporting, and a dedicated test management environment, TestRail could be a strong option – especially if you're working across multiple tools or need something external to Jira. And if you're weighing it against lighter-weight options, our Testpad vs TestRail comparison covers when each fits.

Pricing

TestRail Cloud (Professional) starts at $35/user/month billed annually ($420/user/year), or $37/user/month billed monthly, with a 30-day free trial available.

An on-premise (Server) deployment option is available with 10 or more users and a 12-month minimum contract.

Integrations:

Automation: Selenium, JUnit, NUnit, TestNG
CI/CD tools: Jenkins, GitLab, Azure DevOps, CircleCI
Other Integrations: Jira, GitHub, GitLab, Bugzilla, Redmine, Asana, Trello, and a robust REST API

Pros ✅	Cons ❌
A mature and robust environment for managing complex test suites	Can feel heavyweight and process-heavy for smaller or more agile teams
You’re not tied to Jira – ideal for teams using other tools or working cross-functionally	The UI can feel dated compared to newer tools
Detailed reports, charts, and dashboards help monitor testing progress in real time	Higher price point compared to many Jira-native test management plugins
Supports both manual and automated testing workflows	No exploratory testing features built-in – you'd need to supplement with another tool

When it comes to Zephyr vs TestRail, the choice often comes down to flexibility – TestRail offers a more powerful standalone platform, while Zephyr keeps everything inside Jira.

Xray

Like Zephyr, Xray is a Jira plugin used for test case management. While both plugins tackle similar processes (test case writing and execution). Xray has a few features that Zephyr does not that may make it the chosen tool for those who still want to work natively inside Jira.

Here are a few capabilities that Xray includes that cannot be done with Zephyr Squad or Zephyr Scale:

Preconditions for test cases with the ability to reuse and assign multiple preconditions
The capability to manage all tests as Jira issue types, allowing for full configuration of screens, workflows, and custom fields directly related to testing
Support for splitting test executions and plans between different projects
Ability to import results from: Cucumber, JUnit, NUnit, Robot framework, Behave, Selenium, Xamarin Test Cloud

Every team’s testing needs are different so if you see something in the list above that you definitely want or need, Xray would likely be a solid option for you if you are comfortable working with a Jira plugin.

Pros ✅	Cons ❌
Xray is fully integrated with JIRA, allowing teams to keep their established Jira environments	Like Zephyr, Xray requires an additional app to undertake exploratory testing
Offers detailed reporting and real-time test metrics to assess quality and progress	Xray is JIRA dependent which may not be ideal for teams not using Atlassian products
Allows full traceability between requirements, tests, defects, executions	Xray does not enable native exports to Excel of test results and requires another app to do so

Xray Pricing

Xray Standard - Up to 10 Jira users cost $10/month with additional users adding $6.50 each per month to the total monthly bill
Xray Enterprise - Up to 10 Jira users cost $15/month with additional users adding $6.50 each per month to the total monthly bill

Integrations

Automation: JUnit, NUnit, Cucumber
CI & DevOPs tools: Jenkins, GitLab
Other Integrations: Rest API, BDD scenarios inside Jira

QMetry

QMetry introduces itself as an “AI Enabled Quality Orchestration Platform built for Test Automation”. A bit of a mouthful, the distilled version is QMetry is integrating Generative AI to help with automating test case generation and improving their search function.

While QMetry positions itself as a tool to assist with test automation, it also supports manual testing.

It offers capabilities for test case creation, execution, and management, while also providing predictive analytics (backed by AI and machine learning) and dashboard features. QMetry also supports test automation frameworks and provides tools for traceability, requirement management, and defect tracking.

QMetry offers two product versions:

QMetry Test Management for Jira (QTM4J) - Available on the Atlassian marketplace, this version of the tool resembles Zephyr as it manages the entire testing cycle within Jira.

QMetry Test Management (Enterprise) - Aimed at enterprise level companies, this version of QMetry can scale in or outside of Jira. With its enterprise package, businesses can take advantage of migration services from other popular TCM tools when moving over to QMetry.

Pros ✅	Cons ❌
Supports both manual and automated testing	Some ambiguity around AI features and how they impact the testing process
AI-driven features for optimizing testing processes	The initial setup and learning curve can be steep
Strong integration with JIRA and other development tools	Difficult to find information about pricing and other features of Qmetry

QMetry’s pricing

QMetry Test Management for Jira (QTM4J):

1-10 users - Free.
11+ users - $36.30 total per month, with an additional $3.30 per user monthly.

QMetry Test Management (Enterprise):

Per user - $720/user/year.

Navigating QMetry’s site and understanding what they offer and how it’s priced can be a little tricky compared to some of its competitors. If you run into questions it may be worth reaching out to their team.

QMetry’s Integrations

DevOps CI/CD tools: Jenkins, Bamboo, and Maven
Automation frameworks: QAF, TestNG, JUnit, Cucumber, UFT, and Specflow

QA Touch

Like other TCM’s on our list, QA touch leads with being an AI-driven test case management tool.

QA Touch features built-in bug tracking, customizable timesheets, mind mapping for project visualization, and a detailed audit log. The platform aims to promote efficiency with its agile board for task management and a shareable dashboard that provides a real-time overview of testing progress and metrics.

Pros ✅	Cons ❌
Unique features for test planning, like mind mapping, allows for more detailed test planning	Some users report that import functionality is a bit complex compared to other tools
Users report that QA Touch’s support team is responsive to issues in their system and work to fix those issues at a reasonable speed	Reviewers have commented that AI features could be improved
QA touch offers many users guides and help documents to navigate using the tool	Users report UI can be difficult to work with

QA Touch Pricing

Free Plan - $0 per month, with limited projects and test cases
Startup Plan - $5 per user per month
Professional Plan - $7 per user per month
Unlimited Plan - $15 per user per month, with unlimited projects and SSO

QA Touch Integrations

Two-Way Integration: JIRA Cloud, Monday.com, GitHub, GitLab
Issue Tracking Integration: JIRA Software, Trello, YouTrack, Redmine
Collaboration and Productivity: Slack, Microsoft Azure Boards, Bugzilla, Bitbucket, Asana

PractiTest

PractiTest is a tool for QA teams and developers who want to collaborate on testing. Within PractiTest teams can assign tasks to users and share test runs with fellow team members.

Pros ✅	Cons ❌
Collaborative functions within the tool to accommodate groups and teams	New users or those unfamiliar with test management tools may require training to learn the interface
Customizable dashboards to focus on specific tests and datasets	Pricing can be expensive, and its pricing structure may not be cost effective for smaller teams
Supports Session Based Test Management (SBTM) for teams who like that formalization of Exploratory Testing	Pricing can be a barrier to entry for teams with smaller budgets

PractiTest Pricing

Team Plan - $49/user/month
Corporate Plan - Pricing is available upon request. Starts at 10 Tester Licenses

PractiTest Integrations

Bug Tracking - Jira, Azure Dev Ops, Click Up, Pivotal Tracker, YouTrack
Automation - Rest API, FireCracker, Circle CI, Cucumber, Xbot, Selenium
More Integrations - Jenkins, Git Hub, GitLab, Slack, Zapier, LambdaTest

Testiny

Testiny markets itself as a tool to reduce testing process timelines in order for QA professionals to have comprehensive testing coverage while still meeting the deadlines of tight development cycles. Those who need customization with their testing can utilize Testiny’s custom fields and templates to better organize complex testing workflows, further cutting down on testing time.

Pros ✅	Cons ❌
Comprehensive reporting and real-time analytics that help track and analyze test results	Learning curve for some features or people new to testing
This tool is able to scale test cases with growing teams or increasingly complex projects	Limited integrations compared to other tools
Built with strong features for team collaboration	While “view access” is available it is not free and comes at a discounted monthly rate that must be added to subscription costs

Testiny Pricing

Free Plan - Suitable for small teams up to 3 people, providing basic functionalities. ($0/per month)
Starter Plan - Aimed at medium-sized teams requiring more features, storage, and support. ($18.50/user/month)
Enterprise Plan - Best for large teams or entire test departments, offering extensive features including Single Sign-On (SSO), audit logs, and priority support. ($30/user/month, with custom enterprise arrangements also available)

Testiny Integrations

Issue Tracker Integrations: Jira, GitHub, GitLab, Azure DevOps, Redmine, Asana, Basecamp, Bugzilla, ClickUp, Confluence, Linear, Monday.com, Pivotal Tracker, Todoist, Trac, Trello, Wrike, YouTrack, ZenDesk
Key features include test case management, dynamic test planning, real-time metrics and reporting, and team collaboration capabilities.
Manual, automated, and API testing are all supported on this platform.

Testpad

Many of the tools listed above are quite similar to one another, all belonging to what we like to call “traditional” test case management tools.

But Testpad breaks this mold, taking a distinctly different approach by building test plans around simple checklists that look more like a spreadsheet than a complicated database-driven collection of formal Test Cases. A much simpler alternative to Zephyr, our "freeform" checklist approach doesn't constrain the test team and lets them build their test plans in styles that suit them and their process requirements.

Testpad is designed to get testing done quickly (it's easy and obvious how to iterate on test plans when they're just checklists that look like spreadsheets). Teams that need to iterate and move fast will find Testpad’s straightforward and lightweight design just perfect for getting tests done versus fighting through managing a complex testing platform.

When it comes to Zephyr vs Testpad, here’s where our offering differs and might be what you’re looking for in your testing tool search:

Flexibility: Unlike Zephyr, which operates entirely within JIRA, Testpad is not limited to any single issue or project tracking tool. This flexibility is well suited for teams that use multiple systems, those not committed to the Atlassian ecosystem, or those who want to test without a heavily structured process.
Exploratory Testing Capabilities: Testpad supports exploratory testing natively, without the need for additional add-ons. This allows testers to perform more organic and intuitive testing, which can be crucial for catching unforeseen issues or finding ways to improve your product.
Guest Testing & User Accessibility: Testpad enables guest testing in order to help people bring in extra effort when they're late for a release, without having to pay for extra licenses. You’ll also be able to invite clients to perform user-acceptance tests, without having to add clients as users or otherwise indoctrinate them into your test platform.
Expansive & Efficient Testing Process: If you're into mind maps for test planning, then you'll enjoy using Testpad checklists as a listed-out form of a mindmap, allowing you to build a comprehensive outline of every testing detail. With instant reports, Testpad ensures that progress tracking and updates are immediate, straightforward, and effectively include all parties involved.

For a full side-by-side, see Testpad vs Zephyr.

Testpad Pricing

Essential: Basic account for up to 3 users, $49/month, billed annually
Team: Fully featured account for up to 10 users, $99/month, billed annually
Team 15: Fully featured account for up to 15 users, $149/month, billed annually
Department: Fully featured account for up to 25 users, $249/month, billed annually
Custom: Bespoke arrangements can be made for bigger teams

Final Thoughts

Yes, most tools offer very similar functionality and it's hard to choose between most of them.

The differences will be in their pricing and nuances of how their features work, but the evaluation of these will be unique to each team.

With that said, Testpad does sit apart with its unique approach, and if that sounds interesting, we offer a free 30 day trial– no credit card details needed to sign up. You get to test us out risk-free and see if our unique approach to testing fits your needs.

Frequently asked questions

Is it hard to switch from Zephyr to another test management tool?

It depends on how much data you have and how deeply Zephyr is integrated into your setup. But most modern Zephyr test management alternatives – including Testpad – offer import tools or migration support to help make the switch smoother.

Can I use a test management tool without Jira?

Absolutely. Tools like Testpad, TestRail, and QA Touch work just fine without Jira, and often integrate with other project management platforms if you need them to.

What's the most cost-effective alternative to Zephyr?

For small or growing teams, Testpad is one of the most affordable Zephyr alternatives out there. For larger teams, QA Touch and Testiny offer solid features with enterprise-friendly pricing.

Will I lose my test history when leaving Zephyr?

No – most Zephyr testing tool alternatives support test case import. You might need to do a bit of tidy-up post-migration, but your data should make the jump just fine.

Which Zephyr alternative is easiest to learn?

Testpad is designed to be intuitive from the get-go. Its clean, checklist-style interface feels familiar right away – so most teams can dive in and start testing within hours, not weeks.

What is unit testing?

Stefan Butlin — Thu, 22 Jan 2026 00:00:00 +0000

Unit testing is a type of automated testing where developers check the smallest pieces of code (functions, methods, or classes) in isolation to confirm each behaves as expected. This guide is written for testers, not developers. You probably don’t write unit tests, but understanding what they do, and what they miss, changes where you spend your time.

At a glance

Unit tests are automated checks written by developers for individual functions, methods, or classes
They catch logic bugs early but don’t test user journeys, UI, or how features interact
Testers benefit from unit tests without writing them: fewer broken builds and trivial bugs reach QA
Chasing 100% coverage creates busywork; good teams focus unit tests on complex or risky logic
Focus your manual testing on what unit tests can’t check: real user behavior, workflows, and usability

The rest of this post covers what unit testing does and doesn’t test, who writes unit tests, and how to make the most of them as a tester.

What unit testing tests (and what it doesn’t)

A unit test checks one small, very specific piece of logic in isolation and nothing more. Even the definition of a “unit” varies between teams; Martin Fowler notes that the common ground is tests that are low-level and focus on a small part of the system. For example, a developer might write a unit test to confirm that:

A discount is calculated correctly
An error is returned when required data is missing
A validation rule behaves as expected

The test sets up some input, runs the code, and checks the output. If the result matches expectations, the test passes. If not, it fails. Because unit tests are tightly focused, failures are usually very precise. When a test breaks, developers can see exactly which part of the code is responsible, without stepping through unrelated features.

This early feedback is why IBM often positions unit testing as part of a shift-left approach – catching defects as early as possible, when fixes are faster and significantly cheaper than later in the lifecycle.

What unit testing does not do is test how features behave from a user’s point of view. It doesn’t validate workflows, layouts, usability, or whether a feature makes sense in context.

Who writes unit tests (and who doesn’t)

Generally speaking, unit tests are written and maintained by developers. They live alongside the code and usually run automatically as part of the development process.

Testers typically:

Don’t write unit tests
Don’t manage them in test case tools
Don’t run them manually

And that’s because unit testing exists to protect the code, whereas testing exists to protect the product. How testers influence unit testing is indirect. If the same type of logic bug keeps appearing during testing, that’s often a sign a unit test could prevent it happening in the future. You don’t need to write the test, but spotting the pattern and raising the risk is valuable.

Why does unit testing matter if you’re not a developer?

Good unit testing changes the shape of testing work because it catches simple errors early, letting QA concentrate on the issues that really affect users. When unit tests are in place and kept up to date:

Basic logic bugs are caught earlier
Fewer broken builds reach testing
Less time is spent logging obvious defects

Unit tests reduce the number of simple code-level bugs, which means testers can focus on:

Realistic user behavior
End-to-end workflows
Edge cases across multiple features
Clarity, usability, and intent

What does unit testing miss?

Unit testing checks code logic and nothing else; whole categories of problems sit outside its reach.

Unit tests do not:

Verify that features work together
Validate real user journeys
Check layout, accessibility, or responsiveness
Catch configuration or environment issues
Replace exploratory or manual testing

A feature can pass every unit test and still be confusing, frustrating, or broken from a user’s point of view. That’s not a failure of unit testing; checking the product from a user’s point of view was never its job.

Unit testing vs other types of testing

Rather than thinking in terms of “unit testing vs manual testing”, it’s more useful to see testing as layered, with each type covering different risks.

Testing type	Who owns it	What it’s good at	What it won’t catch
Unit testing	Developers	Checking small pieces of logic in isolation	User flows, UI issues, integrations
Integration testing	Developers / QA	Verifying components work together	Full end-to-end behavior
System testing	QA / testers	Testing complete workflows	Internal code logic
Manual & exploratory testing	Testers	Finding real-world issues and usability problems	Repeatable low-level checks

Unit testing supports everything above it by keeping the foundations stable. It doesn’t replace other testing – it makes it more effective.

Common misconceptions about unit testing

You may have heard a few persistent and problematic myths about unit testing, so let’s clear them up.

“If we have unit tests, we don’t need manual testing.”

Not true. Unit tests confirm the code behaves as expected. Manual testing confirms the product behaves sensibly.

“Unit tests should cover everything.”

In practice, chasing 100% coverage often creates busywork. Experienced teams focus unit tests on logic that’s complex, risky, or business-critical.

“Unit testing slows development.”

Writing tests does take time upfront, but catching bugs early and providing a safety net for future changes saves time overall. Testers benefit because fewer trivial bugs reach QA.

How can testers make the most of unit testing?

Testers don’t need to write unit tests to benefit from them. What testers can do is:

Notice recurring logic issues and flag them early
Highlight high-risk areas where unit tests could help
Avoid duplicating unit-level checks in manual test cases
Focus effort on behavior, workflows, and real-world usage

If a problem can only be found by thinking like a user, unit tests won’t catch it – and that’s exactly where testers are essential.

Want more practical testing advice?

Subscribe to get straightforward tips on all things testing sent straight to your inbox.

Software testing basics to get you started

Stefan Butlin — Mon, 19 Jan 2026 00:00:00 +0000

Software testing means interacting with your product, trying different things, and seeing what works and what doesn't. The goal is finding problems early, when they're cheap and easy to fix, rather than after you've shipped to customers. It doesn't take formal processes or expensive tools to get started, just a handful of basics.

At a glance

Software testing means interacting with your product to find problems before users do
Every team needs three things: a list of what to test, a record of results, and a habit of testing before each release
A plain text checklist is enough to start; add tools only when you outgrow it
Focus first on core user workflows, edge cases, and anything that would embarrass you if it broke

The rest of this guide covers what testing is, the main types worth knowing, how to start, and the most common mistakes teams make.

If you're new to testing, it can feel overwhelming. There's loads of terminology, different types of testing, and tools claiming you need them – but most of it is unnecessary.

What is software testing?

Testing is discovering as much as possible about your product so you can decide what to do next. It's asking "are we ready to launch yet?" and having a real answer. The ISTQB Foundation syllabus defines software testing as "a set of activities to discover defects and evaluate the quality of software work products". In practice that means good testing finds bugs before users do, checks features work as intended, probes edge cases that might break things, and gives you confidence about what you're shipping.

Testing happens throughout development, not just at the end. The earlier you find issues, the easier and cheaper they are to fix.

You can read more about what software testing is in this blog.

Do you really need testing?

Yes. Even small products benefit from basic testing.

Without testing, you're gambling that everything works. You'll ship bugs and users will hit them, which can be embarrassing and cost you customers. You'll spend a lot of time firefighting instead of building new features. Testing doesn't have to mean formal processes or expensive tools, though. It can be as simple as clicking through your product before you ship, trying different inputs, and checking things work.

What do you actually need to start testing?

Strip away all the jargon, and testing really comes down to three simple ideas: what you're testing, when you tested it, and what happened. Everything else is just different ways of organizing or describing these basics. Here's what actually matters.

Test cases

A test case is just an instruction for what to test. It might be a simple prompt like "user can log in" or a detailed list of steps to follow. Keep test cases as simple as your situation allows. Detailed formal test cases have their place, but most teams benefit from shorter, simpler prompts.

Test runs

A test run is one pass through your tests. You might do multiple test runs – testing on different browsers, testing after each code change, or having different people test the same thing.

Pass/fail

The simplest way to record what happened. For each test, did it pass or fail? Mark it green or red. This gives you a quick visual overview of what's working and what isn't.

These three basics are exactly how Testpad models testing: each test is a line of plain text, indented lines add structure, each test run is a column, and the pass/fail marks build a grid you can read at a glance.

What are the main types of testing?

Testing has lots of different types and names, and they often overlap. Don't let that intimidate you. Most teams use just a handful of these, and you don't need to treat them as strict categories. Here are a few of the main types:

Manual testing

A human interacts with your software – clicking, typing, observing what happens. This is the most practical form of testing. Here’s how to get started.

Automated testing

Testing performed by scripts or programs rather than humans. Automated tests run quickly and repeatedly, making them ideal for checking the same things over and over – like verifying login still works after code changes or that calculations remain accurate across builds.

Exploratory testing

Testing where you're free to explore the product, inventing tests as you go and reacting to what you find. This is easily the best kind of manual testing. Get to grips with exploratory testing here.

Functional testing

Checking if features work as intended. Does the login accept valid passwords? Does the shopping cart calculate totals correctly? Most testing is functional testing, even if teams don't call it that.

Regression testing

Making sure previously fixed bugs stay fixed. Every time you find and fix a significant bug, add a check for it. That way you'll catch it if it comes back. Regression testing can be manual or automated.

We talk in greater detail about the various types of testing on this page.

How do you start testing?

Start simple and don't worry about formal processes or tools yet.

1. Make a list of what needs testing

Write down the main features or areas of your product. Keep it simple – bullet points work fine. This becomes your testing checklist.

2. Work through your list

Go through each item. Try it. See if it works. Note anything that seems broken or weird. Don't overthink this. Just interact with your product like a user would and pay attention to what happens.

3. Try edge cases

Edge cases are unusual scenarios that might break things. Maximum values. Empty inputs. Weird combinations. These often reveal bugs. Focus on edge cases that could realistically happen and would matter if they failed.

4. Keep notes

Record what you tested, what worked, and what didn't. This doesn't need to be formal. Simple notes are fine. Good notes help you remember what you've covered and make it easier to report issues to whoever needs to fix them.

5. Test regularly

Don't save all the testing for the end. Test as you build, before you ship and after you ship. Regular testing catches issues early when they're easiest to fix.

How much testing is enough?

There's no magic number. It depends on your product, your users, and what's at stake if something breaks. A good rule: test enough that you're confident about shipping. If you expect users to find major bugs, you need to test more.

Focus testing on areas that matter most. Not everything deserves equal attention. Think about what would cause the most damage if it broke – that's usually payment processing, data handling, and core workflows. Test high-use features more than rarely-used ones, and test things that change more than things that don't.

What tools do you need?

You don't need special tools to start testing. A text file or spreadsheet works fine for simple products. As testing grows, dedicated tools help – test management tools organize your tests and track results.

Choose tools that match your needs. Don't adopt complex tools because you think you should. Many teams over-tool and waste time managing their tools instead of doing the actual testing.

What mistakes do most teams make when they start testing?

Most teams make the same testing mistakes early on. Some waste a bit of time, whereas the ones listed below waste a lot (which is why it’s worth knowing about them beforehand).

Waiting until the end to test. Test throughout development because finding bugs late is expensive and stressful.
Only testing the happy path. Things break at the edges. Test error conditions, edge cases, and unusual inputs.
Testing your assumptions. Test what users will actually do, not what you think they'll do. Users are creative at breaking things.
Making testing too formal. Rigid processes slow you down, so keep testing as lightweight as possible while still being effective.
Thinking automation replaces manual testing. Automation is useful but limited – you need both. Read our guide on manual vs automated testing for more on this.

Getting better at testing

Testing is a skill that improves with practice. The more you test, the better you get at spotting potential issues. Remember to stick to the basics and keep your testing simple and focused on finding real issues. Don't get caught up in terminology or formal processes unless they help you ship better software. Want more testing insight? Subscribe to our emails.

Test Scripts - don’t make them so hard

Stefan Butlin — Mon, 19 Jan 2026 00:00:00 +0000

Testing is all about learning and providing information; learning about the state of the product, informing stakeholders, and therefore making informed decisions – which often boils down to asking and answering ‘are we ready yet?’. To do this repeatedly, reliably, it’s a great help to have a plan, to have something written down to guide the testing and make sure you remembered to take a look at everything. This is where test scripts come in.

But there’s ambiguity in the term “test script”, with different teams using it for different things particularly, the manual side of the software testing process– the testing that you do by hand. We’re also here to encourage you not to overthink test scripts (test planning), prioritizing pragmatic action rather than superficial process.

What is a test script?

Essentially, test scripts are a list of tests to carry out during the testing process. This might be executed by some software as part of automated testing, the test script being the piece of code that defines a series of checks to make. In manual testing a test script is simply a list of instructions for a human to follow. It’s these lists of manual instructions that we’re focusing on.

Test scripts (for humans to read and follow) come in many flavors. Some simple. Some overly complicated. It all depends on the context and what the software team wants to achieve, with what resources, at what cost and in what timescale.

For example, you may want to verify that a “forgot password” link works as designed or an edit button actually allows users to edit. Your test script for the testing around these components could then vary between being:

a very detailed collection of exact steps to take and precise descriptions of expected outcomes
a short list of simple statements reminding the tester of the main aspects to take
a look at the original user scenarios or product features that the developers used when designing and building the software
a collection of ideas that the testers should experiment around

…or anything in between.

Having a list of prompts is helpful in all the ways checklists are helpful. As such, test scripts:

Keep your testing organized, which is especially beneficial if you have a diverse and complex set of features.
Reduce the risk of missing (not looking at) aspects of functionality and letting mistakes slip into production.
Decrease cognitive load, allowing testers to focus on execution rather than trying to remember what to test.
Enable progress tracking: the team and stakeholders can see what’s been looked at and what’s still to go.
Promote accountability, making it clear who is responsible for testing what, when, and how.

Why start with manual test scripts?

So why are we talking about manual test planning here, why not just skip straight to automating all your tests so that a computer can run them in seconds every time developers make the smallest change?

Well, it’s not that simple. And we’ve got a whole article on not only automating your testing. But the jist is, it’s usually much much easier to get started (you just write them down), much easier to add or edit (you can do so on the fly), and much easier to understand whether you’re testing the right things (a real person has deduction skills and practical experience).

That's not to say you can’t convert some of your manual test scripts to automated tests over time, but you need to remember automated tests aren’t the same (think fixed programmed checks versus an inquisitive intuitive human hunting for problems), and that automated tests are themselves more code that can be expensive to develop and come with its own testing and maintenance overhead.

What’s the difference between a test plan, a test script, and a test case?

As we’ve just covered, a test script (in manual testing) is a list of stuff to remember to do when testing – however detailed or not said “stuff” is defined.

A test case, on the other hand, refers to one test description. Usually, test cases are well-defined and come with common structure including:

Title
The environment or pre-conditions
Specific steps to execute
Expected outcomes
Optional extra metadata, such as priority, user roles, etc.

But – and there’s always a but – a test case could just be a single sentence, very much like a test script.

A test plan can also mean different things to different teams. Test plans sometimes refer to the strategic document that sets out how the test process will be conducted, including high-level objectives, resources, scope, what tests to run, how they will be carried out, and in what timescales.

But a test plan can be (and often is) just a list of things to test, i.e. a complete test script!

At the end of the day, it’s all semantics. What really matters is whether or not you actually get some testing done, learn about the state of the product under test and make informed decisions.

How to write a test script … it’s easier than you think

Producing a test script does not have to be difficult, or require hours of analysis. If this is your first go at writing test scripts or planning some tests, then keep it simple and try the following ideas as a place to start.

1. Make a list of user stories or main features

If your engineering team is taking an agile approach to feature development, there’s a high chance a list of user stories exist.

User stories are often in the format ‘Fred, who has an admin account, should be able to do X when Y,’ which makes it fairly easy to come up with a list of tests.

It’s actually perfectly sufficient to just list each user story (or feature, or requirement statement) as your test script. You would then be expecting your testers to dig into each user story, experimenting and exploring, looking for issues.

You might also have a quick think about each user story and list out several ideas for aspects of each to take a look at. For example, for the Fred user story, you could test whether:

Fred can log in as an admin
Scenario Y exists
Fred can do X when Y

Prompts for these test scripts could be written down as formal test cases with criteria around them, but they’re arguably more useful as just a list of one-word features or user scenarios to test, like the bullets above. You should choose what type to use based on the context of your team's needs… which leads us to…

2. Add some context

When you’ve got your list of features or user stories to test, optionally with additional ideas per item, you’re nearly there and might already be ready to start testing. But you might want to pause for a moment and consider who your tester will be, what their experience is with the product, and how much instruction they’ll need.

For someone less experienced, a one or two-word test may be far too vague. “Check ABC” may mean nothing to them if they don’t know what ABC is or how it’s supposed to work. While writing out step-by-step instructions for multiple test scripts is tedious, doing so will help train new testers and lead to more accurate testing results.

On the other hand, detailed guidance is probably too cumbersome for a knowledgeable tester if they’ve tested a feature a hundred times before. And if a feature changes, revising all the detailed test scripts is a huge pain.

In general, we encourage teams to keep it simple. It’s faster to write, less to maintain, and means you’ll probably come up with many more tests and ideas. And remember, if concerned about giving enough guidance to a new tester, if they’re staying on your team, they’re only new once, so consider not overly documenting your tests for their first time and instead just help them the first time.

Here are two test script examples to draw from

Say we’re testing a note-taking app. Your script could be as simple as these bullets:

Test Script Example 1

User interface
Authentication
Create/edit/ delete
Search function
Device compatibility

Someone who’s been testing that app for a while would know what all that means and can explore as necessary.

But for a test team that needs a bit more guidance, we could iterate the above starting point with a few more ideas per topic.

Test Script Example 2

General UI

Check all the buttons, menus, and icons to ensure they are visible and functional
Ensure the text input area is correctly aligned
Test the app’s accessibility features, such as screen reader support and keyboard navigation

Authentication

Verify that login and logout functionalities work correctly
Test password protection and recovery mechanisms

Creating notes

Create a new note and make sure it saves
Check formatting options – bullets, numbers, links
Verify that auto-save works
Add tags for specific categories

Viewing notes

Confirm that previously created notes display in list form and can be clicked into
Make sure you can sort them by date, title, or category
Try using different keywords to make sure the right notes appear in search results

Editing and deleting notes

Verify that the edit button works and you can make updates to notes
See if changes save correctly after editing
Confirm that notes can be deleted and are removed from the list of notes

Compatibility

Test the app on multiple devices (tablet, mobile phone, laptop, desktop)
Test the app on multiple browsers (Chrome, Firefox, Safari, Edge)

At this point, if you want to go as far as building a collection of detailed test cases to form your test scripts, you could then, per item, come up with individual test cases (titles, steps, expected outcomes) detailing exactly what to test. However, the over-specification of what to check will miss out on all the inquisitive, intuitive exploration testing that a human could otherwise give you per topic… which we think is a better direction to go.

Our advice when it comes to test scripts? Just start.

Doing some testing is better than doing no testing at all. Start with what you can and then improve the process and go more into detail, slowly creating test scripts and modifying them over time.

A good way to adopt this iteration approach is to write and store them in a centralized location, like a spreadsheet or testing tool. The unified view keeps everyone organized and makes for easier progress reporting down the line – especially as your testing complexity develops.

So when it comes to choosing a tool for your test scripts, you have a lot of options to choose from. Really, anything will do, it doesn't have to be complicated (post-its, spreadsheets, whiteboards.) Testpad, which has been designed with exactly this simple and pragmatic kind of test planning in mind, would also be a good place to start, and yes, we're rather biased here.

We’ve kept it super lightweight - It feels like using spreadsheets but without the formatting headaches.

We’ve made it easy to learn and use- you don’t need qualifications in testing or training courses.
We’ve made it easy to define tests with hierarchies, folders, tags, and filters.
We’ve got simple fast reporting for at-a-glance progress and result visualization, showing what is against what isn't.

If you’re in the market for a new testing tool or you’re looking to enhance your test script planning, give Testpad a try. You might as well – our trial is free for the first 30 days.

8 Best Tricentis qTest Alternatives for Efficient Test Management

Stefan Butlin — Sun, 18 Jan 2026 00:00:00 +0000

Software testing is crucial for understanding the state of your software and informing stakeholders. Test management tools help structure this process, though they're not essential for all teams.

qTest is a popular choice, but like most tools in this space, it may not suit every team's needs. Many alternatives offer similar core features, often with slight variations in approach or focus.

When choosing a test management tool, consider your team's size, budget, existing workflows, and specific testing needs. Remember that while these tools can enhance efficiency, the most important factor is how well they align with your team's processes and requirements.

What is qTest?

qTest advertises itself as a comprehensive agile test management tool, aiming to enhance project management, test suite management, and bug tracking. Like many competitors, it claims to offer insights across the entire testing lifecycle, covering projects, builds, cycles, and suites.

Agile test case management

As with most modern testing tools, qTest supports agile methodologies. It allows teams to adapt to changing project requirements and facilitates the development, modification, and implementation of test cases, aiming to align with agile development's rapid pace.

Project management and bug-tracking features

A key differentiator for qTest is its integrated bug tracking functionality. Unlike many competitors that rely on integrations with external tools like Jira, qTest offers built-in capabilities for identifying, logging, and resolving defects. This integration potentially streamlines the development-test cycle by keeping all testing-related activities within a single platform.

Comprehensive lifecycle insights

Like many tools in this space, qTest emphasizes its ability to provide detailed insights into the testing lifecycle. This includes tracking test execution progress, visualizing test coverage, and generating in-depth reports on test results. These features aim to give teams a holistic view of their testing efforts, though the actual utility can vary depending on a team's specific needs and processes.

Key features of qTest

Cloud and on-premise deployment: qTest offers both cloud-based and on-premise deployment options, accommodating different organizational preferences and security needs.
Interactive heat maps and dashboards: The tool includes interactive heat maps to show object type and severity and customizable dashboards that visually represent testing data, helping teams quickly pinpoint application flaws and delve deeper into analysis as necessary.
Integration with agile and DevOps tools: qTest integrates smoothly with a broad array of agile and DevOps tools, boosting collaboration and ensuring that testing aligns closely with development and deployment processes.

Common use cases and benefits

qTest’s features cater to both agile and traditional workflows, offering flexibility to adapt to different team structures and project requirements.

Common use cases:

Large-scale enterprise projects requiring extensive test coverage and detailed reporting
Cross-functional teams needing centralized test management and bug tracking
Organizations transitioning between different development methodologies

Benefits:

Test coverage through systematic test case management
Defect tracking and resolution, streamlining the development-test cycle
Team collaboration via integrated tools and shared dashboards
Data-driven decision making supported by comprehensive analytics and reporting

Pain points and limitations

While qTest offers advantages for various team structures and methodologies, its complexity and cost may present challenges for smaller teams or those with simpler testing needs, regardless of their development approach. Teams should carefully consider their specific requirements and resources when evaluating qTest against other test management solutions.

qTest pricing

qTest positions itself at the higher end of the test management tool market, with pricing that may be prohibitive for many teams, particularly small startups and medium-sized businesses.

Detailed breakdown of qTest pricing plans

qTest's pricing starts at $1,200/user/year, billed annually. This represents a significant investment, especially for teams with multiple testers or those operating on tight budgets.

Free trial: qTest offers a 14-day free trial period, allowing teams to evaluate its features before making a financial commitment.
Standard plan: Starts at $1,200/user/year, including features for agile test case management, project management, and bug tracking.
Enterprise plans: Custom pricing for larger teams or organizations with specific requirements, offering additional features and support.

While qTest provides extensive capabilities, its high cost may limit its accessibility to larger enterprises or organizations with substantial testing budgets. Smaller teams or those with limited resources may find this pricing structure challenging to justify, potentially needing to explore more cost-effective alternatives that still meet their core testing needs.

Cost comparison with other tools

Here’s a detailed breakdown of the pricing for various qTest alternatives to help you make an informed decision.

Tool	Free trial	Price for 10 users (1 year)
qTest	14 days	$12,000
PractiTest	14 days	$4,680
QMetry	15 days	Custom pricing
TestRail	30 days	$4,200
ReQtest	10 days	$720 - $5,400 (range based on plan)
TestLodge	30 days	N/A (priced by content, not per user)
Testuff	Contact sales	$3,240
SpiraTest	30 days	$4,000 (cloud)
Testpad	30 days	$1,188

8 Best qTest alternatives

When exploring alternatives to qTest, it's crucial to consider the strengths and weaknesses of each option. This overview highlights some of the leading alternatives, detailing their key features, pricing, and comparisons to qTest.

PractiTest

PractiTest, like many test management tools in the market, advertises itself as a comprehensive SaaS platform for centralizing quality assurance activities. As with most tools in this space, it offers reporting tools and dashboards, customizable workflows and fields, integration capabilities with other development and testing tools, and options for reusing test elements.

Key features include:

Centralized QA hub: Bridges silos and unifies communication across teams.
Customizable reports and dashboards: Tailor views to extract actionable insights.
Productivity features: Reuse testing elements to eliminate repetitive tasks.
Flexibility: Customizable fields, workflows, and integrations with popular tools.

How it compares with qTest

PractiTest provides a comparable level of comprehensive test management but is noted for its modern, user-friendly interface. It excels in real-time visibility and reporting capabilities, which may be more intuitive than qTest’s detailed but occasionally complex dashboards.

Pros:

Strong reporting and dashboard capabilities
Highly customizable
Efficient data management

Cons:

Higher cost for enterprise plans than qTest
It may require some time to fully utilize all features

QMetry

QMetry markets itself as an AI-powered enterprise-grade test management solution. Like many competitors, it claims to support the full lifecycle of test case management, from creation to execution and reporting.

Key features include:

Modern user interface: Easy to navigate and use.
Test authoring, planning, and execution: Comprehensive lifecycle support.
Custom reporting: Personalized dashboards and in-depth analytics.
Integrations: Connects with popular CI/CD platforms and tools.

QMetry advertises AI capabilities, but provides limited information about their practical applications. Without specific details, it's unclear how these AI features meaningfully enhance the testing process or differentiate QMetry from other tools.

How it compares with qTest

Both QMetry and qTest offer comprehensive test management features catering to large enterprises. While QMetry emphasizes its AI capabilities, the practical benefits of these features remain unclear. qTest, on the other hand, focuses on providing a robust, well-established test management solution.

The choice between QMetry and qTest likely depends on specific team requirements, existing tool integrations, and whether the purported AI features align with your testing needs. As with any tool selection, it's crucial to evaluate how these features translate into practical benefits for your testing processes.

Pros:

AI-driven
Strong integration capabilities
Detailed analytics and reporting

Cons:

Pricing is not publicly available, requiring contact with sales
Complexity might be overkill for smaller teams

TestRail

TestRail markets itself as a tool for managing, tracking, and organizing testing processes efficiently, focusing primarily on test case management.

Key features include:

Integration: Works with popular defect tracking and automation tools.
Reporting and comparison: Compare test findings across multiple test runs.
Open API: Integrate with CI/CD toolchains.

How it compares with qTest

TestRail primarily concentrates on test case management, making it accessible for teams that do not require broad project management features. qTest offers a wider range of capabilities, including detailed bug and issue tracking tools. TestRail may be suitable for teams focused primarily on test case management and reporting, while qTest could be a better fit for those needing a more all-encompassing solution that includes project management and bug tracking within the same platform. We've written the same kind of side-by-side for Testpad: Testpad vs TestRail.

Pros:

Competitive pricing
User-friendly interface
Robust reporting features

Cons:

Limited project management features compared to more comprehensive tools like qTest
Higher costs for enterprise plans, which may be necessary for larger teams or those needing more advanced features

ReQtest

ReQtest markets itself as a cloud-based test management solution, emphasizing test management capabilities and bug tracking features.

Key features include:

Aggregated reporting: Gain actionable insights from testing data.
Built-in filters: Quickly identify and manage bugs.
Agile test case management: Supports agile methodologies.
Integration with agile tools: Link items to requirements, bugs, and test cases.

How it compares with qTest

While both ReQtest and qTest offer bug tracking capabilities, ReQtest positions this as a key feature, which is somewhat uncommon among test management tools that often rely on integrations for this functionality.

ReQtest is generally more budget-friendly compared to qTest, potentially making it more suitable for smaller teams or those with tighter budgets. However, it may lack some of the more advanced features found in qTest, such as:

Extensive customization options for workflows and fields
Advanced analytics and predictive quality insights
Comprehensive API and integration capabilities
Robust scalability for very large enterprises

Pros:

Budget-friendly
Excellent bug tracking
Aggregated reporting features

Cons:

May lack some advanced features found in more comprehensive tools like qTest
Shorter free trial period (10 days compared to qTest's 14 days)

TestLodge

TestLodge markets itself as a no-frills platform aiming to cut through the complexity often associated with test case management.

Key features include:

Integration with issue trackers: Works with issue tracking tools like Jira, GitHub, and more.
Easy test plan creation: Use templates or design from scratch.
Intuitive insights: Graphs and dashboards provide clear progress views.
Thorough bug reports: Speed up problem reporting procedures.

How it compares with qTest

Where qTest stands as a feature-rich giant, TestLodge positions itself as the nimble alternative. It's tailored for smaller teams or those who prize straightforward usability over extensive functionality. TestLodge offers a more wallet-friendly option, though it may not pack the same punch in terms of advanced features.

Pros:

User-friendly interface that doesn't require a learning curve
Adaptable pricing structure to fit various team sizes
Generous 30-day free trial for thorough evaluation

Cons:

May leave power users wanting more advanced capabilities
Premium plans can stretch the budget for larger teams

Testuff

In the crowded arena of QA management tools, Testuff steps up with a unique twist: video bug reports. This web-based platform goes beyond the usual test management fare, offering a visual edge to traditional bug tracking.

Key features include:

Requirement management: Manage and trace requirements.
Test case management: Create, execute, and manage tests.
Video bug reports: Attach videos to bug reports for clarity.
Integration with bug trackers: Supports a wide range of trackers.

How it compares with qTest

Testuff is a versatile tool that integrates well with other bug-tracking and automation tools. It offers similar capabilities to qTest but with added features like video bug reports, making it useful for visual documentation.

Pros:

Video bug reporting for show-and-tell issue tracking
Extensive integration options for a well-connected workflow
Budget-friendly yearly plans for the cost-conscious

Cons:

Pricing details hidden behind a sales call curtain
Interface might not win any user-friendliness awards

SpiraTest

SpiraTest is a tool that aspires to be the jack-of-all-trades in the test management world. This platform ambitiously combines requirements, test cases, and bug tracking into one comprehensive package.

Key features include:

Document management: Integrated web-based system with version control.
Test management: Supports automation testing and manual testing.
Extensive plugin support: Works with tools like Selenium, UFT, and more.
Cross-platform compatibility: Supports various operating systems and devices.

How it compares with qTest

Both SpiraTest and qTest aim to be comprehensive solutions, but SpiraTest edges ahead with its document management capabilities. Its wide-ranging compatibility with different testing tools and platforms might give it an advantage in diverse testing environments.

Pros:

All-encompassing test management from requirements to bug tracking
An impressive array of plugin support for maximum flexibility
Real-time reporting for up-to-the-minute insights

Cons:

The downloaded version might leave your wallet feeling lighter
New users might need to prepare for a complex setup process

Testpad: The best qTest alternative for pragmatic testing

Testpad takes a fresh approach to test management, breaking away from traditional test case management (TCM) tools like qTest. It offers a flexible, lightweight solution that emphasizes speed and simplicity. For a full side-by-side, see Testpad vs qTest.

Key differences from traditional TCM:

Checklist-based approach: Testpad uses a simple checklist format instead of complex test case structures. This allows for quick creation and execution of tests via a keyboard-driven editor, ideal for teams valuing speed and adaptability.
Intuitive interface: With its native app-like responsiveness, Testpad enables users to start testing immediately, without extensive training.
Flexible test planning: Users can start with high-level plans and add details as needed, benefiting agile teams and projects with tight deadlines.
Collaborative features: Testpad's guest testing feature enables easy collaboration without logins, streamlining user acceptance testing and cross-department cooperation.
Streamlined reporting: Instant, glanceable reports with guest-access links provide quick progress checks and maintain documentation.

How Testpad compares to qTest

Testpad offers a distinct approach to test management compared to comprehensive tools like qTest:

Simplicity: Testpad uses a checklist-based system that's quick to set up and easy to learn, contrasting with qTest's feature-rich but potentially complex interface.
Flexibility: Testpad provides adaptable, free-form test plans, ideal for agile teams. qTest offers more structured test case management with detailed hierarchies.
Cost: Testpad's pricing scales with team size, making it accessible for smaller teams and startups. qTest typically targets larger enterprises with its pricing structure.
User Experience: Testpad emphasizes intuitive design and minimal training requirements, while qTest's powerful features may require more time to master.
Collaboration: Testpad offers simple collaboration features like guest access, which can streamline user acceptance testing. qTest provides more comprehensive user management and access controls.

Ideal use cases for Testpad

Testpad is ideal for:

Small to medium-sized teams: Teams looking for an affordable, easy-to-use test management tool will find Testpad a perfect fit.
Agile teams: Teams that need a flexible solution to adapt to their iterative development process will benefit from Testpad’s free-form test plans.
User acceptance testing: Involving stakeholders in testing without requiring them to log in is a significant advantage for UAT scenarios.
Projects with tight deadlines: Quick setup and efficient test management are crucial for projects that require rapid testing and deployment.

Considerations for different team sizes and budgets

Selecting the right test management tool involves weighing features against costs, particularly when considering the size of your team and budget limitations:

Small teams: For smaller teams, affordability and simplicity are paramount. Tools like Testpad and ReQtest provide essential features at a lower cost, which is crucial for maintaining efficiency without overspending. Testpad, with its straightforward and intuitive design, is ideal for small teams that need effective solutions without the complexity or expense of larger tools.
Medium teams: Medium-sized teams often need a balance between cost and advanced functionality. Tools like TestRail and PractiTest offer comprehensive test management capabilities without a significant financial burden. Testpad fits well here too, providing flexibility and ease of use that accommodate the dynamic needs of growing teams.
Large enterprises: Larger organizations typically require robust solutions with extensive support and integration options. Tools like qTest and SpiraTest are designed to meet these needs, offering scalable solutions that cater to complex environments and larger team structures.

Wrapping up

Picking the right test management tool can make or break your software quality.

Testpad offers a refreshing alternative to complex platforms like qTest, focusing on simplicity and flexibility.

Testpad's checklist approach is a great fit for agile teams dealing with dynamic requirements. Its quick setup and intuitive interface can give your testing efficiency a serious boost.

Your choice should depend on what you actually need. Testpad shines at creating hierarchical test plans with its outlining style, but if you're after extensive integrations, traditional tools might be more your speed. If you value simplicity and speed, Testpad's pragmatic approach could be just the ticket.

To see if Testpad fits your needs, try the 30-day free trial. It's the best way to figure out if Testpad's streamlined method can kick your testing process up a notch.

What is system testing? Definition, examples, and why it matters

Stefan Butlin — Wed, 14 Jan 2026 00:00:00 +0000

System testing is the stage where you test a complete, integrated software system against its specified requirements. Where unit and integration testing check the parts, system testing checks the whole product working together. It comes after those stages and before user acceptance testing (UAT), as the last internal checkpoint before real users see the software.

At a glance

System testing checks the complete, integrated system against its requirements, after unit and integration testing
It comes before user acceptance testing (UAT) and is usually run by QA testers
Functional system testing checks the system does what was specified; non-functional covers performance, security, stress, usability and scalability
A short checklist (core user journeys, error handling, integrations, notifications) keeps coverage focused
Getting started doesn't need heavy process: plan what to test, test it, report what you find, retest the fixes, and sign off

The rest of this guide covers the definition and an example, how system testing compares with other types of testing, the main types, and how to get started.

What is system testing?

System testing is the process of testing a complete, integrated software system to verify that it meets specified requirements. The ISTQB Foundation syllabus puts it the same way: system testing "focuses on the overall behavior and capabilities of an entire system or product". It checks whether your entire product works as a whole in the way it should. It isn’t any more complicated than that – even though some tools and testing resources make it feel more complex with lots of jargon and complicated explanations.

You can think of it as the stage when everything comes together. Once you’ve tested the individual parts of your product or software individually, system testing makes sure that they all work together as they were designed to do.

System testing example: e-commerce website

If you have an e-commerce site, you might have tested that the login screen, payment system and shopping cart functionalities all work properly – but you then need to do system testing to make sure that they all work smoothly together.

So your system testing would look at how it all works together, which might include things like:

Checking everything works when there are lots of users on the site at the same time.
Making sure that the inventory updates properly after items are sold.
Checking that confirmation and shipping emails are sent after a purchase is made.

How is system testing different from other types of testing?

While the premise of system testing isn’t complex, it can sometimes be helpful to know what something doesn’t do, in order to better understand what it does do. So, with that in mind, here’s what system testing doesn’t cover:

Unit testing: System testing doesn’t focus on testing individual units in isolation. That’s the job of unit testing, which ensures that the smallest testable parts of the application (called the units) work properly on their own.
Component testing: This is essentially the next level up from unit testing, testing a module or feature that’s made up of multiple units.
Integration testing: Testing how specific parts work together, making sure that multiple components talk to each other in the way they’re supposed to.

When it comes to system testing vs unit testing, then, the main difference is the level of focus: unit testing (and component testing) checks individual parts of the software to make sure each function or component works on its own, while system testing looks at the whole software system to ensure all parts work together properly. Unit, component and integration testing are all typically done by developers as part of the software development process.

All of these types of testing, as well as system testing, are done before user acceptance testing. This comes after the internal testing done by your team, when the QA team thinks the product or software is ready for your client or end user.

System testing also shouldn’t be confused with software testing, which is a more general term for the entire process of testing software, while system testing is one of the component parts, along with unit testing and component testing.

Here’s how the levels compare side by side:

Test type	Scope	Usually run by	When
Unit testing	Individual functions or units in isolation	Developers	During development
Integration testing	How components work together	Developers or QA	After unit testing
System testing	The complete, integrated system	QA testers	After integration testing
User acceptance testing (UAT)	The full product against real user needs	End users or clients	After system testing

Why is system testing important?

System testing matters in any test plan because it makes sure that all the parts of your system work together as expected. When you do system testing, you can check that the entire system behaves as intended as a whole. It helps you to identify any potential problems that might not have been found during earlier phases of testing like unit or integration testing, reducing the risk of bugs or failures after you deploy.

Benefits and limitations of system testing

The benefits of system testing include the following:

Comprehensive: System testing verifies that the entire system works as a whole, and that it meets all specified requirements.
Identifies bugs pre-launch: It’s common for things to get missed during earlier rounds of testing, so system testing will help you to catch anything before you launch.
Quality checking: It ensures that your product is stable, reliable and ready for deployment, leading to fewer post-launch issues, and increased customer satisfaction.
Real-world testing: System testing should be carried out in conditions as close as possible to the real world, so the results reflect how the software will behave in production. This also means it helps you to prepare for user acceptance testing.

But there are also some potential challenges you might face with system testing:

Time-consuming: Comprehensive system testing can take time, especially if your system is large or complex.
Complex test case design: Because you’re testing the entire system, there are many test cases needed – which means you need to stay organized for it to be effective.
Risk of incomplete coverage: Again, because the scope for system testing is wide, there’s the risk of missing edge cases.
Dependence on earlier stages: If there were any gaps in your previous testing phases, these may be carried over into your system testing.

These trade-offs are well documented on the automation side too. Martin Fowler’s test pyramid recommends lots of small unit tests and "very few high-level tests that test your application from end to end", and Google’s testing blog suggests a 70/20/10 split across unit, integration and end-to-end tests, partly because a failing whole-system test is harder to trace back to a cause. The lesson carries over to manual system testing: keep it focused on what only a whole-system test can tell you.

What are the types of system testing?

System testing is a broad umbrella term – there are various different types of tests that can be categorized as system testing. These can be broken down into functional and non-functional testing.

Functional testing checks if the system works according to the requirements, for example, checking whether the login feature works. It also includes regression testing. This checks that new features haven’t broken existing functionality, catching bugs that may have been unintentionally introduced. It’s often automated but can also be manual, and some teams consider it to be part of their system testing – but it can also be thought of as standalone testing.

Non-functional testing checks important aspects like performance, security and speed. These tests include:

Usability testing: This checks how user-friendly and intuitive the user interface (UI) is. It can happen as part of product development.
Stress testing: This tests the system's stability under extreme conditions, such as high traffic or resource depletion.
Performance testing: This checks how well your software or system works under different conditions, making sure it can handle the demands of real users, heavy traffic, and processing lots of data.
Security testing: This testing is fairly self-explanatory. The aim is to identify vulnerabilities and ensure that a software system is secure from potential threats or attacks.
Scalability testing: This checks that your application can handle increases in load and traffic.

How does system testing fit in with your wider testing plan?

It’s best to do system testing after you’ve completed unit testing (when all individual units of the system have been tested separately to make sure they work correctly) and integration testing (when you’ve checked that the different components or modules work together as expected).

Once these steps have been taken, you can carry out system testing, to look at the entire system as a whole to make sure that all the parts work together as you expect them to.

System testing should come before user acceptance testing (UAT), which is when your client or real users test the software to ensure it meets the requirements of the real people using it.

You’ll always want to do functional testing as part of your system tests, but it’s not always necessary to do every type of non-functional testing. The decision as to what types of system testing you do should be based on your system's specific needs.

System testing checklist: what to test before release

Before signing off your system tests, it’s worth checking that you’ve covered the most important areas. A basic system testing checklist might include:

Core user journeys, from start to finish
Error handling and edge cases
Performance under realistic load
Data accuracy and integrity
Security basics, such as access controls
Integrations with third-party tools or services
Notifications, emails, and system messages

This helps ensure your testing stays focused on how the system will actually be used – not just how it’s meant to work on paper.

How to get started with system testing

Remember, system testing doesn’t need to be complicated. Here are the steps you should take to make sure it’s simple, stress-free, and effective.

1. Make a test plan
In other words, you should outline your overall framework and strategy for testing.

2. Write your test scenarios and test cases
A test scenario is a high-level description of functionality to be tested, while a test case is a more detailed set of criteria for testing a feature or functionality.

3. Create test data
Make sure you have the information you need to validate your tests. This might involve creating sample accounts, transactions, or datasets.

4. Create the test environment
Remember, the test environment should mirror the production environment as closely as possible to ensure realistic testing conditions.

5. Conduct the tests
Run your tests to check if the system performs the intended functions correctly. You might, for example, test whether users can log in or make purchases as expected.

6. Document and report issues
As you test, document any issues or bugs you encounter. Provide detailed steps, screenshots, or logs to help the development team identify and fix the problem. You may want to use a bug tracking tool to log issues.

7. Test again
Once the development team addresses the bugs, retest the system to ensure the issues were fixed and no new problems were introduced.

8. Final testing and sign off
If the issues have been fixed, you can sign off the system for release. But if the issues persist – or if you discover any new issues – you’ll need to keep tweaking and testing until the problems have been resolved.

Manage your system testing with Testpad

There are lots of different things you can test during your system testing, which means that you could quickly lose track of both the tests you need to complete and their results. So you might be considering a test management tool to help you stay on top of things.

We recommend keeping things simple – because there’s really no need to make testing more complicated than it needs to be. Testpad is a checklist-based testing tool: each test is a line of plain text, each test run is a column, and the resulting grid shows your coverage at a glance.

Some of the key features include:

Plain text tests: each test is a single line, so anyone on the team can read and run the plan, including non-technical users.
Keyboard-driven editor: type hundreds of test prompts in minutes, with free-form test plans so you can test however you like to do it.
Guest testers: invite guests to run tests without a login, useful extra hands during a big system test.
Easy reuse: copy a script (a test plan) from the last release and edit the copy for the next round of testing.
Report view: every script and folder has a Report view you can share as a link, so anyone can see how far testing has got.

If you want quick and easy system testing, Testpad could be the tool for you. Write and organize your tests fast, get through more testing, and share a report link so anyone can check progress at a glance. If you’re ready to kickstart your system testing, why not try our 30-day free trial today?

System testing FAQs

What is the main goal of system testing?

The goal of system testing is to check that the complete software system works correctly as a whole and meets the specified requirements.

Who performs system testing?

System testing is usually carried out by QA testers or testing teams to provide an independent view of the system, although in smaller teams it may also be performed by developers or cross-functional team members.

Is system testing manual or automated?

It can be either. Many teams use a mix of manual and automated system testing, depending on the size of the system and the risks involved.

When should system testing be done?

System testing should take place after unit and integration testing, but before user acceptance testing.

Complete guide to compatibility testing

Stefan Butlin — Sat, 10 Jan 2026 00:00:00 +0000

Compatibility testing proves your software works properly across different browsers, devices, operating systems, and networks – catching problems before users find them.

Say your app works beautifully on Chrome running on your MacBook. It looks perfect, responds instantly and handles everything you throw at it. Then a customer tries it on Firefox on Windows 10 and half the buttons don't work. Someone else then opens it on Safari on their three-year-old iPad and it crashes on load. And finally, another person on a spotty mobile connection gets stuck on a loading screen that never ends. What’s going to happen to those users? They get frustrated, give up, and never come back.

Compatibility testing catches these problems while you can still fix them cheaply – and before they turn into angry support tickets, one-star reviews, and lost revenue.

At a glance

Compatibility testing checks your software on the browsers, devices, OS versions, networks, and hardware your users actually have
There are five types: browser, device, operating system, network, and hardware. Most products need at least two
Start from your analytics: test the top 3-5 configurations your users really run, not every combination that exists
You don't test everything on everything. Pick representative configurations and sample the rest
A grid of checks down the side and a column per configuration makes coverage visible at a glance

What is compatibility testing?

Compatibility testing gives peace of mind that your software performs as it should across:

Browsers - Chrome, Firefox, Safari, Edge and their versions
Operating systems - Windows, macOS, Linux, iOS, Android
Devices - phones and tablets
Networks - different connection speeds and reliability
Hardware - various processors, memory, graphics cards

The goal of compatibility testing is to find configuration-specific issues before your users do.

Why does compatibility testing matter?

Because your users aren't all in the same environment you build in, and any difference can hide its own bug.

Browsers are actually the reassuring part. Most of the web now runs on a handful of rendering engines: Chrome, Edge, Brave, and Opera all share Chromium's, so a page that works in one usually works in all of them. The real spread is everywhere else. Your users are on different operating systems and OS versions, different screen sizes, different hardware, and connections that come and go. A build that's flawless on your machine can still fail on theirs because one of those things is different.

The numbers show how wide that spread is. Fewer than a quarter of Android devices run the current Android version, and almost a third are on Android 12 or older (StatCounter, May 2026). Even the single most common screen resolution is barely 8% of traffic, so there's no "normal" screen to design for. And every iPhone runs Safari's engine, which updates on Apple's schedule and is usually last to support new web features, so the one browser difference that does bite is the one you can't avoid.

Skip compatibility testing and you'll find these the expensive way: through customer complaints, support tickets, and the users who don't complain at all – they just leave for a competitor.

What types of compatibility testing should you do?

There are five main types of compatibility testing. Pick the ones that matter for your product and who uses it:

Type	What it covers	Typical failures	Who needs it most
Browser	Chrome, Safari, Edge, Firefox, and their versions	Usually small now: sub-pixel text alignment, the newest CSS not yet supported everywhere (often Safari)	Web apps and websites
Device	Phones, tablets, desktops	Touch targets too small; slow on older hardware; layouts that assume a big screen	Anything users open on a phone
Operating system	Windows, macOS, Linux, iOS, Android	File paths, permissions, fonts; version-specific bugs	Desktop and native mobile apps
Network	Connection speeds, interruptions, proxies	Endless loading; timeouts; lost form data	Apps used on the move
Hardware	Processors, graphics, memory, peripherals	Crashes on minimum-spec machines; driver conflicts	Games, design tools, anything talking to physical equipment

Browser compatibility testing

Modern browsers agree with each other far more than they used to. The Chromium family (Chrome, Edge, Brave, Opera) shares one engine, so the days of a page rendering completely differently in each browser are mostly behind us. What's left tends to live in the details: a few pixels of difference in how text or spacing lands, and the newest CSS or JavaScript features arriving in one engine before the others. Safari is the usual exception, because it's on its own engine and its own update schedule.

So you don't need to test everything in everything. Check your analytics, cover the browsers your users actually run (current versions plus one or two back), and give Safari a deliberate look if you have iPhone or iPad traffic. If your analytics show 2% of traffic from Opera Mini, skip it.

What to check:

Text alignment and spacing where layouts are tight
Any very recent CSS or JavaScript feature, especially in Safari
Form controls: date pickers, dropdowns, and file uploads still vary between engines

MDN keeps a good introduction to cross-browser testing if you want the deeper web-platform detail.

Device compatibility testing

Smartphones, tablets, desktops – each brings headaches around screen sizes, touch vs mouse, processing power, and memory. The big traps: touch targets that are comfortable with a mouse but impossible with a thumb, on-screen keyboards that cover the field being typed in, and performance that feels fine on a new phone but crawls on a three-year-old one.

What to check:

Tap targets and spacing at phone sizes
The on-screen keyboard: does it hide inputs or the submit button?
Rotation: does the layout survive switching between portrait and landscape?
Performance on the oldest device your analytics show in real numbers

Emulators are fine for layout, but touch feel and real performance only show up on physical devices.

Operating system compatibility testing

Windows, macOS, Linux, iOS, Android – each has its own ideas about file paths, permissions, fonts, and resources. Common issues: Windows loves backslashes while everyone else uses forward slashes, permission models that work completely differently, fonts that render inconsistently.

Versions matter as much as the OS itself. Remember the Android numbers above: a quarter of devices on the current version, almost a third on releases that are four or more years old. iOS updates faster, but not instantly, and Windows users sit on older releases for years.

What to check:

File handling: paths, save and open dialogs, attachments
Permission prompts: camera, notifications, file access
Fonts and rendering on each platform
The oldest OS version you claim to support, not just the newest

Network compatibility testing

Test how your app handles slow connections (3G that feels like dial-up, coffee shop WiFi), network interruptions, proxy configurations, and geographic restrictions. Slow is only half of it: real networks are also flaky. Connections drop mid-request, switch from WiFi to cellular halfway through an upload, and come back with a different IP.

What to check:

What the user sees while waiting: a spinner forever, or a useful message?
Half-finished actions: does a submitted form survive a dropped connection?
Timeouts and retries: does the app recover, or does the user start over?
Big files on bad connections

Hardware compatibility testing

Different processors, graphics cards, memory, and connected devices like printers or webcams. Matters most for apps that need serious power, software that connects to physical equipment, or tools with minimum specs your users need to meet.

Test on a machine that just meets your minimum spec, not the workstation you develop on. Graphics drivers are the classic trap: the same GPU can behave differently across driver versions, which is why games publish known-good driver lists.

And if the product you're testing is hardware – devices, firmware, electronics coming off a line – that's a bigger job than a compatibility pass: test campaigns across product variants, revisions, and environments. We've written separately about managing hardware testing.

What tools help with compatibility testing?

The right tools give you access to the conditions your users actually experience. Here's what works, depending on what you're testing:

Browser testing services - BrowserStack, Sauce Labs, and LambdaTest are cloud platforms that let you test on hundreds of real browsers and devices without owning them. You can test on Safari 12 on an iPhone 8, Chrome 95 on Windows 10, or whatever specific combination your users run. Not cheap (check their current plans for what entry tiers cost), but cheaper than production bugs.

Browser dev tools - The dev tools already built into Chrome, Firefox, and Edge do more than resize the window. They emulate a range of device screen sizes and pixel densities, throttle the connection to simulate slow or flaky networks, mimic touch, and spoof a mobile user agent, all without installing anything. Good for a fast check while you build, but not a substitute for a real device before you ship: emulation misses subtle rendering issues, touch quirks, and real device performance. It's a simulation, not the real thing.

Feature support tables - caniuse.com isn't a testing tool, but before you test a feature at all it tells you which browsers and versions support it. It will often explain why something works in Chrome and not in Safari before you've opened a single device.

Network simulation - Tools like browser dev tools, Charles Proxy, and Network Link Conditioner artificially slow down your internet connection so you can see how your software handles slow networks or spotty connections. For realistic testing though, actual networks behave differently than simulated ones.

Virtual machines - VirtualBox or VMware let you run Windows, Linux, or older OS versions on your computer as if they were separate machines. Useful when you need to verify behavior on specific OS versions (like Windows 7 for legacy enterprise users), but they eat up memory and processing power - overkill for simple browser testing.

Real devices - Keep a few physical devices around for critical testing. Nothing replaces actually using a phone or tablet, especially for touch interactions, performance, and visual checks. Start with whatever's most common in your user analytics.

Most teams use different tools at different times – quick checks while building, then broader testing across more combinations, then hands-on checks with real devices before shipping.

How does compatibility testing fit into your release process?

Compatibility testing works best in stages – quick checks early, thorough testing before shipping, and watching for problems after launch. Here's when to test what:

During development - Test in your main browser plus one other and a mobile view, and catch obvious problems early before they're built into your code. If something breaks on Firefox while you're building it in Chrome, fix it now rather than discovering it later.
Before release - Run through your full list of browsers and devices. Check the basics everywhere (does it load? does it work?), test everything thoroughly on your most common setups, and do focused checks on less common ones. This is where you catch unusual problems before users do.
After release - Watch support tickets, error tracking tools like Sentry or Rollbar, and analytics for strange patterns. Real-world usage always surfaces unexpected combinations – that one user on Safari 14 with an ad blocker and VPN who finds the bug nobody else hit. Use what you learn to update what you test next time.

How do you keep track of compatibility testing?

Most of compatibility testing is repetition: the same checks, run again on a different configuration. The tracking problem is making that repetition visible – what was checked, on which browser, on which OS, and what failed where.

First, though: you don't run every test on every configuration. That's thousands of combinations and most of them would fail in the same way or not at all. Testers borrow a technique called equivalence partitioning here: group the configurations that would behave the same, and test one from each group. A handful of representative setups (a current Chrome, an older Android, an iPhone Safari, a slow connection) covers far more real risk than grinding through every browser-by-OS-by-device cell. Sample the classes that differ; skip the ones that don't.

Then track what you sampled in a grid. Write your checks once, down the side. Give each representative configuration its own column: Chrome on Windows, Safari on iOS, Firefox on a slow connection. Work down each column marking pass or fail. The grid is your compatibility matrix, and the gaps in it are the configurations you haven't covered – visible without anyone writing a status report.

This is how Testpad models testing. Tests are lines of plain text in a script, and each test run is a column beside them. Add a column per configuration and the report becomes a wall of checks and crosses: every test, on every setup, at a glance. When a Safari fix lands, add a fresh Safari column and re-run just those checks; the earlier run stays put as history.

Two habits make the matrix work harder. When a configuration-specific bug turns up mid-run, add it to the plan as a new line, so it gets checked on every other configuration too. And keep the script for next release: compatibility checks barely change between cycles, so the plan you wrote this time is most of the work for the next one.

If you want to try your own checks in a grid like this, the 30-day trial is free.

New to compatibility testing and don’t know where to start?

If you're not doing any compatibility testing yet, don't try to test everything at once. Start with what your users actually use. Check your analytics for the top 3-5 browser and device combinations. Test those manually before each release. When you find issues, write them down – which browser, which feature, what broke. Over time, you'll spot patterns in what tends to break and where.

As you get comfortable, gradually add more combinations. Maybe you started testing Chrome and Safari on desktop – add mobile. Then add Firefox. Then older versions. Build up your testing as you learn what matters for your users. What matters is understanding how your software behaves in the real world and catching issues that would annoy users. Start with basic coverage, find problems that matter, evolve as you learn what breaks.

Want more testing talk delivered straight to your inbox?

We write about testing at Testpad. Sign up and we'll send you useful testing tips (not in a constant, needy ex kind of way though, don’t worry).

Best TestRail Alternatives 2026

Stefan Butlin — Thu, 08 Jan 2026 00:00:00 +0000

TestRail is a popular choice for enterprise companies looking for traditional test case management (TCM). But just because some of the largest companies in the world use TestRail, does that mean it’s the right solution for you and your team?

We have combined research and real user reviews to give you an in-depth visual of TestRail as a tool. We’ll compare TestRail against its top competitors to explore if this traditional test case management tool would fit your needs or if thinking outside the box with a nontraditional test case management solution may be the right move for you.

What is TestRail?

TestRail is a test case management platform designed for QA teams to manage and track test results from both manual and automated tests.

It offers dashboards and reporting functions to help teams track test cycle progress, report on pass/fail rates, and monitor risk within new releases.

TestRail has one of the widest selections of integrations including:
Issue management integrations: Jira, GitHub Issues, and Azure Dev Ops.
Test automation tools: Selenium, Cypress, Playwright, JUnit, and more.
CI/CD pipelines: Jenkins and GitHub Actions

Large companies with dedicated QA teams choose TestRail for its structured, traceable testing processes and collaborative features. Industries such as healthcare and finance favor the tool for its ability to meet stringent compliance requirements.

Pros ✅	Cons ❌
Detailed reporting features to track the entire lifecycle of testing	The user interface, while powerful, can be difficult for new users or those unfamiliar with testing tools to learn
Ideal for large organizations with complex testing needs and large QA teams	Testrail can be relatively expensive, especially for small teams
Supports manual, exploratory, regression, and automated testing
Extensive integration capabilities with a myriad of platforms
TestRail offers teams milestone and bug tracking capabilities so teams can set goals and timelines for testing projects

TestRail offers teams milestone and bug tracking capabilities so teams can set goals and timelines for testing projects
According to user reviews, TestRail has experienced high volumes of customer support requests and has been slow to respond to issues and fix features

If a team is already familiar and happy with formal test case management, they're likely to like TestRail's traditional and structured approach to test suites. On the other hand, the formal and controlled approach comes at the cost of inflexibility if teams want to conduct their testing with different, especially more agile, approaches.

If it's specifically Testpad you're weighing TestRail against, we've written a detailed side-by-side covering the data models, pricing, and when each tool fits: Testpad vs TestRail.

5 TestRail Alternatives to Consider

PractiTest

PractiTest is a tool for QA teams and developers who want to collaborate on testing. Within PractiTest teams can assign tasks to users and share test runs with fellow team members.

PractiTest advertises itself as a solid testing option for large organizations with complex testing operations. It is a comprehensive TCM software tool but smaller organizations (or those who simply want a straightforward testing solution) may not fit with what PractiTest offers – although they do have a scaled back plan that tries to make the tool more appropriate for smaller teams.

Pros ✅	Cons ❌
Collaborative functions within the tool to accommodate groups and teams such as commenting, activity logs, and email notifications	More suitable for larger organizations; less suitable for smaller/agile teams
Extensive integration capabilities with issue trackers, automation tools, and CI/CD pipelines	Pricing can be expensive, and its pricing structure may not be cost effective for smaller teams
Supports Session Based Test Management (SBTM) for teams who like that formalization of Exploratory Testing	As with Testrail, new users or those unfamiliar with test management tools may require training to learn the interface

Tricentis qTest

Tricentis qTest is another test management platform with similar features to Testrail but they promote having a particular focus on supporting agile development and DevOps practices.

It is worth noting that Tricentis offers a range of other testing products and prioritizes integrations with products within the Tricentis ecosystem. For test automation, qTest offers integrations with Selenium and Cucumber, but also offers its own test automation tool, Tricentis Tosca.

Comparably, the list of third-party tools qTest integrates with is more limited than other TCM’s due to preferential integration with Tricentis products. If your team is already using tools available in the Tricentis ecosystem, qTest may make the best fit to organize and manage manual and automated testing. However, if your team needs more flexible integration options, other TCMs offer a wider list of integrations.

Although they don't have specific costs noted on their pricing page, some sources have reported qTest at around $1,200/user/year, but we expect this is based on the individual needs of teams.

Pros ✅	Cons ❌
Capable of supporting large-scale enterprise environments	Complex UI with a steep learning curve for users
Ability to customize workflows, fields, and templates which is helpful for teams using Agile methodologies	Unclear on how cost effective the tool is compared to others, until you provide your details for pricing information
Provides detailed analytics and reporting features for real-time visibility into testing activities and quality metrics	Integration with tools outside the Tricentis ecosystem can be limited

Testmo

Like other test case management tools on this list, Testmo is a TCM software designed to enhance efficiency and productivity in managing test cases, recording test results, and tracking test runs.

Testmo markets itself as a central hub for QA testing, combining test cases, exploratory testing sessions, and test automation integration all in one platform. It features integration with leading bug tracking tools, automation tools, and CI pipeline tools.

Pros ✅	Cons ❌
Supports automated, exploratory, and manual testing	Learning curve for new users who will likely require training to use the tool
Customizable workflows	Reportedly long customer support wait times

Zephyr

Zephyr is a Jira plug-in, a notable difference to all the other TCM options on our list.

While this tool offers a similar swath of testing capabilities that other tools offer - streamlining test case creation, test execution, and tracking - all testing is conducted within the Jira ecosystem. Teams who work closely with Jira choose Zephyr (or other Jira plug-in options such as XRay) as a space to collaborate and unify testing data all under the Jira umbrella.

Zephyr has three levels of test management subscriptions and services aimed at teams of different sizes: Zephyr Enterprise, Zephyr Scale, and Zephyr Squad. Each option has different levels of features, and come suited for small teams, growing organizations, or enterprise users.

With Zephyr being a Jira add-on that means there is an obvious limitation to issue management if you don't already use Jira. While Zephyr does support exploratory testing, it comes with an additional cost.

Pros ✅	Cons ❌
Being native to Jira allows teams to work seamlessly within the Jira ecosystem	Being native to Jira, obviously is then limited to only working within Jira
Easy to monitor for manual testing	Users on forums report bugs in its operation and slow performance
Enables real time collaboration with features like notifications	Exploratory testing needs an optional add-on

Testpad

Testpad is perhaps the most different to TestRail and the alternatives to TestRail listed above.

Testpad helps you manage your test planning and tracking, but unlike the others, Testpad takes a "document-centric" approach, building test plans around documents (test scripts or checklists) rather than a database of Test Cases.

Testpad’s document-centric approach delivers flexibility and agility allowing teams to change course, pursue exploratory testing, or run full-scale test case management with the straightforwardness of a spreadsheet (without the headache of inconsistent formatting and unprofessional reporting).

Testpad’s pragmatic approach makes testing as easy as running through a simple checklist, recognizing that not everyone needs a complex testing setup and that most people just need a way to test that is clear, functional, and flexible.

Pros ✅	Cons ❌
Ideal for agile teams who need to iterate with speed	No off-the-shelf automation integrations, though there's an API and webhooks for building your own
Guest testers, including those without testing experience, can join without a login	Likely not the right fit for enterprise organizations who prefer traditional TCM tools (unless they are frustrated with heavyweight style of test management)
Users can change course mid-testing	Only lightweight integrations with third-party tools
Ability to run tests on mobile or tablet devices
No training or onboarding necessary to use Testpad

The Best TestRail Alternative for Pragmatic Teams

For traditional TCM tools, TestRail is one of several good options. It's hard to pick an outright or obvious best choice as the best tool for a team always depends on individual needs and testing preferences.

But if you want something simpler, whether that's an upgrade from the mess you're in with spreadsheets, or just a modern lightweight approach to a test management solution, then we think Testpad is the way to go (but yes, we're obviously biased here). For the full feature-by-feature picture, see our Testpad vs TestRail comparison.

If you are curious about Testpad’s non-traditional approach to test case management, you can try us out completely free for 30 days, no credit card required.

What is software testing?

Stefan Butlin — Thu, 18 Dec 2025 00:00:00 +0000

Software testing is the process of exploring a product to discover its current state: what works, what doesn't, and what needs attention before users find out. It doesn't require rigid processes or fancy tools. The point is useful information, so your team can decide what to fix, what to ship, and where to spend its time.

At a glance

Software testing is discovery: learning what your product does and doesn't do before users find out
Testing isn't the same as QA, but it's how QA learns where quality needs attention
The main approaches: sanity, exploratory (and its structured session-based form), automated, and regression testing
Manual testing catches the edge cases and unexpected behaviors that automation misses
Finding bugs earlier saves serious money: NIST put the cost of inadequate testing at $59.5 billion a year for the US economy
Start small: one or two testers and a simple checklist is enough to begin

The rest of this guide covers the definition, why testing matters, the main approaches and when to use each, and a four-step way to get started.

What is software testing?

Software testing is about discovery – learning about your product's current state. By exploring the product, you reveal where quality needs attention. It’s also one of those terms that you’ll get a different definition for depending on who you ask (we do have a lot of that kind of vocabulary in tech). To IBM, for instance, software testing is:

The process of evaluating and verifying that a software product or application functions correctly, securely and efficiently according to its specific requirements.

ChatGPT has a slightly different (and a bit more convoluted) answer:

The process of systematically evaluating an application or system to identify and address defects, ensure it meets specified requirements, and verify its functionality, performance, security, and usability under various conditions.

It’s important to note here that testing and quality assurance (QA) are not one and the same. After all, learning about your product’s current state doesn’t produce quality in its own right. But testing is a key part of the QA process: it shows you where quality needs attention.

Why is software testing important?

You might immediately jump to “testing surfaces bugs” or “testing uncovers potential user experience enhancements.” Do a cursory Reddit search, and it’s easy to see why:

HB_propmaster: Found a bug in a timesheet/payroll system where the employee was able to get themselves paid double. Bug had been live for at least two years. No employee had ever found it.

Hello____World_____: Huge sections of the database were going missing overnight in our test environment (not production). It turned out an upcoming feature had a schedule overnight task that was actually deleting tons of valid data. If that new feature made it to production, it would have been a disaster.

nutrecht: I worked for a large bank and replaced a developer who created a bug that allowed clients to see the account balances of other people. Basically a mistake of keeping state in a (supposedly) stateless microservice. It even managed to go through code review by security. Fortunately, they found out before the press got wind of it.

These stories highlight just a few reasons testing matters. Let's break down why testing is worth the effort:

It catches expensive problems early

Finding bugs early in development costs far less than fixing them after release. A NIST study put the cost of inadequate software testing to the US economy at $59.5 billion a year, and estimated that $22.2 billion of it could be recovered just by finding and removing bugs earlier in development. That study dates from 2002; software has only grown since.

Think about it: catching that double-payment bug before it went live would've saved two years of overpayments. Finding the database deletion issue in testing instead of production avoided what could've been a company-ending disaster.

It protects your reputation and keeps customers

In 2015, a failure during a daily system refresh shut down the registers at 7,000 Starbucks stores in the US and 1,000 in Canada, forcing baristas to give away free drinks and close early. In 2016, Nissan recalled more than three million vehicles because the system that decides whether the passenger airbag should fire could fail to detect an adult in the seat; the remedy included reprogramming its software. These are public relations nightmares, not just technical failures.

Users won't stick around for buggy software. They'll delete your app, leave bad reviews, and tell others to avoid it. First impressions matter, and you rarely get a second chance.

It keeps user data secure

The bank bug that exposed customer account balances was more than embarrassing. It was a serious security breach. Testing helps identify vulnerabilities before malicious actors do. Data breaches damage trust, trigger legal consequences, and can sink companies.

Security testing verifies that user data stays protected, passwords stay encrypted, and access controls work as intended. It's not glamorous, but it's essential.

It helps teams decide what happens next

While bug reports and lists of feature suggestions might result from testing, the actual value in knowing how your app is performing is that it helps stakeholders decide what happens next. More specifically, testing can answer questions like:

Is abc feature ready to ship next week?
If not, what needs fixing now?
Can the more trivial issues wait until our next release?

At the root of it, testing should answer: where should everyone spend their time?

What are the main types of software testing?

Like most things, there are many ways to approach software testing. Below, we cover a few top ways to go about it and when you might employ each strategy.

Type	Structure	Manual or automated?	When to use it
Sanity	Light	Manual	A quick check before investing in deeper testing
Exploratory	Freeform	Manual	Hunting edge cases after the planned tests pass
Session-based (structured exploratory)	Time-boxed sessions	Manual	Exploratory freedom with progress you can report
Automated	Coded tests	Automated	Repetitive checks that run on every build
Regression	Growing checklist	Either	After code changes, before a release

1. Sanity testing

Sanity testing is what it sounds like – a quick, manual check to make sure the basics are working. It’s a lightweight form of testing that verifies critical functions work as expected and that deeper testing is worth the effort.

Benefits:

Limited scope. If an update was made to a particular feature, testers can concentrate on that and make sure it’s working fine before testing the modification in relation to the rest of the app.
Saves resources. For small teams or teams on tight deadlines, sanity testing is a good way to make sure obvious issues are caught early before investing in more intensive testing.

When to use it : Before you launch a thorough round of testing using the approaches coming up next, which can run days or weeks.

2. Exploratory testing

Exploratory testing is a hands-on, freeform approach that encourages testers to think critically and creatively. Instead of following rigid predefined test cases, testers actively explore your software, trying to find hidden bugs and unexpected behaviors – as they see fit. At Testpad, we like to say that exploratory testing is “making it up as you go along - with your brain engaged.”

Benefits:

Easy to get started. Testers just need a login and a place to write down their results, observations, and new test ideas.
Catches the “unknown unknowns.” Letting testers interact with the product and improvise tests on the fly helps them discover bugs that could’ve slipped past the predefined test cases or automated checks.

When to use it: To find edge cases after the planned and automated tests have run. Ideally, an exploratory tester is someone who didn’t write or run those tests.

3. Session-based testing

Session-based testing is a kind of exploratory testing, with structure added. If freeform exploration feels a little too loose for your team, session-based testing (SBTM) might be a good happy medium. Session-based testers still have the flexibility to test as they please, but they are confined to testing a specific area of the product for a specific amount of time.

Benefits:

Focus. Exploratory testing can be a little too “out there” for some people’s tastes. SBTM gives you the best of both worlds – the freedom to test however you want and the ability to share what you’ve tested, for how long, and what you have left to test.
Time management. Your testers might have a lot on their plates. Time-boxing their testing sessions helps them stay on track.

When to use it: When you see the value in exploratory testing but want more control over what you test and/or to give more concrete testing progress updates to higher-ups.

4. Automated testing

So far, we’ve only discussed manual testing strategies. But you can also automate your testing: write coded tests, and testing software runs them for you, as often as every build. The main benefit is speed. Thousands of checks can run in minutes, repeating far more often than any human could manage.

Automated testing has some worrisome limitations, though:

Automated tests are only as good as the test code you write, and every test is more code to debug and maintain.
They can’t test edge cases and dynamic scenarios that require human intuition.
Automated testing platforms can be expensive and time-consuming to set up.

We saw some of these dangers firsthand with the CrowdStrike outage in July 2024.

Credit: BananaLegitimate6528

So, while automation can increase your efficiency, it’s not a panacea. To deliver reliable, high-quality software, you need to balance automation with human-centered testing.

When to use it: For repetitive tests that need to happen on a regular basis. This frees up your team to focus on manual testing.

5. Regression testing

Regression testing confirms that new changes haven’t broken existing functionality. It works best as a growing checklist of precise, deterministic tests: every time you fix a bug, add a test for it, so it can’t sneak back in. Automate the tests that are worth the coding effort. The case for keeping a manual checklist too is immediacy: the moment a bug is fixed, you can add a line for it and it protects the very next release, with no automation work to wait for.

Benefits:

Catches side effects. Whenever something new gets added to your codebase, there’s a possibility of breaking things that used to work, especially in complex systems. Regression testing catches those breaks before your users do.

When to use it: After you’ve pushed up new code but before a production release.

How do you get started with software testing?

The thing about software testing is that it’s easy to go overboard. Testing every minute detail of your app isn’t necessarily the best way to expose the kind of data your stakeholders need. Then again, you don’t want to be so broad with your testing that you accidentally skip over things that end users complain about later.

Since testing exists within real-world constraints, teams must balance available time, resources, and expertise to maximize what they can learn about their product's state within those limitations.

The best way to do that? Keep things simple. Here’s a four-step process to get you going:

1. Assemble a team

The size of your team will depend on your budget and the scope of your product. If it’s a huge platform with tons and tons of features, you may need multiple teams – one for each area of the product. For more straightforward apps, you may only need a testing team of one or two.

If you need to bulk up your team but don’t have the resources to up your staff, don’t be afraid to ask trusted customers or folks on other internal teams to help you. New perspectives can help you identify new areas to test (and thereby uncover new insights). Some tools, like Testpad, have built-in features specifically for guest testing, permitting users to test your software (as prompted by a test plan) and log their results.

2. Choose your testing approach

We’ve already shared five ways to go about software testing. Review those again, with your team constraints in mind, and choose an approach (or set of approaches) that gives you the most bang for your buck.

3. Optimize your strategy for efficiency

Don’t spread your team too thin by testing the whole app at once. Focus your efforts where problems are most likely, and take advantage of practical trade-offs that move the process along.

For example, maybe you spend more time testing a feature on browsers you know for sure end users tend to use versus less common ones if you’re really pressed for time.

4. Pick the right software testing tool

In truth, you could just jot down your software testing notes in a journal, but that’s not super sharable (especially if your handwriting is a mess). Excel is a good start because it organizes your notes into a legible system.

But Testpad was built for exactly this. Each test is a single line of plain text, so writing a test plan is as fast as writing a checklist, and adding a new test is as quick as typing it. You can invite guest testers to specific projects, and share a report link so stakeholders can see how far testing has got whenever they look.

There’s very little to learn: you drag rows to rearrange them, indent rows to group related tests (or to spell one bigger test out over several lines), and comment out non-test rows using shortcuts. Each test run is a column of results, so the grid shows your coverage at a glance. And because it asks so little of testers, they keep their results up to date.

Whatever you do, don’t overcomplicate

Remember, software testing doesn’t have to be as elaborate and sophisticated as you might think. Start small, see how it goes, then learn and grow from there.

That advice applies to your testing software, too. If Testpad piqued your interest, sign up for a free Testpad account. You can use it for 30 days to decide whether it’s the right software testing tool for you and your team.

Or, if you’re still working up the courage (or your boss’s approval) to start software testing in earnest, check out our blog. We’ve got plenty of articles to get you inspired and up to speed.

What is OS compatibility testing (and how to do it)?

Stefan Butlin — Mon, 15 Dec 2025 00:00:00 +0000

Your software works beautifully on your Windows machine. Fantastic. But what about the designer on your team using a Mac? Or the developer who swears by Linux? Or the client still running Windows 10 because their IT department won't approve the upgrade?

These are all different operating systems - the core software that runs a computer. OS compatibility testing (Operating System compatibility testing) is making sure your software works across Windows, macOS, and Linux, not just whichever one you happen to develop on.

Windows dominates with around 73% market share, macOS holds about 15%, and Linux sits at 4%. That means roughly one in four of your users isn't on Windows. When your file upload works perfectly on your machine but doesn’t for Mac users because you hard-coded Windows-style file paths, those users just leave. OS compatibility testing doesn’t have to be as complicated as it sounds – keep reading and we’ll explain what it involves and how to do it for desktop software. If you’re looking for mobile-specific OS compatibility testing, you’ll find this blog more useful. And for the other angles – browsers, devices, networks, hardware – start with our guide to compatibility testing.

Can I skip OS compatibility testing?

Your software makes assumptions about how computers work, where files should go, how paths are formatted, what libraries exist – and more. All of those assumptions come from whichever operating system you develop on. If you skip OS compatibility testing, you run this risk of someone trying to run it on a different OS and everything breaking. You'll then spend potentially weeks firefighting platform-specific bugs through support tickets instead of catching them in testing. Or, you test beforehand and catch bugs before they do.

Why operating systems differ (and why that matters)

Different operating systems handle basic tasks in fundamentally different ways. Same code, different results. This is because different operating systems evolved separately and made different choices about how to handle basic tasks. None of them are wrong – they just disagree.

File paths look different: Windows organizes files with drive letters like C:\ and uses backslashes. Mac and Linux start from a root folder (/) and use forward slashes. Your code says "go to C:\Users\config.txt" and Mac has no idea what C:\ means.

File names work differently – Windows treats MyFile.txt and myfile.txt as the same file. Linux treats them as two completely different files. Mac usually acts like Windows but can be configured to act like Linux, which is somehow worse because you never know what you're getting.

Text files aren't the same – Windows ends each line differently than Mac or Linux do. This breaks when your software reads configuration files or processes user input – what looks like separate lines on Windows reads as one giant line on Linux.

Fonts render differently – Same font, different results. Text that's crisp on Windows can look too thin on Mac, or too heavy. Same font file, different systems, different appearance.

For you as a tester, this means the same code behaves differently. Your feature works on Windows, crashes on Mac – not because your code is wrong, but because the systems disagree about how things work. Skip testing on other operating systems and you'll discover these problems through angry support tickets instead of in your test environment. That's what OS compatibility testing catches before your users find it.

What should you actually test?

Focus on core features, file operations, how your interface displays, installation, and system integrations. Check your analytics before spending three days setting up a testing environment for an obscure Linux distribution that represents 0.2% of your traffic. Start with what matters:

Core features on each system – Can users actually do the main thing your software is supposed to do? Log in, process data, save files, complete purchases. Test the important stuff thoroughly.

Saving and loading files – File paths, configuration files, where your software stores things. This is where most OS issues hide. Your code assumes files go in certain places and paths look a certain way. Those assumptions break on different systems.

Security and file access – How your software handles passwords, sensitive data, and file permissions. Operating systems treat security differently and file permissions that work on Windows might create security holes on Linux. Check that your software stores sensitive data securely on all systems.

How your interface looks – Does your UI still make sense when fonts display differently? Are buttons still clickable? Does text still fit where you put it?

Installation and updates – Can users actually install your software? Does updating work? Each operating system handles this completely differently.

System integrations – If you're using notifications, file types that open with your app, or icons in the taskbar/menu bar, test these explicitly. They work entirely differently on Windows vs. Mac vs. Linux.

Start with the OS versions that matter most. Windows 10 still runs on over 60% of systems, while Windows 11 accounts for about 37%. Test both if you're targeting Windows users. For Mac users, focus on the past two or three versions that most people actually use.

How to actually do OS compatibility testing

Once you know what to test, you need a way to actually run your software on different operating systems. You don't need a room full of computers because you've got practical options:

Software that runs other operating systems on your current machine – Tools like VMware, VirtualBox, or Parallels let you run Windows on your Mac, or Linux on your Windows machine - all from one computer. They're affordable and you can quickly test different setups. The downside is they're not quite the same as real computers. How fast things run is different, and some problems only show up on actual hardware. But for catching obvious file path or saving issues, they work fine.

Online testing services – These give you access to real computers and operating systems without buying and maintaining your own hardware. Useful when you need to test on systems you don't own, though nothing beats having an actual Mac or Windows PC in front of you for important testing.

Computers that can run multiple operating systems – Set up a few machines in your office that can restart into Windows, macOS, or Linux as needed. This matters when you're testing how fast things run or tracking down problems that only happen on real hardware.

The right approach depends on your situation. If you’re starting out, you can likely get away with using software to run other operating systems. But if you’re building something graphics-heavy or that connects deeply with the system, it pays to get real hardware to test on. Most teams land somewhere in between – software-based testing for regular checks, real computers for thorough testing before shipping.

Common OS compatibility issues you'll encounter

Know what typically breaks and you'll catch issues faster when testing. These are the everyday problems that crop up when your software runs on a system that isn't the one you develop on:

Hard-coded file paths break – If you've written C:\Users\Documents\file.txt directly in your code, Mac and Linux users hit immediate errors. Use your language's path library instead.

Capitalization matters differently – Your code looks for config.txt but the actual file is Config.txt. Works fine on Windows. Breaks on Linux where capitalization matters. Works on most Macs but breaks on that one customer whose Mac treats capitalization as important.

Who can access files differs – Mac and Linux are strict about file access - not everyone can read every file. Your Windows code creates files assuming anyone can open them. On Mac or Linux, those files might get created as private by default, breaking features that need to read them.

How text files work isn't universal – Your software reads a settings file line by line. Works perfectly on Windows. On Linux, it reads the entire file as one giant line because the systems mark line breaks differently. If your software can't read the settings, it won't work.

Where to save things isn't obvious – Your code looks for a Windows location to store user data. Mac doesn't have that location. Now your software doesn't know where to save anything.

Hardware support differs too – file systems and drivers sit between your software and the physical machine, and each OS handles them differently. If your software talks to printers, webcams or other equipment, hardware compatibility testing is the companion check to run.

Built-in components aren't universal – Your software needs a component that comes with Windows automatically. Linux doesn't include it. Your software won't launch, throws cryptic errors about missing pieces.

Text displays differently – Text that's perfectly readable in your Windows interface appears too thin on Mac. Or too bold on Linux. Same font, different systems, different appearance. Your carefully designed interface looks wrong.

These problems are predictable once you know to look for them. There are, of course, a million other issues you could come across but some testing beats no testing. Just focus on what matters. Using a mind map helps you avoid leaving gaps – we have a blog on using mind maps for test planning here if you’re interested.

When should you run OS compatibility tests?

Test when your software is stable enough that it won't change dramatically, after operating system updates, and when your application starts connecting to new hardware or other software.

Don't wait until release day to discover your software doesn't work on another operating system. Test on the systems you're targeting as you build. Fixing a path problem during development takes an hour, whereas trying to bolt on OS compatibility after you've finished everything else takes weeks (ask us how we know.)

Test at these points:

Before major releases: Always. If you're shipping to users on multiple operating systems, test on those operating systems before you ship.

When Apple, Microsoft, or Linux distributions release updates: Windows updates, macOS updates, major Linux updates. These can break things. Test when they come out, not after users start complaining.

After you change code that touches the system: If you modified how files are saved, how your software connects to system features, or anything that talks directly to the operating system, test on all your target systems. These changes break compatibility most often.

When bug reports cluster around one OS: For example, if you're getting reports that all come from Mac users, that's your signal. Do focused OS compatibility testing now, don't wait for more evidence.

The pattern is simple: test early, test when things change, and test when users tell you something's wrong. That way you’ll catch issues before they become support nightmares.

Should you test on older operating system versions?

Once you've decided to test on Windows, Mac, and Linux, the next question is: which versions? Just the latest Windows 11, or also Windows 10? Only the newest macOS, or the past few versions too?

Testing on newer versions means making sure your software still works when Apple or Microsoft releases their next update. Harder to test because it hasn't happened yet. When companies release early test versions of their next update, try your software on those and watch for announcements about what's changing.

Testing on older versions matters more. Users don't always update immediately (or at all). Plenty of companies are still on Windows 10 – not because they love it, but because convincing IT to approve the upgrade is about as appealing as a root canal, and the current setup works fine anyway.

If your software only works on the latest OS version, you're cutting off users who haven't upgraded. That's a business decision, not a technical one. Just make it deliberately – know which versions you support and test on those – rather than accidentally because you forgot older versions exist.

How much OS testing is enough?

Test enough to catch issues before your users do.

Make a list of which operating systems and versions your users actually run. Check your analytics. If 80% of your users are on Windows 10, test there extensively. If 5% use Linux, test the popular versions but don't try to cover every possible variant.

Start with your top five setups and test those thoroughly. Then add more based on what's risky, not what's possible. Testing every OS version ever released is impractical and unnecessary. You're not trying to test everything that could theoretically exist. You're trying to make sure your software works for the people actually using it. Focus on the setups your real users have, not imaginary scenarios that might never happen.

You might find our blog on test strategy useful for putting some parameters around how much you’re testing.

Start simple and go from there

OS compatibility testing doesn't need elaborate processes or rooms full of hardware. Start simple by figuring out which operating systems your users run. Make a checklist of the important stuff your software needs to do (we happen to know a pretty good checklist-style testing tool...).

Test it on each system. Write down what broke, fix it and ship. That's it. Your users don't care which OS you prefer or which one you think is superior. They just want your software to work on their computer. Test the systems that matter, fix what breaks, and you're done.

Want more practical testing advice? Subscribe to get straightforward tips on all things testing sent straight to your inbox.

Network compatibility testing explained

Stefan Butlin — Tue, 09 Dec 2025 00:00:00 +0000

Network compatibility testing makes sure your app handles the messy reality of real-world connections: slow speeds, high latency, packet loss, sudden drops, and no signal at all. You simulate those conditions with throttling and proxy tools, then check that core features still work, the UI stays responsive, and errors tell users what's happening.

At a glance

Test the conditions your users actually hit: slow connections, high latency, packet loss, WiFi-to-cellular switching, and going offline entirely
53% of mobile site visits are abandoned when a page takes longer than three seconds to load (Google research)
Chrome DevTools throttling is free and takes ten seconds to set up; Charles Proxy or Fiddler give finer control for native apps
For each condition, check four things: core functionality works, timeouts are reasonable, the UI stays responsive, and errors are clear
Automate the repeatable checks; judging whether the slow experience is acceptable still needs a human

The rest of this guide covers which conditions to test, how to simulate them, and what to look for when you do.

What is network compatibility testing?

Network compatibility testing verifies that your software handles real-world connection conditions: slow speeds, high latency, packet loss, network switching, and complete disconnection. If you've ever rage-refreshed a page or clicked "submit" three times because nothing seemed to happen, you already know what bad network handling feels like.

Your app might work great in your office, but your users aren't in your office. They're on a train going through a tunnel, or in a hotel with WiFi that promises 100 Mbps and delivers 2. They could be at a conference where 500 people are fighting for the same access point, or on a construction site with one bar of signal.

Network compatibility testing catches these problems before your users do. It's how you find out that your checkout flow breaks on high latency connections, or that your file upload silently fails when packet loss hits 3%, or that switching from WiFi to cellular mid-session logs everyone out.

This type of testing typically covers:

Different connection speeds (5G, 4G, 3G, slow WiFi, congested networks)
High latency environments (satellite connections, VPNs, international access)
Packet loss and unstable connections
Network transitions (switching from WiFi to cellular mid-session)
Complete disconnection and reconnection
Restricted networks (corporate firewalls, content filtering)

The specific conditions you test depend on how and where people actually use your software. A mobile app needs to handle cellular network switching. An enterprise tool needs to work behind corporate firewalls. A video streaming service needs to adapt to bandwidth fluctuations.

Why does network performance matter so much?

When your app doesn't load, or loses data mid-submission, or just spins forever without telling the user what's happening – the user won’t blame the network, they’ll blame the app.

According to Google's widely cited mobile speed research, 53% of mobile site visits are abandoned if a page takes longer than three seconds to load. The same study found sites that load in five seconds see 70% longer sessions than ones that take nineteen. Every second counts.

A page that loads in two seconds on your office network might take eight seconds on a congested mobile connection. And that's assuming the connection stays stable the whole time.

Network conditions vary wildly. Ookla's Speedtest data shows global median fixed broadband speeds around 95 Mbps, but that's just an average. Singapore users enjoy speeds over 320 Mbps. Users in some countries struggle with under 10 Mbps. Mobile speeds range from over 400 Mbps in the UAE to single digits in areas with poor coverage.

Your users could be anywhere on that spectrum, and unlike slow hardware that consistently behaves the same way, network conditions change moment to moment. The same user might go from excellent to terrible connectivity just by walking into a different room.

How do network problems actually affect users?

Network issues won’t necessarily crash your app, but they are often frustrating enough to cause users to stop using it. Here are some common scenarios your users may face if a poor network affects your app:

Timeouts with no feedback – the user clicks a button, nothing happens for thirty seconds, then an unhelpful error appears. They have no idea if they should try again or wait longer.

Lost data – someone fills out a long form, hits submit, the connection hiccups, and everything they entered disappears. Good luck getting them to fill it out again.

Broken partial states – an action partially completes before the connection drops. Now your database says one thing and the user interface shows another.

Frozen interfaces – the app makes a network request and blocks the entire UI until it completes. On a slow connection, the app appears completely unresponsive.

Silent failures – the request fails but the app doesn't tell the user. They assume their action worked when it didn't.

These failures are cheap to find once you go looking: simulate a bad connection and watch what your app does.

Which network conditions should you actually test?

You can't test every possible network configuration. But you don't need to. Focus on the conditions your users actually encounter.

Start with your analytics

If you have any kind of performance monitoring, check what network conditions your users usually experience. Where are your slowest response times coming from? What percentage of users are on mobile versus desktop? Which geographic regions see the most timeouts?

This tells you where to focus. If 60% of your users are on mobile, prioritize cellular network testing. If you have significant traffic from regions with slower infrastructure, test those conditions specifically.

Test categories, not every possible condition

You're looking for patterns, not exhaustive coverage. Test representative conditions from each category:

Connection speeds:

Condition	Speed	When to test
Fast WiFi/fiber	50+ Mbps	Baseline – your app should feel snappy here
4G/LTE	10–50 Mbps	Common mobile condition; should still feel responsive
Slow 3G	400 Kbps	Weak signal, rural areas, developing markets
Congested WiFi	1–5 Mbps	Coffee shops, conferences, busy offices
Very slow	Under 500 Kbps	Edge cases – should still work, even if slowly

Latency conditions:

Low latency (under 50ms) – typical for local servers, good WiFi
Medium latency (50–150ms) – cellular networks, distant servers
High latency (200ms+) – satellite connections, VPNs, international access

Stability conditions:

Stable connection – no interruptions
Intermittent packet loss (1–5%) – congested networks, weak signal
Network switching – WiFi to cellular or vice versa
Complete disconnection and reconnection

Don't forget offline scenarios

What happens when the network disappears entirely? Users go through tunnels, enter airplane mode, or walk into areas with no signal. Does your app handle this gracefully, or does it just break?

Even if your app requires connectivity to function, it should tell users clearly what's happening rather than silently failing or showing cryptic errors.

How do you actually test network conditions?

You have a few options, ranging from simple to sophisticated.

Use browser and device throttling

Throttling lets you artificially slow down your connection to simulate what your users might experience. Instead of waiting for bad WiFi, you tell your browser to behave as if it's on a slow network.

For web apps: Chrome has this built in. Right-click anywhere on your page, select "Inspect" to open DevTools, then go to the Network tab. You'll see a dropdown that says "No throttling" – click it and choose "Slow 3G" or "Fast 3G" to simulate those conditions. Now use your app normally and see what happens. It's free, takes about ten seconds to set up, and catches obvious problems fast.

For mobile apps: iOS has a tool called Network Link Conditioner (you'll need to enable Developer Mode first). Android's emulator has similar options baked in. Both let you simulate slow or unstable connections without leaving your desk.

Use network simulation tools

Browser throttling is handy, but it only works for what's running in that browser. If you're testing a native mobile app, a desktop application, or you need more precise control over conditions like packet loss, you'll want a dedicated proxy tool.

These tools sit between your device and the internet, letting you control exactly what happens to traffic passing through. You can slow it down, add delays, simulate data getting lost in transit, or block specific requests entirely.

Charles Proxy is popular for mobile app testing. You point your phone at your computer's IP address, and all traffic routes through Charles. From there you can throttle to preset conditions like "3G" or "4G," or dial in specific bandwidth, latency, and packet loss values. There's a 30-minute free trial, then it's a paid license.

Fiddler does similar things and has a free version. It's Windows-focused but works on Mac too.

The setup takes a bit longer than browser throttling – you're configuring proxy settings on your device – but you get much finer control and can test any app, not just web browsers.

Test on actual slow networks

Simulation is useful but not perfect. If possible, test on real networks that match your users' conditions. Take a laptop to a coffee shop with terrible WiFi. Test on a phone with weak cellular signal. Use a VPN to simulate international latency.

Real networks have quirks that simulations miss. A network that's technically fast but has intermittent congestion behaves differently from a consistently slow connection.

What should you actually check?

Testing network conditions is straightforward, but the complexity comes from knowing what behaviors to look for.

Basic functionality

For each network condition, verify:

Does core functionality still work? Slower is acceptable, broken is not.
Are timeouts reasonable? A 30-second timeout on a fast network feels broken. On a slow network, it might be necessary.
Does the UI stay responsive? Users should be able to interact with the app even while network requests are pending.
Are errors clear and helpful? "Network error" tells users nothing. "Connection lost – your changes will save when you're back online" tells them exactly what's happening.

User feedback during delays

When things are slow, does the app tell users what's happening? Loading indicators, progress bars, and status messages make the difference between "this is slow" and "this is broken."

Research from Ericsson finds that smartphone user experience is largely determined by connection speed rather than latency, and you can't control either from inside your app. What you can control is feedback. Silence is worse than slowness.

Recovery from failures

Network failures happen. What matters is how your app handles them:

Does it retry failed requests automatically where appropriate?
Does it preserve user input when submissions fail?
Does it recover gracefully when connectivity returns?
Does it avoid creating duplicate actions if requests are retried?

Can you automate network testing?

Partially. You can automate some aspects, but not everything. Automated tests can verify that requests complete within acceptable timeframes under simulated slow networks. They can check that your app handles timeout errors without crashing. They can confirm that offline detection works.

What automation can't easily check is whether the user experience is acceptable. Is the loading indicator clear? Does the error message make sense? Is the app frustrating to use when it's slow? These require human judgment.

Use automation for regression testing – confirming that network handling you've already verified still works after code changes. Use human testing to evaluate the actual experience.

Start small, expand gradually

Network conditions are one of the five angles in our guide to compatibility testing – worth a read if you're working out which of the others apply to your product.

Begin with the conditions your users most commonly encounter and test those thoroughly. Add more scenarios as you have time and as user reports reveal gaps. You're just trying to ensure most of your users can actually use your software regardless of how good their connection happens to be at that moment.

If you want somewhere to keep these checks, Testpad suits this kind of testing well: write each check as a line of plain text, add a column each time you run through them under a different network condition, and the grid shows which conditions you've covered at a glance.

Want more straightforward testing advice? Subscribe to get practical tips on mobile testing, exploratory testing, and keeping quality high straight to your inbox.

What is mobile OS compatibility testing, and how do I start?

Stefan Butlin — Tue, 02 Dec 2025 00:00:00 +0000

Some people use Android, others use iOS. Mobile OS compatibility testing makes sure your app works exactly as intended on both operating systems. Your app might work perfectly on your own iPhone 15 Pro. Launches fast, looks sharp, everything responds instantly. Then a user on a three-year-old Samsung Galaxy A12 downloads it, waits 30 seconds for it to load, taps a button that doesn't respond, and deletes it. You've just lost a customer because you only tested on the phone in your pocket.

This is why mobile-specific OS compatibility testing exists – it's the mobile corner of the wider discipline covered in our guide to compatibility testing. The challenge is that "the devices people use" means thousands of different combinations of operating systems, manufacturers, and hardware. You can't test them all. You may be wondering which devices actually matter, how to test on phones you don't own, and what typically breaks across different operating systems. Keep scrolling to find out.

The fragmentation problem (when mobile OS testing gets messy)

Fragmentation means one operating system exists in dozens of different versions across thousands of devices. When OpenSignal last counted in 2015, Android was already running on over 24,000 distinct device models, and Google now puts Android at more than 3 billion active devices. iOS runs on about 30 models. This is a big problem for testers.

Google releases Android as open-source software. Samsung takes it, modifies it, adds their own interface, and ships it on hundreds of device models across different price points. Xiaomi does the same thing. So does Oppo, Vivo, OnePlus, Motorola, and dozens of other manufacturers. They all start with Android but end up with something that looks and behaves differently.

Same code, different results. Your layout looks perfect on a Pixel but breaks on a Samsung because of how Samsung changed the default fonts. Your app crashes on a Xiaomi phone because of how Xiaomi kills background apps. You fixed a bug on one Android device only to discover it still happens on three others.

iOS is simpler but not simple. Apple controls both the hardware and software, so you're dealing with fewer variables. But you still have multiple iOS versions running across phones, tablets, and varying screen sizes. And Apple releases major iOS updates every September that can break things in unexpected ways.

Global market share sits at roughly 72% Android and 27% iOS. That single iOS percentage represents a more predictable testing scenario than the entire Android percentage combined.

What tends to break across mobile operating systems

Mobile OS compatibility issues show up differently than desktop. These are some very real, common issues that happen between different mobile operating systems – all proving why OS mobile testing is necessary:

Screen layouts collapse on smaller devices – Your carefully designed interface assumes a 6.5" screen. Half your Android users have 5.5" screens or smaller. Text overlaps, buttons disappear off the edge, the interface becomes unusable.
Touch targets are too small – What feels fine with a mouse cursor doesn't work with a finger. Apple's Human Interface Guidelines recommend 44x44 points minimum for touch targets. Android recommends 48 pixels minimum. Buttons smaller than this get mistapped or missed entirely.
Permissions work completely differently – iOS asks for location permission with a system dialog you can customize but not control. Android lets you request permissions whenever you want. Some Android manufacturers add extra permission layers on top. Your carefully timed permission request works on iOS and confuses Android users.
The back button exists on Android but not iOS – Android users expect a back button in the bottom navigation bar. iOS users expect a back button in the top left corner or a swipe gesture. Your navigation needs to work with both.
Apps get killed in the background differently – iOS is aggressive about closing background apps to save battery. Some Android manufacturers (particularly Chinese brands) are even more aggressive. If your app doesn't properly save its state, users open it and lose their work.
Keyboards cover input fields – The on-screen keyboard appears and hides your login form. Users can't see what they're typing. This happens because operating systems handle keyboard appearance differently and your layout doesn't account for it.
Gesture conflicts – You added a swipe-from-edge gesture to open a menu. Android's system back gesture uses the same swipe. Now your menu and the back button fight each other.

These problems are predictable once you know they exist, and most of them show up within minutes of testing on an actual device that isn't the one you develop on.

How to decide what to test (because you can't test everything)

You're not going to test all 15,000 Android devices. The question is: which ones matter enough to test?

Start with your analytics – Check which devices your users generally have. Google Analytics, Firebase, or your app store dashboard will show you the breakdown. If 60% of your users are on Samsung devices, test on Samsung devices. If barely anyone uses tablets, don't prioritize tablet testing yet.
Test the extremes – Pick one high-end flagship phone (newest Samsung Galaxy or Pixel) and one budget device from 2-3 years ago (Samsung A-series, older Xiaomi). The flagship shows you what your app can do. The budget phone shows you what breaks when resources are limited. Most devices fall between these extremes.
Cover the main Android manufacturers – Samsung, Xiaomi, and Google make the most popular phones. Test on at least one device from each. They modify Android differently, which means your app behaves differently.
Test the iOS versions people actually use – Check Apple's data on iOS version adoption. Usually about 90% of users are on the current or previous iOS version within a few months of release. Test on the current version and one version back. Don't worry about iOS 12 unless your analytics show meaningful usage.
Include one tablet if tablets matter – iPad and Android tablets represent maybe 10-15% of users for most apps. If you know tablets are important for your use case, include one in testing. Otherwise, test phones first.

This approach covers 80-90% of your user base without needing dozens of devices. Testing everything is impossible and unnecessary, but testing nothing means shipping broken software. Test strategically.

Three ways to test on multiple devices

Once you know which devices matter, you need access to them. You have three practical options:

### Cloud-based device testing platforms

Services like BrowserStack, Sauce Labs, or AWS Device Farm give you remote access to real physical devices. You control the phone through your browser, run through your test scenarios, and see exactly how it behaves. This works well for checking that things work across many device combinations without buying hardware. The downside is slightly laggy interaction and occasional connection issues. But for catching broken layouts and basic problems, cloud platforms are practical.

Emulators and simulators

Android Studio includes Android emulators. Xcode includes iOS simulators. Both are free and run on your development machine. They're useful for quick checks during development but shouldn't be your only testing method. Emulators don't show real device performance, touch behavior feels different, and hardware-specific problems don't appear. Use them for rapid iteration, not for final validation.

Physical device lab

Buy or borrow a small collection of actual phones. This matters when you need to test performance, gestures, or anything that requires realistic device interaction. You don't need 50 devices. Five to seven carefully chosen devices covering your main user segments works fine. One high-end Android, one budget Android, one Samsung specifically, one iOS device, maybe one tablet. Keep them on your desk and use them regularly.

Most teams combine approaches – emulators during development for quick checks, cloud platforms for broader coverage, and a few physical devices for the final thorough testing pass before release. You don’t need to pick one method, just pick the right method for each testing phase.

When mobile OS compatibility testing should happen

Test when it matters, not constantly. Here's when it matters:

Before submitting to app stores – Always. Run through your app on the key device combinations before you submit to the App Store or Google Play. Find the broken layouts, permission issues, and crashes before reviewers or users do.
When iOS or Android release major updates – Apple ships iOS updates in September. Android updates roll out gradually across manufacturers throughout the year. When a new version releases, test your app on it. Updates change how things work and can break features that were working fine before.
After changing navigation or gestures – If you modified how users move through your app or added gesture controls, test on both iOS and Android devices. Navigation and gestures work differently enough between iOS and Android that they break more often than other features.
When adding permissions – Every time you request a new permission (camera, location, notifications), test the permission flow on multiple devices. iOS and Android handle this completely differently, and manufacturers add extra variations on top.
When user feedback clusters around specific devices – If you're getting crash reports or complaints that all mention Samsung devices or older iOS versions, that's your signal. Do focused testing on those specific setups.

Between these moments, you don't need constant cross-device testing. Focus your compatibility testing when you're making changes that touch the operating system or when you're about to ship. The rest of the time, develop on whatever device you have and trust your regular development testing.

The one mobile OS testing mistake to avoid

The biggest mistake is testing only on flagship devices your team owns. Your developers have iPhone 15 Pros. Your designer has a Pixel 8. You test on those because they're convenient. Then you ship and discover your app barely runs on the budget Android phones that represent 40% of your user base.

Budget devices expose memory issues, performance problems, and rendering bugs that expensive phones mask with better hardware. If you only test on high-end devices, you're only testing for users who can afford them.

Include at least one budget device in your testing. It doesn't need to be the absolute cheapest phone available. Just something from the mid-to-low range like a two-year-old Samsung A-series, a Motorola G, or a budget Xiaomi device. Run your app on it and see how it performs when memory is limited and the processor is slower. That's the experience many of your users are getting.

Start with what you can actually test today

Mobile OS compatibility testing sounds overwhelming until you break it down. Check your analytics to see which devices your users have. Pick five devices that represent most of your user base – probably a mix of Android models across price points and a recent iOS device. Test your app on those devices before major releases and when the operating systems update.

That's it. You're not trying to achieve perfect coverage across every device ever made. You're trying to make sure your app works for the people actually using it. Start with the devices that matter, catch the obvious problems, and expand your testing from there as needed.

Want straightforward testing advice? Subscribe to get practical tips on mobile testing, exploratory testing, and keeping quality high straight to your inbox.

Hardware compatibility testing explained

Stefan Butlin — Fri, 28 Nov 2025 00:00:00 +0000

Hardware compatibility testing is how you figure out which printers, webcams, scanners, and other equipment will actually work with your software before your users discover which won't.

Your software might work perfectly with the new webcam you bought last month, but when a user tries it with their five-year-old Logitech webcam, the webcam feed freezes. The problem isn't your code, it's that every manufacturer builds hardware differently. Models from different years behave differently. Equipment that should work the same way often doesn't. Your software is supposed to handle all these variations, and users don't care whose fault it is when things break – they just know your software doesn't work for them.

Hardware compatibility testing catches the gap between your software working perfectly on your desk and failing completely on someone else's, purely because they're using different equipment.

What is hardware compatibility testing?

Hardware compatibility testing checks whether your software works with the physical equipment people connect to their computers – printers, webcams, scanners, external drives, graphics cards, and everything else cluttering up their desks.

It's different from device compatibility testing (which tests across phones and tablets). Hardware testing is about the stuff you plug in or install – connected via USB, HDMI, Bluetooth, or whatever other cable you found in a drawer. Both belong to the wider family of checks covered in our guide to compatibility testing.

Do you even need to test hardware?

This depends on what your software does. If your software doesn't directly interact with hardware – you're building a notes app or a task manager – then hardware compatibility probably isn't your problem. Sure, people use keyboards and mice, but the OS handles that.

But if your software:

Prints anything (receipts, labels, documents, reports)
Uses cameras or microphones (video calls, scanning, recording)
Reads from or writes to external storage (backups, imports, exports)
Processes images from scanners or cameras
Interacts with specialized equipment (card readers, barcode scanners, medical devices)
Requires specific graphics card features (3D rendering, video processing)

Then yes, you need to test hardware.

The problem with hardware

Hardware compatibility issues don't follow patterns. A printer works for 99 people and fails for the 100th. A webcam that's been fine for months suddenly stops working after a Windows update. Your software crashes only when someone connects three USB devices simultaneously.

Compatibility problems you’ll often see with hardware tens to fall into one of these categories:

Detection failures - your software can't find the hardware at all, or finds it but doesn't recognize what it is. The user plugs in their printer and nothing happens. There’s no error message or feedback, just silence.

Driver conflicts - the hardware is there but the driver (the software that tells your computer how to talk to the hardware) is wrong, outdated, or conflicts with something else. Your software expects one set of commands but the driver translates them incorrectly. Features work partially or not at all.

Performance problems - the hardware works but performs terribly. Printing takes 10 minutes instead of 10 seconds. The webcam feed stutters and freezes. File transfers crawl along at unusable speeds.

Inconsistent behavior - the hardware works sometimes and fails other times, depending on what else is running, how it's connected, or what mood it's in apparently. These are the worst because they're hard to reproduce.

Missing features - your software assumes all webcams support 1080p, or all printers support duplex printing, or all scanners support certain color depths. They don't. Now what?

Which hardware should you actually test?

You can't test everything. Just look at printers – HP alone has released hundreds of printer models in the last decade. Add Canon, Epson, Brother, Lexmark, and dozens of other manufacturers, and you're looking at thousands of printer models still in use. Now multiply that across webcams, scanners, external drives, graphics cards, and every other category of hardware your software might interact with.

Testing even a fraction of these would take months and cost a fortune. You'd need to buy or borrow hundreds of pieces of equipment, test each one thoroughly, and somehow keep up as manufacturers release new models every few months.

So you need a strategy – a way to test enough hardware to catch real compatibility issues without bankrupting yourself or spending the next year doing nothing but hardware testing. Try this approach:

Start with usage data

Check your analytics and support tickets. What hardware do your users actually report using? What shows up in crash logs and error reports? What equipment do people complain about in support emails?

This tells you where to focus. If 60% of your users have Canon printers and 3% have Epson, test Canon first.

Test categories, not every model

You don't need to test every printer model ever made. Just test a few from major manufacturers in each category:

For printers:

One budget inkjet (Canon, HP, Epson)
One laser printer (Brother, HP)
One receipt printer if relevant
One label printer if relevant
One via USB, one via network

For webcams:

Built-in laptop cameras (MacBook, ThinkPad, Dell)
External USB webcams (Logitech, Microsoft, generic Chinese models)
Different resolutions (720p, 1080p, 4K)

For storage:

External hard drives (HDD and SSD)
Network storage if relevant
SD cards if relevant

For graphics cards:

Integrated graphics (Intel, AMD)
Mid-range dedicated GPUs (NVIDIA, AMD)
High-end cards if your software needs them

You're looking for patterns. If your software works with three HP printers but fails with all Canon printers, that's useful information. You've found a compatibility issue, not a one-off bug.

Consider the age problem

Older hardware is where things get interesting. That five-year-old scanner still works fine, so people keep using it. Your software needs to handle it or fail gracefully.

Testing old hardware is like being a restaurant that needs to keep serving customers who bring their own plates from home. Sure, you'd prefer everyone used your nice matching dinnerware, but some people are attached to that chipped plate from 2018 and they're not replacing it just because you'd prefer they did.

The question is: how far back do you support?

Some teams set a cutoff like "we support hardware from the last five years." This works if you can enforce it. Others test older hardware opportunistically – if they can get it cheaply or borrow it, great. If not, they rely on user reports. There's no perfect answer. Balance the likelihood of users having old hardware against the cost of testing it and maintaining compatibility.

How to test hardware

Testing hardware compatibility is pretty straightforward – plug it in and see what happens. The complexity comes from testing enough equipment to catch real patterns without spending your entire testing budget on USB cables.

Basic functional testing

For each piece of hardware, verify:

Does your software detect it? Not just "is it connected" but "does your software recognize what it is and show it as available?"

Do core features work? Printing actually prints. Webcams actually show video. Scanners actually scan. This sounds obvious but you'd be surprised.

Does it perform acceptably? Not "does it work at all" but "does it work well enough that users won't complain?" A 30-second print job is fine. A 10-minute print job is not.

What happens when it fails? Unplug it mid-operation. Turn it off. Run out of paper. See if your software crashes or handles it gracefully.

Can users recover from problems? If something goes wrong, can they fix it or are they stuck restarting your entire application?

Test the weird scenarios

Hardware fails in creative ways. Test:

Connecting multiple pieces of the same type simultaneously
Connecting and disconnecting equipment while your software is running
Using hardware while system resources are limited
Switching between different models mid-operation
Running your software on a system with outdated drivers
Using equipment connected through USB hubs vs directly

These scenarios catch issues that only appear in real-world usage.

Document what actually works

Keep a simple list:

Hardware tested (model, connection method)
What works
What doesn't work
Workarounds if any

This becomes your supported hardware list. Update it every few months as you test new equipment or get user reports about hardware you haven't tested.

A spreadsheet works for this. A tool built for hardware test management works better: you keep the checks as one checklist and run it as a fresh column for each model you test, so the supported-hardware list builds itself as you go.

When hardware doesn't work

You'll find hardware that doesn't work with your software. Now what?

Option 1: Fix it

If the hardware is common enough and the fix is reasonable, fix it. Add driver compatibility code, handle the edge cases, test thoroughly, move on.

Option 2: Document it

If the fix would take weeks and affect 2% of users, document that this hardware doesn't work. Add it to your "unsupported hardware" list. Show a clear error message when users try to use it.

This sounds harsh but it's honest. Better to tell users upfront than let them waste time troubleshooting.

Option 3: Provide a workaround

Sometimes you can't fix the root cause but you can offer an alternative. "This scanner doesn't work directly, but you can import files it creates." Not ideal, but better than nothing.

The driver nightmare

Drivers are where hardware compatibility goes to die. Your software talks to the OS, the OS talks to drivers, drivers talk to hardware. When something breaks, it's usually the driver's fault. But users blame your software anyway.

You can't fix bad drivers. What you can do:

Detect driver issues - check driver versions, warn users when drivers are outdated or known to cause problems.

Provide clear errors - "Your printer driver appears to be outdated. Update it at [link]" is more helpful than "Print failed."

Test with common drivers - manufacturers update drivers regularly. Test with a few recent versions, not just the latest.

Document driver requirements - tell users which driver versions you've tested and which ones you know cause problems.

It's not perfect but it reduces support burden.

Should I use automation for hardware testing?

Yes, but it has limited use.

Automated tests can check basic technical facts – is the printer showing up in the list of available printers? Does the webcam appear as a video source? Can your software read from the external drive? These are yes/no questions that computers can verify.

What automation can't check is quality. Does the printed page actually look right, or are the colors off? Does the webcam feed look clear and smooth, or is it choppy and blurry? Is the scanned image sharp or slightly distorted? These require human judgment. You need someone to actually look at the output and decide if it's acceptable.

Automation also struggles with the unpredictable stuff. What happens when someone unplugs the printer mid-job? Does your software handle it gracefully or crash? Does a useful error message appear or does nothing happen? Automated tests can simulate these scenarios, but interpreting whether the software responded well requires human context.

Use automation for regression testing – verifying that hardware you've already tested still works after code changes. If your software detected a Canon printer correctly last week, an automated test can check it still detects it after you updated your printing code. Fast, efficient, catches obvious breaks.

But when you're testing a new printer model for the first time, plug it in, print something, and see what actually happens.

Start small, expand gradually

Begin with the most common hardware your users have. Test it thoroughly, expand to other models as you have time and budget, and build up your supported hardware list over time.

You're not trying to support everything ever made. You're trying to support enough that most of your users can actually use your software with the equipment they own.

Want more straightforward testing advice? Subscribe to get practical tips on mobile testing, exploratory testing, and keeping quality high straight to your inbox.

Device compatibility testing explained

Stefan Butlin — Tue, 25 Nov 2025 00:00:00 +0000

Device compatibility testing makes sure your app runs smoothly, displays correctly, and doesn’t tank someone’s battery – no matter the device they are using. While your app might be lightning-fast on your test device, your user’s phone probably has 73 other apps installed, hasn't been restarted in months, and is running an Android version from 2021 that manufacturers stopped supporting two years ago. When they open your app, it takes fifteen seconds to load, stutters through every animation, and crashes the moment they try to upload a photo.

They're not going to email you a detailed bug report. They're going to uninstall it and leave a one-star review saying your app is "trash" and "doesn't work." And they're not wrong. Your app doesn't work – for them, on their device, in their actual usage conditions.

That's the gap device compatibility testing is supposed to catch. The difference between how your app performs in your controlled test environment versus how it behaves on the messy, varied, real-world devices sitting in people's pockets. If you’re wondering how to get started with compatibility testing, stick around – we cover it all in this blog.

What is device compatibility testing?

Device compatibility testing verifies that your software works as it should across the different devices your users most commonly have. It's often called mobile device compatibility testing, but that's too narrow – it covers any portable device people might use: phones, tablets, even smartwatches if your app runs there.

This usually means testing across:

Different device manufacturers (Apple, Samsung, Google, Xiaomi, Huawei)
Various device models and generations
Screen sizes and resolutions
Different chipsets and processor speeds
Varying amounts of RAM and storage
OS versions (including older versions people haven't updated)
Different device capabilities (cameras, GPS, biometrics, NFC)

This list looks intimidating, but you don’t need to test everything – it really depends on what devices your users are most likely to access your app on, and what your app asks of the device.

Device coverage is one of five angles in our guide to compatibility testing, alongside browsers, operating systems, networks and hardware.

Is compatibility testing always needed?

Yes, to varying degrees. Your users aren't all donning the latest – or the same – mobile phones and other tech, and device differences create real problems. A feature that works perfectly on one device might drain the battery on another. An animation that's smooth on flagship hardware might stutter and lag on older models. A layout that looks great on one screen size might be completely broken on another.

If your app runs smoothly on a new phone with 12GB of RAM but crashes on a device with 4GB, you've just excluded a huge portion of potential users. They won't write you a helpful bug report – they'll just uninstall your app and give you a one-star review.

The goal isn’t to make your app work perfectly on every device ever made – that’s unrealistic (and a waste of time). The point is to make sure it works well enough on the devices your real users actually have.

Common device compatibility issues

Devices differ in all sorts of ways that can affect how your software behaves. Manufacturers make different hardware choices. They tweak Android in their own ways. They focus on different features. So something that runs perfectly on one device might completely fall apart on another.

Here are some of the usual suspects you’ll spot when testing across devices:

Performance variations – the same app runs fast on flagship devices but becomes sluggish on mid-range or older hardware. Animations stutter. Pages take too long to load. The app feels unresponsive.
Memory constraints – devices with limited RAM struggle with apps that assume everyone has 8GB+ available. Your app might work fine during testing but crash in the real world when users have multiple apps running.
Screen size differences – an interface designed for a 6.7-inch flagship screen looks cramped and unusable on a 5.4-inch budget phone. Text becomes too small to read. Buttons are too close together. Critical elements get cut off.
Resolution issues – images and icons look sharp on high-DPI displays but pixelated on lower-resolution screens. Or vice versa – your app loads massive image files that look fine but kill performance on budget devices.
OS version fragmentation – features available in the latest OS version don't exist in older versions. APIs behave differently. Security models change. Android is particularly notorious for fragmentation, with users spread across multiple OS versions. There's more on this in our guide to mobile OS compatibility testing.
Hardware capability differences – assuming every device has NFC, or a fingerprint scanner, or a high-quality camera. Not all devices have the same sensors and features. Your app needs to handle missing capabilities gracefully.
Manufacturer customizations – Samsung's version of Android behaves differently than Google's, which differs from Xiaomi's. Manufacturers add their own layers, change default behaviors, and implement features differently.
Battery drain – background processes, location services, or inefficient code that barely impact battery life on new devices can destroy older batteries. Users notice and blame your app.

That’s a lot of ways things can go wrong, and they often do. Device compatibility testing helps you catch these quirks early, so your users get a smooth experience no matter what’s in their pocket.

How to do device compatibility testing

Device compatibility testing sounds like you need a room full of hundreds of phones and tablets, all charging and updating and ready to test. Thankfully, you don't.

What you really need is a clear view of which devices actually matter to your users, a few representative models to test on, and a simple, consistent way to check your core functionality. Most teams either overcomplicate it – testing on every device they can find – or avoid it altogether because it feels too big to tackle. Neither approach helps.

Here’s an easy and practical approach:

Know your audience

Check your analytics to see which devices your users actually own. Don't waste time testing on devices that represent 0.1% of your users. Focus on the models and OS versions that matter.

As of 2025, device fragmentation looks different by platform. iOS users concentrate on the last 3-4 iPhone generations, with most running recent iOS versions. Android users are spread across dozens of manufacturers, hundreds of models, and multiple OS versions. Your analytics will show what matters for your specific app.

Get a testing strategy going

Start by defining your minimum supported specs. What's the oldest OS version you'll support? What's the minimum RAM? What screen sizes matter? Be explicit about this – it guides your testing and helps you make decisions when something doesn't work on ancient hardware.

Then create your device test matrix. List the combinations that represent your user base. You don't need to test every possible device, but you should cover:

Your most popular devices (top 5-10 from analytics)
The oldest device/OS combo you're supporting
One or two budget devices
Different screen sizes (small, medium, large)
At least one device from each major manufacturer your users have

Test systematically

Work through your critical flows on each target device. Think of each device compatibility test as a chance to catch issues before your users do. Install your app, open it, use the main features. Create an account. Complete key tasks. Push the app to the background and bring it back. Leave it running for a while. Rotate the screen. Switch to airplane mode and back.

You're looking for: crashes, performance issues (lag, stuttering, slow loading), layout problems, missing or broken features, battery drain, overheating, and weird behavior that doesn't happen on other devices.

A simple checklist tracking which devices you've tested and what issues appeared works fine. There’s no need to overcomplicate it.

Test on real devices

Emulators and simulators are useful for quick checks, but they're not substitutes for real hardware. They don't accurately represent performance, touch interactions, battery usage, or manufacturer customizations.

Build a device lab with actual hardware. Borrow phones from coworkers. Buy used devices that represent your user base – you can pick up two-year-old mid-range phones cheaply. If you need access to devices you can't get, cloud testing services like BrowserStack or AWS Device Farm provide real devices remotely.

Test throughout development

Don't wait until the end to discover your app is unusable on mid-range devices. Test on your target devices regularly throughout development. Catching performance issues or layout problems early is cheaper than rewriting half your app later.

Pay attention to the edge cases

Test when the device is under stress. Fill up the storage to 90%+. Let the battery drop to 5%. Have 20 other apps running. Test on a slow or spotty connection. These aren't edge cases – these are normal conditions for many users.

Remember to test early, test often, and focus on your real life users rather than hypothetical ones. That way you’ll deliver an app that works reliably for the people who actually use it.

What to actually test

Don't try to test everything on every device. Each device compatibility test should focus on what matters most:

Installation and first launch – can users actually install your app? Does it launch successfully? Does onboarding work? First impressions matter, and if your app crashes on first launch, users won't give it a second chance.
Critical user flows – login, signup, core features, checkout, payment processing. Whatever your users need to do regularly, test it thoroughly across your target devices.
Performance-intensive features – video playback, image processing, animations, games, anything computationally expensive. These are where device differences show up most clearly.
Features using device hardware – camera, GPS, microphone, sensors, NFC, biometrics. Test that your app handles missing capabilities gracefully and works correctly when the hardware is present.
Network handling – how does your app behave on slow 3G? What about when the connection drops completely? Does it handle switching between WiFi and cellular smoothly?
Battery and resource usage – does your app drain battery faster than it should? Does it keep the screen awake when it shouldn't? Does it consume unreasonable amounts of storage or data?
Layout at different screen sizes – small phones, large phones, tablets, unusual aspect ratios. Your UI should adapt appropriately to different screens.
Background behavior – what happens when users switch to another app? Does your app maintain state correctly? Does it resume where they left off?

Start with your most critical paths and expand from there. A broken payment flow is worse than a slightly janky animation on one device model.

Common device compatibility testing pitfalls

Teams that test across devices still make predictable mistakes. Some are obvious, others sneak up on you, and they all cost time, frustrate users, and make your app look unreliable.

Here are the pitfalls to watch out for:

Testing only on flagship devices – your development team probably has nice phones. Your users probably don't all have nice phones. Test on mid-range and older devices that represent real usage.
Ignoring OS version fragmentation – the latest OS version isn't what most users are running. Test on older OS versions that still have significant user bases, especially on Android.
Assuming emulators are enough – they're not. Emulators don't accurately represent performance, touch interactions, or manufacturer customizations. Use real hardware.
Not testing under realistic conditions – testing on a pristine device with perfect WiFi and full battery doesn't reflect real usage. Test when storage is full, battery is low, and connection is spotty.
Over-testing obscure devices – yes, someone somewhere has a device from 2015 running a custom ROM. Unless that shows up in your analytics, don't spend time on it.
Forgetting about tablets – if you have tablet users, test on tablets. The assumptions you made for phone screens don't always translate.

Avoiding these common pitfalls keeps your device testing focused and practical, so you’re checking the right devices, in the right conditions, without wasting time.

Should I use an automated testing tool?

Installing your app on different devices and actually using it – i.e. manual testing – is what we’d recommend you start with. Tap through the features, watch how it performs and notice where it feels slow or looks wrong. This catches the issues that matter – layout problems, performance issues, usability quirks.

Automation helps for regression testing across multiple devices, especially for catching crashes and obvious functional breaks. Cloud testing platforms can run automated tests across dozens of devices simultaneously. Useful for quickly verifying nothing broke after a code change.

But automation won't catch subtle performance degradation, slightly off layouts, or the feeling that something just isn't quite right on a particular device. Manual testing on your target devices remains essential.

Keep it practical

Device compatibility testing doesn’t need complicated processes or a room full of devices. Keep it simple: figure out which devices your users actually have, grab a few representative models, and create a checklist of your critical flows. Work through them, note what works and what needs fixing, and move on.

The goal isn’t perfection on every device ever made – it’s making sure your users can actually use your app, whatever they’re using. Focus on that, skip the rest, and you’ll be fine.

Want straightforward testing advice? Subscribe to get practical tips on mobile testing, exploratory testing, and keeping quality high straight to your inbox.

Cross-browser testing explained

Stefan Butlin — Mon, 17 Nov 2025 00:00:00 +0000

Cross-browser testing makes sure your site works for everyone, no matter what browser they’re on. Your website might work perfectly on your MacBook Pro running Chrome. But what about your users on Windows 11 with Edge? Or the ones still clinging to an iPad from 2018 running Safari? Or the person accessing your web app through Firefox on a Linux machine with an older screen resolution? Even slight differences in browser versions can break layouts, slow down features, or cause buttons not to work.

That's where cross-browser testing comes in. Here we’ll break down how it works, why it’s useful, and some tricks of the testing trade that make it easier.

What is cross-browser testing?

Cross-browser testing is exactly what it says on the tin – making sure your website or web app works properly across different browsers. It’s about catching layout glitches, broken features, or weird behavior for users who aren’t on your team’s preferred setup.

You’ll usually check:

Different browsers (Chrome, Firefox, Safari, Edge, Opera)
Various browser versions (yes, some people are still stuck on older ones)
Different operating systems (Windows, macOS, Linux, iOS, Android)
Screen sizes and resolutions (desktop, tablet, mobile)

Browsers are one part of the bigger picture here. Our guide to compatibility testing covers the rest: operating systems, devices, networks and hardware.

Can I skip cross-browser testing?

Your users don't all use the same setup as your dev team. They're using different browsers, devices, and operating systems. If your checkout process works flawlessly in Chrome but breaks in Safari, you've just lost customers who happen to use iPhones.

Some cross-browser issues are sneaky – a button that’s nudged out of place, a dropdown that refuses to show up. And your users won’t tell you. They’ll just assume your site is broken and leave.

This happens because every browser has its own way of reading your code. Chrome, Safari, Firefox all speak slightly different languages. So even a perfectly crafted layout can look messy if a browser decides to do its own thing.

The goal isn't perfection across every possible combination (that's impossible and unnecessary). It's about ensuring your product works well enough on the configurations your actual users rely on.

Common cross-browser issues

The reason browsers behave differently comes down to how they're built. Each browser vendor makes decisions about which web standards to implement, when to implement them, and how strictly to follow the specs. Chrome might rush to support a new CSS feature while Safari takes a more cautious approach. Firefox might interpret a JavaScript API slightly differently than Edge. These aren't bugs, they're just differences in priorities and timelines.

For you as a tester or developer, this means the same code produces different results. A feature that works perfectly in your primary browser might be completely broken elsewhere. Here are some issues that appear regularly when you test across browsers:

CSS rendering differences – Flexbox, Grid, and newer CSS features work differently across browsers. Your perfectly aligned layout in Chrome could be a jumbled mess in older Safari versions.

JavaScript compatibility – Modern JavaScript features aren't universally supported. Arrow functions, async/await, and newer APIs work great in current browsers but break in older versions. Safari on iOS is particularly notorious for being behind on JavaScript features.

Form validation – HTML5 form validation displays differently across browsers. Required fields, email validation, and date pickers look and behave completely differently in Chrome vs. Safari vs. Firefox.

Font rendering – The same font can look noticeably different across browsers and operating systems. Text that's perfectly readable in Chrome on Windows might be too thin in Safari on Mac.

Video and media – Autoplay policies, codec support, and video controls vary wildly. A video that autoplays fine in Chrome might be blocked in Safari. Format support differs too.

Scrolling behavior – Scrolling acts differently across browsers. Elements that should stick to the top of the page might jump around on mobile Safari. Animations that trigger when you scroll might fire at different times. On iPhones, when you scroll past the top or bottom of a page, it keeps going and then bounces back – this rubber-band effect can cause visual glitches that you won't see in desktop browsers.

How to do cross-browser testing

Testing across browsers doesn’t need to be a big, process-driven ordeal. Here’s a straightforward way to start:

Start with data

Check your analytics to see what browsers, devices, and operating systems your users actually use. Don't waste time testing configurations that represent 0.1% of your traffic. Focus on the combinations that matter – usually the top 3-5 browsers and the major device types your audience uses.

As of 2025, Chrome dominates with around 65% of global browser market share, followed by Safari at roughly 20%, Edge at 5%, and Firefox at 3%. But these numbers shift dramatically by region and device type. Safari dominates on mobile in the US and UK. Chrome leads on desktop everywhere. Your analytics will show what matters for your specific audience.

Get a testing process going

Once you know which browsers to test, the process is straightforward. Open your site in the first browser – say, Chrome. Work through your critical flows: log in, fill out a form, complete a checkout, navigate the main features. Note anything that breaks, looks wrong, or feels slow. Take screenshots of visual issues. Document broken functionality.

Then repeat in your next browser – Safari, Firefox, Edge, whatever your list includes. Compare what you see. Does the form validation work the same way? Does the layout hold up? Are there JavaScript errors in the console?

You're looking for: broken functionality (things that don't work at all), layout shifts (elements in the wrong place), visual glitches (missing images, weird fonts, misaligned buttons), and performance issues (slow loading, janky animations). A simple checklist or spreadsheet works fine for tracking what you've tested and what broke where.

Test early and often

Don't wait until the end of development to discover your layout breaks on mobile Safari. Test on different browsers and devices throughout the development cycle. Catching cross-browser issues early is far cheaper than fixing them later.

Use real devices where possible

Browser dev tools and emulators are useful for quick checks, but they're not perfect substitutes for real hardware. If mobile users are significant, test on actual phones and tablets. Borrow devices from coworkers, set up a device lab, or use cloud-based testing services that provide access to real devices.

Cloud platforms like BrowserStack and LambdaTest give you access to real browsers and devices without needing to maintain your own lab. Useful if you need to test on devices you don't own, but nothing beats having actual hardware in front of you for critical testing.

Prioritize by impact

Not all cross-browser issues are equal. A broken checkout flow is critical. A slightly off font rendering is probably fine. Focus on functionality first, then visual consistency where it matters most.

Document what you're testing

Keep track of which browser/device/OS combinations you've tested. This doesn't need to be complicated – a spreadsheet works. So does duplicating your test plan and renaming it for each browser. Or use something like Testpad where you can create variations of your checklists in seconds and see everything at a glance.

What to actually test

Don't try to test everything. Focus on the features and flows that matter most to the user experience:

Critical user flows – Login, signup, checkout, payment processing. If these break, you lose customers immediately. Test them thoroughly across all your target browsers.

Forms – Input validation, dropdown menus, date pickers, file uploads, error messages. Forms behave wildly differently across browsers. Test every form on your site.

Navigation – Menus, dropdowns, mobile hamburger menus, search functionality. Make sure users can actually find what they're looking for on every browser.

Interactive elements – Buttons, modals, tooltips, accordions, carousels. Anything users click or interact with needs to work consistently.

Media – Images loading, video playback, audio controls. Check that your media displays and functions correctly everywhere.

Layout at different screen sizes – Your site on a 27-inch monitor vs. a phone vs. a tablet. Responsive design breaks in surprising ways across different browsers.

Security features – HTTPS connections, certificate handling, how browsers store passwords and sensitive data. Browsers handle security differently so what works securely in Chrome, for example, might create vulnerabilities in older browsers.

Third-party integrations – Payment processors, chat widgets, analytics, social media embeds. These often work in Chrome but fail elsewhere.

Start with your most critical paths and expand from there. A broken login is worse than a slightly misaligned footer.

Common cross-browser testing pitfalls

Even teams that know they need to test across browsers often make predictable mistakes. These aren't about lack of effort – they're about testing the wrong things or making incorrect assumptions about how users actually access your site. Here's what to avoid:

Testing only on the latest versions – many users don't update immediately (or at all). Test on older versions that still have significant user bases.

Assuming mobile = one experience – iOS Safari behaves differently than Chrome on Android. Test both, especially if mobile traffic is significant.

Ignoring actual network conditions – test on slower connections, not just your office's gigabit fiber. Performance issues often only show up on real-world networks.

Over-testing obscure configurations – yes, someone somewhere uses Internet Explorer 6, but unless that's actually in your analytics, don't spend time on it.

Is cross-browser testing manual or automated?

We always recommend you start with manual testing as it’s the fastest, most cost-effective way to spot issues. Open your site in different browsers and actually use it. Click through your critical paths, watch what breaks, what looks wrong and what feels off. This is how you catch the issues that matter like visual problems, layout shifts and usability quirks that no automated tool will flag.

Automation can help with the repetitive stuff – especially regression testing across multiple browsers after you make changes. Tools exist to run tests across different browser/OS combinations automatically. This is valuable for catching regressions quickly when you make changes to your codebase. Just remember, automation has its limits. It won't catch subtle visual issues or usability problems that only humans notice. Manual testing across key configurations remains essential, especially for new features or significant changes.

Keep it practical

Cross-browser testing doesn't require complex processes or expensive tools. Start simple: test on the browsers and devices your users actually use. Create a checklist (we happen to know a pretty good checklist-style testing tool…) of the critical paths through your website. Work through them on different browser/device combinations. Document what passed and what needs fixing.

The goal is ensuring your users can actually use your website or web app, regardless of their browser or device. Focus on that, skip the rest, and you'll be fine.

Want more practical advice sent straight to your inbox? Subscribe to get straightforward tips on all things testing.

How to start geolocation testing without boarding a plane

Stefan Butlin — Wed, 12 Nov 2025 00:00:00 +0000

Geolocation testing is one of those things that only feels obvious after it goes wrong. Many teams skip global software testing until a customer in another market complains that checkout is broken or content is blocked. By then, you’re scrambling instead of preventing the issue in the first place.

Most teams know they should test globally, but the sticking point is how. Flying testers around the world isn’t realistic, and hiring locals in every market gets expensive fast. Luckily, there’s a much simpler way to handle geolocation testing.

What is geolocation testing?

Geolocation testing means checking that your software behaves correctly when accessed from different locations. It's more than just checking if the translation is correct. It's about performance, compliance, payments, and user experience across regions For example: Do UK users see pounds instead of dollars? Are GDPR cookie consent banners appearing for European visitors? Can Australian customers select local shipping options?

Teams often skip it because it sounds complicated or costly. But ignoring it leaves a blind spot that can tank trust and revenue. The wake-up call usually comes when customers start reporting prices in the wrong currency, missing features, or blocked content. At that point, you’re in catch-up mode instead of fixing problems before release.

How to test in different locations (and why most attempts fall short)

When teams start wondering how to test in different locations, they tend to reach for a few obvious options. Each has its limits:

Flying somewhere: Works, but it’s expensive, slow, and useless for day-to-day bug verification. You can’t board a plane every sprint.
Hiring local testers: Great for cultural and usability insights, but clunky for fast technical checks. You need results in hours, not days.
VPNs: They route all your traffic through their servers, which can interfere with other software you’re running. They don’t integrate with automated testing tools, and you’re limited to one at a time.
Application hacks: Forcing fake locations in your code might “work,” but it doesn’t replicate the real user journey. Easy to accidentally leave in these code changes when you release, too.

Each option might help occasionally, but none scales into a reliable workflow for global app testing.

How to simulate geolocation with proxy servers

Proxy servers change the game for global app testing. They route your traffic through servers in different countries, making websites think you're browsing from there. But most proxies you'll find online are built for people who want to hide their identity or access blocked content. That's not what you need for testing.

For testing, you need proxies that:

Always connect from the exact location you choose
Don't get blocked by websites
Stay connected reliably during your tests
Let you test multiple locations at once

Regular privacy proxies often jump between different servers or use IP addresses that websites recognize as "fake." That makes your test results unreliable. You need a proxy service designed specifically for testing, not for watching Netflix from another country.

WonderProxy is designed for testing

WonderProxy is purpose-built for QA workflows. It's a proxy server network with servers in 98 countries that lets you route your web traffic through different locations reliably and fast. When you browse your site through their German server, your website thinks you're actually in Germany – you see German pricing, GDPR banners, local content, the works.

Why we think WonderProxy is a great help:

Browser extension for quick manual checks
Global coverage with locations in 98 countries
API integration with tools like Selenium and Cypress for automation
Built specifically for testers, not just consumers

How it works in practice: Connect through their proxy, browse your site normally, and see exactly what users in that location see. The key advantage is you're testing the real user experience, not a simulation or hack.

Starting your global software testing workflow

You don't need to test everything at once. Start small:

Pick key markets first: Focus on the countries that matter most to your business (pro-tip: think revenue not traffic!). Can people in the UK buy your product using pounds instead of dollars? Do customers in Canada see payment methods they actually use? Are visitors from Japan able to access all the content they should? Don't try to test every country on day one.

Use your existing test plans: You don't need to reinvent your testing approach. Take your existing test cases and run them from different locations using localization test tools. The scenarios are the same – you're just changing where you run them from.

Keep it checklist simple: Focus on location-dependent features like pricing, payment methods, content restrictions, and compliance requirements. These are where the biggest problems usually hide.

Track what you've covered: Keep simple progress tracking so you know which markets are verified and which need attention. A spreadsheet works to start, but you'll want something more organized as you scale up.

The pros and cons of global testing

Like most things in QA, geolocation testing comes with trade-offs. It’s not about deciding if it’s worth doing at all (it is), but about knowing what you’ll gain and what you’ll need to manage.

The pros are obvious: Catch problems before customers do, verify compliance requirements, understand real performance across markets, and avoid embarrassing currency or content errors.

The cons are real too: Adds complexity to your testing workflow, can slow down release cycles if overdone, and requires ongoing maintenance as you add markets and features.

The balance: Focus on markets that matter to your business, test the features that are location-dependent, and don't try to achieve perfect coverage. The goal isn't testing everything everywhere – it's catching the obvious problems before they become customer complaints.

Making geolocation testing part of your process

Global app testing doesn’t need to be overwhelming. Tools like WonderProxy cover the technical side of simulating location. Location is one more environment variable, like the browsers and networks covered in our guide to compatibility testing. What’s left is workflow – keeping your team organized about what’s tested where.

For small setups, a spreadsheet is fine. But as soon as you add more markets or more testers, you’ll need something smoother. That’s where tools like Testpad help. Testpad gives you lightweight checklists to manage who’s testing what, without all the features of traditional test case management getting in your way.

Ready to start testing globally? Request a free trial of WonderProxy and pair it with Testpad's 30-day free trial to keep your testing organized from day one.

What is test management?

Stefan Butlin — Thu, 06 Nov 2025 00:00:00 +0000

Test management is the process of organizing your software testing. It's how you approach testing: how you plan it, create tests, execute them, and report on results. Some teams use detailed test case management, others prefer exploratory testing. But test management is the umbrella concept that describes the process itself, regardless of which specific approach you take.

At a glance

Test management is how you plan, run, and report on software testing
If you test in any systematic way, you're already doing it
It spans three broad approaches: lightweight tracking, traditional test case management, and pragmatic checklists
Choose based on team size, release pace, and compliance requirements
The process should serve your team, not the other way around

The rest of this post covers the definition, the three approaches in practice, and how to choose and evolve the right one for your team.

If you're checking that your software works before releasing it in any systematic way, you're actually already doing test management. The question is less “what is test management?” and more “how can I do it better?”.

What is test management?

Test management is how you keep all your testing organized, from planning what needs testing to tracking progress and reporting results. It’s the system that keeps things running smoothly, makes sure nothing slips through the cracks, and helps everyone stay on the same page. The ISTQB Foundation syllabus devotes a whole chapter to managing test activities, covering test planning, monitoring and control, and completion reporting. That's the formal version; in practice it can be much lighter.

In practice, test management in software testing means having a plan for testing, executing that plan, and keeping track of what you find. Whether that's through detailed documentation or simple checklists, you're managing your testing effort to answer one key question: "Is this software ready to ship?"

What does the test management process involve?

The test management process boils down to four straightforward activities: planning, creating, executing and reporting.

That’s it. Everything else comes down to how formal or lightweight you want each step to be.

You’re probably already doing test management

If you’re testing software in any kind of systematic way, you’re already managing your testing.

Maybe you’ve got a list of things to check before each release. Maybe you work through user scenarios and jot down what breaks. Maybe you coordinate testing across your team. That’s all part of a test management process. The term sounds more intimidating than it needs to. Don’t let it convince you that you need fancy test management software or heavyweight processes to get started. You don’t.

Test management vs test case management

These terms often get mixed up, but they’re not the same thing. Test management is the big picture, i.e. organizing your entire testing effort. It covers how you plan, execute, and report on testing.

Test case management is one way to do that: the traditional, more structured, documentation-heavy approach with detailed steps and expected results. You can do test management without test case management. In fact, many teams prefer it that way. A simple checklist of what to test still counts, it just doesn’t have the depth of formal test cases.

Why does test management matter?

Test management matters because it gives you five things that make shipping software far less stressful: visibility, efficiency, communication, risk management, and evidence.

And you don’t need complicated systems to get there. Even basic tracking delivers these benefits.

What are the main approaches to test management?

There are three broad approaches to test management: lightweight tracking, traditional test case management, and pragmatic checklists. There's no one-size-fits-all process; the approach that works for a two-person startup won't suit a regulated medical device company, and that's fine. Understanding the options helps you pick what actually fits your context, and avoid adopting unnecessary complexity just because "that's how testing is done."

Starting somewhere

Initially, your approach is likely to be all about keeping things simple. You focus on tracking what’s being tested and reporting major issues without formal test cases or complex reporting. This approach works well with exploratory testing, letting skilled testers follow their intuition while still keeping everything visible.

How it works: Teams use simple lists, spreadsheets, or even post-it notes to record test activities. The focus is on visibility and accountability, not detailed documentation.

Structure level: Minimal. You track high-level testing progress and key findings, but don’t maintain detailed steps for every test.

Benefits:

Fast to set up and maintain
Supports rapid feedback cycles
Encourages flexible, judgment-led testing
Low overhead, minimal process
Keeps the team aligned without slowing down

Challenges:

Limited detailed metrics for reporting
Relies on good communication to avoid gaps

Best for: Small teams, startups, agile projects, or any situation where flexibility and speed matter.

Traditional test case management

Traditional test case management sits at the formal end of the spectrum. Every test is documented in detail: steps, expected results, preconditions, and test data. This approach is all about repeatability, traceability, and complete records.

How it works: Teams create detailed test cases covering every scenario. Each one outlines exactly what to do (“Click Submit”), what should happen (“Success message appears”), and which data to use (“Use TEST_USER_01”). The test management tool tracks execution history, requirement links, and generates detailed reports.

Structure level: Maximum. Everything is documented, versioned, and traceable. Tools for this approach often include test case versioning, requirement traceability matrices, approval workflows, and audit-ready reports.

Benefits:

Fully repeatable tests across testers
Detailed audit trails for compliance
Clear mapping between tests and requirements
Predictable effort estimates
Extensive metrics and reporting
Preserves knowledge across team changes

Challenges:

Time-consuming to create and maintain
Quickly goes out of date in fast-moving projects
Can discourage exploratory thinking
Heavy on time and resources
May give false confidence (documented ≠ effective)
Risk of testers following scripts blindly

Best for: Regulated industries (medical, finance, aerospace), large or distributed teams, and projects with stable requirements. If auditors will review your testing, traditional test management provides the paper trail they expect.

Pragmatic test management

Pragmatic approaches are lightweight and strike a balance between structure and flexibility. You keep enough organization to know what’s been tested, without getting bogged down by documentation. Instead of full test cases, you might use checklists or simple prompts that guide testers while leaving room for judgment.

How it works: Create hierarchical checklists grouped by feature or user journey. Each item might read “password reset copes with expired tokens” or “bulk operations handle 1000+ items.” Testers decide how to test it based on context.

Structure level: It’s sort of up to you. You’ll have clear test lists, pass/fail tracking, and basic reporting, but not the heavy admin of maintaining detailed step-by-step cases. Tools for this approach focus on speed and clarity over exhaustive documentation.

Benefits:

Clear visibility of test coverage
Easy for non-testers to understand and contribute
Quick to create and maintain
Flexible enough for exploration
Good balance of structure and adaptability
Simple progress tracking and reporting

Challenges:

Less detailed than traditional test cases
May not satisfy strict audit requirements
Requires some tester judgment
Can drift toward too much or too little structure if unmanaged

Best for: Most software teams, especially those where testing is a shared responsibility. When developers, product managers, and occasional testers all pitch in, pragmatic test management keeps things organized without overcomplicating the process.

Here's how the three approaches compare:

	Lightweight	Traditional	Pragmatic
Documentation overhead	Minimal	Heavy	Light
Speed to set up	Minutes	Weeks	Hours
Audit readiness	Low	High	Moderate
Room for exploration	High	Low	High
Best for	Small teams, fast feedback	Regulated industries, stable requirements	Most software teams

Choosing your test management approach

Think about these factors when deciding what fits your team:

Team size and setup: Small, close-knit teams can keep things lightweight. Large or remote teams may need more coordination.
Product stability: Rapidly changing products suit lighter, flexible approaches. Stable ones can benefit from detailed test cases.
Regulatory requirements: Compliance often demands traditional test management. Otherwise, you have more flexibility.
Team expertise: Skilled testers thrive with flexibility. Newer testers often need more guidance.
Release frequency: Daily deploys call for lighter processes. Quarterly releases can handle more documentation.
Risk tolerance: The higher the risk, the tighter the process.

Evolving your approach

Your test management setup doesn’t have to stay fixed. Many teams start with a lighter, hybrid approach, add structure as they grow, and simplify again once they know what actually adds value. The process should serve your team, not the other way around.

Begin with just enough structure to stay organized. Add process only when its absence causes real problems. If you’re spending more time managing tests than running them, you’ve probably gone too far.

Even the best test management software can’t replace good testing. Focus first on testing effectively, then use management to stay organized and communicate clearly.

What does a test manager do?

A test manager plans and coordinates testing, communicates status to stakeholders, and keeps the process improving over time. Plenty of teams don’t have someone officially called a “Test Manager”, but someone’s still doing the job. Developers, QA engineers, or product managers often take it on.

Planning: figuring out what needs testing and how to approach it.
Coordination: organizing testing across the team. Who’s testing what? Are we covering everything?
Communication: reporting progress to stakeholders. What’s broken? What’s ready to release?
Process improvement: making testing run smoother over time. What’s slowing you down? What’s working well?

The role is less about enforcing process and more about removing friction so testing actually happens.

Process vs tools

Test management is the activity, not the tool.

Your process is how you plan, track, and communicate testing. The tool simply supports that process. You can actually do perfectly good test management with a spreadsheet. If a simple spreadsheet keeps your team aligned, that’s valid test management software, just a lightweight version.

The problem comes when teams pick tools first and then bend their process to fit. It should be the other way around.

What is a test management tool?

A test management tool is any software that helps teams plan, track, and report on testing. It could be as simple as a shared spreadsheet or as complex as a full test case management platform. What matters is how well it supports the way your team already works.

Options include:

Spreadsheets: perfect for small teams and simple test tracking
Feature-rich platforms with all the bells and whistles: traditional test case management software for structured, regulated environments
Simple tools: lighter options which combine structure with flexibility

The right choice depends on your team, your context, and how much structure actually helps versus how much just adds admin.

Getting started with test management

If you’re new to organizing your testing, here’s how to start:

Keep it simple: basic planning and tracking beat perfect documentation. Start with a list of what needs testing and record pass/fail results.
Stay focused on value: the goal is answering “are we ready to ship?” Everything else is secondary.
Iterate: experiment, learn, and improve. Your first setup won’t be perfect, and that’s fine.
Don’t over-engineer it: the process shouldn’t take more time than the testing itself.
Get the team involved: testing works best when everyone contributes. Developers, PMs, and testers all bring useful perspectives.

Start where you are and build from there. You don’t need to get it right on day one.

Better software, not better documentation

Test management is just organized testing. You’re probably already keeping track of what needs checking, recording results, and communicating status. The key is making sure your process helps, not hinders.

Good test management makes releasing software less stressful. It gives you visibility, improves efficiency, and means you actually know when you’re ready to ship. Start simple, focus on what adds value, ignore the rest. And remember, the goal is better software, not better documentation.

Want more real-world testing tips and insights in your inbox? Sign up for our mailing list to stay in the loop on practical resources, product updates, and new ways teams are approaching test management.

Best alternatives to Testlio

Stefan Butlin — Mon, 22 Sep 2025 00:00:00 +0000

Testlio has built a name for itself in the world of crowdsourced testing, which is the practice of using networks of external testers to test your product, rather than doing it internally. Testlio’s model mixes vetted testers, hourly pay, and professional project management – meaning you get real-world feedback on your product without the headache of finding, paying, and chasing freelancers yourself.

That said, Testlio isn’t the only option out there. Maybe you need faster turnaround times than their managed model allows. Maybe their pricing doesn’t fit your budget. Or maybe you’d just rather have a bit more control over how testing is run, without paying for their white glove service.

Thankfully, there are plenty of Testlio alternatives worth a look. From platforms built for speed, to those that integrate tightly with your existing tools, to ones that focus more on usability than bug-hunting, the landscape is bigger than you might think.

What makes Testlio different?

Testlio position themselves as the "managed" option in crowdsourced testing – taking only 3% of applicants, paying testers by the hour rather than per bug, and providing dedicated project management.

Their model works well for teams that want to outsource not just the testing execution but also the admin around it like tester management, test planning, and results curation. You get consistency and professional oversight, but you also pay for their white-glove service.

Why look for a Testlio alternative?

Testlio's approach works for many teams, but you might want an alternative if you need:

Faster turnaround times – some platforms give results in hours rather than days
More direct control over tester selection, test design, or execution
Different pricing models like per-test rather than managed service contracts
Self-service options to run tests on your own schedule without account management overhead
Specialized testing types like security testing, accessibility, or specific industry needs
Larger tester pools with access to more diverse testing communities

The right Testlio alternative depends on your team size, testing frequency, budget, and how much management overhead you're willing to take on.

Top Testlio alternatives

1. Applause

Best for: Enterprise teams wanting comprehensive crowdtesting with professional oversight.

Applause is probably Testlio's closest competitor – they also offer managed crowdsourced testing with vetted testers and professional services. They've been in the game since 2007 and have a massive community of 300,000+ testers across 200+ countries.

What makes it different:

Larger tester community means better geographic and demographic coverage
Strong focus on enterprise clients and complex testing scenarios
Comprehensive platform covering everything from functional testing to AI training
Established integrations with enterprise development tools

When to choose Applause over Testlio: If you need broader global coverage, have complex enterprise requirements, or want a platform that's proven at massive scale. Their tester pool is significantly larger, which can be crucial for specialized testing scenarios.

Potential downsides: Likely more expensive than Testlio, and the larger scale might mean less personalized service for smaller teams.

2. Global App Testing

Best for: Teams wanting fast, flexible crowdsourced testing with strong platform integration.

Global App Testing focuses on speed and integration, offering results in 6-48 hours through their network of 90,000+ testers across 190+ countries. They're particularly strong for teams using Agile/DevOps workflows.

What makes it different:

Much faster turnaround times (hours vs days)
Strong API and tool integrations (Jira, TestRail, etc.)
Mix of exploratory testing and structured test cases
Video evidence and multiple tester confirmations for issues
More self-service options alongside managed services

When to choose Global App Testing over Testlio: If speed is critical, you want better tool integration, or you prefer more control over the testing process while still getting professional oversight.

Potential downsides: Some users report that test reports can occasionally feel generic and may require re-briefing to get deeper insights, and the premium pricing may not suit smaller teams or solo developers.

3. Rainforest QA

Best for: Teams wanting ultra-fast manual testing with minimal setup.

Rainforest QA takes a different approach – they offer 24/7 crowdsourced manual testing with an average 17-minute turnaround time. Their platform combines software tools with human testers for maximum speed.

What makes it different:

Fastest results in the market (average 17 minutes)
No long onboarding process – you can start testing immediately
Blend of manual and automated testing options
Pay-per-test model rather than managed service contracts
Built for teams that want to maintain control of their testing strategy

When to choose Rainforest over Testlio: If you need extremely fast feedback, want to maintain control over your testing strategy, or prefer per-test pricing over service contracts.

Potential downsides: Less hands-on account management, and the speed focus might not suit complex testing scenarios that need deep product understanding.

4. Test IO

Best for: Teams wanting overnight/weekend testing with minimal management overhead.

Test IO specializes in "follow-the-sun" testing – they can run tests during your off-hours and have results waiting when you start work. They offer both hands-off and managed service options.

What makes it different:

Strong focus on overnight and weekend testing
Fast onboarding (less than 24 hours)
Elite package offers 2-hour turnaround times
Team lead preview and bug filtering to reduce noise
Flexible engagement models from self-service to fully managed

When to choose Test IO over Testlio: If you want testing to happen while you sleep, need very fast setup, or want the option to scale from self-service to managed as your needs evolve.

Potential downsides: Smaller community than major players, and the hands-off approach might not suit teams needing close collaboration.

5. UserTesting

Best for: Teams prioritizing user experience and usability feedback over bug hunting.

UserTesting takes a different angle – they're video-first and focused on understanding user behavior rather than just finding bugs. Their testers provide spoken feedback while using your product.

What makes it different:

Video-first approach shows actual user reactions and thought processes
Focus on usability and user experience over functional testing
Real user insights for design and product decisions
Strong targeting options for specific demographics
Less about bug hunting, more about user understanding

When to choose UserTesting over Testlio: If your primary goal is understanding user behavior and improving UX rather than finding functional bugs.

Potential downsides: Not designed for comprehensive functional testing, and the video format requires more time to review results.

6. Crowdsprint

Best for: Teams wanting a white-label solution or end-to-end testing management.

Crowdsprint offers both crowdtesting services and white-label solutions for companies wanting to offer testing services themselves. They cover everything from usability to functional and regression testing.

What makes it different:

White-label option for creating your own testing service
Comprehensive testing types from concept to finish
Can serve as complete testing outsourcing solution
Mix of expert and non-technical testers for different perspectives

When to choose Crowdsprint over Testlio: If you want to build your own testing service, need comprehensive testing outsourcing, or want access to both expert and general user testers.

Potential downsides: Less established than major players, and the white-label focus might mean less specialized crowdtesting features.

7. Traditional test case management

Best for: Teams that want to handle testing themselves without outsourcing to crowds.

Sometimes the best alternative to crowdsourced testing isn't another crowd platform at all – it's just getting your internal testing properly organized. Traditional test case management tools help you build structured testing processes with your own team, which can actually work better than farming everything out.

What makes it different:

You control everything – who tests what, when, and how thoroughly
No per-test bills or ongoing service contracts to manage
Your team already knows the product inside and out
Plugs straight into whatever development tools you're already using

When to choose this over Testlio: If you've got people who can do the testing, want total control over the process, or need the kind of deep product knowledge that external testers just can't match.

Potential downsides: Sometimes your team can be too close to the product to spot obvious problems that outsiders would catch immediately.

For a lighter approach: Tools like Testpad give you the organization benefits without a complex setup – great for teams that want some structure but don't need all the features that come with a heavyweight tool. Plus, when you do need external input, you can easily invite guest testers to specific projects without the need for extra licenses.

Making the right choice

The best Testlio alternative really comes down to what your team needs. Don’t just pick the biggest name, pick the one that works for you:

Choose Applause if you're an enterprise team that needs massive scale, global coverage, and proven enterprise integration.
Choose Global App Testing if you need fast results with good tool integration and want some self-service flexibility.
Choose Rainforest QA if speed is everything and you want to maintain control over your testing strategy.
Choose Test IO if you want testing to happen during off-hours with minimal management overhead.
Choose UserTesting if understanding user behavior is more important than finding functional bugs.
Choose Crowdsprint if you need comprehensive testing outsourcing or want to build your own testing service.
Choose Testpad if you want to start with organized internal testing but keep the flexibility to add external testers without committing to a full crowdsourced platform.

What about just hiring freelancers directly?

Some teams think, "why not skip the platforms and just hire freelancers directly?" You could recruit testers yourself, hand out instructions, and manage everything in-house. But there's a big difference between using a structured approach like a test case management tool and trying to manage a bunch of independent freelancers.

When you hire freelancers directly, you're not just getting testers – you're becoming a project manager for a distributed team. That means:

Coordinating who tests what, when, and on which devices
Sorting through unfiltered reports and duplicate bugs
Handling payments, contracts, and quality control
Managing the inevitable miscommunications and no-shows

Some small teams try DIY for one-off projects, and it can work if you have the time, patience, and tolerance for chaos. But for anything bigger or ongoing, it quickly turns into a full-time job in itself.

Dedicated platforms make sure the right testers see the right work, results are organized, and payments are handled – without turning your team into full-time project managers for external testers. So while DIY crowdtesting is possible, it’s rarely worth it. If you want reliable, real-world feedback without the headache, using an established platform is almost always faster, easier, and less stressful.

Don’t forget your internal testing

All these crowdsourced platforms are great for getting diverse, real-world feedback on your product. But they're not designed to help you organize and manage your internal testing efforts.

That's where something like Testpad fits in. While crowdsourced testing gives you external validation, you still need a simple way to manage your ongoing manual testing, regression checks, and internal QA processes.

Testpad's checklist-style approach lets you quickly organize test ideas, track results, and build up your testing knowledge over time – without the heaviness of traditional test case management tools. It's the perfect complement to external crowdsourced testing: use the crowd for broad validation and fresh perspectives, use Testpad to keep your internal testing organized and efficient.

Want more insights on testing strategies and tools? Sign up to our newsletter for practical testing advice that works in the real world. We’ll even throw in a free trial of Testpad – no card details needed.

What is a test strategy?

Stefan Butlin — Tue, 16 Sep 2025 00:00:00 +0000

A test strategy is your approach to learning enough about your software to ship with confidence. It's the high-level decisions about how you'll discover what's working, what's broken, and what needs attention before release. Unlike a test plan, which lists the exact tests you'll run for a release, the strategy is the big-picture approach that guides those plans.

At a glance

A test strategy is your overall approach to testing: what types of testing to run, who does it, and how you balance manual and automated
A test plan lists what you'll actually test in a specific release; the strategy guides those plans
Four decisions do most of the work: types of testing, the manual/automated balance, where to focus limited time, and who does the testing
Manual and exploratory testing belong in the strategy alongside automation, not as an afterthought
The best strategy is the one your team actually uses, not the most impressive document

The rest of this post covers the strategy-vs-plan difference, the decisions worth making, an example strategy, and how to put yours into practice.

Think of it as your game plan for uncovering the truth about your software's quality. It’s about making practical decisions: what to test, how to test, and how much testing is “enough” before you hit deploy.

The goal is straightforward: find the most effective way to figure out if your software works well enough to release. Everything else – the specific tests, tools, and tactics – flows from those strategic choices.

Why is a test strategy important?

A clear test strategy is like a coach’s playbook: it makes sure your team uses their time on the field wisely, avoids leaving gaps in defense, and keeps the ball from slipping past into the wrong hands.

But search for “test strategy in software testing” and you’ll be buried under sample documents, strategy templates, and guides full of sections on risk analysis, entry criteria, exit criteria and dozens of other formal elements.

If you’re asking “what is a test strategy?” you probably don’t need all that complexity. You need to make some practical decisions about how to spend your limited testing time effectively. Most teams freeze up trying to design the “perfect” strategy document. But the best strategy isn’t the one that looks impressive – it’s the one you actually use.

Test strategy vs test plan: what's the difference?

The terms get used inconsistently, so let’s clear it up. The ISTQB glossary defines a test strategy as "a description of how to perform testing to reach test objectives under given circumstances" – deliberately general, which is exactly the point: strategy is about the approach, not the specifics.

Test strategy is the big picture. Your overall philosophy and approach: how you’re going to tackle testing across your project or product.

Test plan is the specifics. The actual list of tests you’ll run for a release. (Though confusingly, some teams use “test plan” to mean the whole strategy – no wonder it gets messy.) Haven’t written a test plan before? Read our blog post on how to write your first Test Plan.

Concrete example: Test strategy = focus testing on critical user journeys. Test plan = in this release, test checkout, account creation, and refunds.

	Test strategy	Test plan
Scope	The whole product or project	One release or sprint
Answers	"How do we approach testing?"	"What exactly will we test this time?"
Changes	Rarely – when the product, team, or risks change	Every release
Example	Focus testing on critical user journeys	Test checkout, account creation, and refunds

What should a test strategy include?

A test strategy comes down to a few key decisions:

What types of testing will you do? Manual testing to explore user experiences and spot unexpected issues. Automated tests to catch problems early. Regression testing to make sure fixed bugs stay fixed.

How will you balance manual and automated approaches? Automation is great for repetitive checks, but don’t assume “automation-first.” Your strategy should plan for manual testing as a key tactic – it brings human intuition, creativity, and adaptability.

Where will you focus your limited resources? You can't test everything, so decide what matters most based on user impact, business risk, and likelihood of problems.

Who will actually do the testing? Ideally, people who didn't write the code. They test according to how users might actually use the system rather than how developers imagined it.

Getting a grip on these components makes sure your test strategy is actionable and helps your team focus on key areas rather than trying to cover everything.

Why your strategy needs manual testing

A lot of automation-first strategies miss the fact that human testers catch things that automated checks can't. Humans notice when something feels clunky, they can react to unexpected behavior, and explore paths that weren't planned.

Manual testing, especially exploratory testing, belongs in any strategy because it lets testers:

follow their nose when something feels off
spot usability issues real users would struggle with
think creatively about edge cases
give feedback on whether features really solve user problems

This doesn't mean avoiding automation. It means planning for manual testing as an essential part of your overall approach rather than an afterthought to automation. Often, it’s the fastest way to learn – and it saves you from spending hours maintaining automated checks that only catch the obvious problems.

How to implement your test strategy

There’s no point wasting weeks designing the “perfect” test strategy document. When it comes to software testing, a test strategy that stays practical and flexible enough to evolve with your product should be fairly easy to implement. Just remember to:

Start simple – decide on your mix of testing tactics. Which areas need manual exploratory testing, and which can be handled with automated checks? Focus on high-impact areas first rather than trying to cover everything at once.
Test in real life – run your strategy on actual features and workflows. See how your approach performs in practice: are you catching the important issues? Are testers able to explore effectively, and are automated checks providing reliable coverage?
Iterate and adapt – use what you learn to refine your strategy. Maybe some manual testing is revealing more issues than expected, or certain automated checks aren’t worth maintaining. Adjust the focus, update your tactics, and evolve your strategy as your product and team grow.
Document enough to guide – keep a lightweight record of your decisions and rationale. A full “perfect” test strategy document isn’t necessary; just enough so everyone knows the approach and can pick up where someone else left off.
Communicate and review regularly – make sure your team understands the strategy and its priorities. Periodically review it to ensure it still aligns with product changes, timelines, and risks.

Think of your strategy as a living thing rather than a dusty PDF. It’s there to guide testing, not slow it down.

Your strategy should match your reality

Copy-paste strategies from the internet rarely work. Every team has different constraints and risks. Think about:

Team size and skills – a solo dev won’t test like a 20-person QA team.
Timeline and resources – tight deadlines call for different trade-offs than long schedules.
Product complexity and risk – a simple web app vs. medical device software.
User expectations – internal tools vs. consumer apps demand different levels of polish.

The “best” strategy for you might look nothing like the big frameworks you find online, and that’s exactly right.

What is an example of a test strategy?

A test strategy can fit in a paragraph. Here's a lean one for a small SaaS team:

Developers cover the code with automated unit tests and a small set of end-to-end checks that run on every build. New features get a session of manual exploratory testing before release, guided by a short charter of what to investigate. Before each deploy, one person runs a regression checklist of the critical user journeys: signup, billing, and the core workflow. The product manager does a final pass over anything customer-facing.

Four sentences, and it answers everything that matters: what types of testing (automated checks, exploratory sessions, a regression checklist), who does what (developers, a tester, the PM), and where the limited time goes (new features and critical journeys). A strategy doesn't need to be longer than this to be worth writing down.

Structure your strategy with the right tool

A fit-for-purpose, practical software test strategy benefits from a tool to match. If your strategy is flexible, manual-friendly, and focused on real learning, you don’t want a system that bogs you down with unnecessary fields, forms, or processes.

Testpad is a checklist-style, manual test management tool that gives you just enough structure to stay organized, whether you’re doing exploratory testing, following structured steps, or a mix of both. It keeps your team on track without forcing steps or processes your strategy doesn’t need.

It’s a bit like a test strategy template that adapts to the way your team works. It’s easy to pick up, easy to adapt, and there to help you implement your strategy. Everything in Testpad is there to support the decisions you’ve made in your strategy, so your testing is effective, efficient, and aligned with your team’s goals.

Why not trial Testpad free for 30 days and see how it works in practice? No card needed.

Manual testing is still important – here’s why AI won’t replace you

Stefan Butlin — Tue, 09 Sep 2025 00:00:00 +0000

The software industry loves to predict the death of testing as we know it. First it was manual vs automation – with debates about whether automation had made manual testing obsolete (it hasn’t). Now the spotlight’s on AI, with the same question asked again: will it replace manual testing?

Asking if AI will replace manual testing misses the point. Good testing isn’t a battle between humans and machines, and never has been. Humans bring context, adaptability, and judgment – the stuff that makes software usable. AI doesn’t replace that, it backs it up and makes it faster.

Timing matters here, though: this is the picture in June 2026, and it’s moving fast. Anything written about AI and testing, this post included, has a shelf life measured in months rather than years.

Where things stand in June 2026

Both halves of the story you’ve been hearing are true, which is why the debate sounds so muddled. The layoffs are real: Atlassian and Block cut thousands of roles in early 2026, in the name of AI. The growth is real too: the US Bureau of Labor Statistics still projects 15% growth for developer and QA roles through 2034. The jobs going and the jobs growing are different jobs. What’s being automated away is the execution of scripted checks; what’s expanding is the work that needs judgment.

A big part of the reason: AI is now writing a serious share of new code, and that code needs more checking, not less. GitClear’s analysis of 211 million changed lines of code found copy-pasted code rising sharply and refactoring collapsing as AI assistants spread. Stack Overflow’s 2025 developer survey found 84% of developers using or planning to use AI tools while trust in the output hit an all-time low – the most-cited frustration being “AI solutions that are almost right, but not quite”.

Almost right but not quite is exactly the kind of wrong a script accepts and a person catches. AI-generated tests don’t close that gap by themselves, either: tests generated from the code tend to share the code’s blind spots, and developers reviewing them keep finding tests that could never fail in the first place. More code, written faster, with subtler mistakes leaves more for human judgment to do, not less.

Some of what needs testing now is AI itself. Features built on language models fail differently from traditional software: the output stays fluent and confident while being wrong. In Applause’s April 2026 survey, 44% of organizations had switched off a live AI feature in the previous year because the costs outweighed the value. Working out whether an AI feature is wrong takes a person who knows what right looks like.

And when something ships broken, responsibility doesn’t transfer to the model. James Bach puts it bluntly: “AI cannot behave responsibly. Only natural persons can.” A tool can inform a release decision, but someone has to own it.

The advantages of manual testing that AI can't yet match

AI is great at processing data and checking predefined rules. But software quality isn’t just about “does it work according to spec?” – it’s about whether it works for people, in unpredictable real life. Here’s where human testers bring something AI can’t match:

Real-world context

AI can confirm whether a banking app accepts a payment. But a human tester notices that the same app becomes frustratingly unusable when you’re stressed, rushing to check your balance, or making an urgent transfer on the move. Manual testing doesn’t just validate functionality; it asks whether the software works for humans under real conditions.

Creative rule-breaking

AI follows patterns it’s been trained on. A human tester deliberately breaks those patterns. They’ll try illogical user paths, mash buttons out of sequence, or chain actions no one expected. That bizarre click-refresh-cancel sequence that crashes the app? An AI wouldn’t try it but a human would.

Adaptive investigation

AI can adapt within the rules it knows. Humans can throw the rulebook out entirely. When something feels off, a tester pivots, digs deeper, or connects dots that don’t obviously belong together. If a payment screen loads slowly, a human might think: what if I open two tabs, switch networks mid-transaction, or log out halfway? That leap is instinct, not programming.

Spotting the unknown unknowns

AI is limited to what it’s seen before. Humans spot things no one thought to test like a hidden interaction between features, a rare edge case, or an odd behavior that “shouldn’t” matter but does. A password reset email might land in junk because a spam filter misreads the subject line. That’s not a neat, predictable failure AI could be trained to expect. But a human tester thinks: “What if the email never even arrives?” They try it, see the problem, and make the connection.

How AI can make manual testing stronger

AI isn’t here to replace manual testing – it’s here to take the boring stuff off your plate so you can focus on the interesting bits. Think of it as the assistant that crunches the data while you do the detective work.

Here’s where it actually helps:

Planning faster – scanning requirements, suggesting test ideas, and pointing out gaps you might have missed.
Spotting patterns – trends, risks, and repeat failures across piles of results that would take you hours to sift through.
Generating data – realistic datasets, edge cases, and weird variations at the click of a button.
Handling reports – capturing results and spitting out the paperwork without slowing you down.

AI takes care of the repetitive, data-heavy work. That leaves testers free to do what only humans can: make judgment calls, chase down hunches, and explore software in ways no algorithm would think to try.

7 reasons manual testing is still relevant

Even with AI handling more testing tasks, human testers are still essential. AI can suggest tests, generate data, and spot patterns, but it can’t replace judgment, intuition, or creativity. Here’s why manual testing remains crucial:

User experience needs a human perspective
AI can confirm functionality, but usability is subjective. Humans notice flow, clarity, and whether something “feels right.” Are error messages helpful? Is the journey intuitive? Only a human tester can answer these questions.
Real-world conditions are unpredictable
AI tests in controlled environments. Real users don’t. They multitask, get interrupted, and deal with patchy networks. Manual testers observe how software performs under true conditions.
Mobile complexity demands adaptability
Devices, screen sizes, OS versions, network conditions, and gestures create endless combinations. Human testers adapt on the fly, spotting issues AI might miss without extensive configuration.
Early-stage projects change fast
Features and designs evolve quickly. Manual testing flexes immediately, while AI models may require retraining, and automated scripts need updates – introducing delays.
Reproducing customer issues requires intuition
When bugs appear, human testers investigate, recreate conditions, and follow the trail to understand the real problem. This requires judgment, instincts, and connecting dots in ways AI cannot.
Some quality checks are emotional
Not all quality is objective. Does the interface feel trustworthy? Is the tone right? Will users get frustrated? These subjective judgments rely on human perception.
The most important bugs aren’t in the plan
Critical issues often lurk outside defined test cases. Humans explore, follow hunches, and probe suspicious behavior – finding problems that AI wouldn’t think to test.

The future of manual testing with AI

Manual testing isn’t disappearing – it’s shifting. Teams that thrive will be the ones that combine human insight with AI assistance.

Where human testers shine:

Exploratory testing
Usability and accessibility
Creative scenario testing
Real-world condition simulation
Subjective quality assessment

Where AI adds value:

Test planning and coverage analysis
Pattern recognition in results
Test data preparation
Documentation and reporting
Risk assessment and prioritization

AI handles the systematic, data-intensive work that humans find tedious, while humans focus on the creative, contextual work that AI can't yet match.

If you’re ready to use AI in a way that makes your testing easier, have a read of our blog on how you can use ChatGPT to write better test scripts.

Making manual testing work smarter

Manual testing works best when you’ve got the right mix of coverage and human adaptability. That’s where Testpad comes in – a tool that keeps things simple, flexible, and fast. Just enough structure to keep track, without the drag of heavy process.

Whether you’re digging into new features, running exploratory sessions, or lining up regression checks with the team, Testpad makes it easy to capture results and keep everyone on the same page – while leaving the thinking to humans.

Manual testing isn’t resistance to change; it’s the part of the job that was never mechanical in the first place. AI can speed things up, but human testers make it matter.

See how that balance works in practice – try Testpad free for 30 days.

Types of exploratory testing and how to structure it

Stefan Butlin — Mon, 01 Sep 2025 00:00:00 +0000

You’ll often come across three main “types” of exploratory testing – freestyle, scenario-based, and strategy-based. But these “types” aren’t really types of exploratory testing at all – they are just different ways of organizing your exploratory testing sessions, each with its own balance of freedom and focus, and none of them mutually exclusive.

At a glance

The common "types" of exploratory testing are really ways of structuring a session: freestyle, scenario-based, session-based (SBTM), strategy-based, pair testing, bug hunts, and ad hoc
Each structure trades freedom against trackability: freestyle gives the most freedom, session-based gives the most accountability
Types are how you organize a session; techniques (boundary value analysis, error guessing) are what you do inside one
Real sessions are hybrids: a scenario-based bug hunt in a 30-minute timebox is normal, not a mistake
A lightweight charter plus simple tracking makes any of these structures reportable without killing exploration

The rest of this post covers each structure in turn: what it is, when it works well, and how to combine them.

What is exploratory testing?

Exploratory testing in software isn’t the chaotic “click around until you find something” that some blogs make it sound like. Done well, it’s a disciplined approach: start from a lightweight plan or charter, then combine human intuition with adaptable structure to uncover issues that scripted, step-by-step test cases miss. The ISTQB Foundation syllabus describes it as testing where tests are simultaneously designed, executed, and evaluated while the tester learns about the product.

Exploratory testing means making decisions about what to try next based on what you just observed. It’s testing with your brain switched on – finding the unknown unknowns. Instead of following a fixed list of steps, you’re investigating, reacting, and probing areas that look promising or risky.

That’s why exploratory testing is so good at surfacing bugs that rigid test cases miss. It turns testing into a conversation between the tester and the product: try something, see what happens, let that guide your next move. While automated testing has its place, exploratory testing uses human creativity and intuition in ways that pre-written test cases simply cannot.

Types vs techniques

Before we get into the different types of exploratory testing, let’s clear up an important distinction that tends to trip people up:

Structuring approaches (what most people mean by "types") are about how you organize a session – i.e. freestyle, scenario-based, session-based etc.
Techniques are the specific testing methods you use while exploring – like boundary testing, error guessing, or equivalence partitioning.

The two often overlap in practice, but they're not the same thing. Keeping that clear makes it easier to design your sessions in a way that's purposeful rather than ad hoc.

What are the different types of exploratory testing?

Exploratory testing doesn’t come in fixed “types” so much as different ways you can organize a session. Each approach gives you a slightly different balance of freedom and structure, and in practice you’ll often mix and match them. Here’s a summary, followed by notes on when each works best and what to watch out for.

Structure	Freedom	When to use it	Watch out for
Freestyle	Highest	Early exploration, new features, short windows	Hard to track or report coverage
Scenario-based	High	Customer-facing features, onboarding flows	Can miss paths real users don't take
Session-based (SBTM)	Medium	When you need accountability and progress reports	Reporting depends on note quality
Strategy-based	Medium	Specific risks: security, performance, usability	Narrow lens can miss other issues
Pair testing	Varies	Complex features, onboarding new testers	Uses two people's time
Bug hunts	Medium	Pre-release checks, team exercises	Breadth over depth
Ad hoc	Highest	Anytime, outside formal sessions	No coverage guarantees at all

Freestyle exploratory testing

Completely unstructured, just pick up the product and start exploring.

When it works well: Early product exploration, when you’re brand new to a feature, or when you only have a short window to get a feel for quality.
The challenges: Hard to track coverage or report systematically. Great for quick insights, not so great when someone asks “how much did you test?”

Scenario-based exploratory testing

You anchor exploration to realistic user workflows. Instead of random clicking, you follow paths a real user might take, like signing up and making a first purchase.

When it works well: Customer-facing features, onboarding flows, or any situation where user behavior matters. This approach works particularly well alongside user acceptance testing, where stakeholders are directly involved.
The benefits: More realistic, easier to explain, and ensures testing aligns with actual user priorities.

Session-based exploratory testing (SBTM)

Exploration within a defined timebox, guided by a charter (“explore password reset flows for 60 minutes”). You take notes as you go. The approach was formalized by James and Jonathan Bach, whose original Session-Based Test Management paper is still the canonical description.

When it works well: When you need both freedom and accountability, or when stakeholders want to see progress.
The trade-off: You get structure, but reporting quality depends heavily on note-taking. Sometimes you end up with verbose logs that aren’t easy to scan.

Strategy-based exploratory testing

Exploration with a lens – for example, focusing specifically on security, performance, usability, or integration points.

When it works well: When you need to cover specific risks or want to make use of specialist skills within your team.
The value: Makes sure you don’t just cover happy paths and keeps attention on important non-functional areas.

Pair exploratory testing

Two testers (or a tester and a developer) explore together – one drives, one observes and suggests.

When it works well: Complex features, onboarding new testers, or when you want to generate richer test ideas.
The trade-off: Uses more time and people, but tends to uncover more and spark creative thinking.

Bug hunts

Focused, time-boxed exploration aimed at surfacing as many issues as possible, often run as a team exercise.

When it works well: Before big releases, as a quick quality check, or as a collaborative team-building activity.
The approach: Can layer on other structures – e.g. scenario-based bug hunts or timed sessions.

Ad hoc testing

Opportunistic exploration outside of formal sessions, like quickly checking a fix or noticing something odd while working.

When it happens: Anytime throughout development.
The value: Keeps a constant pulse on quality and often catches issues before they grow.

The overlap reality

These “types” aren’t neat, separate boxes. Real sessions are hybrids. You might run a scenario-based bug hunt, time-boxed into 30 minutes, with pairs of testers. Or do strategy-based exploration focused on usability while also capturing ideas with a tool.

That’s how it’s supposed to work. Exploratory testing is adaptable, and the structure should fit the context rather than the other way around.

Making exploratory testing work in practice

You want enough structure to make exploration trackable, while keeping the flexibility that makes it worth doing. Too little structure, and you can’t answer “what did we cover?” Too much, and you lose the creativity that makes exploratory testing valuable.

Practical ways to strike that balance:

Start each session from a lightweight charter or a short list of test prompts – cues that guide exploration without dictating every step.
Track coverage with simple pass/fail marks or notes.
Capture insights that inform future testing, not just evidence of what passed.
Evolve your test plans as the product grows – add new checks when you find bugs, refine prompts as you learn.

For teams just starting with structured testing approaches, our guide on getting started with manual testing gives you a foundation that works well with exploratory methods.

Exploratory testing works best when it’s treated as a discipline: structured enough to report on, but free enough to let testers think.

Bringing together the right types of exploratory testing

Once you’ve picked a structure, our guide to exploratory testing techniques covers what to actually do inside it.

Rather than worrying about which “type” is the right one, focus on the setup that fits your goals, team, and constraints. New features might call for scenario-based sessions, risky areas might demand strategy-driven exploration, and early prototypes might benefit from freestyle poking around. Most teams use a blend.

What matters most is that your structure helps you learn quickly and gives your team useful answers about quality. And if you’re looking for a tool to support that balance, a checklist-style test manager like Testpad can make it easier – flexible test prompts for exploration and lightweight tracking for coverage.

When you’re choosing testing tools, look for ones that support this balance. A checklist-style approach can give you lightweight structure without the overhead of rigid test cases. That’s the philosophy behind Testpad – designed to make exploratory testing easier to organize, share, and track, whether it’s your core team or guest testers jumping in for extra coverage.

If you’d like to see what that looks like in practice, you can try Testpad free for 30 days – no credit card needed.

Exploratory testing techniques: A practical guide

Stefan Butlin — Fri, 29 Aug 2025 00:00:00 +0000

Exploratory testing techniques are thinking tools: boundary value analysis, equivalence partitioning, error guessing, state transition testing, use case testing, mind mapping, and heuristics like SFDPOT. Each gives you a different lens for finding problems. The skill isn’t memorizing them – it’s knowing when to switch between them mid-session.

At a glance

Exploratory testing techniques are lenses for finding different kinds of problems, not steps to follow
Boundary value analysis and error guessing are the easiest starting points: test the edges, and trust what experience tells you looks fragile
Equivalence partitioning saves time by testing one example from each group of similar inputs
Heuristics like SFDPOT (Structure, Function, Data, Platform, Operations, Time) work as mental checklists so nothing important gets missed
The best sessions mix techniques as one discovery leads to the next

The rest of this post covers each technique in turn: what it finds, how to apply it mid-session, and how to combine them without losing the freedom that makes exploratory testing work.

What are the main exploratory testing techniques?

The main techniques are boundary value analysis, equivalence partitioning, error guessing, mind mapping, state transition testing, use case testing, and heuristic-based approaches like SFDPOT. Several of these are formal test design techniques – the ISTQB Foundation syllabus covers boundary value analysis and equivalence partitioning as core black-box techniques, and notes that exploratory testing can incorporate them – but they work especially well applied on the fly, adjusting as you see how the software actually behaves.

These techniques apply inside whichever structure you’ve chosen for the session – if you haven’t picked one yet, start with the types of exploratory testing. Here’s a summary:

Technique	What it finds	When to reach for it
Boundary value analysis	Off-by-one errors and validation failures at the edges	Any input field or limit
Equivalence partitioning	Differences between groups that should behave the same	Lots of similar inputs, limited time
Error guessing	Bugs where they've happened before	You know the system's history
Mind mapping	Gaps in coverage and missed connections	Planning and reviewing a session
State transition testing	Broken or unexpected state changes	Workflows with statuses and approvals
Use case testing	Integration and usability problems in real workflows	Customer-facing features
Heuristic-based (SFDPOT)	Whole categories you'd otherwise forget	Structuring a broad session

Boundary value analysis

Test the limits of what your software accepts (i.e. push it to the edge). Instead of only trying normal values, focus on the edges where problems are most likely.

How to use it in exploratory testing:

When you see an input field, immediately test its boundaries.
If “age” accepts “25,” try -1, 0, 1, and 100, 150, 999.
Watch for off-by-one errors, buffer overflows, and validation failures.
Follow interesting behavior – if 999 causes an error, try 998, 1000, 9999.

Example: Testing a file upload, you see it accepts a 5MB file. You test 4.9MB, 5MB, and 5.1MB. The 5.1MB file uploads but breaks the preview – an issue you wouldn’t find testing only normal sizes.

Equivalence partitioning

Group similar test conditions to focus on areas that might behave differently instead of repeating the same checks.

How to use it in exploratory testing:

Identify groups of inputs that should behave the same.
Test one example from each group thoroughly, then spot-check others.
Use saved time to explore more scenarios.
If Safari behaves like Chrome, test Chrome in depth and quickly check Safari.

Example: Testing an e-commerce discount system, instead of checking ages 66, 67, 68 for senior discounts, test one from each bracket: 30 (no discount), 65 (boundary), 70 (senior), 90 (very senior). This finds a failure for ages above 99.

Error guessing

Use your experience and trust your gut on areas where problems usually happen. This technique gets stronger as you learn the system.

How to use it in exploratory testing:

Focus on areas that caused trouble before.
Look for common failure patterns (file uploads, forms, payments).
Test scenarios developers might not consider.
Follow your instincts when something seems off.

Example: Testing a new feature, you notice the save button sometimes lags. Based on experience, you test rapid clicks, concurrent saves, and network interruptions. You find a race condition that only happens in specific timing conditions.

Mind mapping for broader coverage

Start with main features and branch out to related areas, making sure you don’t miss important tests while staying flexible.

How to use it in exploratory testing:

Begin with core features at the center.
Branch out to edge cases, integrations, and user scenarios.
Use it for planning, not strict execution – follow discoveries.
Update the map as you learn more about the system.

Example: Mind mapping a login system reveals connections you hadn’t considered – password reset links to email delivery, which links to spam filters, showing the need to test different email providers.

State transition testing

Look at how features behave as they move between states, focusing on transitions that typical tests might miss.

How to use it in exploratory testing:

Map possible states (draft, submitted, approved, rejected).
Test transitions, especially unusual ones.
See if you can get the system into unexpected states.
Check what happens if transitions are interrupted.

Real example: Testing document approval, you discover editing a document in multiple browser tabs while it’s “being reviewed” corrupts the approval process.

Use case testing

Follow realistic user workflows rather than isolated features to find integration and usability issues.

How to use it in exploratory testing:

Think like a real user, not just a tester.
Follow full workflows from start to finish.
Notice friction points and confusing interactions.
Test scenarios users actually face, not just happy paths.

Example: Testing a new customer’s first purchase, you find the shopping cart doesn’t save items if a user creates an account mid-checkout – a critical issue only found with realistic testing.

Heuristic-based testing

Use frameworks to make sure you cover everything while staying flexible. Heuristics are structured ways to guide testing without a rigid sequence of steps. Basically, it’s about using a set of prompts or mental checklists to make sure you don’t miss anything important, without having to write out every single step.

Common heuristic frameworks:

SFDPOT (Structure, Function, Data, Platform, Operations, Time), a product-elements checklist from James Bach's Heuristic Test Strategy Model
User experience heuristics: consistency, feedback, error prevention

How to use it in exploratory testing:

Pick a heuristic that fits your testing.
Use it as a mental checklist, not a strict sequence.
Let each heuristic suggest areas to explore.
Combine heuristics as new discoveries lead you to more tests.

Example: Using SFDPOT, the “Time” part prompts testing during daylight saving changes. You find scheduled reports fail when clocks fall back because the system tries to generate the same report twice.

Mixing techniques effectively

These techniques pay off most when you mix them as you go. You might start with boundary value analysis on a form field, spot an unusual error message that triggers error guessing, then follow that lead into use case testing to see how it affects real user workflows.

What this looks like in practice: Testing a search feature, you try boundary value analysis (empty searches, very long terms) and find searches over 256 characters fail silently. Error guessing suggests a buffer limit, so you check related features and see the same problem in user comments. Use case testing shows that users copying long text from elsewhere often hit this limit, making it a serious usability issue.

Balance freedom with just enough structure

Techniques give you flexibility, but some structure keeps your testing manageable and traceable. The trick is balancing organization with adaptability – enough to track progress and report results without losing exploratory freedom.

Testpad's pragmatic approach handles this with simple test prompts instead of step-by-step test cases. Prompts like "password rules reject weak passwords" or "account locks after repeated failed sign-ins" become mini-explorations where you apply whichever techniques make sense. This approach:

Lets you capture discoveries without breaking your flow
Keeps progress visible to stakeholders
Turns insights into future prompts
Uses techniques to guide exploration rather than constrain it

Getting started with exploratory testing techniques

Exploratory testing can feel overwhelming at first, even more so with all the jargon around it. But you don’t need to overthink it – the key is to just start small and build from there.

Start simple: Pick one or two techniques that resonate with you and practice applying them consistently. Boundary value analysis and error guessing are great starting points because they're quick to learn and immediately useful.

Build technique awareness: As you gain experience, consciously expand your toolkit. When you're stuck or feeling like you're missing something, try a different technique to shift your perspective.

Trust your judgment: These techniques guide investigation, but your experience and intuition determine which ones to apply when. The goal is systematic thinking, not mechanical execution.

Capture what works: Note which techniques reveal the most valuable issues in your context. Different applications and teams will find different approaches most effective.

A tool to support exploratory testing

Exploratory testing techniques give you a flexible, systematic way to test software without being tied to rigid test cases. They’re thinking tools that help you ask sharper questions, follow promising paths, and uncover issues that scripted, step-by-step test cases often miss.

The best results come when you have these techniques at your fingertips and the judgment to apply them fluidly as your investigation unfolds. Paired with just enough structure to stay organized, they make your testing more effective, insightful, and manageable.

This is where tools matter. A lightweight checklist-style tool like Testpad gives you just enough structure – test prompts instead of step-by-step test cases – so you can capture discoveries, track progress, and keep stakeholders in the loop without slowing yourself down. If you want to try it for yourself, there’s a free 30-day trial waiting – no card needed.

A guide to manual testing vs automated testing

Stefan Butlin — Tue, 12 Aug 2025 00:00:00 +0000

When it comes to manual vs. automated testing, the real challenge is understanding which approach suits different types of testing, and when to apply each for the best results. Too many teams get this wrong by treating manual testing like training wheels – something you do until you "graduate" to full automation.

That's backwards thinking, and it's why so many testing strategies fall flat despite heavy investment in automation tools and processes.

At a glance

Manual vs automated isn't a contest between two camps – most teams need both
Automated testing wins for stable, high-volume, repeated checks: unit, regression, load, integration
Manual testing wins for exploration, usability, edge cases, and user acceptance
Automation has real costs: setup, flaky-test maintenance, and the trust that drains away when a suite goes red
Build regression coverage manually first, then promote specific tests to automation when the math works
Testpad models manual testing as a checklist of plain-text prompts, not rigid step-by-step scripts

The automation-first trap

The industry has convinced teams that "proper" testing means automating everything. The more automated your tests, the more sophisticated your team must be. It's a seductive idea, but it's often counterproductive.

Teams spend months trying to automate tests that would take minutes to run manually. They maintain flaky test suites that fail more often than the actual product. They write elaborate automation for features that change constantly, then spend more time updating tests than actually testing.

Meanwhile, real bugs slip through because automated tests only catch what you specifically programmed them to look for. They can't spot the weird edge case, the confusing user flow, or the thing that just "feels wrong" when you use it.

And this isn't manual testers grumbling about automation. The sharpest criticism comes from teams who automate heavily. Nubank deleted its entire end-to-end test suite after working out that for every 1,000 runs it got 42 failures and just one real bug – while bugs were still reaching production behind green builds. Martin Fowler calls non-deterministic tests "a virulent infection that can completely ruin your entire test suite". The pattern they describe is the same: the suite stops protecting you from bugs and starts protecting bugs from being noticed.

What is the difference between manual and automated testing?

Both manual and automated testing aim to answer the same question: does this thing actually work for users? The difference is in how they do it – and the kinds of problems each one’s good at catching. Let’s break it down:

Automated testing works best for:

Unit tests that verify code components work correctly
Regression tests that check the same scenarios repeatedly
Load testing that simulates heavy usage
Integration tests that verify system connections

Manual testing excels at:

Exploratory testing where you investigate and adapt as you go
Usability testing that checks if real humans can actually use your product
Edge case discovery that finds problems you didn't know to look for
user acceptance testing that verifies the software works for its intended users

These aren't competing approaches – they're solving different problems.

What testing can't be automated?

Plenty of testing resists automation, for different reasons. Some of it needs human judgment a script can't fake: exploratory testing, usability and UX, accessibility, and the visual "does this actually look right?" checks. Some of it could be automated but isn't worth it: one-off tests, features that change every sprint, or anything where writing and maintaining the script costs more than running the check by hand. And some of it, like user acceptance testing, is about whether the software solves a real problem, which no assertion can decide.

Exploratory testing is the clearest case of the first kind. You can't script curiosity or automate intuition. When a tester notices something feels off – maybe the loading spinner behaves strangely, or an error message doesn't quite make sense – that's human intelligence finding problems that no predetermined test would catch. We talk more about this in our blog, What Is Exploratory Testing?

It's not about following steps. It's about investigating – trying unexpected inputs, exploring unusual user flows, noticing inconsistencies a script would sail right past.

User acceptance testing is the clearest version of that last point. You can automate whether a feature technically works, but you can’t automate whether it actually solves the business problem it was designed for. This, along with whether real users find it intuitive and whether it fits naturally into their workflow, requires human judgment.

Whole domains land here too. Games are the obvious one. You can automate a build smoke test or a load test, but not whether a level is fun, whether the controls feel right, or whether a physics moment looks convincing. Add the huge, often random state space of a real game and automating the core experience gets expensive fast, which is why studios still lean hard on human playtesters.

And if the question on your mind is AI rather than scripted automation, we take that one on in why manual testing matters.

Don’t jump straight to automation

It's easy to think automation will save you time, but it's not that straightforward. The setup costs and maintenance often eat up more time than you'd expect, especially when teams try to automate everything right away.

Take regression testing – the kind that seems like an obvious candidate for automation. You don't actually have to start there.

Instead, build your regression coverage manually first. Every time you fix a bug, add a check to your list. Every time you release a feature that could break existing functionality, add relevant checks. You'll quickly build comprehensive regression coverage without any automation overhead.

Then – and only then – promote specific tests to automation when it actually makes sense. Maybe it's the payment flow that's complex and business-critical. Maybe it's the user registration process that breaks frequently. But that rarely-changing admin settings page? Probably fine to keep checking manually.

Is automated testing faster than manual testing?

Not always. Manual testing is often quicker, especially once you account for the real costs – which surprises teams raised on "automation is always faster" thinking.

Take a simple example: testing that a contact form sends emails correctly. You could spend hours writing an automated test that sets up test email accounts, sends messages, checks inboxes, and cleans up afterward. Or a human could fill out the form and check their email in 30 seconds.

The automation might save time if you're running that test hundreds of times. But many tests aren't run hundreds of times. They're run a few times per release, for features that change occasionally. The setup and maintenance cost of automation often exceeds the time it saves.

Don't forget the hidden costs: debugging flaky tests, updating tests when features change, and the context-switching overhead when automated tests fail for unclear reasons. A human can quickly verify whether a failure is a real bug or just a test issue. Automation can't. And a flaky test you decide to live with isn't a one-off cost – it taxes the team a little every week, forever, until someone fixes it or trust in the whole suite dies.

Manual vs automated testing: The real comparison

	Manual testing	Automated testing
Best at	Exploratory testing, usability, edge-case discovery, user acceptance testing	Unit tests, regression, load testing, integration checks
Setup cost	Minutes – write a checklist and start	Hours to days per test, plus the infrastructure around it
Maintenance	Low – update a line when the product changes	High – scripts break when the product changes, and brittle suites need constant repair
Speed	Faster for tests you run a few times per release	Faster for tests you run hundreds of times
Consistency	Depends on tester skill and attention	Identical execution every time, can run overnight
What it finds	Problems you didn't know to look for	Only what you specifically told it to check
When it fails	A human can skip or fumble a check	Flaky failures waste time and erode trust in the whole suite
Scales	Poorly for high-volume repetition	Well, once the tests are stable

When should you use manual vs automated testing?

It’s not manual versus automated testing – it’s about using the right tool for the job. Manual testing often brings more value than teams expect, but that doesn’t mean automation doesn’t have a role. It’s all about knowing where each one makes the biggest impact.

Choose manual testing when:

The feature changes frequently
You need to do sanity checks on basic functionality
You need to validate user experience or usability
The test scenarios are complex and exploratory
Setup costs outweigh the benefit of automation
You're testing something new and don't know all the edge cases yet

Choose automated testing when:

You're running the same tests repeatedly
The functionality is stable and unlikely to change
The test scenarios are predictable and well-defined
The cost of manual testing exceeds automation maintenance
You need to test at scale or during off-hours

Start with manual and promote to automation when the math makes sense.

Why do most testing tools get manual testing wrong?

Traditional test case management tools assume manual testers need rigid, step-by-step scripts. Click here, type this, expect that result. It's micromanagement disguised as process.

But real manual testing – especially exploratory testing – doesn't work that way. Testers need room to think, investigate, and adapt. They need structure without straitjackets.

The best manual testing tools provide guidance without getting in the way. They help testers stay organized and track progress without dictating every action.

How Testpad supports smart manual testing

This is where Testpad's checklist approach makes sense for real-world manual testing.

For regression testing, you can build your checklist organically. Add checks when you fix bugs, remove them when you automate specific tests. The list evolves naturally with your product.

For exploratory testing, checklists work like flexible investigation prompts. Instead of rigid test cases, you create prompts like:

"Test password reset with various email formats"
"Check shopping cart behavior with promotional codes"
"Verify mobile responsiveness on different screen sizes"

It's specific enough to ensure coverage without prescribing every click. Testers can investigate each area thoroughly while staying focused on what matters.

Compare this to traditional test case tools that force formal documentation for every possible scenario. That works fine in highly regulated industries, but it's overkill for most teams. You end up spending more time managing test cases than actually testing.

The bottom line on manual vs automated testing

The goal isn’t to choose between manual and automated testing – it’s to use both where they work best. A smart testing strategy balances human creativity with automated efficiency, instead of forcing everything into one approach.

Manual testing isn’t something you grow out of. It’s what you use when human judgment is the best tool for the job.

So stop treating manual testing as a stepping stone to automation. Start seeing it as a strategic choice. Some testing should always stay manual because that’s where it’s most effective. Other testing can – and should – be automated when the investment makes sense.

Ready to try manual testing that thinks the way your team does? Start your free 30-day Testpad trial – no card details needed.

8 Best alternatives to QMetry

Stefan Butlin — Fri, 25 Jul 2025 00:00:00 +0000

Testing isn't just about finding bugs – it's about understanding your software and giving your team confidence to ship. It means getting clear signals on what's working, what's not, and where to focus next.

Tools like QMetry bring serious power: AI-driven insights, enterprise-grade features, deep automation integration. It’s a good fit for teams that need a full-scale testing setup.

But not every team works like that. And when your process is simpler, QMetry can feel like taking a Formula 1 car to the supermarket – impressive engineering, but more than you need to get the job done.

What is QMetry?

QMetry is an AI-enabled test management platform built for large, structured teams. It offers advanced features like predictive analytics, automation integration, and deep reporting – all designed to help QA teams test smarter and scale confidently.

Key features of QMetry

AI-powered insights – QQBot suggests tests, detects duplicates, and recommends coverage improvements
Enterprise automation integration – Connects with CI/CD pipelines and DevOps workflows
Advanced analytics – Custom dashboards and in-depth reporting for decision-making
Scalable test management – Handles authoring, execution, and requirements tracking at scale
Compliance features – Audit trails, documentation, and traceability for regulated industries

Where it fits well

QMetry works best in enterprise environments where process maturity, automation investment, and auditability are critical. If you have large teams, multiple projects, and strict compliance needs, QMetry has the infrastructure to match.

Who it's best for

Enterprise QA teams with formal processes and documentation needs
Automation-heavy teams running extensive CI/CD workflows
Data-driven teams who want AI suggestions and predictive insights
Regulated industries where compliance and traceability matter

Pros and cons

Pros

Advanced AI tools that can improve test efficiency
Scalable platform with full enterprise support
Deep integration with automation and DevOps pipelines
Strong analytics and reporting tools

Cons

Takes time to set up and learn
Complex pricing structure
Can slow teams down if they don’t need the full feature set
Built around formal process, which might not fit everyone

Why explore alternatives to QMetry?

QMetry has a lot going for it. But for many teams, it’s too much.

You don't need enterprise complexity right now – If you're not working in regulated environments or running large automation suites, simpler tools might serve you better
You want easier onboarding – Teams move faster when tools are intuitive and easy to adopt
You need better value – Transparent pricing and lower cost-of-ownership often matter more than extra features
You're focused on manual or exploratory testing – If your QA depends more on people than pipelines, the heavyweight stuff gets in the way

8 top QMetry alternatives

Here's how other test management tools stack up if QMetry feels a little heavy.

Price comparison

Tool	Free trial	Basic plan price per year	Business plan price per year	Price per 10 users per month
QMetry	15 days	Contact sales	Contact sales	Contact sales
TestRail	30 days	$4,200 (Professional)	$8,520 (Enterprise)	$370
PractiTest	14 days	$4,680	$5,880	$390
Testmo	21 days	$1,010 (Team)	$4,070 (up to 25 users)	$99
Zephyr Enterprise	30 days	Contact sales	Custom	Contact sales
TestMonitor	14 days	$396 (Personal)	$4,788	$399
Tuskr	30 days	$900	$1,500	$75
TestLink	Free (open-source)	Free (self-hosted)	Free (self-hosted)	Free
Testpad	30 days	$588 (Essential, 3 testers)	$1,188 (Team, 10 testers)	$99

1. TestRail

TestRail is a long-standing leader in structured test case management. It's known for its depth, reliability, and strong enterprise support.

Key features

Detailed test case tracking
Custom workflows and fields
Powerful dashboards and analytics
Broad integration support (Jira, CI/CD, etc.)

Good for teams that want tried-and-tested workflows with strong reporting and integration options. Cons include higher costs and a setup process that can slow down smaller teams. For a direct comparison with Testpad, see Testpad vs TestRail.

2. PractiTest

PractiTest offers full lifecycle test management, including requirements and issue tracking. It’s especially strong on traceability and custom workflows.

Key features

Centralized platform for QA work
Custom fields, views, and dashboards
Strong ALM capabilities

Best for teams wanting end-to-end visibility across projects. Cons include a steep price tag and complexity that may not suit everyone.

3. Testmo

Testmo is a newer platform that unifies manual, automated, and exploratory testing in one tool.

Key features

Modern UI with fast performance
Native automation support
Scalable for mixed testing environments

Best for teams looking for a simple, modern alternative to older tools. Downsides are fewer advanced features for big businesses and a smaller community of users.

4. Zephyr Enterprise

Zephyr Enterprise is the enterprise-level test management solution from the Zephyr product family, built for larger QA teams that need formal processes, advanced integrations, and deep traceability. Unlike Zephyr Squad (which is more Jira-native), Zephyr Enterprise works as a standalone solution with powerful capabilities across multiple tools and workflows.

Key features

Enterprise-grade test management with cross-project visibility
Custom workflows, test planning, and test execution tracking
Real-time analytics and dashboards
Integration with Jira, CI/CD pipelines, and automation frameworks
Scalable architecture for large or distributed teams

Cons include a lengthy setup time and need for training, plus complexity that may be more than some teams require.

5. TestMonitor

TestMonitor helps teams organize their testing in a clear, step-by-step way. It makes it easy for everyone involved to see progress and focuses on testing the most important risks first.

Key features

Milestone tracking
Risk-based test planning
Built-in reporting for non-technical users

Good for teams wanting formal processes without deep automation. Cons include a more traditional UX and less flexibility for agile teams.

6. Tuskr

Tuskr is a clean, cost-effective test case management tool built for smaller QA teams.

Key features

Simple interface and fast onboarding
Issue tracker integrations
Low pricing tiers

Perfect for teams switching from spreadsheets who want a simple, organized tool. Downsides are limited automation and fewer advanced features.

7. TestLink

TestLink is a free tool best for teams with technical skills and tight budgets.

Key features

No licensing fees
Core test case management tools
API access for integration

Good for teams that can self-host and customize. Cons include dated UI, no official support, and limited built-in automation.

8. Testpad

Testpad keeps things refreshingly simple. It uses a checklist-style approach to test management that avoids complicated workflows and focuses on testing. For a full side-by-side, see Testpad vs QMetry.

Key features

Write tests as checklists – fast to create, easy to maintain
Invite anyone to test – including guest testers, PMs, and clients
Track real-time progress visually
Link failed tests to bugs in Jira, GitHub, or other trackers
Supports exploratory, structured, and user acceptance testing

Why choose Testpad?

If you're looking for something lighter than QMetry but more organized than spreadsheets, Testpad might be exactly what you need:

Built for speed – Get started in minutes, not weeks
Low overhead – No training needed
Real collaboration – Guest access and simple UX mean the whole team can help test
Priced for accessibility – Transparent plans that scale with you

Testpad pricing

Essential: $49/month (3 users)
Team: $99/month (10 users)
Team 15: $149/month (15 users)
Department: $249/month (25 users)

All plans include a 30-day free trial.

Find the tool that fits how your team actually works

If you’re spending more time managing your test tool than managing your tests, it might be time for something simpler.

Testpad is built for manual testing that’s fast, flexible, and collaborative. It’s designed so that anyone in the team – as well as guest testers – can jump on and test.

Start your free 30-day trial, no credit card needed.

FAQs

What makes Testpad different from QMetry?

Testpad is built for manual testing. It's faster to onboard, simpler to use, and flexible enough for everything from exploratory sessions to UAT.

Can Testpad handle automation?

It’s a manual testing tool, but many teams use it alongside automated tools for coverage tracking or planning exploratory sessions.

Does Testpad do reporting?

Yes – you get progress tracking, run histories, and exportable reports. No custom dashboards to configure.

Is Testpad good for cross-functional teams?

Absolutely. Anyone can be added as a guest tester, and the UI is simple enough for PMs, designers, and clients to use.

How secure is it?

Testpad is SOC 2 Type 2 certified and uses secure cloud infrastructure. We follow modern security best practices.

Does it integrate with bug trackers?

Yes – lightweight integrations with Jira, GitHub, and others via smart URLs or copy-paste links, and there's an API and webhooks for building your own.

A guide to test prompts that work

Stefan Butlin — Thu, 24 Jul 2025 00:00:00 +0000

Instead of boxing testers into rigid step-by-step instructions, prompts act more like reminders of what needs checking without dictating how. This frees people up to spot unexpected issues and use their judgment – the kind of things automation or overly scripted tests tend to miss. It also keeps your test plans lighter and faster to write and maintain.

Ever opened a test case tool and ran into this?

Go to login page (www.example.com/login)
Check that username field is there
Check that password field is there
Enter email “test@example.com”
Enter password “password123”
Click “Login”
Check you land on the dashboard
Check it shows your name
Check account info is correct

Many teams are stuck writing this level of detail. But there’s a simpler option.

Say hello to test prompts

Rather than scripting every action, test prompts give outcome-based guidance that leaves room for exploration. They’re made for people who know how to use software – not just formal QA.

Here’s the same login test from above as a prompt:

Login works for valid email and password

One line. It trusts the tester to figure out the rest, while focusing on what actually matters.

Test prompts guide attention without oversteering. This is sometimes called micro-exploration – small, flexible test sessions within clear guardrails.

Why use test prompts

Detailed test cases can cause friction:

Too rigid – testers follow steps instead of finding bugs
Too long – harder to scan and update
Too basic – obvious instructions clutter things
Too much documentation – not enough testing

Test prompts flip the focus to outcomes. They support better thinking, cleaner coverage, and faster updates. (For the broader comparison of the two styles, see test cases vs checklists.)

Good test prompts:

Point testers in the right direction
Assume basic product knowledge
Say what to test, not how
Encourage curiosity
Are quick to write and change

How to write test prompts (well)

Keep it short

Short prompts are easier to:

Write
Maintain
Scan during testing
Understand at a glance

Stick to one line unless there’s a good reason not to.

Skip obvious words

Drop filler like:

“Verify that”
“Check that”
“Ensure that”
“Test whether”

Instead of:
Verify that the search function works correctly
Write:
Search finds relevant results

Combine step and outcome

Don’t separate action and result.

Instead of:

Enter invalid email
Click submit
Check error shows

Write:
Invalid emails show error message

Leave room for exploration

Prompts should invite variation.

Instead of:
Enter 3-character password and check for error
Write:
Invalid passwords not accepted

This encourages testers to try different things that might break.

Write for your audience

Match the prompt to the tester. If they know the product, skip the basics.

No need for:

Navigation walkthroughs
UI labels
“Click the gear icon” types of steps

Focus on outcomes. Trust the tester to handle the rest.

Micro-exploration

Each test prompt becomes a mini test session.

File upload handles different formats → Try various file types
Error handling for network issues → Simulate dropped or slow connections
Mobile layout works on different screen sizes → Test phones, tablets, orientations

You get:

Enough direction to stay on track
Enough freedom to explore
Better test coverage with less friction

Exploration is optional – use it where it fits. When you do explore, exploratory testing techniques give you ways to probe each prompt harder.

Common patterns

Feature + condition

Search works with special characters
Login fails with wrong password
Checkout rejects expired cards
File sharing works across user types

Boundary + behavior

Large file uploads work
Long usernames show properly
Empty forms give useful errors
Character limits enforced

Integration + workflow

Emails sent after checkout
Mobile and web stay in sync
Social login links accounts
Export gives correct format

Error + edge case

Server errors handled clearly
Timeouts don’t crash things
Invalid data rejected properly
Concurrent actions don’t clash

What not to include

Don’t document your product

Prompts aren’t for product walkthroughs. Keep that in a wiki or guide. Including it here just adds noise.

Don’t over-explain simple tasks

Cut lines like:
Click Submit at the bottom right
or
Click the gear icon to open Settings

Your testers know how to use apps. Don’t state the obvious.

Don’t over-specify

Don’t write tests that break as soon as copy changes.

Instead of:
Enter ‘test@invalid’ and expect error: 'Please enter a valid email address'
Use:
Invalid email formats rejected

This lets testers try different things and saves you future edits.

Building your collection

Start with user stories

Turn real product use into prompts.

User story:
As a customer, I want to filter by price
Prompt:
Price filter shows relevant products

Group related prompts

Organize by feature, flow, or risk.

User accounts

Account creates with valid info
Reset password via email
Profile edits save
Deleting account removes data

Shopping cart

Items add to cart
Quantity changes reflect
Cart keeps items between sessions
Checkout catches payment errors

Iterate based on discoveries

After testing, ask:

What slipped through?
What worked?
What got in the way?
What risks appeared?

Update your prompts. Drop what’s not useful.

Advanced techniques

Risk-based prioritization

Label prompts by impact:

Critical – Payment works, data safe
Important – Search relevant, emails sent
Nice to have – Animations feel smooth, color contrast OK

(And yeah – accessibility usually belongs higher.)

Conditional prompts

Some prompts only apply in certain cases:

Mobile – Touch works as expected
Admin – Bulk actions succeed
New user – Onboarding is clear

Progressive detail

Add more depth if needed:

API works
Handles rate limits
Retries failed calls

Tools and organization

Where to keep your prompts

Use what your team will actually use:

Spreadsheets – simple and quick
Wikis – easy to edit
Testpad – fast and focused
Project tools – if that’s your workflow

Avoid tools that:

Slow you down
Need training
Make edits a pain

Organize by usefulness

Group by user journey
Use consistent names
Keep prompt sets tidy
Clear out old ones regularly

Measuring effectiveness

You’ll know prompts are working if they:

Speed up testing
Stay relevant as the product changes
Help find good bugs
Work for all experience levels
Scale with your team

If not, simplify.

Common mistakes

A quick recap of what to avoid:

Too much documentation → Keep elsewhere
Over-polishing → Start fast, refine later
Overcomplicated tools → Pick tools that stay out of your way
Too much detail → Focus on what matters

Making the transition

You don’t need to bin everything. Start small:

Start small

Try prompts for just one area. See how it goes.

Get team buy-in

Show how prompts save time, cut clutter, and surface better bugs.

Track the difference

Compare time and results against detailed test cases.

Address concerns

Worried about losing control? A well-written prompt does more with less.

This isn’t about choosing between scripted or exploratory testing. It’s about doing both better.

Why Testpad is built for this

Testpad is designed for the prompt-first mindset. It’s built on the idea that good testers don’t need a 20-step checklist – they need space to think and tools that help, not hinder. We discuss the wider context of test cases in our article, Test plans, not test cases.

Other tools add layers of process. We remove them. Testpad keeps testing lightweight and effective.

Prompts grow with your product – and Testpad grows with your team.

Want to try it?
Try Testpad free for 30 days and see how fast and focused testing can feel.

Checklist vs. test cases: Choosing what’s right for your testing needs

Stefan Butlin — Fri, 04 Jul 2025 00:00:00 +0000

If in doubt, use checklists: they're faster to write, easier to keep current, and they leave room for testers to think. Formal test cases belong where an auditor expects documented testing, a contract demands detailed evidence, or your testers are new every time. Most teams land on a mix, and that's fine.

At a glance

Your situation	Choose
Agile team, product changes weekly	Checklists
Experienced testers who know the product	Checklists
Business users or clients doing the testing	Checklists
Regulated industry, auditors expect documented testing	Test cases
A contract requires evidence per verification	Checklists if reports give enough detail; test cases otherwise
Testers new every time (rotating contractors)	Test cases, or better, automation
Most teams, most of the time	Checklists, with detail where needed

Checklist vs test case: what's actually different?

A formal test case is a structured record. Each one carries a title, preconditions, numbered steps, an expected result, and often metadata like priority and environment. A checklist item is one line that says what to try: discounts apply at the basket is a complete test for anyone who knows the product.

The difference looks small on paper and compounds in practice, because every test gets written once but read, run, and updated many times.

	Test cases	Checklists
One item is	A form: title, preconditions, steps, expected result	One line of plain text
Writing pace	Minutes per case	As fast as you can type
When the product changes	Every affected case needs editing	Edit the line
Guidance for the tester	Prescriptive: follow the steps	Directional: what to test, not how
Documentation value	Strong: written steps for every item	The plan plus its results record

When checklists are the right choice

Your product changes often. Checklists flex with evolving features; a renamed button is a five-second edit, not an afternoon of case maintenance. If you ship every sprint, this alone usually decides it.

Your testers know the product. Spelled-out steps serve someone seeing the product for the first time. For a team that lives in it, prescriptive steps slow the experienced and bore everyone. A checklist focuses on what to test rather than how to test it, and works as a nod of trust to your testers: they get to use their judgment, notice the odd thing one field to the left, and follow it.

You want exploration as well as confirmation. Test cases confirm the product behaves as expected. Checklists are better at surfacing the surprises, because testers explore around each prompt instead of marching through steps. That's why they suit exploratory testing so well.

Non-testers are testing. Business users, clients, and stakeholders will work through a plain-language list. They will not learn a test case schema.

When test cases are the right choice

An auditor expects documented testing. In regulated work the standard usually asks you to document what you do, prove you do what you document, and show tests traceable to requirements. Formal test cases are the convention for meeting that, and when your auditors expect them, they're not overhead, they're the job.

A contract demands evidence per item. When acceptance is contractual, both sides want the same unambiguous record. Detailed test cases are the safe answer, and a checklist plus its results report can be enough when the report carries the detail your client expects.

Your testers really are new every time. If testing rotates through contractors or an outsourced pool, step-level detail is doing real work. Worth noticing, though: a test that strangers can run identically from instructions is a strong candidate for automation, which retires the documentation burden altogether.

The procedure is genuinely intricate. Some tests have setup nobody should memorize: data states, environment flags, a sequence that matters. Write those steps down. The mistake is letting the exceptional test set the format for all the others.

What most teams end up doing

In practice this is a spectrum, not a switch. Most teams settle on checklists as the default, then add step-level detail to the handful of tests that need it: the intricate setup, the compliance-critical path. The format question gets decided per test, not per team.

This guide is for choosing what fits your situation. For why Testpad sits firmly on the checklist side of it, see Test plans, not test cases.

So which is right for you?

Choose checklists when:

You're solo or a small team moving quickly
Your testers know the product and can fill the gaps
You're doing exploratory testing, or want room for it
Business users or clients are doing the testing
Requirements are still moving and the plan must keep up

Choose test cases when:

You need traceability for audits or regulation
A contract requires documented evidence per requirement
You plan to automate soon (the steps become the script)
The test's setup is too intricate to leave to memory (here's how to write a test case that pays for itself)

If you're unsure, start with a checklist. It's an afternoon's work, you'll learn more from running it than from formatting it, and you can add detail exactly where the first run shows you need it.

Whichever side you land on, the tool matters less than the fit. Most teams start in a spreadsheet, and that's fine until several people are testing at once, results need collecting across releases, or the report is going in front of a client: a purpose-built report looks the part every time, where a spreadsheet takes real effort to make presentable and more again to keep consistent from report to report. Testpad was built for the checklist side of this choice, as plans made of test prompts, with room for step-level detail on the tests that need it. Try it free for 30 days.

How to use spreadsheets for exploratory testing (and when to upgrade)

Stefan Butlin — Mon, 23 Jun 2025 00:00:00 +0000

Spreadsheets are the natural starting point for software test cases – familiar, flexible, and in most cases, free. But how do you get the best from them without locking yourself into rigid scripts or chaotic notes? The answer lies in using spreadsheets to guide exploratory testing: a pragmatic middle ground that balances structure with freedom.

The sweet spot of exploratory testing

Most spreadsheet test plans end up somewhere between rigidly scripted test cases and completely unstructured testing. Teams sometimes gravitate toward this middle ground – and that's actually smart.

This middle ground is structured exploratory testing: where simple prompts guide testers toward key areas, while still leaving room for their insight and creativity to uncover unexpected issues.

Instead of writing:

1. Click login button
2. Enter email
3. Enter password
4. Click submit"

You write:

"login function works with the correct details"

This approach gives you the benefits of exploratory testing while keeping your test planning organized – perfect for small teams getting started.

How to start exploratory testing in spreadsheets

Structure your spreadsheet for exploratory testing:

Replace step-by-step instructions with broader test missions
Focus on what to explore, not how to explore it
Include columns for unexpected findings, not just pass/fail
Group by feature or user journey, not arbitrary test numbers

Examples of exploratory testing prompts that work well:

"Test user registration with different email formats and edge cases"
"Explore payment processing under various network conditions"
"Investigate search functionality with unusual queries"
"Challenge file upload limits with different file types"

Track the right information:

What was learned, not just what was checked
Time spent in different areas
Follow-up questions or areas needing deeper investigation
Unexpected behaviors, even if they're not bugs

Where spreadsheets start to fall short

Even if your spreadsheet is neat, collaborative, and structured, it’s still a spreadsheet. Eventually, you’ll hit friction:

You end up overwriting each other’s notes
Version control can become a mess
You can’t assign tests or track progress
You miss gaps in coverage
It’s clunky to share and update
You need to create reports manually

The more testers or test sessions you add, the harder it gets to stay on top of things. And the testing itself – the part that actually matters – ends up getting slower, not faster.

What tools to use for exploratory testing instead?

When spreadsheets start slowing you down, you don’t need to jump to heavyweight tools. You need something fast, flexible, and built for testing.

Exploratory testing works best with tools that are:

Fast to use
Easy to update mid-session
Flexible enough to evolve with your test ideas
Built for collaboration

That’s where Testpad comes in.

Testpad as your spreadsheet alternative

Testpad keeps the lightweight, flexible nature of a spreadsheet – but adds just enough structure to make testing easier, faster, and more trackable.

You get:

Simple, checklist-style test plans
Real-time collaboration across your team
Easy tracking of who’s tested what
Instant progress visibility without writing reports
No need to learn a new way of working

You can write your test plans like a to-do list or a mind map. Keep them scrappy. Or refine them over time. And when you’re ready to run the tests again, just duplicate the plan and go again.

No formatting cells. No updating 20 columns. No confusion. Just better testing.

Of course, there are other alternatives to spreadsheets out there that might suit your team – especially if you’re trying out different approaches. But Testpad was built with this kind of structured exploratory testing in mind. If you're curious, we've rounded up a few more exploratory testing tools options.

Testpad works the way you already do

You just need a tool that works the way you already do – only faster, cleaner, and built for testing.

Try Testpad free for 30 days. It’s an easy upgrade from spreadsheets for exploratory testing.

What’s the point of testing?

Stefan Butlin — Tue, 03 Jun 2025 00:00:00 +0000

Ask ten people what testing is, and you'll get ten different answers. Some call it "quality assurance" and picture clipboard-wielding folks robotically checking boxes.

Others see it as just finding bugs – hunting down errors before users do.

Many developers view it as that frustrating final hurdle before they can ship their code.

The real point of testing is to find out what your product actually does versus what you think it does. Essentially, it serves as an information service that reveals the gap between intention and reality before your customers make that discovery for you – usually at the worst possible moment.

Testing helps answer crucial questions like:

Does this thing actually work?
Will users figure out how to use it?
Is it going to crash right when the CEO is showing it off?
Did we build what we thought we were building?

We all test things without thinking about it – proofreading an email, checking a door's locked, tasting the sauce before serving.

Software testing is the same concept: making sure things work before they go out into the world.

Testing is for learning

Think of testing as gathering intel – not spy stuff, but the kind that helps you avoid releasing something that doesn't work. Testers dig into how the software behaves, how reliable it is, and whether it holds up in the real world. Then they share what they’ve found so the team can make smart calls about what’s ready and what still needs work.

Looking at testing this way flips the idea of being a blocker. Testers aren’t there to say no to a release. They’re helping the team say yes with their eyes open. That means fewer embarrassing moments where a new feature falls over in front of a customer or crashes during a demo.

When someone asks, “can we ship this?” they need more than just a bug count. They need to know:

Which issues are likely to cause real problems
What still feels risky or uncertain
Where more digging might uncover something important
Whether this version is actually good enough for users

Getting the most from limited testing resources

Time, budget, and focus are always limited. But effective testing doesn't have to be expensive or complicated. It's about starting simple and focusing on what matters most.

Think about:

Where testing will uncover the most insight
Which areas are the riskiest
How to balance thorough coverage with time
When to use different testing styles(scripted, exploratory, automated)

Remember, the goal isn't to test everything exhaustively – that's impossible. Instead, aim to gather the most valuable information efficiently, focusing efforts where they'll reveal the most important insights about product quality.

Don't fall into the trap of over-planning your testing. Excessive planning can consume valuable time that could be better spent on hands-on testing. Also, consider that manual testing can often be cheaper and easier in the early stages of testing. Automation has its place – but relying on automation alone can slow you down.

Understanding what your software really does

Counting bugs is like judging a restaurant by its dirty dishes – you're missing the full experience from the taste to the ambiance.

To truly grasp your software's quality, consider asking:

Does this feature solve the problem it's meant to?
Will users find it intuitive and easy to use?
How does the system perform under stress?
What happens when things go wrong?
Are there edge cases we've overlooked?

This broader perspective moves beyond just defect counts. It focuses on whether the software meets user needs, delivers a satisfying experience, and provides real value to the business.

Get the most out of testing

Testing isn't just about checking boxes or collecting bug counts; it's about uncovering meaningful insights that guide better decisions. To maximize the value of your testing efforts:

Focus on learning, not just checking: Approach each test with curiosity about what you might discover.
Communicate context, not just results: Help stakeholders understand what findings mean for their decisions.
Prioritize based on risk and value: Direct efforts where they'll yield the most important insights.
Adapt methods to goals: Choose testing approaches that best support current information needs.
Think beyond the immediate: Consider how today's testing insights inform tomorrow's development.

Remember, great testing doesn't have to be expensive or complicated. It's about starting simple and focusing on what matters most.

Testing gives you confidence

Think of testing as your product's dress rehearsal. It helps you catch the off-notes before the big performance, ensuring everything runs smoothly when it counts.

Of course, testing won't catch every single issue – software is complex, and surprises can happen. But it does give you the best possible insight into how your product behaves, allowing you to make informed decisions about what's ready and what needs more work.

The goal isn't perfection; it's confidence. Confidence that your users will have a good experience, that your app won't crash during a critical demo, and that you're delivering value. That's the real power of testing.

With Testpad's intuitive, checklist-style approach, you can explore your application's behavior, identify surprises, and get insights that might otherwise go unnoticed. Sound good? Give Testpad a go with our free 30-day trial – no credit card required. It’s an easy way to see how better testing leads to better decisions – and better products.

Testpad vs Tuskr: test plans, not a structured case manager

Stefan Butlin — Mon, 02 Jun 2025 00:00:00 +0000

The difference between Testpad and Tuskr comes down to what a "test" looks like in each tool. In Tuskr, a test is a structured form: a case with steps, expected results, an auto-incrementing ID, and attachments. In Testpad, a test is a line of plain text in a checklist. This page sets out that structural difference, where each tool is stronger, and how the costs compare, so you can decide which fits the way your team actually works.

The short version

Tuskr is a structured cloud test case manager: projects contain test suites, which hold test cases with numbered steps, expected results, and IDs like TC-1234. Test runs are assignable, have custom statuses, and generate PDF reports. Testpad holds a test plan as a nested outline of plain text prompts, with a column added per test run, marked pass or fail as you go.
Tuskr has a free tier for small teams, plus a requirements module for traceability and automation result sync via CLI. Testpad has a 30-day trial rather than a free tier, but every paid plan includes all features.
Teams choose Tuskr for structured test case management with steps and expected results, per-test IDs, requirements traceability, and a free starting point. Teams choose Testpad for fast, write-as-you-think test planning, a column-per-run grid that puts runs side by side, and guest testing that lets UAT participants or extra hands run a plan with no account.
Tuskr is $9/user/month. Testpad is from $10/user/month, and guest testers are free.
Neither choice is wrong. It comes down to whether you want tests to be structured cases with steps and IDs, or plain-text prompts in an outline.

What's the actual difference?

Tuskr is built around structured test cases. A test case has a title, a numbered list of steps, an expected result per step, an auto-incrementing ID (TC-1234), custom fields, and optional attachments. Cases live inside test suites, which live inside projects. When you run them, you create a test run: assign testers, set statuses, lock runs when they're done, and export a PDF report. There's also a requirements module for tracing coverage from requirement to case, and a CLI tool for pushing automation results in from CI. Tuskr integrates with Jira, GitHub, GitLab, and others for defect tracking.

Testpad is built around the test plan, as a document. A test is a line of plain text. Indenting builds structure: group related tests under a heading, or break a bigger check into sub-prompts. Add a column for each test run and mark each line pass or fail as you go. Reports are shareable links, not exports. You write the plan the way you'd write a document, and anyone you share the link with can run it. Guest Testing lets you invite testers who don't have a Testpad account, useful for UAT rounds or bringing in extra hands without buying seats.

If your process depends on structured test cases with steps, expected results, and IDs you can reference in a defect tracker, Tuskr's model is built for that. If you'd rather a test stayed a line of plain text and your plan stayed readable by anyone, that's the gap Testpad fills.

How do Testpad and Tuskr compare?

A side-by-side comparison of the aspects that matter when choosing.

	Testpad	Tuskr
Data model	A standalone document: a nested outline of plain text prompts with a column per test run	Structured test cases with steps, expected results, and auto-incrementing IDs (TC-1234), inside test suites
Writing tests	Type a line, hit enter, repeat; indent to add structure	Create a case with numbered steps and expected results; attach files; set custom fields
Guest / UAT testers	Guest Testing: invite testers with no Testpad account for UAT or extra hands	Testers need a seat, even on the free tier; a client portal allows stakeholders to view results
Free tier	No free tier; 30-day trial includes all features and up to 20 users	Free tier for small teams
Requirements traceability	Not today	Requirements module: link cases to requirements and track coverage
Automation results	Push from CI via REST API; Gherkin-style syntax supported	CLI tool for syncing automation results; integrations with common CI tools
Per-test IDs	Not today	Yes; auto-incrementing IDs (e.g. TC-1234)
Audit trail / permissions	Not today	Lockable runs; user roles within projects
Reports	A shareable live link	PDF export; customizable run reports
Integrations	Jira, GitHub, Trello (issue links); REST API for CI	Jira, GitHub, GitLab, Azure DevOps, Slack, and others
Pricing	From $10/user/month, guest testers free	$9/user/month; free tier available
Best for	UAT, regression, exploratory, dev-led testing; teams writing plans at pace	Teams wanting structured test case management with steps, IDs, and requirements traceability

Tuskr facts checked against tuskr.app, June 2026.

Why do teams choose Testpad over Tuskr?

Writing a test takes one line. In Tuskr you fill in a structured form for each case: title, steps, expected results, custom fields. That's the right model if formal structure is the goal. In Testpad a test is a line of plain text: type it, hit enter, write the next. A 20-item regression plan takes minutes to draft and reads the same way on day one as it does six months later.

The column-per-run grid. Each test run is a column in Testpad's grid, so you can see multiple runs side by side in the same view. Pass rates across runs are visible at a glance without switching views or pulling a report.

Guest Testing. Send a Testpad plan link to a client, a product manager, or a freelancer: they run the plan and record results with no Testpad account and no seat to buy. Tuskr's testers need a seat (the free tier has a user limit), and there's a client portal for viewing results but not for running them directly. For UAT rounds, that means bringing in extra hands without buying each one a Tuskr seat.

Shareable live reports. Testpad reports are links, not exports. Share the URL and the recipient sees the live state of the run. Tuskr produces PDF reports, which are a snapshot at export time.

Cost follows your testers. Testpad is from $10/user/month, and guest testers are free, billed for people testing in Testpad. Guest testers don't add to the seat count. Tuskr's free tier covers small teams, but its paid tiers scale in cost per user.

When is Tuskr the better choice?

When your team needs structured test case management with steps, expected results, and per-test IDs from the start. Tuskr's data model is built for teams that want cases referenced by ID in a defect tracker, requirements linked to coverage, and PDFs as deliverable reports. It has a free tier, integrations with Jira, GitHub, GitLab, Azure DevOps, and Slack, and automation result sync that handles hybrid manual-and-automated QA workflows without a separate tool. If that structure is what your process requires, Tuskr covers it and Testpad does not.

When is Testpad the better choice?

When you want to write a test the way you'd write a list, and open that list to people outside your QA team. You run UAT with clients or stakeholders, do exploratory and regression work, or your developers test their own code and a structured test case per check is more ceremony than the testing actually needs. Teams of that shape get going in minutes, keep plans light enough to stay current, and use Guest Testing to bring in non-testers without buying seats.

"We use Testpad to track all of our testing. It offers the depth and flexibility to model our entire test plan, but remains simple enough that onboarding new testers is effortless. The import and export facilities are really helpful for migrating test plans from other test management tools."

Eric Wolf, Senior Solutions Architect, Bell

Common questions

Is Testpad a replacement for Tuskr?

For light, fast manual and exploratory testing it can be: UAT, regression, dev-led testing, ad-hoc checks. If your process depends on structured test cases with numbered steps, per-test IDs, requirements traceability, and a free tier to start on, those are things Tuskr has today that Testpad doesn't.

What's the actual difference in the data model?

Tuskr stores test cases with numbered steps, expected results, and auto-incrementing IDs inside test suites. Testpad stores a test plan as a nested outline of plain text prompts, with a column added per test run.

Does Tuskr have a free tier?

Yes. Tuskr has a free tier for small teams. Testpad doesn't have a free tier; it offers a 30-day trial that includes all features and up to 20 users, with no credit card required.

Can clients or non-technical people test in Testpad?

Yes. Testpad's Guest Testing feature lets you share a link with someone who has no Testpad account; they run the plan and record results without buying a seat. In Tuskr, running tests requires a seat; there's a client portal for viewing results, but external testers generally need an account to run tests themselves.

How does pricing compare?

Tuskr starts at $9/user/month with a free tier for small teams. Testpad is from $10/user/month, and guest testers are free, with every paid plan including all features. The right comparison depends on team size and whether the free tier or the trial fits your evaluation style.

Does Tuskr handle automation results?

Yes. Tuskr has a CLI tool for syncing automation results into test runs, and integrates with common CI tools. Testpad accepts results from CI via its REST API and supports Gherkin-style syntax for BDD-flavored plans, but doesn't run automation itself.

Does Testpad have per-test IDs or an audit trail?

Not today. If your process requires per-test IDs that you can reference in a defect tracker, or audit logs for a compliance process, Tuskr has both; Testpad doesn't, and it's worth checking before you switch anything over.

See the difference in five minutes

Testpad is now SOC 2 Type 1 certified

Stefan Butlin — Thu, 29 May 2025 00:00:00 +0000

A SOC 2 Type 1 certification is proof that we were already doing things the right way – this just makes it official. It’s a recognized industry standard, so if you work in finance, healthcare, or any regulated field, it’s a clear signal that you can trust us with your data.

Update, January 2026: Testpad is now SOC 2 Type 2 certified as well. This post covers the original Type 1 milestone.

Security’s always been a priority at Testpad. Getting SOC 2 didn’t change that – it just meant putting our existing processes under the microscope and having them checked off by independent experts. This is Type 1, which means everything was in place and working on the day of the audit. Next up is Type 2 – proof that we keep it up over time, not just on paper.

SOC 2 is a security standard

In simple terms, SOC 2 (System and Organization Controls 2) is a security standard developed by the American Institute of CPAs (AICPA). It was created specifically to help organizations verify their security practices and reduce the risk of security breaches in our increasingly digital world. For Testpad, that means an independent audit confirmed we’re doing the right things to keep your information safe.

Unlike certifications that focus just on tech infrastructure, SOC 2 looks at the big picture by evaluating organizations across five key Trust Service Criteria:

1. Security: Protection against unauthorized access

2. Availability: Systems are operational and accessible as committed

3. Processing Integrity: System processing is complete, accurate, and authorized

4. Confidentiality: Information designated as confidential is protected

5. Privacy: Personal information is collected, used, and retained appropriately

Our SOC 2 certification specifically covers the Security criterion, which is the foundation of any robust data protection strategy.

We’re a modern, cloud-based service with a remote team, so our security focus looks a little different from traditional, office-based setups. Our SOC 2 controls are designed for today’s challenges – things like access to software, securing employee devices, and protecting cloud infrastructure. In short: the stuff that actually matters when your data lives online.

If your company needs vendors that meet recognized security standards (think finance, healthcare, or anything highly regulated), our SOC 2 certification helps check that box with confidence.

Big certification, small team that cares

At Testpad, we don’t have a big compliance department. We’re a small team, so we adapted SOC 2 principles to fit the way we actually work by defining clear roles and checks without unnecessary complexity.

While we might wear multiple hats in our day-to-day operations, SOC 2 requires clear separation of duties, which we have covered. Each role is defined, and the right checks are in place, without slowing us down.

We didn’t just check boxes to meet requirements. We embedded security practices directly into our existing workflows, so they’re practical, sustainable, and genuinely part of how we work, rather than just written down for the audit.

For you, that means tighter processes and a team that personally stands behind keeping your data safe. It’s not just a task on someone's checklist but something every team member owns.

We’re backed by experts you can trust

We chose proven experts to ensure our security controls meet the highest standards, so you don’t have to just take our word for it.

We partnered with Vanta, a leading security and compliance platform, to help automate monitoring and streamline documentation. Vanta has a handy, in-depth guide on the ins and outs of SOC 2 security that you can read if you’re interested.

Our audit was performed by Prescient Assurance, specialists in security assessments for tech companies, giving you independent confirmation that your data is protected. They checked our systems, our processes, our documentation – the works. And they confirmed that Testpad meets SOC 2 Type 1 standards.

Strengthening what we were already doing

SOC 2 didn’t force us to start caring about security – it gave independent confirmation of protections we already had in place. You’re trusting a platform where security isn’t an afterthought, but something that has been baked in from day one.

Beyond SOC 2: Our bigger security picture

SOC 2 is a major milestone, but it’s just one part of our broader security commitment.

We've also recently updated our Security and Compliance page to give you more transparency on:

Data encryption (in transit and at rest)
Access controls and role-based permissions
Vulnerability scanning and proactive patching
Incident response plans (for the "just in case" moments)

Security isn’t a one-and-done. It’s an ongoing part of how we build and operate Testpad.

What's next

Type 2 certification followed in January 2026, showing we’re not just secure on paper but in practice over time. We’ll keep evolving and improving our security practices while we continue to make security clear and accessible

If you have any questions about our SOC 2 certification, or want more details about our approach to security, get in touch at support@testpad.com. We’re always happy to chat.

8 Best TestMonitor Alternatives for Pragmatic Test Management

Stefan Butlin — Wed, 28 May 2025 00:00:00 +0000

Testing helps you understand your product – what’s working, what’s not, and what still needs attention. It’s not about chasing every edge case. It’s about getting clear, actionable insights that move your team forward.

Tools like TestMonitor bring structure to the chaos, helping teams stay aligned with features for traceability, reporting, and keeping stakeholders in the loop. It’s a solid, full-featured option for managing complex testing.

Not every team needs that level of depth. For some, Test Monitor can feel like overkill – too complex, too expensive, or just more than what’s needed. In those cases, something leaner or more focused might be a better fit.

Below, you’ll find a breakdown of the top TestMonitor alternatives, highlighting which tools deliver the right balance of speed, structure, and value based on your team’s needs.

What is TestMonitor?

TestMonitor is a cloud-based test management platform that helps teams plan, organize, and run their software testing with structure and clarity. It brings everything into one place – from documentation and progress tracking to detailed reporting.

At its core, it’s about helping teams manage risk and stay aligned on requirements throughout the testing process.

Key features of TestMonitor

Risk-based testing that prioritizes coverage where it matters most
Requirements and milestone tracking to align testing with broader project goals
Issue management and reporting tools to keep defects visible and actionable
Comprehensive test case management with detailed documentation
Custom fields and flexible configurations to tailor the tool to team-specific workflows

Where it fits well

TestMonitor shines in environments where formal processes and structured test management are critical. For teams that need to align closely with project milestones and deliver robust, documented testing cycles, TestMonitor offers a well-organized platform with clear dashboards to keep everyone on the same page.

Who is TestMonitor best for?

Teams in regulated industries needing formal processes: Industries like healthcare, finance, or government often require detailed testing documentation, traceability, and audit-ready reports.
Mid-to-large QA teams managing complex test plans: Larger teams benefit from the platform’s ability to coordinate multiple testers, track progress, and manage issues across a wide range of test cases.
Teams prioritizing detailed reporting, metrics, and dashboards: If your team needs deep insights, clear dashboards, and exportable metrics to communicate with stakeholders, TestMonitor’s reporting capabilities stand out.

Common pros and cons

Like any tool, TestMonitor has strengths and a few areas where teams might encounter friction. Here’s a quick look at both sides.

Pros

Comprehensive dashboards and reports: Clear visuals make tracking progress, spotting issues, and sharing insights with stakeholders easy.
Strong traceability between requirements and tests: Reliable links between cases, requirements, and defects help demonstrate coverage and accountability.
Responsive customer support: Many users highlight the helpful, attentive support team that steps in when challenges arise.
Built-in risk management and requirements tracking: Designed for process-driven environments, especially in regulated or high-stakes industries where traceability matters.

Cons

Steep learning curve for new users: Teams unfamiliar with formal test management tools may need time to onboard effectively.
Complex setup and configuration: Tailoring the platform to team-specific needs can feel cumbersome, especially at the start.
Less budget-friendly for smaller teams: While feature-rich, the platform’s pricing can escalate quickly, making it less appealing for startups or small groups.
Limited integrations compared to lightweight tools: Teams needing seamless connections to certain development or CI/CD platforms sometimes find the options restrictive.

Why explore alternatives to TestMonitor?

TestMonitor offers plenty of strengths: detailed traceability, advanced reporting, and formal, organized testing workflows. But sometimes, those strengths don’t align with a team’s immediate priorities.

Every tool has strengths and quirks. The trick is finding the one that best suits your team's needs.

You don’t need the full feature set right now: If your team doesn’t rely on deep traceability, milestone tracking, or risk-based testing, you might be paying for advanced capabilities you rarely use.
You want faster, easier onboarding: Non-technical testers like designers, PMs, or clients may benefit from a tool with a more intuitive setup and smoother learning curve.
You need an adaptable, exploratory testing tool: While TestMonitor is built for formal, process-driven testing, some teams need a platform that supports more hands-on, evolving testing sessions.
You prefer a lightweight, checklist-based approach: For some teams, documenting every detail can feel like extra overhead. A more streamlined tool focused on practical test execution may offer just enough structure without slowing you down.
You’re looking for smart value at scale: Small teams or startups often benefit from tools with flatter, scalable pricing models or usage-based tiers that deliver strong value without enterprise-level costs.

8 best TestMonitor alternatives

Here’s a look at some of the best alternatives to TestMonitor – each offering its own blend of features, simplicity, and pricing.

Tool	Free trial	Basic plan price per year	Business plan price per year	Price per 10 users per month
TestMonitor	14 days	$396 (Personal)	$4,788	$399
TestRail	30 days	$4,200 (Professional)	$8,520 (Enterprise)	$370
PractiTest	14 days	$4,680	$5,880	$390
QMetry	15 days	Contact sales	Contact sales	Contact sales
Tuskr	30 days	$900	$1,500	$75
Zephyr	30 days	Contact sales	Custom	Contact sales
Testmo	21 days	$1,010 (Team)	$4,070 (up to 25 users)	$99
TestLink	Free (open-source)	Free (self-hosted)	Free (self-hosted)	Free
Testpad	30 days	$588 (Essential, 3 testers)	$1,188 (Team, 10 testers)	$99

TestRail

TestRail is a widely used test case management tool designed to help teams organize, execute, and track their testing efforts smoothly. It offers organized workflows, detailed reporting, and strong integration options.

Key features

Test runs and result tracking: Maintain detailed records of test executions and outcomes
Jira and CI/CD integrations: Connect easily with development and automation tools
Versatile API: Extend functionality or customize integrations to fit team needs

How it compares with TestMonitor

TestRail is a better fit for teams focused on test case organization and automation workflows. While TestMonitor centers on risk-based planning and milestone tracking, TestRail offers stronger integrations and is often preferred by teams combining manual and automated tests.

Pricing

Starts at $37/user/month; 14-day free trial available

Pros

Comprehensive feature set
Strong, customizable reporting

Cons

Can be costly, especially as teams scale
Steeper learning curve for new users

PractiTest

PractiTest is a test management platform offering centralized control across all QA activities. It’s designed for teams seeking real-time insights, adaptable workflows, and detailed traceability.

Key features

Live dashboards: Monitor progress and results across projects in real time
Custom workflows: Tailor the platform to match your QA processes
Strong traceability: Connect requirements, tests, and defects seamlessly

How it compares with TestMonitor

PractiTest offers greater customization and centralized management, whereas TestMonitor emphasizes formal, risk-aware testing. PractiTest’s adaptability is a win for teams managing varied QA efforts, though its setup can be more involved.

Pricing

Starts at $49/user/month; 14-day free trial

Pros

Excellent customization options
Powerful reporting and dashboards

Cons

Higher cost, especially for larger teams
More complex initial setup

QMetry

QMetry is a test management platform built for enterprise teams that rely heavily on automation, analytics, and CI/CD. Its AI-powered features help teams fine-tune their testing strategy and improve outcomes.

Key features

Advanced analytics and predictive insights: Drive decisions with actionable data
Seamless CI/CD integration: Plug into DevOps pipelines for automated testing
Scalable architecture: Handle complex, enterprise-scale testing needs

How it compares with TestMonitor

QMetry emphasizes automation and data-driven insights, making it ideal for large enterprises. In contrast, TestMonitor’s strengths lie in manual testing, formal reporting, and risk tracking.

Pricing

Pricing available upon request

Pros

Enterprise-ready scalability
Strong automation and integration capabilities

Cons

Complexity may overwhelm smaller teams
Opaque pricing

Tuskr

Tuskr is a budget-friendly test management tool built for small to mid-sized teams that want an efficient way to handle manual testing, without unnecessary extras.

Key features

Straightforward test case creation and management: Quickly set up and organize tests
Integrations with bug trackers: Connect easily to issue-tracking tools
Clean, intuitive interface: Designed for fast onboarding and minimal friction

How it compares with TestMonitor

Tuskr focuses on affordability and ease, appealing to smaller teams, while TestMonitor provides more formal, process-driven features suited for regulated or larger environments.

Pricing

Starts at $9/user/month; free tier available

Pros

Very affordable pricing
Easy to use, even for non-technical testers

Cons

Fewer advanced features
Limited customization compared to larger tools

Zephyr

Zephyr is a Jira-native test management tool tailored for agile teams. It delivers real-time tracking, insightful dashboards, and seamless Jira integration, making it a natural fit for teams already embedded in the Jira ecosystem.

Key features

Real-time test tracking and dashboards: Keep stakeholders informed instantly
Deep Jira integration: Work directly inside familiar agile workflows
Agile lifecycle support: Align test activities tightly with sprint cycles

How it compares with TestMonitor

Zephyr’s biggest strength is its Jira-native design, perfect for teams committed to Jira. TestMonitor, by contrast, offers broader platform independence and formal risk management features.

Pricing

Pricing available upon request from sales team

Pros

Excellent Jira integration
Strong analytics for agile teams

Cons

Pricing can add up for larger teams
Best suited only for Jira-based environments

Testmo

Testmo is a unified test management platform supporting both manual and automated testing. It’s designed as a central hub where teams can track all testing activities across workflows.

Key features

Unified manual + automated testing: Manage all testing types under one roof
CI/CD and automation tool integrations: Connect easily to DevOps pipelines
Structured reporting: Get strong visibility into test coverage and progress

How it compares with TestMonitor

Testmo is designed for teams blending manual and automated work, while TestMonitor focuses more on manual, risk-based tracking. Testmo’s integration breadth makes it appealing for automation-heavy teams.

Pricing

Starts at $99/month for up to 10 users; 21-day free trial

Pros

Strong support for mixed testing strategies
Competitive pricing for larger teams

Cons

Limited customization for reports
Setup complexity for mixed environments

TestLink

TestLink is an open-source test management tool offering core functionality for managing test cases and tracking execution, which is ideal for technically savvy teams seeking a no-cost solution.

Key features

Open-source platform: Fully free to use, with customizable codebase
Core test case management: Plan, execute, and track test cases
API access: Extend or integrate with in-house tools as needed

How it compares with TestMonitor

TestLink provides a basic, no-frills alternative best suited for technical teams, while TestMonitor delivers polished dashboards, risk management, and structured oversight out of the box.

Pricing

Free (self-hosted open-source)

Pros

No licensing costs
Highly customizable with technical resources

Cons

Outdated interface
No official support; requires technical expertise

Testpad

Testpad offers a deliberately pragmatic approach to test management, designed for real-world teams that want clarity without extra process overhead. Instead of locking teams into rigid test-case structures, Testpad’s intuitive, checklist-driven system lets them draft, revise, and run tests faster, more smoothly, and with fewer barriers.

Whether you’re a startup, an agile team, or a non-technical group stepping into testing, Testpad’s modern design makes it easy to set up, execute, and manage tests without the baggage of process-heavy tools.

Testpad's features for test management

Testpad takes a more hands-on approach to testing. It strips away the overhead of traditional test-case formats and gives teams a straightforward way to plan and run tests. Here’s what those features look like in practice:

Checklist-driven testing: Write and organize tests as keyboard-friendly checklists. It’s easy to build out or tweak plans as things shift.
Fast, intuitive setup: The interface is clean and responsive, so teams can get started without tutorials or drawn-out onboarding.
Easy collaboration: Need feedback from clients or non-technical teammates? Invite guest testers (no logins required) to participate in exploratory or user acceptance testing (UAT).
Plans that scale with you: Start broad or go deep. Testpad lets you work top-down or step-by-step depending on the level of detail your team needs.
Clear visibility: Track progress in real time and share updates without needing custom dashboards or extra configuration.

Why choose Testpad over TestMonitor or similar tools?

While TestMonitor is built for formal, process-driven testing with advanced documentation and risk tracking, Testpad focuses on speed, adaptability, and ease of use.

Testpad is a good match for teams that want clarity without extra process overhead. It’s especially useful when:

You need flexibility without complexity: The checklist-driven format makes it easy to adapt test plans on the fly, without managing rigid test-case structures.
You work in fast-paced, agile environments: Teams can keep up with shifting priorities and evolving features without slowing down testing.
You involve non-technical collaborators: From PMs to clients, anyone can contribute to testing without needing logins, training, or onboarding.
You’re running UAT or exploratory testing: Built-in guest access and a lightweight setup make it easy to share test runs and collect feedback.
You’re growing and need smart value: Scalable pricing gives small and mid-sized teams room to grow without locking them into enterprise-level tools.

Pricing

Testpad offers scalable plans that fit a variety of team sizes:

Essential: $49/month for 3 users
Team: $99/month for 10 users (full feature access)
Team 15: $149/month for 15 users
Department: $249/month for 25 users

Custom enterprise plans are available for teams that need more seats or prefer to pay by invoice. All plans come with a 30-day free trial so you can explore the platform before committing.

Compared to TestMonitor’s per-seat pricing (which can add up quickly for small or growing teams), Testpad delivers smart, scalable value, giving you the right mix of features without paying for bloated enterprise tools you might not need.

Thanks to its intuitive design, minimal administrative burden, and guest testing capabilities, Testpad remains a favorite among non-technical and cross-functional teams, making collaborative testing accessible to everyone – not just QA pros.

Finding clarity in your test management approach

There’s no perfect, one-size-fits-all solution.

The right test management tool is the one that matches your team’s pace and priorities. Do you need formal traceability and structured workflows? Or do you need a fast, pragmatic system to capture and run tests without adding complexity?

TestMonitor offers plenty of strengths, especially for teams needing detailed risk tracking, dashboards, and milestone oversight. But if the cost, integrations, or setup feel too heavy for your needs, alternatives like Testpad deliver a simpler, more adaptable fit.

Want more real-world testing tips and tools in your inbox? Sign up for our mailing list to stay in the loop on practical resources, product updates, and new ways teams are approaching test management.

FAQs

What makes Testpad different from TestMonitor?

Testpad focuses on simplicity and speed, using checklist-based test management to avoid the heavy structure of traditional test case tools. While TestMonitor offers formal risk tracking, detailed documentation, and dashboards, Testpad delivers a lightweight, flexible alternative that’s easy for both technical and non-technical users.

Is Testpad suitable for automation?

Testpad is primarily designed for manual and exploratory testing. It doesn’t include built-in automation frameworks, but many teams use it alongside their automated tests for coverage tracking, UAT, or exploratory testing where human judgment is key.

How does Testpad handle reporting?

Testpad offers real-time progress tracking and instant, shareable reports. You can generate links for stakeholders, export reports, or print detailed summaries to keep everyone aligned, without needing to configure complex dashboards or custom templates.

What teams get the most value from Testpad?

Testpad works well for small-to-midsize teams, agile groups, and startups that want a straightforward way to manage testing. Its accessible interface and guest access make it easy for anyone, technical or not, to participate, which is especially helpful for user acceptance testing (UAT).

How secure is Testpad?

Testpad uses secure, cloud-based infrastructure to keep your data safe. We’re SOC 2 Type 2 certified and our security pages outline the details. For teams with specific security requirements, we’re happy to discuss further.

Can Testpad integrate with bug trackers or CI tools?

Yes. While Testpad keeps its core interface simple, it offers lightweight and flexible workflows that can connect with tools like Jira or GitHub for bug tracking and workflow coordination. If you need specific integrations, the Testpad team can advise on setup.

How to use ChatGPT to write better test scripts in Testpad

Stefan Butlin — Mon, 12 May 2025 00:00:00 +0000

People are uncovering the potential of AI tools to transform their workflows from laborious processes into ready-to-go test scripts. ChatGPT can help you move faster and catch things you might have missed. When paired with a checklist tool like Testpad, it’s a perfect fit.

Using AI tools like ChatGPT can generate test scenarios in seconds – and when you feed it clear product requirements, user stories, or bug reports, those scenarios slot straight into Testpad’s checklist format, making your whole testing process smoother and more thorough.

ChatGPT: Your partner for better test ideas

Coming up with test scripts can be a bit of a chore. That’s where ChatGPT shines. AI tools like ChatGPT can generate dozens of scenarios in seconds, suggest edge cases you might not have considered checking for, and draw from an endless pool of software knowledge. Not only does this save you time, it also delivers better, more complete test coverage than you’d get doing it all yourself.

Before diving in with complex prompts, start with these basic prompts to get familiar with how AI can help your testing process:

"What are all the ways the login feature could fail?"

"What edge cases should we test for multi-factor authentication?"

"Generate test scenarios for the shopping cart, considering different user roles."

Give ChatGPT what it needs to help you

Great input = great output. The more context you give, the better your test ideas will be. Think of AI like a new team member who needs to be brought up to speed. Providing specific information leads to more useful and targeted test scripts rather than generic suggestions.

Here's what to feed ChatGPT:

Product requirements docs

Tell it what your product does and what matters most.
Prompt: "Based on this PRD, generate Testpad-ready test prompts for user onboarding."

User stories

Explain who the feature is for and why it matters.

Prompt: "Using this user story about password reset, generate test scenarios that match the acceptance criteria."

Bug reports

Use ChatGPT to write regression tests and sniff out similar risks.

Prompt: "Here’s a bug we fixed in form submission. Write regression test prompts to make sure it doesn’t happen again."

Existing test scripts

Improve what you already have. Identify gaps, expand coverage, and enhance quality.

Prompt: "Here’s our current auth test script. Suggest additional prompts for better coverage."

Heads up – remember to be mindful of your AI settings if you're concerned about your documentation being used to train the model for others' benefit.

More ways to use AI for testing

ChatGPT isn’t just for test scripts. It’s great for:

Expanding test coverage

Prompt: "Here are my current test prompts. Suggest edge cases and overlooked scenarios."

Updating old test cases

Prompt: "These test cases are from 2020. Modernize them for today’s devices and browsers."

Risk-based prioritization

Prompt: "Which of these test prompts cover the riskiest areas of the product?"

Cutting redundancy

Prompt: "Review this test plan and identify duplicate or redundant prompts."

AI helps you test smarter – not harder.

Remember: Humans are needed

ChatGPT is undeniably fast, but it's not a magical solution. The human element in testing remains crucial for contextual understanding and adaptability. While automation and AI have their place, manual and exploratory testing bring the human perspective that can spot issues an algorithm might miss.

Always:

Review what it generates
Tweak the wording to match your style
Check for context misses or weird assumptions
Trim irrelevant or overly generic ideas
Add your team's expertise and domain knowledge where AI suggestions fall short

AI serves as your assistant – providing useful suggestions and efficiency – but cannot replace the nuanced judgment and adaptability of an experienced tester.

Manual testing allows you to adapt during the testing process when you encounter unexpected behaviors – exactly why we think exploratory testing is the best kind of testing.

Why ChatGPT + Testpad are a great match

Testpad's flexible checklist format creates a seamless bridge between AI-generated content and practical testing execution – marrying machine efficiency with human testing precision.

You don’t need fields for preconditions, steps, or expected results.
Just write what to test – not how.
Copy. Paste. Ready to test.

To get the right format from ChatGPT, try this prompt:

"Please format your test scenarios as a simple checklist with one test idea per line, use indentation for sub-items, avoid bullets or numbering, and use short direct phrases."

Here’s what the output should look like:

Formatting tips:

One test idea per line
Indent for sub-items
No bullets or numbering
Use short, direct phrases
Avoid “verify that” or “check if”

Start small, learn fast

The best way to get value from ChatGPT in testing is to try it.

Pick one feature, one test script and experiment with ChatGPT on a small scale. Copy the output into Testpad or your testing tool – then tweak it, run it, and learn from it.

When you combine AI's speed and scope with Testpad's simplicity and flexibility, you get not just faster test script creation, but higher-quality testing with broader coverage and fewer bugs slipping through the cracks. This creates a more effective and efficient testing process.

If you’re ready to see how Testpad can support your testing efforts, visit our website to learn more or sign up for a 30-day free trial. Happy testing!

Why your test reports must show what works

Stefan Butlin — Wed, 30 Apr 2025 00:00:00 +0000

Test reports tend to focus on the problems. They’ll show you the bugs, the failures, maybe a percentage or two about what passed – and that’s useful. But it’s only half the picture.

To really understand how your software is doing, you also need to show what’s working. Otherwise you're making decisions with incomplete information – seeing the obstacles but missing the clear path forward.

Why it's not enough to just report the bugs

There’s nothing wrong with highlighting what’s broken – that’s part of the job. But if your report is just a list of bugs, it’s not telling the whole story. It can make things look worse than they are – like everything’s broken when most of it works fine.

Or worse, it can make things look fine when they’re not. One lonely defect might seem minor, but if it’s a critical failure in a key feature, you’ve got a serious problem hiding in plain sight.

Bug-only reporting can:

Skew your sense of progress – in either direction
Make it harder to prioritize fixes or spot gaps in testing
Leave teams demoralized and stakeholders second-guessing

And if you’re working with outsourced testers who only report bugs (especially if they’re paid per bug), you’re left wondering: what did they actually test? Did they cover everything? Or just log the broken bits?

Why showing what works matters

If you only report what’s broken, your team and your stakeholders are flying blind. Showing what works isn’t a nice-to-have. It’s how you steer releases with confidence and keep everyone on the same page.

Some people call this "verified functionality" – meaning the features or behaviors that were tested and found to be working. While the terminology is technically precise, it's worth simplifying. Essentially, it just means showing what passed, not just what failed.

It builds real confidence in your release

You can’t greenlight a release just by looking at a list of bugs. You need to know what’s been tested, what passed, and what’s still untested. Without that, you’re guessing. Being able to say, “Yes, this feature was tested and worked as expected” gives teams and stakeholders real assurance. It’s about replacing gut feelings with evidence.

It helps prevent embarrassing post-release bugs

Every team has encountered the inevitable support ticket: “I just found a bug in [really obvious feature].” If your test report only lists what failed, you have no idea whether that feature was ever tested in the first place. By documenting what was tested and passed, you reduce the risk of gaps in coverage and prevent easily avoidable mistakes from reaching production.

It provides an audit trail for critical environments

In some industries – finance, healthcare, anything with legal or safety compliance – you don’t just need to test; you need to prove that you tested. Regulators don’t want a vague list of bugs. They want evidence that all critical systems were checked and worked correctly at the time of testing. Showing what passed is essential for demonstrating due diligence and traceability. Knowing what broke isn’t enough. You need a clear, documented record of what worked.

It helps teams focus their efforts

When test reports include what worked, testers don’t waste time retesting already-stable features. Instead, they can focus on high-risk areas, untested functionality, or complex scenarios that require more attention. This targeted approach makes better use of everyone’s time – and makes it easier to prioritize when testing time is limited.

It gives everyone a clearer picture of progress

Showing what’s working does more than track success. It tells you how far along you are. If 80% of tests have passed, and 20% are still being written or executed, that tells you something meaningful. Just listing bugs doesn’t give that kind of directional insight. When reports highlight verified functionality, they help teams visualize real progress, not just problems.

It makes communication easier

Developers, PMs, execs – everyone wants to know: “How are things looking?” When you can show what was tested and what passed, the conversation shifts from firefighting to strategic planning. It’s no longer about whether there are bugs (there always are), but about whether the important stuff is working.

It keeps everyone aligned

Test reports that clearly show what was tested, what worked, and what didn’t help teams stay aligned on priorities. You avoid duplicated efforts, misunderstandings, and mismatched assumptions about what’s ready to go.

Bottom line: reporting what worked – what was tested and passed – doesn’t just make your reports more complete. It makes your whole development process more efficient, transparent, and demonstrably reliable.

A quick word on RTMs

If you’ve worked in compliance-heavy industries, you’ve probably come across Requirements Traceability Matrices (RTMs). These tools are designed to track which requirements have been tested – and they’re often used to demonstrate due diligence in regulated environments.

They can be helpful, but they’re not the full story.

RTMs can:

Be time-consuming to maintain
Create a false sense of completeness ("we tested all the requirements" doesn’t mean the app actually works well)
Discourage testers from exploring beyond what’s written down

In other words, RTMs might check the boxes, but they don’t always reflect real-world quality. That’s why it’s so important to supplement formal requirement tracking with clear, contextual reporting that shows what was actually tested and what worked. Even in the most process-heavy environments, reporting needs to go beyond traceability to tell the whole testing story.

Your testing style makes a difference

It’s important to understand that your ability to report clearly on what was tested – and what worked – is closely tied to the way you approach testing in the first place. Some testing styles make it easier to capture meaningful results than others. That’s why choosing the right style of testing isn't just a technical choice. It directly impacts what your test reports can (and can’t) show.

Traditional test case management

You might recognize this approach: fully-scripted test cases, executed step-by-step, marked as pass or fail. It's the classic model of traditional test case management – great for producing clean, auditable reports. But when it comes to actually finding bugs, it can fall short. Sticking rigidly to scripts leaves little room for exploring unexpected issues. It’s neat and orderly, but not always the most insightful.

Exploratory testing

On the other end, you’ve got pure exploratory testing. Testers roam through the product and note what they find. It’s great at uncovering unexpected problems, but documentation can be patchy. What did they try that worked? Depends on what they wrote down.

Testpad’s approach: Pragmatic exploratory testing

We think the best kind of testing uses a pragmatic approach. Testers work from a list of prompts – ideas to try, grouped by feature or scenario. Each prompt is a chance to explore and spot any unknowns. Testers record simple pass/fail results, with notes or bug IDs if needed.

The result? You get the best of both worlds:

The freedom to find real bugs
A clear record of what was tested and what worked

Real-time reporting: Don’t wait for the end

A test report shouldn’t be something you throw together right before your stakeholder meeting. Ideally, it’s a live, evolving document that anyone on the team can check in with at any time.

That way:

Issues can be spotted (and fixed) faster
Testers know what’s already covered (and don’t waste time redoing it)
Stakeholders get visibility into what’s working, what’s not, and what’s left to do

Tools like Testpad are built for this kind of workflow. You can see results as they’re added – with prompts, pass/fail marks, notes and issue references – all in a simple, scannable format. It’s not complex visualizations and elaborate multi-page reports. It’s just the info you need, right when you need it.

What a good test report should include

To make your test reporting genuinely useful, make sure it:

Shows what was tested
Includes both what worked and what didn’t
Is updated regularly, not just at the end
Is easy to read and interpret – even for non-technical folks

If your current reports only tell you what’s broken, they’re not giving you the full picture. By showing what works, you make better decisions, reduce unnecessary work, and help everyone feel a little more in control.

It’s not too much information

Sometimes people worry that showing all test results will be overwhelming. But actually, if presented well, it’s the opposite.

Imagine a dashboard:

Green check marks where things passed
Red crosses where problems were found
Gray for things not yet tested

You instantly get a feel for the health of the product. You can spot problem areas, see what’s been covered, and where testing is still needed. Far from being too much, it’s exactly the right amount of clarity.

Testpad makes that kind of reporting effortless

Test reporting shouldn’t just be about counting bugs. And it shouldn’t stop at pass/fail stats either. The real job of a test report is to tell the story of testing – what was looked at, what worked, what didn’t, and what still needs checking.

If you’re only reporting what went wrong, you’re missing most of that story. Show what was tested. Show what worked. Your stakeholders, your team, and your future self will thank you.

With the right approach to testing documentation, this kind of clear, comprehensive reporting becomes straightforward. Testpad was designed specifically to solve this challenge – experience how it transforms your testing workflow with a 30-day free trial.

9 Best Xray Alternatives for Simplified Test Management

Stefan Butlin — Wed, 16 Apr 2025 00:00:00 +0000

Xray Test Management is known for its comprehensive features and Jira integration. It may work for teams heavily invested in Jira’s ecosystem, but its complexity isn't for everyone.

Teams that value simplicity, flexibility, and pragmatism may find other tools better suited.

Luckily, the market is full of alternatives. From intuitive, checklist-driven approaches to tools designed specifically for agile workflows, there's no shortage of options to suit different styles of testing and team needs.

What is Xray Test Management?

Xray Test Management is a Jira-native application built to streamline complex test case management, version control, and agile integration. As part of the Jira ecosystem, Xray enhances Jira’s core functionalities by enabling detailed visibility into testing processes, outcomes, and related issues.

Key features of Xray Test Management

Full Jira integration: Xray seamlessly plugs into Jira, leveraging familiar workflows and providing deep integration with issue tracking and agile project management tools.
End-to-end test lifecycle management: Covers the entire spectrum of test activities from planning and execution to monitoring and reporting, keeping every step of testing transparent and traceable.
Traceability between tests, requirements, and defects: Offers clear mapping between user requirements, executed tests, and identified bugs, ensuring comprehensive traceability throughout the development cycle.
Advanced reporting and analytics: Provides detailed dashboards and analytics, enabling stakeholders to visualize test progress, pinpoint risks, and make informed decisions.
Manual and automated test management: Supports both manual testing processes and integration with automation frameworks, facilitating flexible testing approaches for various project needs.

Use cases and benefits

Xray excels in large, agile-focused teams and enterprises already committed to Jira. Its advanced traceability and reporting features are particularly beneficial in highly regulated industries (like finance or healthcare) or for complex projects where documentation and audit trails are non-negotiable.

Teams deeply familiar with Jira benefit from Xray’s seamless integration, ensuring minimal disruption to established workflows. Xray is powerful, structured, and robust – qualities that suit large-scale, complex development environments.

Pain points and limitations

Despite its strengths, Xray isn’t ideal for every team or scenario. Common challenges include:

Steep learning curve: Smaller teams or those unfamiliar with Jira often find Xray challenging to adopt, requiring significant time and training to achieve proficiency.
Pricing complexity and hidden Jira-related costs: Xray’s pricing structure, tied closely to Jira licensing, can become complicated and unpredictable, particularly for budget-conscious teams.
Overwhelming interface: The extensive feature set, while beneficial for large-scale projects, can feel unnecessarily complicated or cumbersome for smaller teams and straightforward testing scenarios.

Criteria for choosing an Xray alternative

When evaluating test management tools as alternatives to Xray, keep these key factors in mind:

Ease of use: A test management solution should be intuitive, enabling testers to easily create, run, and maintain tests without needing extensive onboarding or ongoing training.
Integration capabilities: Good integration with your existing tools (including development frameworks, bug trackers, and CI/CD systems) ensures smooth workflows and minimal disruption.
Flexibility: Look for adaptability – your test management tool should accommodate changes to testing strategies, project scopes, and team structures without friction.
Pricing: Clear, transparent pricing helps teams budget accurately, with scalability options that adjust to team size or changing requirements.
Support: Responsive customer support, comprehensive documentation, and an active user community can significantly enhance the tool’s long-term value and usability.

9 Best Xray test management alternatives

There’s no one-size-fits-all in test management – tools that feel like a lifeline for one team can feel like a headache for another. Xray offers powerful Jira integration and comprehensive features, but if its complexity outweighs its advantages, looking into alternatives might make sense.

Below are a few solid alternatives to Xray, each with its own strengths, drawbacks, and unique spin on test management.

Tool	Free trial	Basic plan price per year	Business plan price per year	Price per 10 users per month
Xray Test Management	30 days	Jira-dependent (from $1,000+)	Custom (Jira-dependent)	$200+
BrowserStack	Free tier	From $468 (manual)	From $2,388 (automation)	$390
Zephyr Enterprise	30 days	Contact sales	Custom	Contact sales
Tricentis qTest	14 days	$12,000	Custom	$1,000
PractiTest	14 days	$4,680	$5,880	$390
TestLink (Open-source)	Free (open-source)	Free (self-hosted)	Free (self-hosted)	Free
OpenText ALM	Contact sales	Custom pricing	Custom pricing	Custom
QMetry Test Management	15 days	Contact sales	Contact sales	Contact sales
Tuskr	30 days	$900	$1,500	$75
Testpad	30 days	$588 (Essential, 3 testers)	$1,188 (Team, 10 testers)	$99

1. BrowserStack

BrowserStack specializes in running tests across multiple browsers and real devices. It’s particularly suited to teams that need to ensure their applications behave consistently, no matter where they're accessed.

Key features:

Real device and browser cloud testing: Quickly run tests on actual devices without needing physical hardware in your office.
Automated and visual testing integration: Supports automation frameworks (like Selenium) and helps you easily spot visual differences in your UI.
Accessibility and performance testing: Identifies accessibility issues and helps optimize site speed and performance.

How it compares with Xray:

Unlike Xray, BrowserStack best suits teams whose main priority is consistent cross-browser experiences rather than comprehensive Jira-based traceability. Teams already comfortable with Jira and primarily needing internal workflow management might lean toward Xray, whereas those prioritizing cross-browser testing might prefer BrowserStack.

Pricing:

Manual testing plans from $39/month; automation plans from $199/month
Custom enterprise pricing available

Pros:

Extensive device and browser testing
Strong automation capabilities

Cons:

Might offer more features than teams with simpler testing needs require
Can become pricey quickly, especially for smaller teams

2. Zephyr Enterprise

Zephyr Enterprise is a Jira-friendly test management solution offering detailed insights and analytics across the testing lifecycle.

Key features:

Real-time dashboards: Provides at-a-glance views of test status, progress, and bottlenecks.
Comprehensive lifecycle tracking: Manages test cycles from initial planning to completion.
Advanced analytics and reporting: Robust reports help stakeholders quickly understand test outcomes and potential risks.

How it compares with Xray:

Zephyr and Xray share similar ground, both fitting neatly into Jira ecosystems. Zephyr suits Jira teams who prefer clear, digestible dashboards rather than the granular complexity of Xray.

Pricing:

Custom pricing (contact sales)

Pros:

Excellent reporting clarity
Smooth Jira integration

Cons:

Pricing isn’t clear upfront, making budgeting tricky
Initial setup could be complicated

3. Tricentis qTest

Tricentis qTest caters specifically to agile teams that need to rapidly develop and adjust test cases alongside changing project requirements.

Key features:

Agile-focused test case management: Easily adaptable test plans designed to keep pace with iterative sprints.
Advanced bug tracking: Streamlined issue tracking within testing cycles.
Detailed execution reports: Provides actionable insights on test progress and issues.

How it compares with Xray:

Tricentis qTest and Xray both work well for agile workflows. However, qTest specifically emphasizes flexibility and rapid adjustments in agile environments. Xray’s robust Jira integration may offer more depth for Jira-centric teams, while qTest could feel lighter and more flexible for those who want fewer Jira dependencies.

Pricing:

From $1,200/user/year
Free trial available

Pros:

Strongly suited to agile teams
Scalable for larger organizations

Cons:

Cost may be prohibitive for smaller teams
Complex interface could slow down adoption

4. PractiTest

PractiTest offers a centralized solution for managing QA activities, aiming to simplify testing processes with clear visibility and customizable workflows.

Key features:

Real-time dashboards and reporting: Keeps stakeholders in the loop with accessible reports and dashboards.
Highly customizable workflows: Adapts easily to specific QA processes and team needs.
Broad integration options: Seamlessly connects with existing project management and CI/CD tools.

How it compares with Xray:

PractiTest is particularly useful for mid-sized teams or organizations that want centralized QA management without relying on Jira. PractiTest’s approachable interface and adaptable workflows may appeal more to teams not fully committed to the Jira ecosystem, or those who simply prefer less complexity in their testing.

Pricing:

From $39/user/month
14-day free trial available

Pros:

User-friendly, customizable interface
Excellent reporting capabilities

Cons:

Enterprise plans can quickly become costly
Initial setup and customization may take some time to fully optimize

5. TestLink

TestLink is an open-source test management application ideal for teams comfortable maintaining their own installations.

Key features:

Free, open-source licensing: Fully open-source, TestLink allows teams complete flexibility to customize and tailor the platform to specific workflows.
Basic test case management: Provides core functionality to create, manage, and execute test cases, covering essential testing needs without unnecessary complexity.
Customizable through open APIs: Teams can extend functionality and integrate TestLink with other internal tools and systems through available APIs.

How it compares with Xray:

Unlike Xray, TestLink doesn't offer extensive Jira integrations out of the box. However, it provides foundational test management at no cost, making it appealing to teams comfortable with handling their infrastructure. If Xray’s cost and complexity pose issues – and your team has the technical expertise – TestLink could offer a simpler, cost-effective alternative.

Pricing:

Free (open source)

Pros:

No licensing costs; ideal for budget-conscious teams
Highly customizable for teams with specific requirements

Cons:

Limited official support means reliance on community help and self-troubleshooting
Outdated user interface can make usability a challenge

6. OpenText Application Quality Management

Formerly known as Micro Focus ALM, OpenText Application Quality Management is an enterprise-level platform designed for complex projects, especially in regulated industries.

Key features:

Comprehensive ALM functionality: Manages the entire application lifecycle from requirements gathering to testing and deployment.
End-to-end traceability: Detailed tracking and documentation provide thorough visibility and auditability, which is essential for regulatory compliance.
Built for large enterprises: Offers robust security, integrations, and scalability required by sizable teams and highly regulated industries.

How it compares with Xray:

OpenText Application Quality Management is built for similar large-scale, regulated environments as Xray. However, it is even more heavily geared toward complete ALM processes rather than just testing. Smaller teams or agile-focused groups may find OpenText’s solution even more complex and expensive compared to Xray.

Pricing:

Custom pricing (contact sales)

Pros:

Excellent fit for highly regulated industries (e.g., healthcare, finance)
Strong security features and integrations for complex enterprise setups

Cons:

Expensive and potentially cost-prohibitive for smaller teams
Complexity and steep learning curve require significant onboarding resources

7. QMetry Test Management

QMetry is an enterprise-level test management tool known for its advanced analytics, AI-enhanced capabilities, and deep integrations within the ALM space.

Key features:

Advanced analytics and reporting: Offers powerful reporting and visual analytics to provide stakeholders granular visibility into testing processes.
Strong CI/CD integrations: Integrates seamlessly with popular continuous integration and delivery tools, simplifying automation and pipeline workflows.
AI-enhanced features: Leverages artificial intelligence for predictive analytics and enhanced reporting, aiming to optimize testing strategies.

How it compares with Xray:

QMetry and Xray share a strong emphasis on integration and reporting. However, QMetry differentiates itself through explicit AI capabilities and deeper CI/CD integration options. Teams looking for advanced, predictive analytics and automated insights might find QMetry more attractive than Xray, but smaller teams might find both tools similarly overwhelming.

Pricing:

Custom pricing (contact sales)

Pros:

Strong integration capabilities ideal for automation-focused teams
Advanced analytics and AI-driven features to enhance reporting accuracy

Cons:

Complexity might exceed what smaller teams require
Non-transparent pricing structure can make budgeting difficult

8. Tuskr

Tuskr positions itself as a budget-friendly test management solution suitable for small to medium-sized teams that need basic yet effective test management without overspending.

Key features:

Easy test case management: Simple interface for creating, executing, and managing test cases, helping teams quickly get started with minimal training.
Integrations with bug trackers: Connects directly to popular bug-tracking software, streamlining the issue management process.
Intuitive interface: Clean, straightforward user experience aimed at smaller teams or those new to dedicated test management tools.

How it compares with Xray:

Tuskr's primary advantage over Xray is its affordability and simplicity. Smaller teams or those new to test management tools might find Tuskr more accessible and less intimidating. While it lacks the extensive integrations and complex lifecycle management that Xray provides, its simplicity and lower price point can be highly appealing.

Pricing:

Plans from $9/user/month
Free tier available

Pros:

Very competitive pricing makes it accessible for small to medium-sized teams
User-friendly, straightforward interface reduces learning curve

Cons:

Limited advanced functionalities may not suit complex projects
Customization and flexibility may be limited compared to other, pricier solutions

9. Testpad as an alternative to Xray

Testpad offers a deliberately straightforward approach to test management by using intuitive checklists instead of complex test-case hierarchies. It’s intentionally designed to strip away unnecessary complexity, enabling any team member – technical or not – to quickly grasp the state of your software.

How Testpad compares to Xray

Both Testpad and Xray share the goal of supporting effective test management, but each takes a distinctly different approach. Xray provides extensive Jira integration, detailed traceability, and deep feature complexity, which suits highly regulated industries and larger teams. Testpad, on the other hand, deliberately streamlines testing to focus on clarity and ease of use, eliminating unnecessary complexity.

Where Xray prioritizes comprehensive lifecycle management and robust integration within Jira, Testpad emphasizes simplicity, rapid onboarding, and practical features designed specifically to enhance productivity without steep learning curves. For a full side-by-side, see Testpad vs Xray.

Key features of Testpad

Checklist-based interface: Intuitive checklists make test creation and execution straightforward, avoiding the need for complex test-case structures and excessive documentation.
Quick keyboard-driven test writing: Write and edit tests quickly using keyboard shortcuts – ideal for agile teams who need to adapt tests rapidly during sprints.
Instant, shareable progress reports and real-time tracking: Stakeholders and team members can quickly understand testing progress through clear, immediate reporting – no complex dashboards or elaborate setup required.
Easy collaboration with guest testers: Allows stakeholders and external users to participate without needing accounts or logins, simplifying user acceptance testing (UAT).

Ideal use cases for Testpad

Testpad excels for teams that value straightforward, practical testing processes:

Small to medium-sized teams: Cost-effective pricing and intuitive design make Testpad ideal for smaller teams looking to step away from spreadsheets or complex test tools.
Agile projects: Agile teams benefit from flexible, adaptable test plans that effortlessly match iterative development cycles.
User acceptance testing (UAT): Quick onboarding for non-technical stakeholders and guest testers streamlines UAT processes significantly.
Rapid project turnarounds: Immediate usability ensures your team can jump straight into testing, crucial for tight deadlines and fast-paced delivery cycles.

Pricing

Testpad offers affordable pricing with plans designed to scale based on team size:

Essential: $49/month for 3 testers
Team: $99/month for 10 testers
Custom plans: Available upon request
30-day free trial: Available to evaluate fit and usability

Testpad offers clear, predictable pricing designed to scale with your team, compared to Xray’s Jira-dependent pricing structure, which can fluctuate based on Jira license requirements.

Finding clarity in your test management approach

When evaluating test management tools, consider which factors genuinely matter to your team: Do you value comprehensive Jira integrations, or would simplicity better serve your workflows? Reflecting honestly on your team’s actual testing needs – rather than aspirational complexity – can clarify your choice.

If Xray’s complexity seems more than your team realistically needs, exploring simpler, checklist-based options like Testpad might be worthwhile. A free 30-day trial can help teams quickly see if it’s a good fit.

FAQs

What differentiates Testpad from Xray?

Testpad uses a checklist-based approach designed for simplicity and easy adoption, compared to Xray’s more comprehensive and Jira-centric design.

Is Testpad suitable for automated testing?

Testpad primarily focuses on manual test management. ~~An API for integrating automated test results is currently under development~~ The API now supports this, including webhooks, so teams can complement their manual tests with automation.

Can Testpad handle User Acceptance Testing?

Yes. Testpad’s guest testing feature enables non-technical users and stakeholders to participate easily in User Acceptance Testing without needing an account.

How secure is Testpad?

Testpad maintains robust security measures, including HTTPS/TLS encryption, encrypted data storage, hourly backups, regular penetration testing by external security experts, and strict firewall protections – ensuring your data stays safe and secure.

Does Testpad support integrations with bug-tracking tools?

Yes. Testpad integrates smoothly with popular bug-tracking systems, including Jira, GitHub, GitLab, and more – streamlining your test-to-issue workflows.

How does Testpad's pricing compare with Xray?

Testpad offers transparent, affordable pricing starting at $49/month, scaling predictably with team size. By comparison, Xray’s cost depends heavily on Jira licensing, which can quickly become expensive or complicated, especially for smaller teams.

Checklist-style test plans for outsourced testing

Stefan Butlin — Wed, 26 Mar 2025 00:00:00 +0000

For outsourced testers to be helpful, they need to be testing the right things. But too much instruction can backfire.
Traditional test case management, complete with preconditions, a zillion steps to follow, and expected outcomes to check for, is overwhelming enough. Pair that with a legacy test case management platform, and outsourced testers’ eyes immediately glaze over.

As testing contractor Thechanman707 puts it:

“In my 7 years of manual testing, test steps have been the biggest waste of time and resources.”

Why? Well, in theory, you’re paying a pretty penny for your outsourced testers because you trust their expertise. That means they don’t need you to hold their hand. And they don’t need a complicated tool slowing them down.

Checklist-style test plans give outsourced testers enough guidance to know what they should be testing but not so much that they feel stifled – and miss the unknown unknowns.

What’s a checklist-style test plan?

Before we get into the “checklist-style” portion of this definition, let’s first review what a test plan is. A test plan – not to be confused with a complex plan for your testing strategy – is simply a list of things that need to be tested. Each bullet on that list is a prompt, an idea of what to check.

Sample prompts in your test plan could be:

Login functionality
Multi-factor authentication
Profile management
Keyboard navigation
Touch gestures (swipe, tap, pinch-to-zoom)

Each prompt clues outsourced testers into an area of the product they should explore. But it doesn’t tell testers how to test each of those prompts. That part is up to them. Redditor irsupeficial emphasizes:

“Going through individual test cases, describing every step [to take], unless in a very, VERY specific context - is a waste. Maintenance headache and the value derived (if any at all) rarely (but not always) justifies the investment.”

The “checklist-style” part of the definition refers to how you track the prompts in your plan. It looks a lot like – yep, you guessed it – a checklist. Each prompt gets its own row, and then the tester marks whether that test passed or failed:

Prompt	Pass (✅) / Fail (❌)
Test invalid password	✅

If your outsourced testing team is doing a lot of tests, your checklist may look more like this, where there’s a higher-level testing prompt with more detailed tests and their results below it.

With a checklist-style test plan, it only takes a quick glance to see what functionality is working and what isn’t – and that helps you make key decisions.

For instance, maybe you notice that there’s a particularly buggy feature. To make sure you cover all your bases, you could request that outsourced testers spend more time there. Or you could start assigning bugs to your development team as soon as they’re identified, getting fixes into production faster.

Why checklist-style test plans work well for outsourced testing

As we alluded to up top, managing outsourced testing is all about balance. If there’s too much structure, it’s easy for outsourced testers to go through the motions and overlook the hard-to-find bugs. If there’s too little structure, you risk gaps in coverage – gaps that could outweigh the benefits of contracting an outsourced team.

Checklist-style test plans are the ideal solution because:

They are easy to understand.

Unlike other testing tools that have a steep learning curve, checklists are something everyone is familiar with. Testers don’t need extensive training on a platform they’ve never used before. They can just get to work. And a faster ramp-up means your outsourced testers get more done in less time.

Plus, checklists are far quicker for you to whip up than exhaustive test cases. As Redditor GlitteringProject922 points out:

“I can probably cover testing a registration form using one checklist of 20 requirements, while I’d need a good 7 cases of 10 steps each where 50% of the steps are identical and frankly obvious. This makes for a huge inflation of the documentation, that, to me, becomes unwieldy really fast. Writing test cases themselves is also much more time-consuming and much, much more prone to the pesticide paradox.”

They allow for the unexpected.

In theory, formal test cases, step-by-step test scripts, and a tedious bug-reporting process “guarantee” that all the parts of your product you want to be tested get tested. But that’s not necessarily true.

If you’re too close to your own product, you may not be able to think of all the possible ways you could test something – and that’s a skill that great outsourced testers have. Checklist-style test plans point testers in the right direction and allow for impromptu tests.

A Redditor in r/QualityAssurance explains the value of this autonomy well:

“A test case will usually be one path along a decision tree, while a checklist can be the decision tree itself. Each check is basically equivalent to a complete test case. Test cases seem like huge time sinks compared to checklists and offer no added value.”

Ultimately, letting testers make their own decision trees ends up giving you even more coverage than you’d get if you planned everything to a T. It’s the same prompt-based approach we recommend for organizing exploratory testing.

They are low maintenance.

One of the biggest challenges in QA is keeping test cases relevant as products evolve. Heavy test documentation often becomes outdated quickly, requiring constant updates that drain time and resources.

Checklist test plans, on the other hand, are designed for flexibility.

If your outsourced testers come up with new test ideas during testing, they can jot them down and slot them right into the plan. If features change, you can tweak checklist items or delete them altogether – no need to rewrite long, complex scripts.

They’re also easy to distribute and scale. They work for outsourced testing teams of 2 or 2,000. And they work well with easy-to-use tools like spreadsheets or a more purpose-built tool like Testpad.

They are reusable.

Since core functionalities remain largely unchanged between releases, your outsourced testers can reuse checklists to validate that previous features still work as expected. They might even be able to use some checklists to test similar parts of other products, reducing redundant work and ensuring consistency across test cycles.

They are transparent.

With a checklist-style test plan, it’s easy for everyone to get and stay on the same page.

You can monitor testing progress at any point in time, adding more prompts in certain areas that need more coverage or directing testers away from other features that don’t need as much prodding.
Testers can easily see what’s been tested, what’s still at risk, and where gaps exist in their coverage.
Engineering teams don’t have time to dig through lengthy reports to figure out what bugs are happening where. An easy-to-read pass/fail grid shows them exactly where to focus their energy (more on that in why test reports shouldn’t be hidden).
Stakeholders can take a peek at how testing is going, perhaps even eliminating the need to send them daily or weekly updates.

An added benefit: They show you who your best outsourced testers are.

The best testers don’t find testing monotonous. They find it an exciting challenge.

“Figuring out why, how, and what to test is where you truly become valuable as a tester. Being able to identify the scenarios that will uncover something new and increase your confidence in the quality of the product and design a set of tests that will identify critical risks as quickly and efficiently as possible is where the real skill comes in.”

- Redditor perdovim in r/software testing

The testers who consistently add smart tests based on your prompts are the ones you want to keep and continue engaging with over time.

A smarter way to manage outsourced testing

While you can run checklist-style testing in something as simple as a spreadsheet, it can be tough to consolidate all of your outsourced testers’ results into one easily viewable and reportable document without at least some manual manipulation.

Purpose-built tools like Testpad rid you of that busy work, allowing multiple outsourced testers to log their tests and corresponding results into one central repository. With everything in one place, you can easily see what’s working and what’s not – and you can share that information with clients and stakeholders instantly with guest-access links. Those same guest links make user acceptance testing easy to run when the client tests it themselves.

Testpad was also built with testers in mind, with keyboard shortcuts and a native outline structure to support comprehensive coverage.

So, why not try it out? Sign up for a 30-day free trial today to see whether it’s right for your outsourced (or even in-house) testing team.

UAT testing made simple

Stefan Butlin — Fri, 21 Mar 2025 00:00:00 +0000

User acceptance testing (UAT) is the stage of software testing where the people who’ll actually use the software confirm it works for them in real-world conditions. It’s less about finding bugs and more about catching gaps between what was built and what’s needed, before launch rather than after.

At a glance

UAT is validation by the intended users: does the software do the job in practice, not just pass technical tests
It takes two main forms: client-focused acceptance testing against agreed requirements, and end-user testing in everyday conditions
UAT isn't usability testing: usability measures ease of use, UAT confirms the software supports real workflows
Run small UAT sessions as major features become ready, rather than one big phase at the end
For non-technical testers, a simple checklist works better than a formal QA tool

The rest of this post covers the forms UAT takes, when to run it, and a practical way to keep it simple.

Here for a tool rather than a primer? See Testpad for user acceptance testing: send testers a guest link, no logins, no training.

What is UAT? And what does it mean?

UAT testing is where software meets reality. It happens in real-world conditions, helping teams catch misalignments before they reach users. The ISTQB Foundation syllabus frames acceptance testing the same way: it focuses on validation and demonstrating readiness for deployment, and ideally it’s performed by the intended users.

It answers key questions, like:

Does it function in real-world workflows?
Can users complete tasks without frustration?
Are there gaps between expectations and reality?

Unlike traditional QA, UAT doesn’t focus on bug-hunting. It looks at whether the software is actually useful in practice.

What are the different types of UAT?

UAT comes in two main forms: client-focused acceptance testing and end-user testing. Which one you’re doing depends on who’s involved. Some teams focus on acceptance – validating that software meets predefined business needs. Others prioritize users – seeing how the product performs in actual, messy, unpredictable use.

Client-focused UAT (Acceptance testing)

When software is built for a client, UAT is about meeting agreed-upon requirements. It’s structured, checklist-driven, and built to fit neatly into the client’s workflow.

Success starts with clear expectations. Before testing begins, teams need to agree on what will be tested and how results will be shared.

Many teams assume formal test case management tools will help, but clients often find them confusing. The best approach is practical. A simple checklist or test plan makes the process smoother.

A structured UAT plan should:

List key workflows that need verification
Be easy for non-technical stakeholders to follow
Provide a way to document issues clearly

Checklists keep client testing focused and friction-free.

End-user-focused UAT (User testing)

For software built for general users, UAT checks whether it works in everyday conditions. This form of testing is less structured and focuses on real-world use.

Key questions:

Can users complete key tasks without confusion?
Do workflows make sense outside of a test environment?
Are there common points of frustration or failure?

Observing users interact with the software provides valuable insight. If direct testing isn’t possible, stepping into the mindset of an end user can reveal the same pain points.

UAT vs. usability testing

UAT and usability testing get confused, but they measure different things: usability testing focuses on ease of use (design, UI, navigation), while UAT confirms software functions as intended in real-world workflows. It also helps to place both against system testing, the internal check that comes before UAT:

	User acceptance testing	Usability testing	System testing
What it checks	Software supports real workflows and business needs	How easy the software is to use	The complete system against its specification
Who runs it	End users or clients	Users, observed by designers or researchers	QA testers
When	After system testing, before release	During design and development	After integration testing

UAT for client projects

When working with clients, the first step in the UAT testing process is agreeing on what will be tested and how. If expectations aren’t clear from the start, the process can quickly become frustrating for both sides.

Many teams default to professional QA tools, assuming they’ll speed things up. But if clients aren’t familiar with these tools, they can create more friction than they solve. Bug trackers, test case management software, and complex workflows might work well for internal QA teams – but clients don’t always have the time (or patience) to navigate them.

That’s why a checklist-based approach works better: no rabbit holes, and no forcing clients to learn yet another tool. A simple spreadsheet or a lightweight tool like Testpad lets them focus on what matters – testing what actually needs testing.

UAT for consumer software

Client UAT focuses on contracts and workflows. UAT for consumer software is different. It involves examining how real users interact with the product in everyday conditions.

Effective UAT for consumer products includes:

Observing real users as they complete tasks: Instead of running hypothetical tests, watch how real users interact with the software. Are they struggling with certain workflows? Do they hesitate or make mistakes? These moments are just as revealing as technical failures.
Collecting direct feedback and noting where users struggle: Users might not always articulate what’s wrong, but their actions tell the story. If multiple users stumble over the same feature, that’s a sign it needs refinement – even if it technically “works.”
Simulating real usage scenarios when direct testing isn’t possible: When direct user testing isn’t possible, UAT can involve simulated use cases where testers act like actual users. This means thinking like an end user – not just testing functionality, but imagining real-world goals, frustrations, and workflows.

Example: An eCommerce checkout flow. Instead of just confirming the "Buy" button works, test how different payment methods perform, check address validation, and simulate abandoned carts. Real-world usage is unpredictable, and UAT should reflect that.

When should you run UAT?

UAT works best when integrated into development, with small sessions starting as soon as major features are testable. Running tests only at the end increases risk.

A good rule of thumb is to run small UAT sessions as soon as major features are ready for testing rather than waiting for full completion. This allows teams to catch issues while they’re still easy to fix.

Benefits of early UAT

Catches misalignments early: When users or clients first interact with a feature, it’s often obvious what doesn’t quite work in practice. Fixing these issues early in the development cycle is significantly cheaper than reworking them later.
Prevents last-minute chaos: A big UAT phase at the end of development often leads to a mad scramble – major flaws surface just as deadlines are locked in. Running smaller UAT sessions throughout development means that by final testing, you're refining details, not uncovering major problems.
Keeps feedback relevant: Users and clients may struggle to provide meaningful feedback if they only see the product at the very end. Regular testing sessions keep input fresh and actionable, allowing teams to adjust before bad assumptions are made.

Frequent, small UAT sessions prevent surprises. Instead of rushing to validate everything at once, teams can address issues as they arise.

How do you run UAT in practice?

UAT doesn’t need to be complicated. A simple, structured process works best:

Start with a checklist of key workflows: Focus on the critical paths users will follow.
Use a format that makes sense for testers. Spreadsheets and lightweight test tools work, while overly complex systems create friction.
Iterate and refine: Testing should evolve with the product. The more teams learn, the better the process becomes.
Keep lightweight records: Track major issues, unexpected behaviors, and recurring pain points.

Make UAT work for you

Good UAT informs better decisions. It’s about understanding how a product performs where it matters most – in the hands of real users.

Start early. Keep it simple. Focus on meaningful feedback. A well-run UAT process means fewer surprises and greater confidence when it’s time to launch.

How to organize your exploratory testing without losing its benefits

Stefan Butlin — Fri, 14 Mar 2025 00:00:00 +0000

Exploratory testing stays effective when you organize it lightly: write a plan of brief, one-line test prompts grouped by feature, let testers explore within each prompt, and record results beside each one. You get coverage you can see and share, without telling anyone which buttons to press.

At a glance

Pure ad hoc exploring finds unknown bugs but leaves coverage gaps; rigid step-by-step test cases have the opposite problem
Write test plans as lists of brief, one-line prompts grouped by feature (“Unicode in username”)
Keep prompts short enough that testers still decide how to test
Record pass/fail beside each prompt, plus who tested and in what browser or environment
The grid of results doubles as a progress report you can share
Let testers add new prompts mid-session so good test ideas aren’t lost

The rest of this post walks through each step, with example prompts you can copy. First, a quick refresher.

What is exploratory testing?

Exploratory testing lets testers decide what to test next – based on their expertise, their experience in the space, and how their testing has already gone. Cem Kaner coined the term in the 1980s, and James Bach, who popularized it, defines it as performing tests while learning things that may influence the testing. At Testpad, we like to say exploratory testing is “making it up as you go along, with your brain engaged.”

The biggest benefit of this form of testing is that it harnesses human intuition and adaptability.

Good testers have a hunch of how a feature should behave. And if it doesn’t behave the way they expect, they also have a hunch of how to continue testing it in ways that expose even more issues that end users would encounter if the feature went live.

As we’ve alluded to, the problem with such an unrestrictive approach is that bugs can fall through the cracks. And in software testing, that’s not a good thing.

Why does exploratory testing need structure?

Exploratory testing works because testers have the freedom to explore your product, just as an end user would. The thing is, not all end users use your product the same way.

For example, to edit a post, some people might click an edit button. Others might click a pencil icon in the upper right corner or type an edit shortcut on their keyboard.

And if a tester only tests the edit button functionality (because that’s the approach to editing they personally would take if they were using the product), they could very likely overlook errors hidden in the editing pencil or shortcut.

That’s why exploratory testing needs to have at least a little bit of structure around it. Otherwise, you can’t be sure the important features and capabilities get tested.

At the same time, you can’t be too stringent with your instructions, or you defeat the purpose of exploratory testing.

While those may seem like two diametrically opposed requirements, it is possible to give enough leniency to your testers and feel confident about your testing coverage.

How does exploratory testing compare with other approaches?

Because of the coverage risks with exploratory testing, many commercial testing teams revert to writing every test as a detailed, step-by-step test case (aka, “Type A in this input field,” “Type B in that input field,” and so on).

But, as you might guess, there are problems with that, too.

To understand why, you have to know what constitutes well-managed testing. In our opinion, well-managed testing comes down to four elements:

Planning what to test
Tracking progress
Reporting results clearly
Reusing test knowledge in future cycles

With those elements in mind, here’s how common forms of testing (including exploratory testing) break down:

Type of testing	Pros	Cons
Purely ad hoc exploratory testing	Catches more unknown unknowns than any other form of testing	Lacks all four management aspects
Detailed step-by-step test cases	Easy to track and report on, ensures testing coverage	Biases and knowledge are baked into the cases, making it less likely for testers to find blind spots
Session-based test management (SBTM)	Has good test planning through high-level charters	Tracking, reporting, and reuse rely heavily on reading through test notes

SBTM deserves a word of credit here: James and Jon Bach introduced it at Hewlett-Packard in 2000 as activity-based test management, an alternative to managing testing through artifacts. Its high-level charters inspire the prompt-based approach below.

As you’ll notice, none of them are perfect. But if you’re able to combine the good parts of each into a kind of middle ground, you’ll get the results you want.

That middle ground is exploratory testing with some structure.

How do you structure exploratory testing without losing its benefits?

Here’s how to take a pragmatic approach to exploratory testing that (1) preserves its strengths and (2) makes it manageable for you and your testing team.

Write test plans as lists of brief test prompts

To make sure you’ve got enough testing coverage, start by mapping out the main features or capabilities of your product that you want exploratory testers to test. Underneath each one, compile a list of things to test related to that feature, including edge cases and special cases. It’s the same idea as the charters Elisabeth Hendrickson teaches in Explore It! (crafted to guide exploration, not prescribe it), just at a finer grain: one prompt per thing worth probing.

But – and this is a big but – do not go overboard with your list.

Each test should be as exploratory in nature as possible, so that means you need to keep your prompts super brief. (The same format works for guided testing too – see checklist-style test plans for outsourced testers.) Here are some examples:

Capability: Profile management

Prompts:

“Entering extremely long name/special characters”
“Updating profile picture with a large file”
“Autosave changes”

Capability: Authentication

Prompts:

“Unicode in username”
“Paste text with formatting into password”
“Rapid clicks on login during 2FA”

Capability: Payment processing

Prompts:

“Expired credit card during checkout”
“Browser autofill”
“Prepaid or virtual card”

Where to write your test prompts

You can jot these prompts down in a spreadsheet or a tool that’s purpose-built for exploratory testing, like Testpad. Whatever you use:

Make it easy for testers to record their results. The less intuitive your process is, the less likely testers will follow it to a tee, and the less accurate your results will be. Having a test prompt in each row and asking testers to mark pass or fail in the column next to it should be sufficient (more on that next).
Make it easy to copy/paste. Chances are, you’ll have to use a lot of these test prompts again, so they should be easy to reuse and adjust over time.

Helpful hints

You don’t need to say “check” or “verify” in your prompts. It’s obvious to your testers that that’s what they should be doing.
You also don’t need to say “test all fields.” That can get too onerous and take testers down an unproductive rabbit hole.
Filter all of your prompts like Goldilocks. Prompts shouldn’t be so detailed they turn into step-by-step instructions. Prompts shouldn’t be too vague or testers won’t know what to do. They should be just the right balance of the two.

Record results beside your test prompts

Doing so helps you understand exactly what was tested and whether it passed or failed. In your spreadsheet or in a tool like Testpad, we recommend having multiple columns that list:

Who was testing, as each person tests in different ways.
What environment they were testing in, because the results may differ.
What browser (Edge, Safari, Chrome) or device (desktop, iPad, iPhone) testers used – again, those could have varying results.

We also recommend hard-coding “pass” and “fail” values in the cells next to each prompt so recording results is easy and quick for your testers. In the example below, pass is represented as a green check mark, and fail is represented by a red X:

Helpful hints

Sometimes, testers may not be able to test a specific prompt or may have questions about how or what to test, so you may want to add other picklist values to your results columns, like “blocked” or “query.”
Testers may also have important notes to share about certain prompts or will be logging tickets related to failed tests, so give them a way to leave optional comments or issue tracker references.

Use your results as a visual indicator of progress

If testers log results next to test prompts, it should be immediately apparent:

What’s planned for testing
What’s been done (and what’s left to test)
What’s working (pass results)
What’s not working (failed results)

And you can slice and dice that information as needed before sharing in stand-ups or with higher-ups or clients – simple test reporting covers what to share and what to leave out. Here’s an example of such a report in Testpad:

From this report, we can quickly see:

How many tests passed (57)
How many failed (12)
How many were blocked (1)
How many have an associated question (1)
Who performed each test (Anna, James, and a guest tester)
Which browser each test was performed in (Safari, Chrome, Edge)

And even though we don’t know exactly what product this is, we can see from the report that there’s some sort of issue with how login and password functionality is working in Edge. This can inform our future testing and give us a starting point for regression tests or even a round of testing on a different but similar part of the app.

Add new test ideas during testing

The best test ideas don’t always come up in planning. Most emerge as testers move through your product and naturally think of variations of your prompt or encounter unexpected behaviors worth investigating further.

Enabling your testers to add their own prompts (by inserting additional rows, for example) is a great way to make sure those ideas don’t get lost – you want them as a reference when that area of the product is tested again.

Over time, this creates a continuously evolving, more effective testing process without the overhead of rigid test case management.

What tools work best for organized exploratory testing?

While you can design a perfectly good exploratory testing strategy in spreadsheets, they can be tough to manage over time. Even something as simple as not knowing which version is the latest one can throw off your reporting and future testing plans.

Being able to plan, track, adjust, and reuse your prompts – all in one centralized platform – can help you stay organized without giving up the freedom that makes exploratory testing work. We’ll admit we’re a little biased, but we think Testpad is a great place to manage your exploratory testing because it has:

An outline-based testing structure for test prompt planning
Optional comments and issue tracker references beside each result
A keyboard-driven editor to type hundreds of test prompts quickly
The ability to add new prompts mid-session as testers come up with ideas
A grid of results showing everything that’s been tested, at a glance
Report views you can share as a link or save as a single HTML file, an audit record proving what was tested
Testing tags to selectively include or exclude certain prompts in future testing

Sound like a good fit? Try Testpad out and see for yourself.

Simple test reporting that actually works

Stefan Butlin — Tue, 04 Mar 2025 00:00:00 +0000

A good test report answers three questions fast: what’s been tested, what’s broken, and what happens next. Most reports fail because they answer none of them – they bury busy stakeholders in metrics and statistics instead. (We cover why that goes wrong in stop hiding your test results.) This post is the practical side: how to build a report people actually read.

The practical approach to test reporting

It’s easy to fall into the trap of thinking that lots of charts, graphs and statistics make a ‘good’ test report. But unless they’re helping readers to get a clear handle on the status of your project, it’s not actually offering any value – and could end up creating confusion rather than clarity.

Test reporting, after all, is supposed to tell us about the state of the product. A report that shows the product is 80% passing doesn’t tell you anything about the state of your product – it doesn’t tell you what is passing or (perhaps more importantly) what isn’t passing.

That’s why it’s so important to step away from lengthy documentation and graphs and instead embrace clear, actionable insights. Effective reporting should clearly show what’s broken as well as what’s been confirmed as working. This gives stakeholders concrete visibility of testing coverage that they simply can’t get from charts and abstract metrics.

What, then, should a test report include? Well, there are endless things you could include but in our view, the key is to keep it simple. Rather than just documenting everything, that means focusing on:

Reporting on what matters to decision makers
Making information accessible and scannable
Regular live updates – but these should be concise and scannable
Making sure the report can be easily understood by all stakeholders, whether they’re technical or not
Making it actionable – you should make it clear what’s working, what’s broken, and what needs to be done to address the broken aspects

Remember, if stakeholders can’t quickly understand the status of testing, the report isn’t doing its job. So while it’s important to structure the report clearly to make it easier to understand, the devil’s in the detail.

What to include in your report

You could consider including the following sections in your report to make it more useful and practical:

Test summary

This should be a high-level overview of what’s been tested, and why it matters. It’s tempting to introduce charts and graphs here, but there’s no need. Keep it brief and focused on key outcomes, rather than getting bogged down in the numbers that don’t tell stakeholders what they need to know.

Defect overview

There’s nothing wrong with bug reporting – it’s just important that it’s not simply a list of bugs without any further context. It’s best to list the bugs alongside their impact, priority level, and the action that needs to be taken.

Test coverage and test details

A key part of the report is showing both what’s been tested and what hasn’t. You should list out the functional areas of the software that’s been tested, and those which haven’t, as well as the type of testing. This is important to help stakeholders understand how complete the testing is, and whether there are any gaps in what’s been tested.

Of the features that have been tested, you should show what passed (known as verified functionality) and what failed.

But, crucially, instead of just showing what has or hasn’t been tested, you should also highlight key actions. This is where the test details come in. If a feature hasn’t passed, for example, why hasn’t it passed? And what needs to be done to make sure it does pass next time? These types of details are essential to include, as they highlight what the next steps should be.

Live documentation vs final paperwork

So, should a test report be the final report? In a word: no. Modern testing demands real-time insights, and static, end-of-cycle reports simply can't keep up with today's development pace.

Your reporting approach should reflect this, bringing in elements of live reporting (this could be dashboards or automated updates for example), to make sure that everyone is kept up to date on project progress, in real time.

Tools like JIRA, TestRail, Testpad and even shared spreadsheets keep the current state of testing visible – whenever someone looks, they see the latest results rather than last week’s snapshot. This means:

Product owners can spot emerging risks early
Developers get immediate feedback on new features
Project managers can adjust resources based on real-time needs
Stakeholders can stay informed without the need for update meetings

Live reporting is particularly useful in certain situations, such as:

Feature releases: When you’re rolling out new functionality, it’s important that everyone can quickly and easily see (and address) any issues before they become a problem for users.
Sprint testing: During agile sprints, clear daily progress visibility can help teams adjust their testing focus, based on what’s been tested and what hasn’t, as well as what’s working and what isn’t.
Critical fixes: When addressing high-priority issues, real-time updates keep everyone informed and on-track without the need for multiple time-consuming meetings.

That’s not to say that there isn’t a place for final reports – they can also serve a purpose. They can act as an important part of the audit trail for compliance requirements, and can be a place to document lessons learned for future projects.

So by all means, create a final report for formal documentation needs. But in day-to-day test reporting, it’s important to move away from static reports that become outdated quickly.

Building stakeholder trust through clear updates

Another important reason to include live reporting is that it helps to build stakeholder confidence. When stakeholders can see testing progress in real-time, they're not left wondering what's happening behind the scenes.

Clear, consistent updates show that testing is thorough and thoughtful, not just a checkbox exercise. Stakeholders are more likely to trust both the testing process and the final results when they can see:

How testing decisions are made
What areas are being prioritized and why
How issues are identified and addressed
What risks exist and how they're being managed

This can be especially beneficial if things go wrong. If stakeholders are already getting regular updates, it means that issues won’t come out of the blue – and they’re also more likely to understand the steps that need to be taken to resolve the problem.

Live updates can be incredibly helpful for building stakeholder trust and confidence – but these updates need to be effortless to generate, or they won't happen consistently. And that could lead to even more stakeholder frustration.

Putting it all together

So what do you need to create a simple, effective test report – and how can you go about it?

It’s a good idea to ask yourself some key questions:

Who needs this information?
What will they do with it?
How often do they need updates?

These three questions can give you the foundations you need to build your report. Whether you use a traditional test management tool, collaborative spreadsheets, simple dashboarding tools, or JIRA, making sure to always keep these questions in mind will help you to build a clear report that keeps your stakeholders informed with the information they need, when they need it.

We’re biased, but we think Testpad does it pretty well. In Testpad, reports present the full list of test prompts, with results shown in a grid of checks (green) and crosses (red) against each prompt. It might sound like a lot of information to wade through, but it’s surprisingly quick and intuitive to scan. That means that readers can immediately see what’s working as well as what’s not.

The report also includes all comments and issue numbers that have been captured during testing, meaning that the essential context and evidence is right there. There’s no need to cross-reference separate bug tracking systems – everything you need to understand and act on test results is all there in one place.

Test prompts are also structured in an organized hierarchy. That gives the report a natural structure, making it immediately obvious how thoroughly different areas of the product have been tested. It means stakeholders won’t get lost in an unstructured list, or be left to interpret abstract metrics – the information is all there upfront, with additional background detail and actions to take if they want to understand further.

And with these three simple features, you’ll have a clear test report that’s a living, breathing document, and can be easily understood by anyone – whatever their job role.

How to manage outsourced testing

Stefan Butlin — Tue, 25 Feb 2025 00:00:00 +0000

Even the best outsourced testers can’t be expected to operate the way you want them to – unless you give them a little guidance. Without that, they won’t know if you’re ok with them making up their own tests, reporting bugs the way they’ve always done it, or when to share their progress, offer testing ideas, or flag potential roadblocks to testing deadlines.

Having your ducks in a row and communicating your expectations to your outsourced testers ahead of time makes it much easier for everyone to get moving in the right direction.

To help jumpstart your planning, we’ve put together a list of five things to consider when managing outsourced testers.

Note: If you haven’t read our Setting Up For Outsourced Testing blog, you’re going to want to before you dive into these steps.

That’s because it covers how to prepare for outsourced testing, from detailing your testing process to developing product training to ensuring testers uphold security requirements – all things you’ll want to have in place before you start thinking about managing your testing projects.

5 Steps to smooth outsourced testing management

1. Choose a test planning approach that works for your product and your goals

We put this one first for a reason: What you want to get out of your outsourced testing should inform your testing strategy. And outsourced testers need to know what you want in order to deliver it.

If you want neat and tidy results for testing a highly specific area of your product:

A more scripted test case management approach would likely work better for you. Testers go through a set of pre-defined test cases and follow step-by-step instructions to determine whether a test passed or failed.

Though it ensures specific functionality is tested, it also limits the discovery of unexpected issues.

If you want a fresh set of eyes on an area of your product to uncover bugs you never thought to check for:

Take a more exploratory approach, where outsourced testers have free rein over your app, making up their tests as they go along, with their brain engaged.

This method is particularly useful for uncovering edge cases, usability issues, and real-world scenarios that scripted tests often miss. On the other hand, it makes it harder to guarantee that certain features were tested.

If you want to test specific areas for a specific amount of time:

Go for session-based test management (SBTM). It strikes a nice balance between scripted and exploratory testing in that you assign testers areas of an application to test for a certain period of time.

That way, you know you’re getting the test coverage you need but still give testers the freedom to decide how to test.

Whichever approach you lean toward, checklist-style test plans are a format outsourced testers pick up quickly – worth a look before you decide.

When you might use each approach

We have to start with a disclaimer here – every product and platform is different, which means they may require a different approach to testing than what might be “generally accepted” for a certain industry.

So, use these as suggestions or starting points and modify as needed:

Finance, accounting, and healthcare applications typically require more tightly controlled testing with predefined test cases, as they’ve got strict regulatory requirements, like IFRS, GDPR & CCPA, GAAP, SOX, and HIPAA.
E-commerce platforms might benefit from a mix of scripted regression testing (to make sure new things aren’t breaking the old things) and exploratory testing (to capture unexpected user behaviors).
Mobile applications are a good candidate for SBTM to balance real-world usability and performance.

2. Define testing responsibilities

You know how the saying goes, “If you fail to plan, you plan to fail.” And planning isn’t just about what your outsourced testers are going to test or how they’re going to test them. It’s also about who is going to be doing what.

There are a couple of ways you could go about doing this:

Go more hands-off

One option is to delegate almost everything to your outsourced testers. Based on deadlines you give them, they decide which of their team members is testing what, and they report their results to you.

Sounds great, right?

The caveat with this one is that you really have to trust your outsourced testing partner. Do they have the knowledge and proven expertise to operate at the level you want them to?

Run a few test tests (see what we did there?) to avoid a horror story like this one in r/QualityAssurance:

“An outsourced team completely ignored the test cases. They were responsible for updating them, and never did. They had control for a couple years, and by the time it was noticed they pretty much had to be trashed.”

Go more hands-on

You could also go in the opposite direction, where your team spearheads the testing project. You write test cases, you decide who is testing them, and you measure outsourced testers’ progress toward your goals.

While this option adds predictability (you’re the one in charge!), it could limit the outsourced team’s ability to identify the unknown unknowns – you’re inserting your own biases and knowledge directly into test scripts that they execute. Not to mention it adds a lot of prep and follow-up work to your plate.

Go hybrid

In this scenario, your team offers some high-level guidance about what to test and by when, but the outsourced tester(s) have autonomy over how the testing gets done.

Your team provides high-level guidance while testers define the specifics of test execution. This is a nice happy medium, giving each party some control and opening the door to unexpected bugs or enhancements. Plus, it spreads out the work.

3. Outline the bug reporting process

Chances are you have an internal bug reporting process already. Now, you just have to adapt it to external testers.

Will they be using the same tool?

Going this route not only provides immediate visibility into testing progress, it ensures outsourced testers use the same terminology and classification you use, such as:

Severity levels
Reproduction steps
Screenshots or video evidence

For most companies, this is the easiest way to integrate outsourced testers into a typical testing workflow. But it also may come with an additional cost: licenses for each outsourced tester.

Will they submit bugs in batch?

To avoid paying for extra licenses, you could have outsourced testers track their tests in a spreadsheet that gets handed off to your internal team for de-duplication and review.

But if you don’t say exactly how you want that spreadsheet to look, you could run into consistency issues. And those could require more work on the backend that lags your entire process.

Whichever workflow you choose, set up regular triage meetings or asynchronous review processes to help clarify defects, refine test approaches, and improve overall testing effectiveness. More on that in #5.

4. Figure out how (and when) you’re going to measure progress

There are lots of ways to measure how well testing is going. And people have lots of opinions on how it should be done. Just Google “how to measure testing progress Reddit,” and you’ll find a smattering of heated posts.

The thing is, there’s no one right way to do it.

Like test planning, you have to find out what metrics will give you, your team, and your boss the confidence that testing was up to snuff. Here are some ways to show that your outsourced testing team is doing the work you want them to do – and doing it well:

Test completion rate. This should be easy to track, even in spreadsheets. It’s just how many tests were completed within a specific time period (and, ideally, in comparison to a previously stated goal).
Pass/fail rate. This is more of a gauge of software stability than it is of testing efficiency or quality. But it does act as an indicator of something potentially fishy going on. For instance, if you’re asking outsourced testers to test an area of the product that’s notoriously full of bugs or has never been tested before, it would be weird if they didn’t report any issues.
Code coverage, which shows how much of the application has been tested, whether in terms of number of features, lines of code (you’ll see this referred to as LOC), or number of user stories. The greater the code coverage and the higher the pass rate of what’s been tested, the more confident you should feel about a release.

For additional inspiration, consider the metrics in this post:

But if we have one word of advice here, it’s that you shouldn’t rely on any one metric alone. A Redditor in r/ExperiencedDevs warns:

“Metrics that are arbitrarily created just make you question their validity and usefulness. I’d say that [you just need] a collective agreement to create meaningful test cases. No need to cover everything but mostly critical stuff. Coming up with exceptional cases to cover is hard. Wasting time on that just slows you down, so you push out less features.”

So, make sure you’re tracking things that actually demonstrate testing effectiveness. You’ll also need to decide when you’re going to be assessing these metrics. Weekly? Monthly? Quarterly?

Try to align reporting with when your leadership team wants an update and your product release deadlines. Once you decide on a specific cadence, try wrapping reporting into your communications with outsourced testers:

Send everyone a monthly report so they are aware of how they’re doing.
Add progress metrics to your weekly standup agenda.
Enable outsourced teams to pull metrics themselves – straight from your testing tool. (Simple test reports are usually all anyone reads.)

That way, everyone stays on the same page throughout the project.

5. Establish a forum for feedback

No matter how much you plan, there will always be things you don’t account for, things that aren’t communicated as clearly as you thought, and things that could be improved. The same goes for your outsourced testers.

Having a way for both parties to share feedback helps you identify new opportunities and address any issues quickly (sometimes even proactively). You could:

Set up joint Slack or Teams channels for real-time feedback.
Have testers log feedback in your testing tool.
Organize a regular meeting to exchange thoughts and ideas.

Though you don’t have to require a specific format for sharing feedback, this one from a Redditor in r/SoftwareTesting is a straightforward and useful template:

This is the problem or idea. Cap it at two or three sentences.
This is why you should care about it. Assess the possible damage or return on investing in a new process or idea as specifically as possible. Keep this part short as well.
This is a possible way forward. Offer possible remedies or other helpful processes as a potential future solution – and be ready to hear other opinions.

A testing tool that’s as flexible as you want it to be

Just because your outsourced testing team is testing one thing now doesn’t mean they’ll be testing that same area of your product later.

And if your planning, execution, and tracking will need to change dramatically with that new type of testing, you shouldn’t have to throw your testing tool out the window – it should be customizable enough to support your new requirements.

Though we’re biased, we know that our customers have used Testpad for very stringent testing and more exploratory testing. It can handle complex test cases, allowing for notes, attachments, and time tracking. It gives you the ability to pull instant reports and save or print a copy as an audit trail.

Testpad can handle ad hoc testing, where users log their tests and results as they go. It even allows you to invite guest testers to run tests (without them needing a login). It is the same approach that makes user acceptance testing painless when a client does the final sign-off.

We like to think it’s a kind of “Goldilocks” of testing platforms: it offers teams and their leaders just the right amount of structure and freedom.

Think it just might be the platform for you? Give it a try – free – for 30 days.

Hire testers sooner than you think

Stefan Butlin — Tue, 18 Feb 2025 00:00:00 +0000

Launching a product only for customers to stumble across glaring bugs isn't a good look. Those bugs damage trust and leave a deeply lasting negative impression – just not the kind you want.

The good news? Avoiding that embarrassment doesn’t require a massive QA team or fancy tools. Sometimes, all you need is a fresh pair of eyes – a junior tester who can spot the issues your developers are too close to see.

Starting small is easier (and cheaper) than you might think. Even basic testing can save your product and your reputation from a rocky start.

Why developers testing alone isn’t enough

Developers are great at writing code, but testing? That’s not their superpower. Here’s why:

Too close to the code

Developers often miss issues because they’re operating on assumptions. It’s like proofreading your own writing – you skim over mistakes because you know what you meant to say. The same goes for code. Developers understand the logic behind every line, but users don’t think like coders. Testing is about discovering how your product performs in the real world, not just in a controlled environment.

Unit testing ≠ product testing

Unit tests confirm that individual components work as intended. But what happens when those components interact? That’s where things get messy. Real-world usage introduces edge cases and unexpected behaviors that unit tests can’t predict.

Skillset mismatch

Testing is more than checking boxes. It’s about stepping into the shoes of your users. It’s noticing the quirks, the clunky workflows, and the moments where things just don’t feel right. That requires curiosity, creativity, and an eye for detail – traits developers aren’t typically trained to focus on.

The takeaway? Relying solely on developers for testing leaves too much room for bugs to sneak through. A fresh perspective, a tester who sees your product as your customers will, makes all the difference.

Fresh eyes beat familiar ones

Catching bugs during development is far cheaper than fixing them in production. Each issue found early saves time, money, and frustration. A single tester with a fresh perspective can shed light on how your product performs in real-world conditions – long before customers discover the flaws.

Different habits, workflows, and assumptions: Users don’t follow scripts.They explore unpredictably, click where they shouldn’t, and uncover edge cases you didn’t anticipate. A fresh tester mirrors this diversity, bringing invaluable insights to the process.
Small steps, big impact: Testing doesn’t have to begin with a fully staffed QA team. Even one curious, willing individual can uncover critical issues before they reach your customers.

Sometimes, all it takes is one new perspective to catch what familiarity has blurred. Testing isn’t about overhauling your process. It’s a simple, effective first step toward building a better product.

Who can be your first tester?

You don’t need a seasoned QA professional to start making a difference. In fact, your first tester might come from an unexpected background. Consider:

High school leavers: Eager, curious, and ready to explore the tech world.
Career changers: problem-solvers looking for a fresh start who bring unique perspectives.
Return-to-work parents: Detail-oriented multitaskers with an unmatched ability to organize.
Recent graduates: Smart, adaptable, and eager to learn – regardless of their degree.
Freelancers or part-time help: Flexible options to manage workload surges or tight budgets. If a permanent hire feels premature, outsourcing your testing is the halfway house.

The bar for entry is lower than you think. A sharp eye, a curious mind, and a logical approach often go further than technical skills or certifications.

What makes a good starter tester?

Testing is less about qualifications and more about mindset. The best starter testers excel at:

Pattern recognition: Spotting inconsistencies, logical gaps, and things that just feel “off.”
Imagination: Anticipating what users might try that developers didn’t account for.
Attention to detail: Catching the subtle issues that can cause big problems.
Curiosity: Digging deeper, asking questions, and exploring beyond the obvious.
Communication skills: Providing clear, constructive feedback that helps the team fix issues efficiently.

Great testers are defined by their ability to see the product with fresh eyes, think critically, and communicate effectively. These traits lay the groundwork for a strong, scalable testing process.

Making the most of your tester’s time

Maximizing the value of your first tester doesn’t have to be complex. Start small, keep things simple, and focus on what matters:

Exploration adds immediate value: Encourage testers to freely explore the product without rigid instructions. Their fresh perspective will uncover issues that the team might have overlooked.
Use basic checklists: Structure testing around simple prompts rather than step-by-step instructions. This encourages creativity while keeping the process organized and manageable.
Refine over time: Test plans aren’t static. They evolve alongside your product. Each release adds new insights, strengthening your foundation for future testing. Beyond catching bugs, well-maintained test plans provide stakeholders with critical information to prioritize fixes and allocate resources effectively.
Regression checklists: For every bug found, create a quick checklist to ensure it doesn’t resurface in future builds. This prevents regressions without adding unnecessary complexity.

With the right approach, even a single tester can bring clarity, consistency, and confidence to your product. The result? Fewer headaches, smoother releases, and a reputation for delivering quality.

Common concerns, answered

“But we need automated testing!”

Manual testing is quicker to set up, more adaptable, and finds issues that automation can’t. Scripts follow rules, but users don’t. Begin with manual testing to uncover quirks, edge cases, and real-world usability flaws. Save automation for later – when your processes are stable, and the return on investment is clear.

“We can’t afford a tester.”

Testers cost significantly less than developers. High school leavers, part-time workers, or return-to-work parents can add value at an affordable rate. Even hiring someone on minimum wage can prevent costly production bugs – and the reputational damage they bring.

“Our product is too complex.”

Your first tester doesn’t need to be a domain expert. Simply using the product with fresh eyes can surface critical gaps and usability issues. Deep knowledge can come later, but early testing is about finding the obvious flaws that slip past developers.

“Developers should test their own code.”

Unit testing is critical – it ensures components work as intended. But it’s not the whole picture. Developers are too close to their own work to see it objectively. A tester’s fresh perspective reveals how the product functions for real users, catching blind spots that developers might miss.

“Good testers move on quickly.”

Testers deliver value from their very first day. Even if they leave, the test plans and processes they create stay with your team, ensuring consistency and progress. For testers who stick around, offering clear paths to growth – into QA, automation, or specialized roles – helps retain top performers and builds expertise.

Start small, start soon

You don’t need a big budget or a team of senior QA professionals to get started. Even a single, curious new hire can make a huge difference by catching issues early and protecting your product’s reputation.

Testing doesn’t have to be overwhelming or expensive. Starting small today means fewer bugs tomorrow, less stress for your developers, and happier customers.

Tools like Testpad make testing simple: manage checklists, organize exploratory testing, and scale your efforts as your team grows. Start a free trial today and see how easy it can be to hire testers sooner – and smarter.

Setting up outsourced testing

Stefan Butlin — Tue, 11 Feb 2025 00:00:00 +0000

There’s a lot of groundwork that needs to be laid before you can experience the full benefits of outsourced testing. Without proper preparation, even the best testers can face delays.

So while your internal teams may breathe a sigh of relief when you sign an outsourced testing contract (finally, they won’t be weeks behind their testing schedule; finally, they have the specialized help they’ve been asking for; finally, they have the confidence to ship new products at a faster pace), the truth is a signed agreement is just the first step toward relief.

To get accurate results, testers need to understand your product and testing process. To deliver those results in the format you want, they’ll need a login for your testing tool and a general walkthrough. To do the actual testing, they’ll need access to your sandboxes. And all of this also requires them to learn and adhere to your security standards.

If the proper groundwork isn’t laid, testing can be riddled with stops and starts, miscommunications, and inefficiencies – effectively eroding the benefits of outsourcing it.

The good news is that you can be proactive. We’re giving you a head-start, outlining the four major things to prepare when welcoming outsourced testers.

How to Prepare For Outsourced Testing Teams

To set outsourced testers off on the right foot, you’ll want to:

1. Nail Down Security in Advance

Testers see features that aren’t released yet and have access to tools that contain your company’s data and possibly your customer’s data. That means security needs to be taken super seriously – particularly if you’re operating in an industry that has extra strict rules (healthcare, banking, to name a few).

If you work at an enterprise organization, or even a mid-sized one, your company has likely hired external consultants before and has security policies in place.

In this case, prep ahead of time. You may not be the only one who is enlisting the help of contractors next month or next quarter. Avoid any delays by logging an IT or InfoSec ticket early. Specify exactly what you intend your outsourced testers to do, what tools they’ll likely need access to, and what permissions they’ll need for each one.

If your company hasn’t hired outside talent before, you’ll want to:

Get NDAs and other paperwork signed. Work with your legal team or outside counsel to cross all your T’s and dot your I’s – before any outsourced testers get added to your tools. Keep these agreements where you can easily pull them in case things go haywire.
Follow Zero Trust security practices. This fancy cybersecurity term just means granting testers the minimum necessary access they need to do their jobs. Ideally, your testing tool and your sandboxes have role-based access controls (RBAC) to help you limit testers’ permissions based on their specific responsibilities. For example, if they’re only testing the Library module in a Partnership Relationship Management tool, just give them access to that module and others that connect or relate to it.
Ensure secure data handling. Work with your CTO to develop and distribute guidelines for handling proprietary or sensitive information to your outsourced testing team. This could include requiring password managers, multi-factor authentication, antivirus, and other data masking procedures. As Redditor phillmybuttons highlights in r/SaaS:

“A text field is a breach waiting to happen, an uploaded file is like opening a door to your server. Use 2fa on everything related to your platform, from server logins to email services.”

Lock down your sandboxes. Use anonymized data where ever possible and confirm that all of your test environments comply with relevant data protection standards, like GDPR or CCPA. Running manual or automated audits in these environments can surface any anomalous or prohibited behavior.
(Possibly) enforce time-bound access. It may be overkill, but if you want to make sure all your bases are covered, you could consider implementing time-bound access to test and production environments. If you’re taking a session-based test management approach, this could feel pretty natural.

You might be in a rush to get all of this going, but make a point to write down the process so you’ve got at least a loose plan for onboarding additional outside testers or freelancers in the future.

2. Think Through Product Training

One of the benefits of outsourced testing is having a fresh set of eyes. But that doesn’t mean testers should go in cold turkey. That’s a recipe for missed bugs.

As Sick4Quality points out in the r/QualityAssurance subreddit:

“I’ve noticed this happens when the outsourcing team didn’t receive a proper training about the product, so they don’t know enough, or don’t feel comfortable enough with the product to report issues because they don’t know if is actually an issue or not.”

If testers don’t know how your product is supposed to look, react, update, [fill in other relevant verb here], they won’t know what’s in working order and what’s not. They can probably guess, but you’re better off not taking that chance. It could lead to unnecessary alarm. It could lead to repeat work – testers may have to recheck certain sections of your product because they misunderstood it. Worse, undetected bugs could get released to production.

So, before you bring on outsourced testers, you’ll need to determine the best way to give them the information they need without overwhelming or brainwashing them (after all, you still want them to be able to uncover the unknown unknowns).

If your company has a partner program or a really good new hire training, you may have some fantastic resources to tap into. Explore this first before creating your own material. Bonus points for any kind of tests or skills assessments – they show you that your testers actually paid attention in training and are ready to roll.

If you don’t have these at your disposal, here are some other ideas:

Create interactive demos. An interactive demo is typically a set of screen captures that walks users through specific functionality, with tooltips and pointers for extra context on how it works. This can help testers understand what to expect when they actually get access to your product, and they’re simple to share – just send a link.
Record videos. These days, there are so many tools available to record yourself walking through your product. And like interactive demos, videos are easy to share. Before you make your own, though, reach out to your product or customer success team. Even if you don’t have a formal training program, they often create videos for product marketing and onboarding, so you may not need to recreate the wheel.
Host live demos. These are more hands-on and can be a pain to schedule, but they allow testers to ask questions in real time.
Share a list of “gotchas.” Though testers should go in with an open mind, it’s a good idea to let them know where bugs are commonly found or edge cases to watch for. You might even note differences in performance on specific browsers or using specific hardware.

In r/softwaretesting, Redditor lilastoken suggests making a list of all problem features and properties:

“If it is a software component, I list all the variables it takes in and the variables that can affect its use-even time and geography can matter.”

Pro tip: Issues that frequently rear their ugly head in regression tests are probably good candidates for this list. And don’t forget: your product is always changing.

If your outsourced testers are staying on for a good chunk of time (say, a year), you’ll want to keep them updated of any changes you’re making. It could be a good idea to send them recordings of Product All Hands meetings, or even invite them to attend so they get the latest and greatest information.

3. Standardize the Testing Process

Outsourced testers – whether they’re an individual or work on a team – have their own way of managing testing. While their methods may match yours, it’s a good idea to level-set on:

Features to be tested. Does that also include their interactions with other areas of the product?
Method of testing. Are you asking testers to take an exploratory approach, or do you want them to use more prescriptive test plans you’ve written? Checklist-style test plans sit nicely between the two for outsourced teams. Do they need to provide screenshots or other kinds of evidence?
Role they’ll be assuming. Should they be impersonating a specific kind of user? If so, how should their testing change based on what that user is supposed to (or not supposed to) be able to do or see?
Reporting. Will they need to use your QA tools, or can they use their own? Do certain types of bugs need to be escalated to support or engineering? If so, how?
Communication. Will you be meeting with testers on a regular basis? How can they find product documentation? Who should they reach out to with questions?

Share your process ahead of time, store it in an easily accessible place like Confluence or Google Docs, and reiterate your testing protocols in standups with your outsourced testing team.

4. Get Testers Proper Product Access

Sounds easy, right? If you’ve been working in testing for a while, you know it’s not. Account and environment setup can be more time-consuming than you think. That’s because you need to:

Define appropriate roles and permissions (in every environment). Some testers may need admin access in one sandbox and more restricted access in production. There could be lots of variations here, and you’ll want to test them out ahead of time.
Create dummy data. Testers may need data to simulate real-world scenarios. And you don’t want to put any old data in your test environments. You want the data to reflect common user behaviors and edge cases, even if it’s fake.
Configure integrations. If your product relies on third-party integrations or APIs, testers need access to those systems as well. This could mean providing API keys, sandbox environments, or test credentials – it just depends on how your product works, the scope of their testing, and your security standards.

Make your testing tool the easiest part.

Preparing for outsourced testers can feel like a lot of work – and it is. But it’s really in favor of testing quality and efficiency. Getting testers up and running with minimal disruption can mean better results in less time (and fewer worries related to security and compliance).

One way to accelerate outsourced tester’s time to productivity is to pick a highly flexible and intuitive test management tool. We have some inherent bias, but we think Testpad should be on your radar.

Testers of all kinds tend to pick it up quickly because it looks just like a checklist. You can also organize test scripts within specific folders or projects and tag them for your outsourced testing team to speed up your testing process. Plus, you can follow the team’s progress in real time with Testpad’s visual overviews and easy-to-pull reports.

Want to give it a whirl? Try it out – it’s free for the first 30 days.

All set up? The next step is the day-to-day: how to manage outsourced testing.

Stop hiding your test results in graphs and charts

Stefan Butlin — Mon, 03 Feb 2025 00:00:00 +0000

When it comes to test reporting, colorful charts and graphs often take center stage. They’re visually appealing and can give you a boost when you see “80% success”. But there’s a danger in relying too heavily on these metrics.

Pass percentages and pie charts can paint an overly simplistic picture of your test results, without actually giving you a clear picture of what’s working and where there are critical issues with your product.

That’s why it’s so important to have transparency in test reporting. Instead of focusing on abstract figures, it’s more important to communicate the nitty gritty details–that means ensuring you know what’s been covered, what hasn’t, what’s working and what isn’t.

What’s the problem with metrics?

What’s our problem with metrics? Well, there’s nothing wrong with metrics per se. It’s useful to know what percentage of your tests have passed, and how many have failed–but those numbers alone don’t give you the true picture of where your product is at.

Pretty charts and graphs shouldn’t stop you finding out from what you really need to know: what’s passing and what’s failing. While visual elements are useful for helping you to see at a glance where the problems lie, they need to give you the details so you can clearly see what works and what doesn’t.

There’s also another danger: that metrics don’t communicate testing gaps.

Charts and graphs only show what has been tested, not what hasn’t – which could leave stakeholders unaware of potential blind spots. A report might show that all the tests that were carried out passed – but that might miss out the crucial detail of an entire feature set going untested due to time constraints.

Metrics have their place. But if they’re presented without any context, or without enough context, they can be misleading. Instead of relying on charts and graphs that barely scratch the surface, it’s important to dig deeper and provide actionable test reports that tell you what you really need to know–while still being easy to understand, even for non-technical audiences.

The problem with test case counts

Many test reports include test case counts – that is, the total number of individual test cases that have been written or carried out during the testing process. But this number doesn’t actually tell you anything important about your product.

You might have a test case count of 100. But what if the testers have focused on low-priority areas of your product, leaving the high-risk features untouched? The team may have focused their efforts on lower priority areas like error messages, rather than testing business critical features like checkout functionality, for example.

A large number of test cases doesn’t guarantee that your product has been comprehensively tested. If there have been multiple test cases for minor edge case scenarios, but none for critical workflows, it could lead to significant problems going unnoticed – but you’d never be able to tell that from a simple test case count.

The problem with pass percentages

Pass percentages are misleading in the same way. Let’s say you run a software testing report which shows that 95% of your tests have passed. That sounds like a great success – but it doesn’t reveal what’s passed and what’s not.

What if the 5% of tests that failed include critical functionality? Without context, these numbers can be misleading, making you think that a product is ready for release when it’s nowhere near that stage.

An overall test completion percentage (looking at the number of tests that have been run compared to those not yet run) can be useful for tracking progress. But pass/fail percentages need context to make it worthwhile to include them in your test reporting.

Why showing actual test coverage matters more than numbers

Test coverage is often reduced to metrics like the percentage of test cases executed, or the test case count. The number of tests carried out is important – but it’s not what really matters.

Understanding test coverage goes beyond surface-level statistics – it should offer meaningful insights about the scope and depth of testing, including:

Feature coverage: Which features and functionalities have been tested – and how thoroughly?
Risk coverage: Have the areas with the highest business impact been thoroughly tested?
User workflow coverage: How well have critical user journeys been tested?
Test types: What kinds of tests have been carried out (for example, unit testing, system testing or functional testing)?
Untested areas: Are there features or functionalities that haven’t been tested? And why haven’t they been covered?

So far we’ve focused on how pies, charts, graphs and metrics don’t always give you the full picture of what’s not working. But it’s also important that you understand what has been tested and what is working. If a test report simply focuses on highlighting bugs and issues, it can leave stakeholders uncertain about whether the rest of the product works well – or whether it simply hasn’t been tested.

That’s why it’s important to clearly show what’s broken as well as what’s been proven to work well, to make sure that everyone has the full picture and can be confident in the testing that’s been carried out.

How exploratory testing complicates metrics further

Exploratory testing is a different type of testing to traditional test cases. While scripted tests are carefully planned, written and carried out, exploratory testing is an unscripted approach in which tests are carried out as testers go along.

Testers learn about the software, designing and running tests as they go rather than scripting everything up front. It can encourage creative and critical thinking, and can save time as no test cases need to be written in advance. It’s also a human-centric approach as testers explore the product in the same way that end users might do. Because the testing process evolves dynamically, exploratory testing can often uncover unexpected issues that scripted tests might miss.

However, it does make test reporting using metrics more complicated. How do you assign a number to the insights gained during an exploratory session?

That’s why, instead of trying to force exploratory testing into a traditional metrics framework, it’s better to focus on outcomes and actionable insights. That might mean creating reports that focus on outcomes rather than trying to quantify the results – which could, for example, look like a list of risks or gaps that have been discovered, categorized by the potential impact or risk level. Or you might create high-level summaries of each of the areas tested and their overall health, helping to identify areas that need further testing.

How we address these things in Testpad

So, what makes an effective test report? Well, rather than using lots of graphs, charts and statistics, a simpler approach is to simply show the full test plan, with clear visual indicators of what’s been tested, what hasn’t, what’s working, and what’s not.

In Testpad, our reports present a grid of checks and crosses against test prompts. This means users can quickly scan to find out what’s working (in green), while it’s also clear what’s not working (in red).

The report also includes all the comments and issue numbers that have been captured during testing. This gives readers the essential context behind the tests, as well as evidence for any problems found – meaning that all the details needed to understand and act on test results are in one place. There’s no need to cross-reference separate bug tracking systems, or chase testers for an explanation of what’s been done – it’s all right there for everyone to see.

Plus, the hierarchical structure of test prompts within Testpad makes it obvious how thoroughly each area has been tested, so you can clearly see whether there are any features that need further attention.

Make testing simpler – lose the graphs and charts

Graphs, charts and statistics might seem like the easiest way to present your test results – but don’t be fooled. All too often, they simply take our attention away from the details that matter the most.

Truly effective test reporting isn’t about colorful visuals or statistics that look good on paper. We’ll let you into a little secret: it’s actually about clarity and actionable insights.

Luckily, it’s easy to make your test reports clearer and easier to understand, for everyone. (For the how – what to put in, what to leave out – see our guide to simple test reporting.) Tools like Testpad show reporting test results can be made straightforward, making sure that everyone (whether they’re technical or not) can really understand what’s going right, what’s not quite working, and what needs further investigation and testing.

For the practical side – what a report like that looks like and how to put one together – read simple test reporting.

Pragmatic testing: The practical approach to software testing

Stefan Butlin — Mon, 27 Jan 2025 00:00:00 +0000

Some teams operate their software testing without structure, leaving critical gaps (and results) to chance. Others overcorrect with rigid processes and endless documentation, draining time and energy from the actual work of testing.

The sweet spot is pragmatic testing. This approach values efficiency, adaptability, and learning. It helps teams uncover more bugs, adjust based on new discoveries, and sidestep processes that waste effort. Pragmatic testing works because it’s simple, scalable, and focused on what matters most: understanding your software.

What is pragmatic testing?

Pragmatic testing provides practical ways to guide product planning, identify priorities, and weigh trade-offs, offering clarity without overcomplicating the process.

Rather than getting stuck in rigid frameworks or chasing perfect documentation, pragmatic testing finds the middle ground. It values learning over strict procedures and balances structure with creativity. This approach is about solutions that work, not appearances that impress.

Finding balance: the principles of pragmatic testing

Pragmatic testing walks the line between structure and freedom. It offers enough guidance to stay organized without making you spend more time documenting than testing. It’s all about finding the right balance.

Start simple

Every testing process begins with a straightforward list of what needs checking. These aren’t essays, just quick prompts that help you focus. Starting simple gets you testing faster, and unlike rigid documentation, simple lists are easy to tweak as you go. Think of it as a guide, not a rulebook.

Iterate based on value

Testing evolves as you learn. As you spot patterns or recurring issues, refine your checklist with only what genuinely improves the process. If a bug keeps showing up in a feature, create a targeted regression test for it. Pragmatic testing sharpens your process with every iteration – like tuning an instrument until each note rings clear.

Blend structure and exploration

Rigid scripts can stifle creativity. Pragmatic testing creates enough structure to stay focused but leaves room to explore. Document what’s helpful, but don’t overdo it – nobody wants to write a novel just to check for bugs. This approach leaves space for testers to follow hunches and uncover the unexpected.

Focus on bug discovery

Pragmatic testing centers on finding what matters and addressing what’s broken. Time is better spent testing than perfecting documentation. Processes should grow naturally, reflecting what helps your team identify problems and understand the software. Keep things light, and add only what supports the goal: discovering what needs fixing.

Why pragmatic testing works

Pragmatic testing focuses on simplicity while delivering meaningful results. It avoids extremes – too rigid or too chaotic – by finding a middle ground that keeps testing effective and adaptable.

Efficiency: Pragmatic testing begins with simplicity, offering enough structure to start quickly while remaining flexible as your product changes. It avoids long setup times and unnecessary hurdles, allowing your team to focus on what matters.
Better results: Combining structure with exploration helps testers uncover issues that rigid processes often miss. It provides a clear framework, allowing testers to investigate areas where unexpected problems might lurk. Some of the most valuable discoveries happen off the planned path.
Team buy-in: A straightforward approach makes testing feel less like an obligation and more like an essential part of improving the product. Reducing unnecessary complexity helps the team focus on testing the software itself.
Scalability: Pragmatic testing works because it starts simple and grows thoughtfully. A lightweight framework keeps the focus on real priorities, avoiding unnecessary complexity. As your team and product evolve, you can expand your process step by step, adding structure only where it genuinely adds value.

Getting started with pragmatic testing

Pragmatic testing keeps the process lightweight and practical, letting your team refine as they work. The goal isn’t to create a perfect system but to build one that works and adapts with you.

1. Build your initial checklist

Start with a simple list of features and capabilities that need testing. This checklist serves as a helpful guide, keeping testers focused without restricting their ability to explore.

2. Iterate over time

Testing reveals patterns and areas needing attention. Adjust your checklist and process to address these discoveries. Add structure only when it helps, and avoid overloading the system with unnecessary steps.

3. Add regression testing

Bugs often signal areas to revisit. Track critical problems by creating manual regression tests that prevent them from returning in future updates. These tests act as a log of lessons learned, keeping the process proactive and forward-thinking.

4. Encourage exploration

Exploratory testing often leads to the most surprising and useful discoveries. Clear prompts can guide testers without restricting them, providing enough direction to focus on key areas while allowing space for creativity and curiosity.

Starting small and improving incrementally helps build a practical and effective process. Pragmatic testing focuses on learning and adapting rather than rigid adherence to plans.

Misunderstandings that hold testing back

Testing often gets tangled in misconceptions that slow teams down, leading to frustration (and maybe some shouting at spreadsheets). Let’s separate fact from fiction and rethink what testing can look like.

Myth 1: Detailed test cases are necessary for every feature

Detailed test cases might feel comforting, but they can quickly spiral into a maintenance headache. Instead of aiming for exhaustive detail, focus on what drives meaningful improvements – highlighting problem areas rather than compiling lengthy, rigid plans.

Myth 2: Documentation guarantees good testing

Detailed documentation might look polished in an audit but doesn’t uncover issues. Testing shines when it reveals the unknown – highlighting what works and what needs fixing.

Myth 3: Automation is always better

Automation is excellent for repetitive tasks, but it has its limits – it can only uncover what you’ve programmed it to look for. Edge cases, user experience quirks, and those “Wait, what just happened?” moments often require manual or exploratory testing. Pragmatic testing uses automation wisely, balancing efficiency with human intuition.

Myth 4: Perfect processes ensure success

A process that looks perfect on paper can fall apart under real-world conditions. Rigidity often blocks progress, while flexible methods adapt to changing products and priorities. Success comes from making the process work for your team, not forcing your team to work for the process.

Takeaways for smarter testing

Pragmatic testing prioritizes what works. It’s about balancing structure and flexibility while focusing on learning and improvement. These principles can help guide your approach:

Focus on learning: Testing is about discovery, not checking boxes. The aim isn’t perfection but uncovering your product’s strengths and weaknesses so stakeholders can make informed decisions.
Iterate with purpose: Treat testing processes like your product and refine them as needed. Adjust what’s useful and trim what isn’t, keeping your approach efficient and effective.
Flexibility over perfection: Aiming for perfection often creates unnecessary friction. A flexible approach lets you adapt to your product’s evolving needs while keeping testing practical and impactful.

How Testpad simplifies pragmatic testing

At Testpad, we’ve built our tool around this practical mindset, making testing simpler and more effective without unnecessary restrictions.

Simple, structured checklists: Think of them as focused to-do lists – clear and adaptable without the fluff.
A balance of structure and exploration: Enough guidance to keep you focused but with space to explore when inspiration strikes (or when that sneaky edge case rears its head).
A focus on bug discovery: We prioritize finding meaningful issues that improve your product – not creating documentation no one reads.

Keeping testing practical and effective

Pragmatic testing isn’t about rigid rules or chasing perfection. It’s about balancing structure with creativity, prioritizing simplicity, and staying focused on what matters most.

At Testpad, we’ve designed a tool that reflects this philosophy. Simple, structured checklists offer clarity without stifling creativity, allowing testers to explore where it matters most.

Whether moving on from messy spreadsheets or seeking an alternative to overcomplicated test management tools, Testpad offers a lightweight solution that focuses on results without adding unnecessary complexity.

Explore how Testpad can simplify your testing process and keep your software on track – without the bloat.

Outsourced testing: When and how to bring in external help

Stefan Butlin — Wed, 22 Jan 2025 00:00:00 +0000

Getting outside help to test your product is what outsourced testing is all about. It’s a practical way to grow your testing capacity without needing to hire full-time. That makes it especially useful for short-term projects, tight deadlines, or one-off releases where you need extra hands, fast without long-term overhead.

Whether your current team is too small, hiring’s taking too long, your testing load keeps changing, or you need skills your team doesn’t have – you outsource when you need more people. Outsourcing can be a flexible, fast-moving way to stay on top of quality without stretching your team too thin.

When outsourcing makes sense

Outsourcing isn’t just for big-budget projects or companies without QA teams. It can be a smart move in many situations, especially when time, capacity, or specialist knowledge is tight.

You need to scale quickly

Hiring testers takes time – writing job specs, reviewing applications, running interviews, waiting on notice periods. Meanwhile, your release date isn’t moving.

External testers can get going almost immediately. The good ones are used to fast onboarding and can contribute within days. If they’re in a different time zone, you might even get around-the-clock progress.

You need specialist skills

Some testing needs are niche, and hard to build in-house:

Security testing for finance, health, or anything compliance-heavy
Performance testing when scale matters
Domain-specific knowledge like gaming, where expectations are high
New tech like AI, where testing for things like hallucinations or bias requires a new approach

Instead of rushing to upskill your team, you can bring in someone who already knows the ropes.

Your testing needs change

If your testing load peaks and dips, hiring doesn’t always make sense. Some months are quiet, others intense.

Freelancers or external teams let you flex your capacity without adding long-term overhead. Scale up when you’re busy, scale down when you’re not.

You’re too close to see the cracks

In-house teams know the product so well they sometimes stop seeing its flaws. They understand the intended flow and unconsciously work around quirks.

External testers come in cold and they notice things your team might miss. They’re often more thorough too, checking every edge case. It’s not quite like real-user behavior, but it’s great for surfacing hidden issues.

Your three main options

Once you’ve decided to outsource, the next step is choosing how to do it. You can work directly with freelancers, go through a platform, or bring in a full testing company. Each has its pros, cons, and ideal use cases – it just depends on your budget, timeline, and how much help you need.

Individual freelancers

Work directly with a freelance tester. Best when you just need a couple of extra hands.

Pros:

Direct communication – no middlemen
Flexible hours and setup
Can be great value, especially from global markets
Often available to start immediately

Cons:

If they go quiet, you’re stuck
Quality can be hard to assess up front
Not ideal for big or ongoing projects

Cost: Usually the cheapest option after full-time hires. Rates vary widely by region.

Freelance platforms

Sites like Upwork, Toptal, and Braintrust give you access to large pools of talent.

Pros:

Big talent pool, broad skillsets
Upfront rates, reviews, and filters
Payment and contracts handled by the platform
Global access across time zones

Cons:

Language and time zone gaps can slow things down
Freelancers may juggle multiple jobs
Platform fees add up
Still need to vet for actual testing skill

Cost: Mid-range – cheaper than agencies, can be more expensive direct freelancers.

Testing companies

Agencies that provide managed testing services. They handle process, people, and reporting.

Pros:

Proven processes and experience
Easy to scale up or down
Tools and reporting often included
Account managers handle admin

Cons:

Most expensive route
Less control over how testing’s done
May feel generic or templated
Takes longer to kick off

Cost: Highest option – you're paying for structured delivery, scalable resources, and project management, though the trade-off is that the testing can sometimes feel generic if not well tailored to your product.

Whichever route you choose – freelancers, platforms, or agencies – it helps to have a plan. Once you've picked a model, the next steps are setting up your outsourced testing, managing it day to day, and choosing a test plan format your testers can run with.

Common challenges with outsourcing testers

Outsourcing can be a smart way to boost your testing capacity, but it’s not entirely hands-off. Like any working relationship, it takes a bit of effort to get right.

It’s harder to judge quality early on

You don’t get much insight into how good someone is until they start testing. They might miss obvious bugs or spend too long on things that don’t matter.

Start small and test the waters. Ask detailed questions. Look for referrals or reviews if you can.

You’ll still need to onboard them

Even experienced testers need context. Expect to spend time walking them through your product and process. That effort pays off – but don’t expect results overnight.

You’ll need to think about access and security

If they’re testing real data or working on sensitive areas, lock things down properly. Use NDAs. Work with your legal and security team to stay covered.

Managing external testers takes time

You’ll need to stay involved – reviewing work, answering questions, managing timelines. Time zones and language barriers can add friction.

Making outsourced testing work

Outsourcing testing works best when you approach it like hiring: be clear about what you need, selective about who you choose, and realistic about the time it takes to get things running smoothly. (Need help with that? Here’s what to consider when hiring testers.)

Whatever setup you’re working with – freelancers, agencies, or short-term contractors – the right tool makes a big difference. You want something easy to learn, lightweight to manage, and flexible enough to suit different testing styles.

A tool like Testpad is great for this. It’s a checklist-style testing tool that helps testers get up to speed quickly and gives your team clear visibility into what’s been tested – and what hasn’t. This post on checklist-style test plans covers why this format works well with outsourced testers.

It also helps that guest testers don’t need a license. You can loop in external testers and give them access to just the test runs you want them to work on. This is the same guest-access setup teams use for user acceptance testing, where a client signs off without needing an account.

If you’re exploring tools that support this kind of setup, we think Testpad is a strong fit. You can try it free for 30 days – no card needed.

9 Best Exploratory Testing Tools for 2026

Stefan Butlin — Tue, 07 Jan 2025 00:00:00 +0000

Exploratory testing is all about discovering what your software can really do – beyond the scripts and automation. It helps teams uncover hidden issues, explore edge cases, and gain a clearer picture of how their product performs in real-world scenarios. It’s creative, flexible, and belongs in any QA strategy for delivering software that works as users expect.

But with all its freedom, exploratory testing can feel disorganized. Tracking progress, documenting findings, and ensuring consistency can quickly become overwhelming.

That’s where the right tools step in – bringing structure to the process without stifling creativity.

Let’s take a look at some of the best tools for exploratory testing in 2026 and how they can help you balance flexibility with focus.

What is exploratory testing?

Exploratory testing is the art of designing, executing, and learning from tests in real time. Picture it as improvisation with purpose – each move guided by what you uncover along the way. It’s flexible and unstructured, but always intentional.

Unlike rigid scripted testing, exploratory testing mirrors how real users interact with your product. Testers adapt on the fly, diving into areas that feel interesting, unusual, or suspicious. This adaptability makes it invaluable for uncovering edge cases, usability quirks, and the kind of bugs scripted testing tends to overlook.

Exploratory testing is about pushing boundaries. It’s about discovering where your software doesn’t work, not just proving that it does. It’s creative, investigative, and deeply engaging for testers, giving them the freedom to think critically, make things up as they go, and keep their brain fully engaged. This approach encourages them to ask, “What if?” and dive into areas others might overlook.

Why does exploratory testing matter?

Exploratory testing excels at finding the unexpected and the unknowns. While automation and scripted testing follow predefined paths, exploratory testing pushes beyond assumptions, revealing usability gaps, hidden bugs, and unpredictable behaviors that could impact the user experience.

Beyond bug hunting, it helps testers engage more deeply with the product, fostering a better understanding of its behavior. This approach reveals blind spots in traditional testing methods and creates a more comprehensive view of software quality.

What is exploratory testing software?

Exploratory testing software is the bridge between creativity and structure. It helps testers document insights, track progress, and maintain focus without stifling the freedom to explore.

These tools balance flexibility with organization, offering a framework that keeps discoveries actionable and aligned with team goals. Think of them as a toolkit: ready to capture notes, track findings, and light the way through complex testing scenarios.

Here’s what these tools bring to the table:

Dynamic result capture: Document observations and bugs without breaking your flow.
Flexible structure: Stay organized without rigid workflows, leaving room for discovery.
Collaboration and documentation: Share findings easily through reports or real-time updates, keeping stakeholders informed.

Challenges these tools address

Exploratory testing is inherently freeform, which can make it tricky to manage. The right tools streamline this process by addressing common pain points:

Tracking progress: Ensures what’s been tested and what’s left is clear, without creating administrative headaches.
Capturing insights in real-time: Allows testers to jot down notes and log bugs quickly, maintaining creativity without interruption.
Making results reusable: Clear documentation ensures findings can be shared and referenced later, helping teams build on their insights.

What makes a great exploratory testing tool?

The best exploratory testing tools enhance your process without getting in the way. They empower testers to adapt and explore while staying organized. Here’s what to look for:

Quick capture of ideas: Tools should allow seamless recording of insights, from notes to screenshots, without breaking stride.
Flexible structure: Support for free-form notes and lightweight plans helps testers stay organized while encouraging creativity.
Collaboration made simple: Sharing findings with stakeholders should feel natural, whether through reports or integrations with other platforms.
Ease of use: Tools should have minimal setup, enabling teams to start testing without a steep learning curve.
Reusable test plans: Discoveries should easily translate into repeatable plans, preserving valuable insights for the future.
Freedom from rigid workflows: Great tools let testers follow their instincts, striking a balance between structure and adaptability.
Effortless coverage tracking: Progress tracking should be simple, offering clarity without unnecessary overhead.

Best exploratory testing tools for 2026

Exploratory testing tools aren’t one-size-fits-all. Each has unique strengths, and the best choice depends on your team’s goals, workflows, and budget. From lightweight, creative options to enterprise-grade solutions, here’s a list of tools designed to enhance your exploratory testing efforts.

What to consider when choosing a tool

When evaluating exploratory testing tools, focus on these key criteria:

Flexibility: Does the tool adapt to your testing style, or does it force rigid workflows?
Usability: How quickly can your team get started? Intuitive tools with minimal setup win points here.
Collaboration: Can findings be shared easily with teammates and stakeholders? Look for tools with robust reporting and integrations.
Pricing: The right tool should offer good value for its cost, whether you’re on a tight budget or ready to invest.

Different teams have different needs, and no single tool is perfect for everyone. As you evaluate options, think about your workflows, team size, and priorities. The best tool is the one that complements your process without complicating it.

Tool	Best for	Key features	Pricing (10 users/month)
Testpad	Lightweight, flexible solutions and accommodating guest testers	Hierarchical test plans, on-the-fly test creation, mobile-friendly access, spreadsheet-inspired reporting, and seamless guest tester support for ad-hoc collaboration	From $99/month
Xray	Agile teams using Jira	Session charters, video/audio recording, desktop apps	From $10/month
Testuff	Remote team collaboration	Cloud-based, video recording, bug tracking integration	From $270/month
Bug Magnet	Quick browser testing	Browser extension, customizable configurations, input validation testing	Free
Zephyr	End-to-end testing visibility	Real-time dashboards, CI tool integration, unified manual/automated workflows	From $10/month
Azure Test Plan	Enterprise-grade testing	Scenario capture, end-to-end traceability, advanced security compliance	From $520/month
Spira Capture	Free, lightweight solutions	Session tracking, evidence capture, bug reporting	Free
Test.io	Crowdsourced real-world testing	Global tester network, rapid feedback, diverse environments	From $2,000/month
TestRail	Comprehensive test management	Customizable workflows, rich analytics, integration-ready	From $370

1. Testpad

Best for: Teams seeking a flexible solution with seamless collaboration.

Testpad strikes a balance between simplicity and functionality, making exploratory testing accessible for teams of all sizes. Its checklist-inspired interface blends the ease of spreadsheets with the power of dedicated testing tools, keeping testers organized while fostering creativity.

Key features

Hierarchical test plans: Organize tests intuitively for better coverage and clarity.
On-the-fly test creation: Capture new ideas as they arise without breaking the flow.
Checklist-style interface: Combines spreadsheet familiarity with flexibility for real-time exploration.
Robust reporting: Track progress and share findings with stakeholders effortlessly.
Mobile and tablet-friendly: Test wherever the need arises.

Pricing

From $59/month (3 testers).

Pros/Cons

Pros: Customizable, intuitive, and great for collaboration.
Cons: Integrations are simple by design, which might not meet the needs of more complex workflows.

2. Xray

Best for: Agile teams deeply integrated with Jira.

For teams already using Jira, Xray offers seamless integration, making it an obvious choice for adding exploratory testing into agile workflows. While it’s feature-rich, the learning curve can feel steep for new users.

Key features

Session charters: Set focus areas to guide exploratory test sessions.
Video and audio recording: Document findings comprehensively.
Desktop apps: Extend testing capabilities outside the browser.

Pricing

From $10/month.

Pros/Cons

Pros: Excellent Jira integration, robust evidence collection tools.
Cons: Limited functionality outside Jira; steeper learning curve.

3. Testuff

Best for: Remote team collaboration.

Testuff focuses on distributed teams, with cloud-based features that keep everyone connected and on track. While its interface feels a little dated, its strong defect tracking and reporting capabilities make up for it.

Key features

Cloud-based platform: Access and collaborate without server maintenance headaches.
Comprehensive defect reporting: Includes video recording for detailed bug documentation.
Bug tracking integration: Sync issues seamlessly with tools like JIRA or Bugzilla.

Pricing

From $27/user/month.

Pros/Cons

Pros: Great for remote teams, solid defect tracking.
Cons: Outdated interface might hinder user experience.

4. Bug Magnet

Best for: Quick exploratory testing in browsers.

Bug Magnet is perfect for browser-based testing. It’s simple and customizable, making it a handy companion for quick exploratory sessions. While it’s limited to browser testing, its efficiency and ease of use make it a valuable tool for testers focusing on web applications.

Key features

Customizable configurations: Tailor inputs to suit your testing needs.
Browser-based simplicity: Works with Chrome and Firefox, no installation required.
Input validation testing: Test fields, dropdowns, and text areas quickly.

Pricing

Free.

Pros/Cons

Pros: Easy setup, highly customizable, open source.
Cons: Limited to browser-based testing.

5. Zephyr

Best for: Teams needing end-to-end visibility.

Zephyr excels in unifying manual and automated testing efforts, providing real-time dashboards and extensive reporting tools. However, its complex setup may require some patience upfront.

Key features

Real-time dashboards: Gain immediate insights into test cycles.
CI tool integration: Works with Jenkins, Bamboo, and more.
End-to-end visibility: Comprehensive tracking across multiple projects.

Pricing

From $10/month.

Pros/Cons

Pros: Excellent for tracking and collaboration; strong integrations.
Cons: Steep learning curve for new users.

6. Azure Test Plans

Best for: Enterprise teams working on web and desktop apps.

Azure Test Plans offers robust traceability and data logging features, making it a go-to choice for enterprises requiring detailed test management.

Key features

Scenario capture: Record test cases with rich context.
Traceability: Follow test results from design to execution seamlessly.
Security compliance: Advanced compliance features for sensitive environments.

Pricing

$52/user/month (Basic + Test Plans license).

Pros/Cons

Pros: Strong traceability, enterprise-ready features.
Cons: Documentation gaps may slow onboarding.

7. SpiraCapture

Best for: Free session-based testing.

SpiraCapture offers a straightforward way to capture notes and logs during exploratory sessions. While it lacks the advanced features of some platforms, its simplicity and cost (free) make it a great option for small teams or individual testers starting out.

Key features

Session-based tracking: Note actions and results in real time.
Evidence capture: Attach screenshots and time-stamped logs effortlessly.
Bug reporting: Integrates with bug trackers like SpiraTest.

Pricing

Free.

Pros/Cons

Pros: Free and easy setup.
Cons: Limited compared to full-featured platforms.

8. Test.io

Best for: Crowdsourced testing for diverse environments.

Test.io connects teams with a global network of testers to simulate real-world scenarios across devices and platforms. It’s a powerful option for teams seeking varied environments without building an in-house team.

Key features

Crowdsourced testing: Tap into a worldwide network of testers.
Rapid feedback: Initial results in as little as an hour.
Diverse environments: Cover a range of devices and operating systems.

Pricing

From $2,000/month.

Pros/Cons

Pros: Diverse coverage, fast results, scalable for enterprise needs.
Cons: High price point; may be overkill for smaller teams.

9. TestRail

Best for: Comprehensive test management and reporting.

TestRail supports both exploratory and structured testing with detailed analytics and customizable workflows. It’s particularly suited to teams managing complex testing environments.

Key features

Customizable workflows: Tailor test cases to your team’s needs.
Rich analytics: Visual dashboards and instant insights.
Integration-ready: Connects to automation tools, CI/CD pipelines, and critical issue trackers.

Pricing

From $37/user/month.

Pros/Cons

Pros: Comprehensive, intuitive interface, great for larger teams.
Cons: Higher cost per user; advanced features may require training.

How to get started with exploratory testing

You don’t need fancy tools to begin exploratory testing. A basic spreadsheet or checklist is often enough to organize your thoughts and track progress. The key is to document just enough to make testing actionable and repeatable. As your needs grow, you can scale up to tools that add structure without stifling creativity.

Start small

Start with what you have – spreadsheets, checklists, even pen and paper. The focus is on capturing insights and tracking what’s tested, not perfection. These simple methods keep the process accessible while giving your team room to learn and adapt.

Define high-level charters

Use charters to guide your testing without boxing it in. Objectives like “explore the checkout flow” or “evaluate navigation on mobile devices” set a clear focus but leave room for flexibility. This approach fosters creativity while keeping efforts aligned with your goals.

Track progress

Exploratory testing doesn’t have to mean chaos. Keep a simple log of what’s been tested, what’s working, and what needs improvement. Lightweight tools or even checklists can help maintain clarity without slowing things down. A well-documented process ensures findings are actionable and easy to revisit.

Iterate

Exploratory testing is a learning process. Use what you uncover in each session to refine your approach, adjust charters, and expand your focus areas. Testing evolves alongside your product, making it an ongoing cycle of discovery and improvement.

Unlocking creativity in QA

Exploratory testing does more than find bugs; it informs decisions. Concise, well-organized reports help translate findings into actionable insights for stakeholders, ensuring that usability gaps, priorities, and bugs don’t fall through the cracks.

The right tools can amplify this process. Tools designed for exploratory testing balance structure with flexibility, letting testers explore while keeping results organized and sharable.

Whether you’re working with a simple checklist or a more advanced platform, the goal is the same: unlocking creativity to deliver better software.

To see how Testpad handles exploratory testing, sign up for a free, 30-day trial today.

Don't Over Plan Your Testing

Stefan Butlin — Thu, 02 Jan 2025 00:00:00 +0000

As a testing team, you're the last line of defense between your product and your customers. Your quality assessment determines whether users have a smooth experience or encounter frustrating issues that could impact a company’s bottom line.

That's a lot of responsibility. So it's natural to want to get everything perfect – to create comprehensive test plans, detailed documentation, and rigorous processes.

But here's the challenge: Many teams get so caught up in planning how they'll test that they sacrifice valuable hands-on testing time.

The very thoroughness they aimed for becomes their weakness.

Understanding What Testing Really Is

Testing can’t be boiled down to just following rigid processes or checking boxes on a requirements document.

At its heart, testing is a discovery process – it's how we learn what state our product is actually in, not what state we hope it's in.

Testing should answer fundamental questions like "Is this ready for our customers?" or to put it even more directly: "Would we be embarrassed if we shipped this?"

The only way you get there is to keep the testing process somewhat open.

Think of testing like exploring a new city. Sure, you could plan every street you'll walk down in advance, but wouldn't you learn more by starting with a basic map and then following interesting paths as you discover them?

That unplanned turn during testing could be the reason you avoid your customers finding an obvious issue that should have been caught before product shipment or the same bug appearing twice.

Often, lapses in product happen not because teams aren't taking testing seriously, but because they're focusing on a test plan that is too formulaic that it leaves room for error.

It’s that mindset that leads to an over-planning trap.

The Planning Paradox

It's remarkable how many teams fall into the over-planning trap. They get caught up in industry buzzwords and frameworks, agonizing over whether they're following "best practices" or using the "right" methodology.

It’s not a mystery why teams end up feeling a bit stuck. Complex test case management tools, while powerful, often push teams toward unnecessarily formal approaches.

The reality? Most of the complexity these tools offer isn't adding value.

It’s easy to lose sight of this truth when your team has all the best intentions: every hour spent perfecting a test plan is an hour not spent finding actual problems in your product.

Why We're Drawn to Over-Planning

The urge to over-plan comes from a very human place.

We're afraid of missing critical issues, so we try to plan for every possibility. There’s the comforting illusion that having everything documented and planned out makes testing infallible.

Industry pressure doesn't help – there's a constant stream of articles and conferences promoting increasingly complex testing frameworks, as well as management teams' desire for metrics and tracking that push teams toward over-planning.

But this pursuit of the perfect process often becomes a security blanket, making us feel safe without actually making our testing more effective.

The Hidden Costs of Over Planning

Over-planning doesn't just waste time – it actively damages our testing effectiveness.

When testers are forced to follow detailed scripts, they stop thinking creatively. They miss issues that fall outside the prescribed steps. The rigid structure kills the natural curiosity that makes great testers effective.

Consider a tester following a detailed test script versus one exploring with basic guidelines. The script-follower might execute perfectly but miss the unexpected behavior that would catch a real user's attention.

Whereas an explorer approach, guided by curiosity and experience, is more likely to find those critical issues that hyper-formalized test cases often miss.

Overplanning can distract teams from understanding their product, increase the risk of mistakes, and slow down development. This makes it harder to launch a product that team members feel good about.

A Better Way: Start Simple and Scale Up

Begin with the Basics

The most powerful testing starts with simple, human observation. Instead of getting lost in elaborate planning, have someone actually look at the product.

This means moving beyond spreadsheets and test case management tools and getting hands-on with the actual software.

As testers interact with the product, they should carefully document their observations, discoveries, and initial impressions. Write down what’s learned and then use that to inform your next step in the testing process.

Add Structure Gradually

As you begin to understand the product, start building a lightweight structure around your testing approach.

Begin with a simple, flexible list of areas to check – think of it as a loose guide rather than a strict script. Create broad prompts that encourage creative thinking instead of detailed, prescriptive steps.

For example, instead of "Click button X and verify response Y," use prompts like "Explore user registration flow" or "Investigate payment system interactions." This approach allows testers to think critically and approach each area with fresh eyes.

The magic happens when you let the testing experience itself shape your test plan. Each testing session becomes an opportunity to learn and refine your approach.

Your test plan can then evolve naturally, becoming a living document that reflects genuine product understanding rather than theoretical assumptions.

Embrace Exploratory Testing

Exploratory testing is about giving testers the freedom to investigate without constraints.

Encourage your team to follow their instincts and investigate. When a tester notices something unusual, that's not a distraction – it's an opportunity to uncover potential issues.

This approach relies on trusting human intuition. Not every interesting path will reveal a critical bug, but many of the most significant issues are discovered through curious, unscripted investigation.

Ideally, you should create an environment where testers feel comfortable sharing their thought processes and unexpected findings. The goal is to transform testing from a mechanical checklist into a dynamic process of product discovery.

When Structure Makes Sense

Of course, there are situations where more structured testing approaches are appropriate.

Regulated environments, safety-critical systems, and large teams requiring coordination may need more formal processes. But even in these cases, the key is to add only the structure that demonstrably adds value.

For example, a medical device might require documented test cases for regulatory compliance, but that doesn't mean every aspect of testing needs the same level of formality. Keep the heavy structure for what matters most, and maintain flexibility everywhere else.

Practical Tips for Right-Sized Testing

Creating a Flexible Mind Map

Start by developing a simple, visual outline of your product's features. This mind map should be a living document that captures the essential testing areas without becoming overly complicated. Think of it as a strategic overview that can be easily modified as you learn more about the product and its potential vulnerabilities.

Developing Open-Ended Test Prompts

Try to move away from detailed, prescriptive test scripts that lock you into a rigid approach. Instead, create testing ideas as flexible prompts that guide exploration while leaving room for tester intuition. These prompts should highlight key scenarios and potential risk areas without dictating every single step, allowing testers to uncover insights organically.

Prioritizing Coverage Areas

Focus on broad functional areas and potential interaction points with the goal of understanding the system's overall behavior and potential risks.This approach helps you identify critical paths and potential weak spots in the product without getting bogged down in exhaustive, time-consuming testing procedures.

Embracing Exploration and Adaptability

Build flexibility into your testing process. Encourage testers to explore unexpected paths, follow their intuition, and deviate from pre-planned scripts when interesting discoveries arise. You’ll be more likely to uncover issues that rigid testing might miss.

Documenting What You Learn

Shift from documenting what you plan to do to capturing what you actually learn during testing. This creates a valuable knowledge base that tracks unexpected behaviors, emerging patterns, and critical insights. Prioritize action and you’ll get out of a planning rut!

Maintaining Lightweight Testing Plans

Develop plans that can be quickly updated, allow for rapid feedback, and respond efficiently to changes in the product or discovered issues. If you can avoid complex, bureaucratic test plans, you reduce the risk of slowing down the testing process.

Moving Forward

If you walk away from this article with anything, it should be this: testing doesn't need to be complicated to be effective.

Often, the best testing comes from giving skilled people the freedom to explore and investigate, guided by simple prompts rather than detailed plans.

Start testing now with whatever and whoever you have available. You can always add more structure later if you genuinely need it. What matters most is learning about your product's actual quality, not perfecting how you plan to learn about it.

The next time you find yourself in a lengthy test planning session, ask yourself: "Would we learn more about our product by spending this time actually testing it?"

The answer might just be the change you need for a testing process that really works.

How to Get Started With Manual Testing

Stefan Butlin — Mon, 09 Dec 2024 00:00:00 +0000

Getting started with manual testing takes four steps: pick the user flows that matter most, write them up as a plain-text checklist, have a human work through them, and record what passes and what fails. You don't need expensive tools or a dedicated QA team to begin, and even one tested workflow catches bugs before your customers do.

At a glance

Manual testing means a human works through the software, using judgment to find defects and usability problems
Start with the critical paths: logging in, key pages, checkout, whatever your users depend on most
Bring in someone who didn't build the feature; fresh eyes find the obvious problems
Write your checks down as a flexible checklist so each round is repeatable
Automate the repetitive checks later, once manual testing shows you what's worth automating

The rest of this post covers what manual testing is, when to choose it over automation, and the five steps to get started.

Simple tests can save everyone a lot of frustration and give you a head start on delivering a product that works smoothly from day one. After all, wouldn’t you rather hear about issues from your development team than your customers?

What is manual testing?

Manual testing is a human tester exercising software, observing its behavior, and recording pass or fail results, without automation. The ISTQB Foundation syllabus notes that test execution "may be manual or automated"; the manual kind relies on human judgment and real-time interaction. It’s about understanding how the software performs in the wild, spotting clunky workflows, and confirming it feels natural for your users.

Why it matters

Automation is great at following orders, but it doesn’t have the creativity to say, “Hang on, this feels weird.” That’s where manual testing comes in. It’s the human touch: finding those awkward workflows or unexpected behaviors that only real users would notice, and helping you prioritize fixes before users point them out.

The benefits of manual testing

Manual testing doesn’t need a fancy setup or hours of prep. It’s flexible, creative, and perfect for spotting the weird stuff automation might miss.

Here’s why manual testing deserves a spot in your toolbox:

Human insight and creativity: Machines follow the rules; humans ask questions. Manual testing uncovers those “but what if...?” scenarios, spotting quirks that could frustrate users and helping you see the product as they would.
Flexibility: Software evolves, and manual testers adapt with it. Need to switch gears and test a last-minute feature tweak? No problem.
A reality check: Manual testing gives a snapshot of your product’s state. It’s not about running every test under the sun but confirming whether the basics work as intended.
Resource-friendly: Start small with what you have. No need for big budgets or fancy tools when a simple checklist can do the job.
Enhanced collaboration: Fresh eyes see what yours might miss. Involve your team – designers, developers, or anyone who can click a mouse. Each perspective adds depth and helps identify those sneaky issues that hide in plain sight.

Is manual testing right for you?

Manual testing isn’t a relic of the past. It’s a practical, strategic approach that puts your product through its paces in the way your users will. It’s about stepping into their shoes to answer the big question: Does this work the way it’s supposed to in real-world scenarios?

For dynamic, user-facing features where intuition, creativity, and flexibility are key, manual testing is your best bet. It helps you uncover the quirks, edge cases, and usability gaps that automated scripts can’t predict. Whether it’s spotting clunky workflows or identifying the little things that frustrate users, manual testing ensures your product feels as good as it functions.

But this isn’t about chasing perfection or testing every possible outcome. It’s about understanding your product’s state – its strengths, weaknesses, and how it holds up in the wild. By focusing on these insights, manual testing gives your team the clarity to prioritize fixes and fine-tune the user experience.

Manual vs. automation testing: when to choose what

Manual and automated testing work best as a team, each covering what the other can't. Here's how they compare:

	Manual testing	Automated testing
Setup time	Minutes	Hours to days
Best for	New features, usability, exploratory work	Regression, repeated checks
Cost to start	Low (a checklist is enough)	High (writing and maintaining test code)
Finds unexpected bugs	Yes	Only what the tests cover
Human judgment	Yes	No

Manual testing

Manual testing is the starting point, the first step in understanding your product’s state, and the best way to uncover those sneaky issues that only a human touch can reveal.

Exploration at its finest: Manual testing shines when you need creativity and judgment. Whether you’re testing new features or digging into edge cases, it’s all about the real-time adaptability that machines just can’t replicate.
Seeing the big picture: Beyond checking that something works, humans notice whether it works the way it should. Does that feature make sense on first use? Is the interface doing its job, or is it a usability maze? People are great at spotting these nuances.
Adaptability on demand: Features change, priorities shift, and manual testers are ready to roll with it. No test code to rewrite, just a willingness to dive in and get things done.

Automated testing

Automation plays an important role, taking over the repetitive, time-consuming tasks that don’t need human creativity. It keeps the basics in check and frees your team to focus on the interesting work.

Perfect for the predictable: Regression tests, unit tests, performance checks: automation thrives in these scenarios. Think of it as the assembly line of your testing workflow, keeping everything consistent and efficient.
Scale and speed: Once your automated tests are up and running, they can zip through thousands of checks in record time. But don't forget the setup. Building and maintaining that test code takes time and resources, so it’s not always the fastest or cheapest option upfront.

Why not both?

The smartest testing strategies blend manual and automation to play to their respective strengths.

Manual testing is your first responder, exploring, analyzing, and uncovering the unexpected. Once you’ve nailed down repetitive tasks or stable workflows, automation can step in to take care of the grind. Even automation-heavy teams keep a manual element: Martin Fowler's practical test pyramid notes that "even the most diligent test automation efforts are not perfect" and recommends keeping exploratory testing in your portfolio.

Remember that automation isn’t the end goal. It’s a tool in the toolbox, not the whole workshop. For smaller projects or rapidly evolving features, manual testing is often the faster, more cost-effective choice. Writing and maintaining automated tests can be its own time sink, so automate thoughtfully.

When repetitive tasks crop up, automation can take the reins, handling the routine so your testers can dig deeper into the creative, investigative work where they shine.

Balance is what you're after. Manual testing is the foundation, giving you the context and confidence to know where automation adds value. Starting here lets you build a strategy that’s both effective and efficient, creating a product that works well and resonates with users, without wasting resources.

Bottom line: Use manual testing to see your product the way your users will and to uncover the quirks that make or break their experience. Use automation to handle the predictable, repetitive tasks that need consistency when it's cost effective to do so.

How to get started with manual testing

Start with the obvious stuff and things quickly feel more manageable. Here’s how to break it down:

Step 1: Test the essentials

Start with the big-ticket items. If logging in doesn’t work, it’s game over. These are your critical paths: logging in, navigating key pages, making a purchase. The goal isn’t to nitpick every tiny thing yet, just to catch the glaring issues. Think of it as a "does this basically function?" test. Spot something clunky? Congratulations, you’re already adding value.

Step 2: Bring in fresh eyes

You could be too close to the code to see its quirks. Ask someone who hasn’t been elbow-deep in it. They’ll approach it like a user would, which is perfect for spotting the obvious stuff you’re too familiar with to notice. Bonus points if their testing style is totally different from yours.

Step 3: Write it down

Don’t rely on your memory. A simple checklist can work wonders for staying organized. Keep it flexible, though. Instead of “Click checkout,” try “Customer can complete checkout.” It leaves room for creativity and invites testers to explore. Plus, having a checklist means you’re already building a foundation for future testing cycles, nice and repeatable.

Step 4: Iterate and scale

Manual testing is like any good habit: it gets better over time. Start small, and with each round, tweak what works, ditch what doesn’t, and keep evolving. Focus on the areas that matter most first. You’re not aiming to test everything in one go; this is about building confidence and momentum.

Step 5: Automate if it makes sense

Manual testing is all about that human touch, especially for user flows and design quirks. But when the same thing needs checking over and over you may want to let automation handle it. The trick is balance: automate where it’s practical and saves time, but keep your testers doing what they do best, digging into the unexpected and uncovering the issues.

Finding the right manual testing tool

A good testing tool shouldn’t feel like a slog. It should keep everything organized while you focus on making your product better.

Take Testpad, for example: a checklist tool with real testing depth. Structured enough to keep things consistent across releases but loose enough to let your creativity shine. It’s a practical mix of order and flexibility, designed to make manual testing effective and fun (yes, fun!).

When choosing a tool, ask yourself:

Can I hit the ground running?
Does it fit my workflow without needing a PhD to figure out?
Does it make collaboration easy (because endless email chains tracking bugs are nobody’s idea of a good time)?

Look for features like checklist management, support for exploratory testing, and integrations with your go-to project management tools (Jira, Slack).

A great tool doesn’t bog you down with complexity. It simplifies your manual testing process without losing depth, grows with your team, and makes testing less about pulling your hair out and more about getting stuff done. Whether you’re just starting or scaling up, Testpad is there to make testing simple, effective, and dare we say, enjoyable.

Start testing today and improve tomorrow

Manual testing doesn’t need to be complicated. Even testing one workflow can reveal valuable insights and set your product on a better path.

The beauty of manual testing is that it evolves with you. Start small, refine with each iteration, and let your process grow alongside your product. As testing becomes part of your team’s rhythm, you’ll gain clarity, catch issues early, and keep development rolling smoothly.

Ready to simplify your testing process without giving up depth? Testpad’s checklist-based tools make manual testing easier and more effective, offering the structure you need without sacrificing flexibility. Sign up for a free trial today and see how it fits your team.

What is Session-based test management?

Stefan Butlin — Wed, 30 Oct 2024 00:00:00 +0000

Session-based test management (SBTM) is a structured approach to exploratory testing. Testers get a charter (a specific area to test) and a timebox (a session length), explore freely within that scope, then document what they tested and what they found. It sits between rigid, step-by-step test cases and completely unstructured exploration.

At a glance

SBTM structures exploratory testing into time-boxed sessions, each guided by a charter
The four components are sessions, charters, note-taking, and debriefing
It keeps the bug-finding freedom of exploratory testing while giving you progress and coverage to report
Reporting quality depends heavily on testers' notes, so results vary from tester to tester
Many teams land on something more pragmatic: a lightweight checklist that guides testing without dictating it

The rest of this post covers where SBTM came from, its four components, and how to decide whether it fits your team. To explain where it fits in the testing world, we first need to define a few other types of testing.

Traditional Test Case Management vs. Exploratory Testing

Let’s start with traditional Test Case Management or TCM. TCM is built around the concept of – you guessed it – test cases.

Test Cases are detailed instructions for completing a test, along with expected outcomes and any other data a tester might need to know or capture. TCM is most commonly used by enterprise companies with large QA teams. They need a more rigid structure so they can report on specific KPIs on a specific cadence.

There is a major downside to Test Case Management, though: it only catches the bugs you can anticipate.

To get around that, you might use exploratory testing, a form of testing that gives testers the freedom to test as they see fit. We like to describe it as testing with your brain switched on: deciding what to try next based on what you just observed.

Unlike TCM, testers aren’t following a set of instructions. They are modifying their tests on the fly, based on product behavior and what they’ve already observed. This adaptive approach to testing tends to unearth bugs or enhancements that may not have been found if testers stuck to a rigid list of steps.

By the same token, exploratory testing without any framing around it can be too unstructured.

What is session-based test management?

Session-based test management (SBTM) is a formalization of the more general idea of exploratory testing. Rather than letting testers choose what they want to do next, you assign them areas of an application to test for a certain period of time. The approach was created by James Bach and Jonathan Bach in 2000, and their original Session-Based Test Management paper is still the canonical description.

Why do we need this?

Because – like we hinted at above – without it, exploratory testing has no built-in way to show that everything that needs testing got tested. Testers just pick up your app and see what works and what doesn’t.

Exploratory testing is also limitless. When you ask testers how long testing will take, they reply, “Well, how long have you got?”

That wishy-washy response isn’t something you can share with your boss in a status meeting or with cross-functional partners so they can plan downstream work.

SBTM, on the other hand, ensures testers are confined to testing a specific thing for a specific amount of time so you can share specific results and timelines. At the same time, SBTM isn’t as restrictive as Test Case Management – testers still have the freedom to decide how to test, which can reveal unknown unknowns.

There are four core components of SBTM:

1. Sessions

Sessions are the length of time testers are to spend testing a piece of software. They can differ from feature to feature.

The idea is to budget time according to the complexity of the topic and the likelihood that there will be bugs in it. For instance, you may want to allocate longer sessions for new features with a higher probability of issues. Shorter sessions can go to established, stable, old features that haven’t changed.

2. Charters

Charters are basically a test plan with a time box. Testers are to spend a certain amount of time in each area of functionality, testing as they see fit. For example, your charter might be:

Set up and login - 20 minutes
Social sharing - 10 minutes
Account deletion - 15 minutes

…and so on. When testers are done, you know that each part of your app has been investigated at least once by a human for a given length of time.

3. Note-taking

Extensive notes should be the output of sessions and charters. Testers should journal what they tried during their sessions (in accordance with the charter) and what happened as a result. These logs should clearly show what testers tested and what they didn’t.

4. Debriefing

Debriefs are a chance to analyze and act on testers’ notes. During the conversation, pull out identified bugs and potential improvements to share with the development team. Then, plan subsequent sessions and charters based on what is left to test.

Here’s how SBTM compares to the approaches either side of it:

	Rigid test cases (TCM)	SBTM	Unstructured exploration
Structure	High: every step written out	Medium: charters and timeboxes	Low: ad hoc
Coverage tracking	Easy	Moderate	Hard
Bug-finding	Finds the bugs you anticipated	Anticipated bugs plus unknowns	Best at unknowns
Reporting	Easy	Depends on note quality	Hard
Best for	Large teams with formal reporting needs	Teams that want exploration with accountability	Experienced testers, early discovery

Does SBTM fit into your testing strategy?

Let’s just start by saying SBTM is much, much better than no manual testing at all. And it’s a good option for those who see the value in exploratory testing but want a bit more structure. SBTM makes sure you’ve:

Tested everywhere you need to (and didn’t accidentally forget whole chunks)
Spent adequate time on each of those sections
Stayed focused – sessions are similar to the popular Pomodoro productivity technique
Documented what’s been tested and what hasn’t

Plus, SBTM keeps humans involved, letting them brainstorm their own things to test and react to what they notice is happening – a much broader type of testing than traditional Test Case Management.

If testing were reduced entirely to step-by-step test cases, a robot could perform all the tasks all in the same manner. Human testers introduce subjectivity, using their unique background and abilities to pinpoint issues or potential enhancements you wouldn’t have found otherwise.

But SBTM isn’t perfectly project-manageable. It can come with:

A lack of consistent note-taking - Some logs might be more or less precise than others, some more pithy or less pithy than others, making it hard to know what, exactly, was tested. This could:
- Impact the extent to which certain features were tested across testers
- Extend the time it takes to debrief post-session
- Make it harder to standardize internal or external testing reports
Less predictable coverage - If a charter is too broad, testers might miss important features. For example, if a charter says, “Explore login for 10 minutes,” testers may or may not have remembered to check forgotten password functionality.
Subjectivity - Yes, it’s a pro and a con... Human testers also introduce variability. How well a login screen is checked, for instance, depends on the experience and skill of the tester.

To recap, SBTM is a good option if you like the idea of exploratory testing but need more structure. For some teams, though, that structure isn’t quite enough.

Why isn't SBTM used more?

Though we don’t have data to back it up, our perception is that SBTM isn’t used much. Perhaps it’s because the “test case management Process” – with a capital P – is just easier to track.

You can hand testers a thousand detailed test cases that trace back directly to requirements. If all those tests pass, you can say all your requirements have been tested. You’ve got the plans and audit trail to prove it.

But is that really true?

Sure, your app may have passed single-point tests, but did your testers find all the new bugs in your product? Maybe. It depends on how well those detailed test cases predicted the right bugs.

In all likelihood, someone writing a boring test case probably won’t have thought to include edge case tests in advance. A human, by contrast, invents their own tests, adapting to what they see. They notice things that look off and chase them down.

So, how do you get the reporting and traceability you need without restricting a tester’s natural ability to find bugs?

The pragmatic approach

There is no one single best way to test. But if test case management is too confining, unstructured exploration is too hard to track, and SBTM – though an improvement over pure exploratory testing – is still too uncontrolled, the best way to get things done might be to strike a balance between the two.

To standardize notes, you could create a templated grid in a spreadsheet or tool like Testpad. This keeps your testers on track while giving them the option to add in more tests as they think of them.

But make sure that pass/fails have specific criteria, as in, pass = “Yes, we looked at this, and there are no problems,” and fail = “This particular thing failed, and I have comments in the next cell over explaining what went wrong.”

To ensure testing coverage, you could make your charters more detailed.

But don’t go so far as to make each item in the checklist a “check.” Stick to high-level prompts using words like “look at” so a tester has autonomy over how to do their testing.

To make your testing more objective, you could reuse your charters.

But remember to iterate on them from release to release so testers review areas that were updated and remember to do regression testing.

Testpad is designed with this pragmatic approach to testing in mind, giving testers enough control to uncover the hard-to-find bugs while maintaining enough control over the process to make your manager happy.

Sign up for our 30-day free trial to give Testpad a try. Or, if you’d like to learn more about our take on testing, give our editorials a read.

Test scenarios: What are they, and when should you use them?

Stefan Butlin — Fri, 25 Oct 2024 00:00:00 +0000

Testing is key to understanding what’s working and what’s not during software development. But do you ever feel like banging your head against a wall trying to figure out what to test? We’ve all been there – but test scenarios are one way of making it simpler.

What is a test scenario?

A test scenario is, in simple terms, a high-level description of a functionality or feature in software that needs to be tested. It describes a situation or use case that the software might face, and that you might need to test.

In some software, the term ‘scenario’ can mean different things. In Cucumber, for example, a scenario represents a single test case, while a scenario outline is used when you want to run the same scenario multiple times with different sets of data.

But more broadly speaking, test scenarios can be compared to user stories in software development. User stories describe a feature or functionality from the end user's perspective, helping to plan what the software needs to do – and similarly, test scenarios help to shape what features or functionality needs to be tested. If you already have user stories, you can even use them to shape your test scenarios.

A test scenario for an online banking app, for example, could be to confirm that users are able to log in. Or if you’re working on a task management app, your test scenario might be to check that users get notifications.

With us so far?

Test scenario vs test case

While these terms can have different meanings in automated testing, when it comes to manual testing, a test scenario shouldn’t be confused with a test case. A test scenario is a high-level description of functionality to be tested, while a test case is a more detailed set of criteria for testing a feature or functionality.

There can be several test cases within a test scenario. Let’s think about that online banking app again. The test scenario to check whether users can log in may include the following test cases:

Check users can log in with valid username and password
Verify login with invalid username
Verify login with invalid password
Verify login with blank username and password

So where do test scripts come in?

Both test scenarios and test cases are different from test scripts. A test script is a list of step-by-step instructions for carrying out a test case. While a test case describes what needs to be tested, a test script gives a detailed list of steps to take and the expected outcome.

All of these are part of a test plan. The test plan is your overall framework and strategy for testing, while the test scenarios, test case and test scripts provide the specifics – in an ever-increasing level of detail – needed to carry out your tests effectively.

Got all that? Testing jargon can give you a headache – but we promise, it’s not as complicated as all the terminology makes it sound. Once you get your head around the different terms, testing is actually quite simple.

Importance of creating test scenarios

So, now you know what test scenarios are, why are they so important? In short, they put you in the shoes of users and help you to make sure that every function of your software works as it should.

Some benefits of creating test scenarios:

Thorough software testing: Test scenarios help you to make sure that all key functions and edge cases are tested. By coming up with test scenarios, you can be confident that every aspect of the software has been tested and verified, reducing the risk of missing embarrassing issues.
User-centric: Testing prioritizes the end-user experience, which leads to the creation of software that’s more intuitive for the user.
Identifying improvements: Testing can help you to spot any functions that require improvements or updates before release.
Improved efficiency: Test scenarios can help you to streamline the testing process. By breaking down complex functionalities into bite-sized scenarios, you can clearly see what needs to be done – making it easier to plan and execute tests.
Future planning : Streamline the future development process and learn what features work well and which ones need improvement – knowledge that can help your team to discover new use cases and better meet user needs.
Future documentation: Plus, testing scenarios provide a reference point for testing processes – which can make it easier for new team members to understand past decisions and test approaches.
Improve collaboration: Test scenarios give developers, testers and stakeholders a shared understanding of both your user journeys and your testing objectives.

Test scenario examples

For any software, you’ll need to test multiple functionalities, so here are some examples to better illustrate what a test scenario is.

1) New user sign up

If you have a tool, you’ll likely want to make sure that the sign up process is smooth. A key function to test, then, is the user registration process. So your test scenario might be:

Verify that a new user can successfully sign up for the tool

This is a high-level scenario looking at a single functionality (user registration). From this scenario, you can then create multiple test cases, like:

Testing sign up with valid details
Testing sign up with an email that’s already been used
Checking whether someone can sign up with a password that’s too long or short

2) Payment methods

If your software requires payment, you’ll need to verify that users are able to pay using different methods. So, your test scenario could be:

Verify that users can make a payment using different methods in an online payment system.

That could then be broken down into several test cases, such as:

Verify successful payment with a valid credit card
Check that payment fails with an expired credit card
Ensure that the payment process times out after a period of inactivity

3) Forgotten password

It’s inevitable that users will forget their password at some point – and they need to be able to reset it. A test scenario, then, could be:

Verify that users can reset their password using the 'Forgot Password' feature.

This top-level scenario describes a key functionality that needs to be tested. You could then write up several test cases, such as:

Check it’s not possible to reset password with an email address that isn’t registered
Verify that users receive a password reset email after entering a valid email
Verify that the new password field can’t be left blank

Best practices for test scenarios

Before you dive right in and start writing your test scenarios, here are some pointers to help you

Understand user requirements: Your test scenarios should align with user stories and requirements.
Prioritization: You should test the most critical functions and features first. You can prioritize based on factors like user impact, functionality criticality, and the likelihood of failure.
Different test types: You can create different test scenarios to cover different areas, such as functional testing, security testing and performance testing.
Clear objectives: Each test scenario should have a clear goal.
Keep it simple: Test scenarios shouldn’t be too complex or jargon-heavy. Keep it simple to ensure the purpose is clear and it can be easily understood by everyone.
Clear documentation: Track your test scenarios including descriptions, expected outcomes and actual outcomes – this will give you a reference for future testing.

How to write a test scenario

Are you ready to write your first test scenario? Here’s a step-by-step guide so you can get your testing scenarios right the first time, every time.

1) Understand the requirements

First things first: You can’t write an effective test scenario if you don’t understand what needs to be tested. So ensure you thoroughly review the software requirements, user stories and specifications to understand what functionality needs to be tested. From this, you should be able to identify all user interactions.

One great way of doing this is with mind mapping, which can help you to organize and visualize test scenarios. This can help you to brainstorm a range of possible user interactions and paths within the software to ensure that the software meets users needs and expectations.

2) Define the scope

Clearly define the scope of each test scenario, determining which feature or functionality will be tested. You’ll want to keep track of your test scenarios, so keep them organized in either a testing tool or a simple spreadsheet.

3) Write a clear title

Provide a concise and clear identification of the test scenario, helping testers to quickly understand what the scenario is about at a glance

4) Write a clear scenario description

The test scenario should be simple and straightforward, avoiding technical jargon – but it should be descriptive enough so you can see at a glance what needs to be tested.

5) State any preconditions

You should also outline any preconditions that must be met before the scenario can be tested. This could include things like having access to the software and a stable internet connection.

6) Define expected results

Be sure to outline what results you expect to see from each test scenario.

7) Review and validate

Once you’ve written your test scenario, review it with developers, testers and stakeholders to ensure it covers your requirements and aligns with the user stories.

8) Maintain and update

You can use your test scenarios again in the future, so don’t just write them and forget about them. Regularly revisit and update the test scenarios as your requirements change, or as new features are added – you can even keep a bank of standard test scenarios to use again in the future.

What tools to use for test scenarios

The tools you use for test scenarios will depend on your workflow and what tools you have available. If you already have user stories and are basing your test scenarios on them, you may already have tooling you can use.

But if you’re starting from scratch, there are various options:

Word processing documents: You can keep it simple and use Microsoft Word or Google Docs to write up your test scenarios.
Spreadsheets: Similarly, spreadsheets are a good way of creating, tracking and managing your test scenarios – and they make it easier to sort and filter information than word processing documents.
Mind mapping tools: You may find mind mapping an easier way of visualizing relationships between user stories and test scenarios. It’s a good method to use when you’re brainstorming, then you can document the scenarios more formally in a spreadsheet or tool.
Test management tools: Tools like Testpad allow you to easily duplicate and group tests into test scenarios, which can make things simpler when it comes to organizing and tracking your testing. For more complex needs, you might want to use test case management tools which offer additional features for managing detailed test cases.

Go forth and test

See, once you’ve got your head around the terminology, test scenarios are a really simple way of putting yourself in your users’ shoes and figuring out what you need to test. Taking the time to create well-defined test scenarios is well worth it when it comes to software testing. You’ll be able to test that every function of your software works as it should and – ultimately – deliver software that works.

The right tools can help you to streamline your testing efforts, making it easier to do everything from organizing to reporting on your testing.

We may be biased but if you want to find out how Testpad can support your testing efforts from start to finish, sign up for a 30-day free trial today.

How to write your first Test Plan

Stefan Butlin — Wed, 09 Oct 2024 00:00:00 +0000

You’re gearing up for a crucial software release, and the pressure is on. It’s easy to feel like your head is spinning with so much to think about, and moving forward in a clear way becomes obscured.

Yes, there’s definitely a place for sophisticated test plans that cover every edge case, integration point, and user scenario. But here’s the thing: you don’t need to sprint before you’ve learned to walk.

Sometimes, a straightforward approach can give you 80% of the results with 20% of the effort.

Let’s break down how to structure a test plan that’s effective, manageable, and gets you moving in the right direction.

But wait, what is testing?

At its core, testing is about gaining insights into the state of your product so you can make informed decisions.

It’s a little like a chef tasting a dish to see if it’s good enough before serving it to guests. Testing tells you whether your software is ready for release or if there are issues to fix before deploying.

The challenge is to develop a test plan that’s cost-effective and appropriate for where you are right now, keeping in mind that your needs will evolve as your product – and its complexity – grows.

What is a test plan?

In its most formal sense, a test plan can be an overarching document that outlines the entire QA effort – detailing who will conduct the testing, what the objectives are, the criteria for starting and stopping, how defects will be managed, and the timeline for everything.

But here’s the thing: Writing a traditional, standardized test plan can quickly become overwhelming. It’s easy to get caught up in perfectionism or lost in the rabbit hole of formatting and structure.

People often come into the process with preconceived notions of how comprehensive a test plan should be from the outset, or they might feel pressured to follow a process just for the sake of due process.

Instead of worrying about the entire structure and layout, the focus should be on creating a collection of test ideas or prompts (clear instructions that guide your testing) that are repeatable, measurable, and trackable.

The real value lies in getting something down on paper and trying it out so you can start refining the content. Don’t stress about making it 100% detailed from the start; after you run through a test once, you have far more perspective and then can start iterating and perfecting it. See Test plans, not test cases for why short prompts beat formal test cases.

Writing your first test plan

Writing your first test plan doesn’t have to be complicated, it can be as simple as jotting down a list of prompts. The key is just to have something written down, whether it’s on post-its, spreadsheets, wikis, or even a whiteboard. Use whatever works best for you.

But you might be wondering, what exactly should I write down?

Start with a list of the main features and functionalities you need to test. This ensures you’ll remember to check at least something from each of the core aspects of your product.
If you’re feeling stuck, try looking at your requirements documents, feature lists, user stories, or even the top slice of your backlog if you’re working in sprints.
To make it easier, take those user stories, requirements docs, or whatever you’re working with, paste them into Excel or document, and start editing them into tests.
Add other test ideas as they come to you.

Alternatively, you could create a mind map – start with a main concept, break it down into satellite topics, and then figure out each component that needs testing. This not only helps structure your thinking but also ensures that nothing important is overlooked.

Choosing a Where to Keep Your Test Plans: the Pros and Cons

When it comes to where you write your test plans, each option has its pros and cons. If you’re using post-its, pieces of paper, or a whiteboard, you might find it harder to share your work, especially if you’re working with a remote team.

On the other hand, spreadsheets or systems like Testpad are ideal because they’re intuitive and easily shareable, making them the easiest way to plan tests.

While there are specialized test case management tools out there, you don’t need to dive into those right away. These tools can be powerful, but they are often overly complicated to set up, requiring training and experience to use effectively.

Starting with something simple and accessible, allows you to focus on the content of your test plan rather than the complexity of new tools.

Don’t lock yourself in with word-for-word test plans

You don’t have to write out every test word for word.

That level of detail might be necessary if your testers are complete strangers to your product and methods every single time. But for most teams, their testers are only new to the system once and then will return to the same tests many tens of times.

So, don’t worry about telling testers how to test. The real value in your first test plan is simply listing what needs testing – think of the items in the plan as "test prompts" or "ideas of things to take a look at."

For example, consider the login functionality. You don’t need to spell out every step, like loading the login page or where to click. Instead, just remind testers to check that logging in works with the correct username and password, and that it should fail with an incorrect or blank password.

By keeping things concise, you allow testers to focus on the important parts of the process without getting bogged down in unnecessary details.

If something does get complicated, it’s better to reference the product documentation elsewhere – assuming you’ve already written that, right?

Then, iterate on your test plan over time

Writing test plans is about establishing a repeatable process (as opposed to having nothing written down and making it up every time you need to test).

Once your initial test plan is in place, the real work begins: iterating on it over time.

But why is iteration so crucial? It’s about improving that process gradually, to learn from experiences of previous releases; and to lower the bar for starting - knowing that you'll be improving it later.

With a solid process, you ensure that everyone is aligned on what needs to be tested and what will be tested. It helps you determine the resources required, gives structure and purpose to your testing efforts, and, most importantly, catches bugs before they reach your customers. It also forces you to think through potential risks and prepare for them.

How to iterate a Test Plan?

After running your tests, you have the foundation to iterate.

Take a step back and evaluate the results: How did testing go last time? As in, did any problems get discovered after testing that perhaps should have been found during testing? Was it reasonable that they were missed? Is there something more you can do next time to reduce the risk of a similar thing happening again?

But keep in mind – don’t let this process become overly complex. Just because you haven’t yet built out an automated test and CI system doesn’t mean you should delay writing a plan or getting started with manual testing.

The goal is to have something actionable in place and then improve it as you go.

Some ideas for iteration

As you continue to iterate on your test plan, consider incorporating these areas into your approach:

Stress tests: Evaluate how your product performs under heavy loads.
Different environments: Test across various browsers, platforms, devices, and conditions like network speeds or weather.
Performance testing: Assess the speed and efficiency of your product.
Automation: Save time by automating repetitive tests.
Accessibility: Ensure your product is usable for people with disabilities.
User experience and ease of use: Focus on the overall user journey and interface simplicity.
Maintainability: Plan ahead for how easy it will be to update and manage the system over time.
Security: Test for vulnerabilities to protect user data and prevent breaches.

It’s also important to assess the tools you’re using. Are they working well for your team? How easy is it to refactor your tests when needed? If you find yourself spending too much time formatting everything to look nice, ask yourself if that’s really worth it?

The same goes for how reusable your plans are from build to build or release to release. You want your test ideas to be so easy to write and add that no one hesitates when a new idea pops into their head.

And don’t forget, AI tools can be a powerful ally in your testing process. You can use something like ChatGPT to generate a list of test ideas for a product with specific features, and then ensure your plan covers all those bases. Always make sure to check over your AI results as AI can make mistakes, but in general AI can help you fill in gaps you might have missed and ensure your testing is as comprehensive as possible.

Conclusion

While having a higher-level strategy document can be useful, the real value lies in a straightforward checklist of things to remember – a list of test prompts that form a simple test plan.

The key is to be pragmatic about the level of detail you need from the start and to balance the time spent on planning with the actual testing. It doesn’t have to be complicated – just get something down and refine it as you go.

Remember, you can build your list by jotting down main features and functionalities, incorporating feedback from previous testing, and gradually adding more types of tests, such as stress, performance, and security.

Over time, you can iterate on your plan, moving items into the main plan, automating where it makes sense, and evolving your approach to ensure thorough, efficient testing. Don’t overthink it – just start simple, and improve as you learn.

Bias aside, we think Testpad is a great tool to help you simplify testing and we offer a free 30 day trial to see if we are the right fit for your testing needs.

The surprising benefits of Manual Regression Testing

Stefan Butlin — Tue, 01 Oct 2024 00:00:00 +0000

When most people think of regression testing, they think “automation” – and while automation is definitely where you'll want the majority of your regression tests to be, you shouldn't overlook the benefits of having a manual regression testing process.

If you're not doing any regression testing at all (or if you do, but it's all automated and those automated tests aren't up to date because you haven’t had time to catch up), have a read below and see if running some manual regression testing might be the answer.

What is manual regression testing?

Regression testing is about trying to make sure your product doesn't regress, and making sure that bugs which have been previously fixed don't come back to haunt you. It's a safety net that can catch what might otherwise be embarrassing. No product is totally bug free, but a product that repeats the same bugs gives the impression of a development team that doesn’t learn from its mistakes, which isn’t a good look.

The regression testing process involves creating a growing list of tests to check that everything that has broken before is still working in the latest release. Think of it as the equivalent of a vacation packing checklist. You go on vacation and realize you forgot the sunscreen, so as well as going out to buy some, you amend your packing checklist with a "did I pack sunscreen?” option for next time.

Automation tends to be the go-to for most organizations when it comes to regression testing. It’s fast, reliable, and super efficient – and it’s a perfect solution when the conditions are right and budget allows it.

So where does manual regression testing come in? Manual testing follows the same process, but the testing is performed manually, by hand, with a human working through a defined list of bug checks.

It’s less about speed, because automation is so fast, and more about having a regression test for a bug immediately – regardless of whether you have the time and resources to implement an automated test for it.

It's also a good solution for when automating a test is never going to be cost effective, a test is too difficult or awkward to code, or there’s simply not enough developer capacity available.

When to go manual, and when to automate

So which should you choose, manual or automated testing? It boils down to trying to automate regression testing when it’s a cost effective option, and using the manual process for everything else.

When to use manual regression testing

The key benefit of manual regression testing is that you can bring a new test into existence almost instantly. All you need to do is open your regression test list document and type in a new test.

It can be a good idea to have a regression testing process where, for every bug that's fixed, you add it to your list of manual regression tests. Then later, when resources allow it, consider promoting these tests into your automation framework, if you have one.

Manual testing is your best friend in situations where you need to catch previously encountered bugs, but can’t immediately automate a test for whatever reason. Having a checklist of predefined manual tests means your team can start testing immediately, rather than waiting for automation scripts to be created, debugged, and launched.

Regression tests don’t need to wait until you have time or money or resources to automate them, because their value stands however they're implemented.

When to use automated regression testing

Basically, any test that can be automated cost-effectively should be, as soon as resources allow it. Automated tests can be run over and over again, near instantly, and often automatically when a developer makes any change to the code base.

This lets you identify issues as soon as they're created, which can also be the cheapest time to fix them, as the relevant code is still fresh in the developer's mind.

But of course, not all tests can be easily, cheaply, or quickly implemented in code. Many tests are tricky to automate, sometimes requiring complex test harnesses to replicate conditions and test responses.

Every automated test adds more code that needs maintenance – and that will have bugs in it from time to time that also need to be detected and fixed. So automations aren’t a catch-all solution by any means.

In the early stages of development, or dealing with iterating on complex features, it’s best to start with manual tests. As your software becomes more stable, and your regression tests begin to prove their value, consider automating the tests where it makes sense to do so.

Remember, the goal isn’t to automate everything. It’s to automate wisely, leaving room for your human testers to step in and check things when it makes sense.

Tips for Effective Manual Regression Testing

The manual regression testing process is simple. You just need to build and maintain a list of tests for things that have been previously detected and fixed. Here are some tips to get you started:

Make a list

Open a new spreadsheet or document (or use a tool like Testpad) to keep your list of manual regression tests in. Decide what you’ll be adding to your test checklist, and make sure that all the relevant people know where the checklist is located so they can add to it and run manual tests when resources allow.

Maintain your list

Your list of manual regression tests should evolve along with your software. Every time a bug is fixed, add a new test to your checklist to make sure it doesn’t come back to haunt you.

Keep it simple

Don’t overcomplicate things. A simple checklist can be your best friend for manual regression testing. Use it to ensure you’re covering all the bases without missing a step. Tools like Testpad can help keep your checklists and testers on the right track, but even a spreadsheet can do the trick.

Review your list

It’s a good idea to regularly review your list to see if there are any manual tests that could be automated.

Prune your list

Later on in the product life cycle, say after several releases, your manual test list might be taking your testers hours to run through. If the list gets too long, consider pruning older tests for bugs that are very unlikely to happen again, or if they do regress, no-one will remember anyway so it won’t be so embarrassing.

Prioritize your tests

If the test list gets long and needs to be long, consider prioritizing the more critical or important aspects of the product. This will find any regressions in more important areas earlier in the process, saving time if you need to fix and restart the regression testing process.

Is regression testing the only type of testing you need?

Regression testing is a useful part of the development process, but it doesn’t give you a complete picture of what’s going on with your software.

Because each regression check (whether manual or automated) is precisely defined, the scope of testing is limited to exactly those checks. Any bugs or problems that might exist outside that detailed scope won't be detected.

For the wider picture of possible problems, a good test strategy will include methods that go beyond regression testing.

Exploratory testing

Exploratory testing is arguably the best kind of testing. It takes advantage of tenacious human curiosity and intuition to hunt for the unexpected, to dig into software, invent test ideas on the fly, and react to how the software is behaving.

Where regression tests make structured, precise checks for specific things, exploratory testing is more freeform. Your human testers are free to use their own ideas to move around in the software, and react to what they're seeing. In the process, they learn much more about the state of the software and whether it’s ready to ship or not.

Pair regression testing with exploratory testing and you've got a great test process that is likely to find bugs, both new and old.

Other useful tests

Unit testing: These are automated tests for small units of code (components, classes, functions, capabilities), written beside or together with the code they're testing. They are always run automatically, usually as part of continuous integration. It’s a great process for helping to make sure each separate tiny part of a software system is doing what the developer intended, but it’s not as good for the bigger picture. This means it’s not a substitute for exploratory and regression testing of the whole product.
System/integration testing: Essentially this is just testing at a higher level from individual components. Simpler products don't need to worry about taking this approach versus just testing the whole product. If your system is more complicated, then this article probably isn't for you anyway!
Stress/performance testing: It’s a good idea to make sure your testing (of whatever kind) includes checking system performance – both normal performance, and performance under heavy usage. These tests could be a separate process, or could be part of the scope of your exploratory testing, or even your automated testing (if it’s automatable).
Accessibility testing: The global standards and guidelines set out for web accessibility can help to guide your testing and make sure your software is usable by people with disabilities.
UX testing: This is testing carried out by live users. By setting tasks or asking targeted questions, users can give you feedback on how easy and intuitive your product is to move around in, so you can identify areas to improve on before release.

Each type of testing has its place, and combined with manual regression testing, they’ll help to make sure your software is ready for every user scenario.

Wrapping up

Manual regression testing isn't really about manual versus automatic testing. It's just about doing some regression testing in the first place, and not failing to do it because you're waiting for the time and resources to automate everything. It’s also about accepting that some regression testing is simply going to be easier or more efficient to perform manually.

Whether you’re using manual or automated tests, it’s important to remember that regression testing is just one piece of the development puzzle. To build truly resilient and stable software you need a variety of testing methods, with each one bringing something different to the table.

We may be bit biased, but if you’re looking for a simple and effective tool to help you stay on track with your manual regression tests, check out Testpad. We combine spreadsheet simplicity with the technology you need to quickly organize and assign your tasks, so you can spend less time documenting, and more time testing.

Mind Maps for Test Planning in Testpad

Stefan Butlin — Fri, 13 Sep 2024 00:00:00 +0000

When creating a test plan from scratch, you’re likely going to need a structure or tool to help you design a thorough testing process. The ambiguity of not knowing where to begin can be challenging. Without help it can lead to incomplete test plans, overlooked scenarios, and ultimately, embarrassing gaps in your testing that customers might find.

Mind maps make an excellent methodology to create a plan that takes your testers across everything you want to cover in testing, thus giving you the best chance of discovering as much as possible about how ready your software is (or not). They are also a natural fit for planning exploratory testing, where you want a map of what to cover without scripting every step in advance.

Mindmapping doesn’t need to be limited to a 2D format on a big sheet of paper. We’ll explore how to build them as a 1D outline that gets increasingly more detailed as you iterate your plan, and show how easy it is to use mind mapping strategies in an agile test planning tool like Testpad.

What is Mind Mapping?

Mind maps are a visual way to represent ideas, information, or tasks. They are a graphic representation of hierarchical concepts; a way to organize thoughts.

If you were to imagine a mind map you might conjure up images of a classic whiteboard. You’d start with a central idea in the middle connected to different bubbles of ideas, with those ideas spawning off into the next related idea.

At each node in the diagram, it's easiest to brainstorm “what should we be thinking about for this item”. At this point you know you don't have to dive into all the other nodes yet because you're focused on a singular point. But, of course, if you do think of something random from elsewhere, you can add it to a relevant next node.

Every connected thought or piece of information becomes a thorough exploration of an idea – the perfect foundation for a test plan.

Why Mind Mapping works for Test Planning

Drawing up a test plan, or a list of things you don’t want to forget during testing, can be daunting. You’ll want to cover all potential outcomes: testing everything that was specced, and everything that wasn't but could be reasonably expected or anticipated by your users.

Mind maps offer a great solution for exploring the expected and potentially unexpected behaviors of your product. And they're great in several ways:

Visual Clarity: Mind maps provide a clear and visual representation of ideas, making it easier to understand the structure and visualize coverage.
Improved Organization: They help in organizing thoughts and tasks logically, ensuring that no important aspect of the software is overlooked.
Enhanced Creativity: The non-linear format of mind maps encourages creative thinking and allows for brainstorming different scenarios and test cases.
Quick Modifications: Mind maps are flexible and can be quickly updated or modified as new insights or requirements emerge during the planning phase.
Broad Overview: They provide a comprehensive overview of the entire testing process, helping to identify potential gaps or areas that need more focus.
Time-Saving: By visually organizing information, mind maps can help speed up the planning process and make it more efficient.

Simply getting started can be one of the toughest parts of test planning, and a mind map can be just what you need to get you off the ground. Offering you a starting point and just enough structure to give you the confidence to press on with putting pen to paper.

The mind map methodology is helpful, but you may be wondering: how can I actually use mind maps to build test plans that aren't drawings on big sheets of paper?

Making the Most of Your Mind Map: Going “1D”

In all the discussion we’ve had about mind mapping, we’ve been referring to a “classic” 2D format – an expansive diagram with interconnected nodes representing related ideas.

It's ideal for brainstorming when first starting out, but when trying to use a 2D whiteboard scribble as the basis for a test plan, it becomes difficult to convert that into something that will collect test results, let alone be re-usable next time.

This is where you might consider building text-based hierarchical outlines – essentially "1D mindmaps" – instead.

Just as if you made an export from a mind mapping tool, you'd get an outline list (in text, XML etc) of nested items. With that, you’d put these into the column of a spreadsheet (or testing tool) and collect results in columns to the right.

Mind Mapping Tools: 2D vs. 1D Options

2D Options

Numerous free tools like Miro, Canva, Figjam, and ClickUp allow for creating 2D mind maps.

These tools are great for the initial stages of test planning, providing a visual layout of ideas and scenarios. These mind mapping tools make it easy to collaborate with a team and allow everyone to contribute to their own sections of the plan.

Worth noting, most of these tools can export mind maps into an outline-structured text (1D) that can be used in a testing tool or spreadsheet.

1D Options

You could argue that Spreadsheets are the original test planning tool. They’re the ultimate blank slate for organizing a test plan (or really any data for that matter, it’s a blank sheet of rows and columns after all!)

A spreadsheet can be adapted to mimic a 1D mind map by creating a linearized test plan, though with all the freedom they afford, you do experience some important limitations:

Difficult to Build an Outline Structure: Within a spreadsheet it’s hard to make indented rows. Every row in a spreadsheet is just a row that's the same level as the one before it, so it’s harder to maintain a hierarchical structure of information that mimics a mindmap.
Manual Effort for Consistency and Formatting: Building and maintaining a test plan in a spreadsheet is labor-intensive when it comes to formatting information and being consistent with updated information and results. The manual nature of spreadsheets requires managerial oversight and a game plan for keeping information up to date.
Lack of Professional Reporting: If you’re testing, odds are you’re sharing results with team members and stakeholders. Spreadsheets may not be the easiest to navigate, most professional looking option when it comes to sharing reports with stakeholders who need to weigh in on testing results.
Disjointed System: Information can become fragmented across multiple spreadsheets and software, causing friction and inefficiency in the testing process. If a spreadsheet is lost or the one person who manages the test plan in a spreadsheet quits, you could lose your test plan altogether.

Introducing Testpad: A “1D Mind Mapping” Tool Perfect for Test Planning

Testpad is a test planning tool that builds test plans as outlined structured hierarchical lists – exactly like a 1D version of a mindmap.

As you type, you are essentially building a one-dimensional mindmap, starting with high-level concepts and iterating with more detail at deeper levels.

When you start planning in Testpad, the process begins with a short list of high-level system features or aspects. From there, it’s easy to go back and expand on any item. Simply hit "Enter" to insert new ideas and elaborate on the initial points you’ve made, allowing for iterative refinement. This flexibility means that you can always revisit sections to add more detail as your test plan evolves.

You can easily build grouped sections (just press tab/shift-tab to indent and outdent) eliminating the frustrations of spreadsheets, where pressing the wrong key can jump you to a different cell.

By creating a hierarchy of test prompts, you can break down complex test cases into manageable parts (as you might singularly focus on building out one module in a mind map).

Where spreadsheets presented challenges: lack of professional reporting, a fragmented system, and difficulties with formatting information into a mind map-like structure; Testpad inherently solves those problems: it's a single source of truth containing your test plans and results, everything is arranged and formatted with the job of test planning and reporting in mind, and is a perfect fit for mind mapping with test plans built as hierarchical checklists.

Testpad’s structure very much leans on a mind map’s ability to create overarching plans, while enabling detailed documentation and results tracking.

You can easily publish real-time reports to share with stakeholders, or even give them guest access to join the testing process. Testpad becomes the go-to homebase for all test plans and results so no important test case gets lost in a disjointed system.

In breaking down test plans into manageable sections, Testpad helps you stay organized and focused, making it easier to navigate through your testing process.

If you’re ready to get your testing underway with ease, clarity, and precision, you can try out Testpad risk-free for 30 days, with no credit card needed to sign up.

Test Case Management: Classic Tools vs. Modern Solutions

Stefan Butlin — Fri, 30 Aug 2024 00:00:00 +0000

You’ve likely landed here because you are either new to testing tools or are unhappy with the testing platform you’re currently using.

We understand that’s a frustrating spot to be in. You need to run tests now but you’re stuck having to figure out what tool to use first.

If you’re knee-deep wading through research on tools and keep running into questions like “What even is test case management?”, “How would I know what is the best test case management tool for my team?”, or even “but they have way more features than I need”, we think your answers lie in understanding your two main options: traditional test case management (TCM) vs more modern, agile tools.

What Do We Mean By “Traditional Test Case Management”

You'll find we refer a lot not just to 'test case management' but often more specifically to 'traditional test case management’, so it’s worth defining what that means.

We see traditional TCM as tools that are built around the concept of a "Test Case" - they help you create, organize, execute and track test plans by building and managing collections of Test Cases stored in a database. You might even think of these tools as being database-centric.

"Test Cases" are formal test instructions consisting of several parts, usually including Title, Environment, Steps to execute, Expected outcomes, and other metadata (like project, components, priority, and so on).

Typically test cases are created and edited one at a time. You’d click on a new test case, fill in the form fields for each section, then click on save, etc. (This is a relevant distinction when we explain nontraditional options later).

Traditional TCMs are often used by enterprise companies and large QA teams with demanding process controls. The formulaic testing structure can be a preferred choice for teams with managerial oversight and tight standard operating procedures. The complexity of many traditional TCM software tools arises from the level of controls that bigger companies want to apply to managing huge teams, across multiple departments, and dozens to hundreds of projects.

Traditional TCMs would be names you might be familiar with if you shopped around for testing software – TestRail, Zephyr, Practitest, etc. Most of the popular TCM’s would be considered traditional in the sense that they are heavyweight software tools - that plan testing based around the database-centric management of test cases. If TestRail is the one you're weighing up, we've compared the two approaches side by side in Testpad vs TestRail.

So what would be a more modern alternative?

Anything that's not "test case' based could be considered a more agile, alternative option.

Notepads and spreadsheets would count, and indeed, are useful places to get started, simply for building a list of things to remember to test, without the burden of having to format those tests according to some process. However, we wouldn’t define spreadsheets or notepads as modern or agile.

Our own Testpad was built precisely because of this gap: the lack of pragmatic, lightweight tooling for simple test case management.

Testpad: A Pragmatic Alternative

Testpad is built around the idea of checklists (documents we call "scripts" or "test scripts", and as such, could be thought of as a document-centric approach contrasting the database-centric approach of traditional TCM.

Freeform checklists, along with some outlining structure (think hierarchies formed from indentation), make it very easy to structure test plans in a lightweight and flexible way. The deeper question is whether the test case is the right unit at all – see Test plans, not test cases for more.

You could write them out so they look like test Cases, but there's no need to. Often it's faster and more useful to just prompt testers with features, ideas, or user-stories, to review.

This makes it ideal for more exploratory style test processes, where you want some kind of plan for what you're doing, but don't want to overly prescribe exactly what the testers have to do.

This testing setup is simply intuitive. There's no training needed for what exactly a test case is or what it should or shouldn't have - it's just obvious how to write a list (a checklist) of things you want to remember during testing and then executing on that list.

Traditional TCM, A Pragmatic Alternative, Or Both?

There are plenty of people who find that staying with a traditional tool makes sense for them. Some teams should (and do) go for both a traditional and a modern alternative - augmenting their tool set with an agile/exploratory tool while keeping their TCM for due diligence.

However, we have a feeling that most of our readers fall into one of two camps:

Teams that are in a mess with spreadsheets thinking there must be a better way, but not impressed with the complexity and constraining rigor of traditional TCM tools.
Teams that are used to TCM wondering if there's something lightweight, more agile and modern, especially those trying to be more exploratory (less prescriptive) in their testing; or just tired of maintaining test cases one edit-form at a time.

That leaves these two camps in a bit of a bind: what they’re currently doing or using isn’t working and they need to find a solution that works.

So, which to choose?

If you're in a mess with spreadsheets, the obvious path is to try the easy upgrade to a tool like Testpad.

If you're unhappy with your TCM tools in general, then try running a project with a lightweight alternative. Or review the needs of your current projects and see if having both kinds of tools available would be a good fit.

Changing the Way You Test With an Agile Alternative TCM

Traditional TCM can be like using Gantt Charts from the 1990s vs modern tools like Trello, Notion, Basecamp.

You likely ditched Gantt charts in the ‘90s, so it begs the question: why are you still using traditional TCMs?

They can be a cumbersome and an ineffective approach to the ultimate goal of testing: learning as much about the state of your software in as little time as possible.

Testpad enables a pragmatic approach to testing that allows you to stay dynamic and iterative in the testing process.

If Testpad sounds like the simple modern test planning tool you've always been looking for, you can sign up for a free trial of Testpad for 30 days risk-free without handing over your credit card number. If you love using Testpad (and we hope you do!) we offer several tiered pricing plans to suit any team size.

Why exploratory testing should be part of your QA strategy

Stefan Butlin — Thu, 16 May 2024 00:00:00 +0000

Teams can over-rely on automated tests and miss the deeper value of exploratory testing – the hands-on, creative investigation that uncovers hidden bugs and real-world issues.

Balancing speed, thoroughness, and creativity isn’t easy. Without exploratory testing, products can sail through every scripted test but still break once customers start using them. Exploratory testing is your safety net, your magnifying glass, and your best chance to find problems you didn’t even know existed.

What is exploratory testing?

Exploratory testing doesn’t have one single definition, but the common thread is that it’s a dynamic, hands-on approach. Officially, the ISTQB describes it as testers designing and executing tests on the fly, using their knowledge and what they learn as they go.

But if you ask us, it’s really just making it up as you go along, with your brain firmly switched on. In other words, exploratory testing means deciding what to try next based on what just happened, making it reactive, thoughtful, and fast-paced – much like the way real users interact with your product.

The strategic role of exploratory testing

Think of your QA strategy like an investment portfolio. You don’t put all your money into one stock, you diversify.

Each testing method plays a different role:

Automated testing handles the knowns. It’s your safety net for regression and your speed boost for fast release cycles.
Scripted testing checks that you’re meeting documented requirements. Good for compliance and repeatable flows.
Exploratory testing is your wild card. It finds the bugs you didn’t think to test for. The ones that slip through every net until your users find them first.

In short: exploration covers what you didn’t expect, whereas automation only covers what you did. That’s why exploratory testing belongs in your QA strategy. It fills the gaps no other method can cover.

To build a QA strategy that catches both known and unexpected issues, it's crucial to know why automation alone won't cut it. We explain this more in our guide to QA automation limitations.

When exploratory testing delivers the most value

Exploratory testing doesn’t need to be everywhere. It works best when risk is high or user behavior is unpredictable.

Where exploratory testing adds the most value:

New features where it’s still unclear how people will use them
Products that customers interact with directly, where the experience matters most
Systems where mistakes could lead to real costs or damage your reputation
Complex setups that don’t follow simple step-by-step processes
Agile teams working quickly with lots of changes

Where it’s less critical:

Established products with predictable use
Internal tools used by trained staff
Low-risk updates or areas already covered by thorough automated tests

This isn’t about skipping steps but about focusing your time and energy where it will pay off.

Resource allocation: A rough guide

Wondering how much exploratory testing your strategy needs? Here’s a rough framework to start with:

Feature type	Exploratory effort %
New features	30-40%
Stable functionality	10-20%
Business-critical	50%±
Experimental ideas	40-60%

This isn’t gospel. But it helps you think beyond "we should do more exploratory testing" and start planning for it like the strategic layer it is.

Common objections (and how to solve them)

“I need to show coverage."

Use lightweight checklists. Keep a record of what was explored, what passed, and what broke. You don’t need a full test case library. Just show what was tested and what worked.

“I can’t estimate how long it’ll take.”

Set a fixed time for your testing – say, 60 minutes – and stop when that time is up. This is called “time-boxing.” It keeps your testing focused and manageable, so you won’t spend forever trying to cover everything. You might not find every issue, but you’ll make steady progress and know exactly when to stop.

“It’s not repeatable.”

That’s the point. You’re testing for things you didn’t plan. But you can capture good test ideas and reuse them next time, especially with tools like Testpad, where adding prompts is quick and easy.

How to run exploratory testing without losing control

One method that brings structure to exploratory testing is Session-Based Test Management (SBTM). This approach uses time-boxed sessions, clear goals (called charters), and lightweight documentation to help testers stay focused. Giving you visibility without killing creativity.

Exploratory testing isn’t an excuse for chaos. You can keep it structured without locking testers into a script.

A practical format looks like this:

Define what to explore (a feature, a scenario, a risk)
Time-box the session (30–90 minutes)
Ask testers to jot down:
- What they tested
- What passed
- What broke
- What they’d do next time

You can even write simple test charters like:

“Edge cases in checkout flow with multiple currencies”
“Incorrect passwords and password reset behavior”

This gives testers flexibility while giving you visibility. Win-win.

Integration with your QA workflow

Exploratory testing works best when it’s embedded, not tacked on.

During design: Test ideas and assumptions before coding starts
During development: Find bugs while features are still fresh
Before release: Explore risky areas that automation might miss
After launch: Investigate real user-reported issues or odd patterns in analytics

It’s not a separate process. It’s a mindset that fits anywhere in your QA workflow.

Measuring the impact

Not everything worth doing is easy to measure, but exploratory testing can still show value. Try tracking:

Problems caught: How many important bugs are found through exploration?
Areas missed by other tests: How often does it find things scripted tests missed?
Time to insight: How quickly can testers understand a new feature?
User-facing issues caught: How many embarrassing bugs never make it to production?

These aren’t perfect metrics – but they’re meaningful. And they help justify the time investment.

Organizational readiness

Exploratory testing only works if your culture allows it.

You’ll need:

Testers with product intuition and curiosity
Processes that allow room to explore
A culture that values learning over box-checking
Managers who care more about insights than spreadsheets

If your environment is rigid, time-obsessed, and allergic to “unstructured” work, you’ll need to shift that mindset before this really works.

Pragmatic tools make it easier

Exploratory testing doesn't need heavyweight tools, but the right tool helps.

Testpad is built for this style of testing. Its checklist format lets you:

Plan sessions with as much (or as little) detail as you need
Record simple pass/fail outcomes
Add notes on the fly
Track progress at a glance
Share results with anyone, no extra logins needed
Invite guest testers for User Acceptance Testing or extra help when you're late for a release

It's built for people who want to actually test, not just update fields in a database.

Smarter testing starts here

A good QA strategy doesn’t just test what you built. It explores what it really does.

That’s where exploratory testing comes in. It’s how you learn what your users are likely to discover for you.

You don’t need to replace your current approach. You need to balance it. Add exploration where it matters most and let our testers think. Track just enough to prove value. And use tools that support you, not slow you down.

Testpad makes it easy to bring exploratory testing into your workflow with simple checklists, clear results, and just the right amount of structure. Try it free for 30 days, no credit card needed.

Don't Only Automate Your Testing

Stefan Butlin — Fri, 01 Dec 2023 00:00:00 +0000

Automated testing has quickly become the go-to mantra for many software teams, hailed as the holy grail of efficiency and reliability. While its advantages are undeniable, the question arises: Should every testing scenario be automated? In this piece, we’ll explore whether the ROI of automation deserves its reputation, covering its pros and cons in the context of the type of testing you need to do and the resources you have.

If your software team is guilty of always reaching for automated testing without considering the possibility that manual testing might actually be cheaper or more appropriate, keep reading.

What is automated testing?

Automated testing is when tests are performed by software instead of manually by humans; a way for developers to instantly validate the functionality of their code, using code, rather than doing it by hand.

Using special frameworks and software, developers can create and run thousands of tests while they sit back and sip their coffee. And because testing would otherwise be done manually, automated tests save developers significant time once they are written, which they can allocate to bug fixes, enhancements, and new development.

An ideal scenario for automated testing would be:

You have an established collection of automated tests
Engineers are committing changes to the code base
You have a continuous-integration system immediately re-building and re-running the automated tests
The engineers immediately learn of any new problems that their recent changes introduced

Automated testing can be considered in most engineering projects, from website frontends and backends to mobile apps, to embedded software, to everything in between. For instance, you can automate:

Website testing. With tools like Cypress and Selenium, developers don’t even need to physically write tests. As a developer pokes around a site, the software runs in the background, tracking static and dynamic web elements like titles, images, and buttons and turning them into corresponding test scripts. Developers can augment with more scripts and control when the tests run. Post-execution, they can see where commands failed almost immediately.
Unit testing. JUnit and PyUnit frameworks – built for Java and Python, respectively – allow developers to speed up their testing at the code level. Engineers can define and organize test cases for each method or class and then schedule them for execution. When tests are done running, developers get notified of all failures that need fixing and can address each as they see fit.
API testing. Building and testing APIs with live environments can put systems and processes at risk. One go-to API testing tool is Postman, which allows developers to create and automatically execute tests for various API requests (e.g., GET, POST, PUT, DELETE) with specific parameters, authentication details, and payloads – without disrupting the flow of work. Running multiple tests at a time helps developers catch and fix errors in staging environments before API connections break.

As these examples suggest, automation can be useful for your development team, helping them iterate on their projects and deploy changes quickly (aka the key to keeping internal and external customers happy).

And yes, you should be automating your testing

Though this article is about why we shouldn't always be automating testing, we must acknowledge that automated testing has lots of benefits. Namely:

Speed of execution. Once your test scripts are written, you can configure your automation platform to perform thousands of tests in near-real time.
Consistency. Automated tests run the same way every single time. So, if you get a different result, that means some part of your code was changed and may need to be tweaked.
Quick bug identification. If automated tests are running constantly, they will find bugs as they are created. The closer you are to the point of bug creation, the faster and cheaper it is to fix it. If a few months go by and the original developer hasn’t documented the bugs extensively, they (or someone else who has assumed their role) will have to fully relearn that subcomponent to figure out what’s wrong. That could add days or even weeks to the resolution time.
And thus, comprehensive unit testing can protect against future bugs when systems are later modified to use new aspects of components.
Automated testing can happen at the unit level. Automated testing software enables developers to test each component in relation to every other component. This is helpful because components are often capable of more than they need to be, and end-users can't test behaviors outside of what’s possible to do with their app or system permissions.

…But automation isn’t always the answer

Many companies don't hire testers. They always have developers. And so they try to get their developers to write the tests, and developers are ONLY ever going to want to automate a test so they don't have to do it again.

But in certain scenarios, automation may be more expensive than you realize, or indeed, not even the best way to prove your software is what you hoped it was. You have to weigh the pros against these significant cons:

1. Can you afford it, really?

You have to write automated tests first if you want to run them, and that requires the skills of engineers who can code. These folks don’t come cheap.

Even if you hire them on a contract basis, the hours will rack up quickly – it takes time for them to design and write functioning code. And the more code you write, the more bugs you’ll get, compounding this issue.

2. It can be too hard

Some applications have so much complexity, unpredictability, and variability that they are almost impossible to test in a standardized manner.

Take mobile apps, GUIs, or video games, for example. If it's not straightforward how to write automated tests for a product, it'll take longer to write them, and you'll probably have to settle for fewer tests.

3. It can be too predictable

Automated tests can be far too defined and prescriptive to reach all, or even just most of, the functionality and myriad special conditions. The only bugs you’ll find are the ones you predicted might exist and therefore tested for – the "known unknowns". You won't find the unforeseen issues, the "unknown unknowns", that testers might find in more exploratory testing: more free-form testing, without prescriptive scripts, exploring for possible problems.

In many cases, you need the kind of real-time human interaction you can only get from manual testing. They test for all the undocumented aspects, things that are obviously wrong to any person trying to use the software but that no one may think to write an automated test for. Some examples are:

Performance - Is it all working fast enough without lag?
Basic UI - Does the interface look nice? Is text written in a color that’s easy to read?
Basic UX - Is the product intuitive?

Humans can conceive of test ideas and execute them there and then, which is faster than it would take to automate a test for every single conceivable function of the product. With much lower friction, more of the app gets tested, and more hidden defects and vulnerabilities get uncovered – ones that automated tests may miss.

Which brings us to…

4. You can test the wrong things

If developers writing your automated tests have the wrong assumptions about how a product is supposed to work, they may write perfect tests for exactly the wrong thing. Subsequent “pass” test results will only mean that the wrong thing works – not that your app or software actually works.

The first step to ensuring you test the correct things is to swap devs on each others’ code. They may find discrepancies or ask questions that could reveal a significant misunderstanding.

But even then, engineers may not always have the same perspective or context in mind as non-engineer end-users and end up approving automated tests that don’t reflect the main goals or value of the software.

5. It’s tough to do on the fly

A key aspect of exploratory testing is that testers can invent things to try on the fly. They can do this as ideas occur to them based on what they’ve just observed. In other words, exploratory testers can hunt around for what might be broken.

Automation can't do this if it takes too long to code up each test. A human doing manual tests (especially in an exploratory setting) can hammer through ideas nearly as fast as they can think of them.

6. Friction to write tests means fewer tests

It takes significant time and effort to write and process automated scripts. You have to write code for every single aspect of the product, and it’s easy to get bored and stop early. A sloppy or hastily written set of automated tests may only sample a handful of features, leaving room for undetected bugs to slip in.

Someone can create or add to tests much faster by hand, and exploratory testing is often the only way to find new problems that weren't predicted in advance. Building manual test plans as you go allows you to capitalize on a time when you’re most likely to have new ideas for new tests and test them right away.

Examples of when automation is NOT the answer

Automation can give you speed and consistency, especially at the unit level. But some products simply aren’t conducive to automated testing at all.

For instance, visual testing, usability testing, and security testing can’t be limited to hard-coded specs. There are way too many implied requirements based on observation and analysis that automation software cannot test.

Video games are another example. It’s extremely difficult to forecast how a player will interact with their environment and other players, let alone use the tools at their disposal. The sheer number of variables and time dependencies make it impossible to reasonably build sufficient automated software to test everything.

Even products that seem well-matched for automated testing at first glance really aren’t when you dive deeper. While website testing can be automated, code maintenance becomes a problem. Whenever you make a significant change, your test scripts must change with it, or else the automation breaks.

Other products that aren’t well-suited to automated testing include: real-time interactive software, UI tools, VR/AR apps, creative writing apps, and video editing tools.

The bottom line:

The reality is that most software needs automated and manual testing.

Automated testing is great for unit tests, ensuring all components making up the system are functioning properly, and it’s also beneficial for running a growing collection of regression tests.

Manual testing is essential for testing the unexpected. Automated testing is too prescriptive and simply doesn’t give you as much coverage and confidence as exploratory testing. Manual testing is also good for completing tests that can be done right now – without waiting for automation to be implemented. You can always "upgrade" those tests to automated versions as and when time, resources, and capabilities allow.

The human touch cannot be replaced

There’s no doubt automated testing can be helpful and speed up the testing process dramatically. But it comes at a high cost, and some products lend themselves far more to automation than others.

The truth is, you need humans – with their intuition and tenacity to try lots and lots of ideas – in the loop. Until automation can fully replace us, manual testing is your ticket to testing success.

Tools that might help

Really, you don't need any tools. Just having someone try your product is better than nothing. But writing some test ideas down to encourage repeatability from release to release is a good idea. And the less prescriptive these ideas are, the better (unless, of course, it's for regression testing where you want to address the exact circumstances of a previous problem).

To add some structure, think in terms of checklists: features, functions, capabilities, and contexts. That way, you won’t forget anything you need and want to cover.

Excel is a perfectly good tool to get started. But – with obvious bias – Testpad is an even better tool. It’s similar to the simplicity you're looking for in a spreadsheet but is laid out perfectly for the job of writing down structured test ideas and recording results, release after release.

A Fresh Look: New Website and New Faces

Stefan Butlin — Sun, 19 Nov 2023 00:00:00 +0000

Changes are afoot at Testpad: one bold and dramatic on the outside, one subtle and significant on the inside. On the external front, as is hard to miss, we've just updated our website with a fresh coat of paint; a visual upgrade to reflect a modern tool for modern testing. Internally, and more importantly, we've been expanding our team over the past year, a move that will enable more regular updates and enhancements to the Testpad ecosystem.

A Fresh Face for testpad.com

Firstly, our marketing website has received a fresh, modern makeover. This update isn't about adding new features or functionality (yet!) – it's a visual refresh aimed at keeping our brand up-to-date. We've launched this on a new platform (the geeky keywords are eleventy.js and Netlify) which is going to enable us to further enrich our site with useful content. Watch this space for help docs, tutorials, and educational materials on pragmatic approaches to testing.

Fresh Faces at Testpad Inc

The more significant news, however, is in the expansion of the team.

Since 2010, I've built and run Testpad single-handedly – a testament to modern tools that this is even possible as a solo venture. However, as Testpad's popularity has grown (obviously a nice problem to have), it's become increasingly difficult to maintain a focus on product development amidst growing operational demands.

We're now serving over 10,000 customers across 70 countries, and have cumulatively recorded over 100 million test results!

So, starting in 2022, we embarked on an exciting new chapter at Testpad by expanding the team. We now have 7 awesome people, some full-time, some part-time, but all fully remote and located across the globe, from Argentina to Malaysia.

The Fresh Future

With this recent expansion, we're now set to sail through previous bottlenecks (a.k.a me!) – crucial for accelerating the roll-out of new features, including the rather-overdue API.

We're also using our bigger team to improve our security stance. Or rather, we've always operated very securely, but want now to invest in gaining certification to prove it! We've therefore recently engaged Vanta as our security partners and are working toward SOC2/ii certification in 2024. Meanwhile, we've just completed (and passed) our latest annual Pen Test – certificates available on request.

Essentially, this internal growth sets the stage for more consistent and regular updates across all domains of the business. Our focus remains on coming up with efficient and pragmatic solutions to testing, especially in the rather process-heavy world of QA.

As ever, any questions or suggestions, please email support@testpad.com and we'll be happy to help.

Testpad Tips - don't make Scripts too short

Stefan Butlin — Sun, 06 Aug 2023 00:00:00 +0000

This is the third post on usage tips for Testpad and is about getting the most from a Script. Actually there are lots of aspects to using Scripts well, but this post is all about avoiding a common mistake: making test scripts too short.

It's very tempting to treat a script as a single test case, and thus put as few as 5-10 rows in it that only collect 1 or 2 meaningful results. While this works, it's not what the UI was designed for and it will quickly become annoying navigating to and fro from the project view.

Aside: it is also possible to make scripts too long, but a) this is way less common, and b) Testpad tries to protect you from yourself by limiting scripts to 2000 rows. In fact, too long only becomes a problem if you've got 1000+ rows combined with 100+ columns, but see the first post in this series for tips on fewer run columns.

Before we get into it, here's a screenshot of the top of a well-formatted script. This one happens to be test-case inspired in terms of specifying steps and expected outcomes separately, but the ideas apply equally to exploratory style guides and simple checklists of terse test prompts.

The formatting in this example is pure convention. There are lots of possibilities, but the general aim is to make good use of the hierarchical structure and keep each cell to a single row of text.

This example also makes use of Link Shortcodes defined in Project Settings, for convenient linking to e.g. User Story documents.

Short Scripts

The main issue with short scripts is in missing out on the power/efficiency of the script-editing page, with its progress bars, indentation structure, inline styling, keyboard-driven UI etc etc. It also overloads the Project view, as any reasonably sized project will have several hundred cases to test, and hundreds of scripts in one folder is just annoying to manage.

What does a short script look like?

Or worse...

When instead you can have lots of tests in the one script:

Which then lets you do things like collapse the rows for convenient overviews of your test coverage (collapse buttons hiding at the very bottom of the browser window):

Or even:

And here's another example in the BDD/Gherkin syntax format, which Testpad will auto-highlight when it spots rows starting with keywords like Given, When and Then:

Refactoring: Joining Scripts Together

Lastly then, if you find yourself with lots of short scripts and want to combing them, here are two ways of getting that done...

COPY/PASTE BETWEEN TABS

Open Script A and Script B in separate tabs in the same browser.

In Script A, make a multi-row selection and press Ctrl-C (you should get a message saying "N tests copied").

Switch tabs to Script B, select (but don't focus on, as in you don't want the text edit cursor visible) the last row, and press Ctrl-V. You should get a message saying "N tests added".

If successful, head back to the Project view to delete Script A (right click on its name).

EXPORT/IMPORT

In Script A, use the Script Menu → Export → Tests As Raw Text.

Select and Copy the text in the text export dialog box.

Navigate to Script B, and use the Edit Menu → Import.

Paste in the copied export from script A and click on Import.

The tests from Script A should have been added to the bottom of Script B.

Refactoring: Splitting Scripts Apart

Similarly, if you have a script that's too long and haven't started collecting results yet, then you can use either of the above methods to copy a subset of tests out of one Script and paste them into a New (empty) Script. You then head back to the long script and delete the rows you just copied out. Be careful though, if you delete the wrong rows, you've only got Undo while you're on the page... as soon as you navigate away or reload, the Undo history is lost.

As usual, don't hesitate to email support@testpad.com if you have any questions, or even just to discuss your own test formatting in Testpad.

API Project Update and Early Overview

Stefan Butlin — Sun, 30 Jul 2023 00:00:00 +0000

Testpad has long been promising an API, and the project is now nearly ready. The code has been implemented for all endpoints and webhooks, along with UI settings to control access keys and configure the webhooks etc. Remaining work includes our own testing (!), reviewing the documentation, and the server/networking deployment of the API servers. The deployment aspects are critical as we want to protect the availability of the main UI app servers from errant
(buggy, malicious even!) code flooding the endpoints with requests.

The rest of this post is to give you a teaser/taster of the API and what it will look like. The syntax presented here is not final, but do write in if any of the choices being implied here raise questions for you.

As a reminder, if you are interested in early access to the beta version of the API, to both get started with it but also help test it in real scenarios, then please register your interest and enthusiasm with support@testpad.com.

Endpoints and Webhooks

The API will be presented in two parts:

a collection of endpoints for making calls to, and
a collection of events for subscribing webhooks to.

Endpoints

Full documentatation will be released alongside the beta of the API, but the general goals of the endpoints are to enable:

injecting test results from external systems (such as automated testing and CI systems), with options for doing this whole script at a time, whole test run at a time, or just individual results one at a time
creating new folders to post new scripts into
extracting result and progress statistics at the folder, script and run levels

Example, injecting whole script of tests and results

For example, to create a new script in project 5 in folder f2, populated with tests, header fields, test runs and results, you would send an HTTP POST:

POST /projects/5/folders/f2/scripts
{
  "name": "Automated tests for rain predictor",
  "fields": ["(weather)", "build", "date"],
  "runs": [
    ... run definitions ...
  ],
  "tests": [
    ... test definitions with results per test...
  ]
}

Example, extracting a folder progress summary

For example, to fetch the current progress statistics for folder f3 in project 4, but without also drilling down in the contents and progress of each contained script, you would send an HTTP GET with parameters:

GET /projects/4/folders/f3?progress=terse&scripts=none

Generating a response along the lines of:

{
  ...
  "data": {
    "folder": {
      "id": "f12",
      "name": "Release folder 3.2",
      "progress": {
        "pass": 31,
        "fail": 42,
        "block": 0,
        "query": 1,
        "total": 87
        "summary": "Pass:31 Fail:42 Block:0 Query:1 Total:74/87",
      },
    }
    ...
  }
}

Webhooks

Again, full documentation to follow, but the general goals of the webhooks are to enable external URLs to be called in response to test run events arising in Testpad. Further events will be added in time, but the initial collection of subscribable events are mainly designed for:

individual results being set, filterable for e.g. just failed results (which you might connect up to the automatic creation of a JIRA ticket, assuming you want the possible duplication this will entail!), and
run-level events such as test runs being started and completed

Example, subscribing to results set to fail

To connect an external action, such as a Zap in Zapier or some custom integration with JIRA or AWS Lambda, you would configure a webhook using the Testpad interface (API endpoints to subscribe webhooks won't be in v1, but certainly could be added if there's demand in the future).

Configuring a webhook means telling Testpad that you want your URL, e.g. https://hooks.zapier.com/hooks/catch/345678/abc34, to be called (by Testpad) whenever the event result.fail occurs.

For now, events will be generated for all projects in an account, however we anticipate providing for project-level filtering fairly soon after the initial release (and again, feedback welcome on this).

When a result.fail does then fire, your URL would be called with an HTTP POST:

POST https://hooks.zapier.com/hooks/catch/345678/abc34
...
... HTTP headers for signatures and content meta data
...

[
  {
    "_event": {
      "topic": "result.fail",
      "id": "bb8f5cba-17b73e73688",
      "ts": { ... various timestamp formats ... },
    },
    "result": {
      "comment": "",
      "issue": "",
      "result": "fail",
      "url": "https://stef.testpad.com/script/3657/#2/1.2"
    },
    "context": {
      "account": { ... },
      "user":    { ... }
      "project": { ... },
      "folder":  { ... },
      "script":  { ... },
      "test":    { ... },
      "run":     { ... }
    }
  }
]

Timescales

Our most frequent support email these days (besides requests for old invoices - sorry folks, and ahem FastSpring) are customers asking when the API will be out. Having long got this wrong, I'm not promising a specific date. However, the project is mostly complete and the hope, but not promise, is to have this out early next year.

Meanwhile, if you are in the crowd itching to integrate your other tools with Testpad, I hope the above details are exciting and thank you for your continued patience!

Any questions or feedback, please do write in to support@testpad.com

Testpad Tips - make copies to go from release to release

Stefan Butlin — Thu, 20 Jul 2023 00:00:00 +0000

This is the second post on usage tips for Testpad and is about a great way to organize tests when going from release to release. The first post was about using retesting to go from build to build within a release, but this article goes 'up a level' and looks at how to get re-use of your test plans from release to release (or Sprint to Sprint if that's your thing).

Use a Folder per Release

The simplest way to model releases is to use a whole new folder for each new release, and to populate the new folder with copies of the scripts you used last time.

When scripts are copied, all the tests and run headers(*) are copied, but the results are left behind.

A copied script is therefore like an on-the-fly template for the next release.

(*) If you hold the ALT key down when copying (either via the Duplicate menu item, or when drag'n'drop+CTRL), then the scripts are copied without the run headers too.

Example first, details below

Suppose you have a product called SlicedBread and you've just finished testing v1.0.

Prepare for v1.1 by right-clicking to Duplicate the folder.

Finally, rename the new folder to e.g. SlicedBread 1.1 and it's ready for testing the next thing since SlicedBread.

In a bit more detail

Copying the whole folder

You can copy a whole folder with a right-click on the folder name, and selecting the Duplicate option. Or you can drag'n'drop with the CTRL key held down. Either way, you get a new folder with all the contents from the previous folder copied.

Or copy the individual scripts

Alternatively, make an empty new folder for the new release, and selectively drag'n'drop+CTRL each script you want a copy of from the previous release.

This is useful if you only want a subset of the scripts from last time. If you want all of them, it's going to be quicker to just copy the whole folder as above.

(Additional detail: if you also hold down the ALT key, you get copies of scripts without the run columns.)

Or copy templates instead

Some much more complex projects, typically those involving custom configurations of components that are different from release to release, might instead look to populate a new release folder with scripts taken from a Library of Templates. Templates are nearly the same as scripts, except Templates never collect results, and only ever exist to be copied to make a script from.

Use templates (or folders of templates) by dragging and dropping onto the Project Name (over on the left) that you want the template copied into. Then go to that Project and move the new scripts (which are created at the top of the project) into the right folder.

Keeping a record of the previous release

The whole point of making copies for new releases is to leave intact the tests and results from last time.

Tests need to be updated in step with each evolution of a product, and it would be a shame to lose the consistent record of what was tested and with what results if the old scripts were then edited to add new features etc.

Instead, by working on new copies, the old tests and results are left alone, and the new copies can be edited as much as required to bring them up to date for the latest version of the product.

Archiving old Releases

And to keep the interface tidy, it helps to archive away old releases once they're only needed for their reports.

Archive a folder by right-clicking on its name and selecting the Archive option.

Find archived scripts and folders via the Archived Scripts link at the bottom of the list of scripts and folders for a project.

This is archiving within a project, and is most relevant for archiving old releases. Which is not to be confused with archiving a whole project (right-click on the project name over on the left and select Archive) for when you don't need a whole project to be around anymore.

Please get in touch if you need any help with how to apply these ideas to your projects... just email stef@testpad.com.

Testpad Tips - use Retesting to go from build to build

Stefan Butlin — Sat, 08 Apr 2023 00:00:00 +0000

Testpad has a very flexible model for writing test plans/ test scripts which lends itself to pretty much however you want to approach and organize your testing. However, with this flexibility comes the power to go a bit wrong too.. it's perfectly possible to build inefficient plans and lose out on a lot of the value Testpad has to offer!

This post then is the first in a series of three providing tips on getting the most from Testpad. In time, Testpad's interface will itself be improved to nudge users in these "more optimal" directions, but until then, here are some hints toward what you might call 'best practice'.

These tips also have a side-benefit of keeping content to a sensible size, both for manageability by the user and in terms of browser performance slowing down if you've got just too much content on the screen. However, that said, you have to build an enormous script (think 1000+ rows with 100+ columns) before browser lag becomes annoying.

Spoiler alert... if you don't have time to read all the detail, the top three usage tips boil down to:

using the Retest feature for retesting new builds as part of the same release (the subject of this post)
copying Scripts (or whole Folders) when preparing for new releases - see the second post
and getting Script length right; combining together scripts that are too short (very common) or splitting apart truly massive scripts (less common) - see the third post

Retesting New Builds

First up is the idea of "retesting" test runs (columns). When a Test Run in Testpad is completed, whether marked as such manually in the Test Run Details dialog, or through setting results for every test, the Test Run Details dialog offers the "Start a Retest" button.

Retests are intended for retesting e.g. a new build. You've run through your tests a first time and found a number of test fails. The developers have fixed these and issued a new build that needs another test. So you come back to Testpad to make another run through your tests.

The thing not to do at this point is click on "New Test Run" to make a new column, additional to the columns already present. This is the path to the dark side and will lead to an ever accumulating number of columns, eventually slowing down the browser's responsiveness as you get north of 100 columns (sooner if you have >1000 rows).

Instead, you want to be using the "Start a Retest" button, offered in the Test Run Details dialog for runs marked Completed.

A Retest makes a new column that takes the place of the old column. To start with, the old column is displayed beside it, but grayed out. After a page reload, or when you next return to the script, the old column is not displayed at all. (You can get old columns back on screen with a right-click on the run header, selecting "Show Old Runs").

Retests are numbered like version numbers. Test Run 1.1 is the first retest of Test Run 1. Test Run 2.4 is the fourth retest of Test Run 2, and so on.

You can optionally inherit the results from last time. Inherited results are shown slightly lighter than new results and are there if you want to e.g. only retest the problems from last time.

A Retest also takes over the contribution to the progress statistics for the script. If you keep making new test runs (the bad way!), the progress statistics are always the sum of all runs ever conducted, and so can never approach a 100% pass rate with successive new builds. But use retests, and each retest can iterate the results for that run and allow them to reach 100% when everything is passing.

That's it for tip #1. Use the Retest feature when retesting new builds and don't keep making more and more columns, stretching the page off to the right.

Any questions, please email stef@testpad.com - always happy to help you get the most out of Testpad.

We have a new home!... testpad.com

Stefan Butlin — Sun, 11 Dec 2022 00:00:00 +0000

As of today, Testpad is now hosted at testpad.com after over a decade at the similar but always somewhat confusing "ontestpad.com". The switch to the new domain is automatic and happens when you next visit Testpad. If you have any links to the old domain laying around, for example, stashed in a wiki or in the comments of a Jira issue perhaps, these links will also automatically redirect to the new domain.

Impact on customers

The switch to the new domain is automatic and happens either when you change page within Testpad (if you were already logged in), or simply when you return to the main website to login again.

If you were logged in, and go to change page in the app somewhere, you will find yourself having to login again. This happens because your session is tied to a cookie, and your cookies are tied to your domain. So when we changed up the domain on you, you won't have a session cookie anymore and therefore have to login again to continue. Testpad does remember where you were trying to go however, so it should be as seamless as remembering your password!

Links to reports etc

Any existing links that are "out there" will obviously have the old domain in them and should seamlessly to the new home. There's no time limit on this, we'll simply support old links indefinitely.

Similarly for guest test invitations, new user invitations, account sign-up verifications and so on: they should all seamlessly

Emails

All Testpad emails are also switching over to use the new domain, so please expect Testpad emails to come from "support@testpad.com" from now on. Of course, the old email addresses will still work, so again, no rush to update.

History

Testpad always wanted to be hosted on its brand name .com of course, but when I started Testpad in 2010, it wasn't available. I could have started the business with a different name, but despite trying hard, I couldn't come up with a name that so perfectly encapsulates what Testpad is all about. So I went with Testpad and settled for the domain "ontestpad.com".

Why "ontestpad.com" in the first place? Well, when you signup and get an account, your account is hosted on a subdomain, giving you a Testpad address of "yourname.ontestpad.com"... "yourname".. on Testpad... geddit?

However, while that appealed to the nerd in me, I'm not sure how many folks out there also appreciated it. And of course, for people looking for this testing tool they've been told about called "Testpad", there's always the question when they find "ontestpad.com" of whether they've found it yet or not.

Fast-forward to 2022 and, with the help of our friend Adam at Lumis, we finally managed to engage the previous owner of "testpad.com" and negotiate its purchase. I'm not publishing numbers here, but let's just say it wasn't cheap. A cool simple two-word .com like "testpad" was never going to be cheap! But it was a great investment and secures the brand name for the great things we have planned for 2023.

Blog

All except for this blog that is!

The blog is staying put at blog.ontestpad.com until the launch of our new marketing website in early 2023.

As ever, any issues with this domain change, or anything else, please don't hestitate to email us on support@testpad.com. Happy Testing!

Release notes for minor update (4.1.110)

Stefan Butlin — Mon, 15 Jun 2020 00:00:00 +0000

This weekend, we upgraded Testpad with a collection of small updates and tweaks. Some bug fixes. Some customer suggestions. Some adjustments to keep Testpad running smoothly. The changes touched on reporting features, mobile image attachments, subscription options and keyboard shortcuts. As ever, if you have any feedback or suggestions, please don't hesitate to write in on support@testpad.com – even if we're not about to give you exactly what you're asking for, the feedback and discussion around what you're trying to do is immensely useful and 100% shapes the direction Testpad takes in the future.

Reporting: new option to include old test runs

The report config settings (found at the top right of a report page) have a new option to include Old Runs. Old test runs are test runs that have been superseded by a newer retest. See using retests to go from build to build for more details on what retests are.

Previously, old test runs were only accessible on the script-editing page with a right-click on the test run header and selecting the Show Old Runs option. But now you've got the option to also include old runs in reports.

So if you use retesting a lot, and want a report that captures the history of how you got to the final status, open a report, head up to the top right config button, and turn Old Runs to ON.

Throughout your reports, if included, old runs will be shown as grayed out to indicate their "old" status. This includes in the summary section at the top of folder reports, in the grids of test run columns per script, and in the comment summary sections below each script.

Reporting: new option for XL column widths

And in another tweak to the report config: an XL column width option. If you ever use long values in your run headers, and if you don't have too many run columns, you can now set the display width of the test run columns in script reports to be extra wide.

This option is really only useful if you've got a wide display. If the browser gets too narrow (e.g. by making it small or viewing on a smaller device) then the XL setting will be ignored and Testpad will do its best to display your data with the space available - as before.

Mobile: attach images during testing

You can now use the mobile UI to view and attach images to test results. Support for this will depend on your mobile and browser, but modern iPhone and Android devices should work.

If you're not familiar or aware of the mobile UI, it's a really neat way to run your testing. From your desktop, you can display a QR code for one of your test run columns, scan it with your mobile, and then instantly begin running that test run on your mobile.

New subscription option: the "Team 15" plan

We've added a new subscription option for a 15-user team that sits between the existing Team and Department plans.

If your Testpad team grows above 10, you now don't have to make the big jump to paying for 25 users when you only needed e.g. 12.

We haven't updated the pricing page on the website, but the new plan is listed as an option in the app on the Subscriptions and Billing page.

New keyboard shortcut: `ALT` `+` for new test runs

By popular request, we've added a new keyboard shortcut for making new test runs. Hit ALT = (but think Alt-Plus) to create a new test run column.

As for the normal way to make a new test run (clicking the New Test Run button), you might be interrupted with a prompt checking you really do want a new test run. And this is because you might want a Retest instead. Again, see using retests to go from build to build for more on what retests are if you're not familiar.

This shortcut joins a big collection of keyboard shortcuts that make editing and running scripts possible almost entirely from the keyboard. Look for the help popup on keyboard shortcuts in the menu in the top right of the script-editing view, or indeed, use the keyboard shortcut for the keyboard shortcut help popup ALT ?.

Bug fixes

Finally, we included some bug fixes in this release:

attempting to send test run emails to an assignee or guest would sometimes fail depending on the values of the test run header fields
more protection against weird and wonderful filenames in image attachments that caused the upload (or subsequent download) to fail. But top tip: please try to use simple file names for attachments; every part of the internet is much happier if you do
you can now have more than one markdown-style link in a test row
copy/pasting multiline text in a test row now repaints the edit box properly

Feedback (please!)

As ever, any questions, feedback or suggestions, please don't hesitate to email Testpad support.

As one customer said this week...

"I never realized how effective the feedback button was" :)

Email addresses don't have to be unique anymore

Stefan Butlin — Mon, 02 Sep 2019 00:00:00 +0000

Testpad now lets you re-use your email address in different team accounts. Until this weekend, Testpad required all users to have a unique email address - once an email address was used in one account, it couldn't be used again anywhere else. But that's now changed. Like other popular tools (e.g. Slack!), Testpad now let's you register the same email address against multiple team accounts (often called workspaces in other tools).

This means you can sign up your own trial account, and if you later decide to subscribe to a paid plan, but on a new "official" corporate account for your team, you can simply add yourself to the corporate account without having to use a different email address or delete your own trial account.

Or for those on the Custom plan who're running multiple team accounts, you no longer need to use a different email per account that you want to be added to. (If that's not you, but it sounds like something you'd want to do, please get in touch to ask more about how Custom plans work.)

How does this work?

Just sign-up for new trial accounts, or add new users, or change email addresses, with whatever email addresses you like!

When you come to login, providing an email address and password to identify yourself, Testpad will check for whether those credentials match one or more accounts.

If the credentials only match one account (which will be the norm for the vast majority of people), then, as you're probably used to, you'll get taken straight into your account to get on with your test planning.

But if the credentials match more than one account, Testpad will log you in to all the matching accounts and prompt you for which one you want to proceed to. At that point, you can use the new "switch to a different account" option in the user menu (the menu in the top-right corner).

Note that if you set different passwords for different logins (on the same email address), then you obviously won't access the other accounts for that email address. Access is only granted to an account when the correct email address and password are supplied.

Login to more than one account at a time

And not just re-using emails, as part of this update, Testpad now also allows you to be logged into more than one team account at once (in the same browser). Use the user menu in the top right corner to access the new "login to a different account" to go back to the login page without logging out of the account you were in. If you provide good credentials (email and password) for another account, Testpad will keep you logged in to both accounts. You can switch between them via the same menu option, which becomes "switch to another account" once more than one account have been logged into.

But Testpad still complains "address already in use"?

So, while you can use the same email address in different team accounts, you still can't use an email address more than once within any one account. Otherwise, how would Testpad know who was trying to log in?

If Testpad stops you using an email address with the message "address already in use", then this means that email is already being used by someone else in that account.

Custom plan subscribers running multiple accounts

For those customers on the custom plan and running multiple team accounts, with their users using unique email addresses per team account: the existing email addresses and passwords will obviously continue to provide access to the relevant account. However, if you want to now migrate to instead re-using the same email address, then simply use the Manage Users page (and the relevant Edit Details option per user) to update the email addresses to the desired address. Note that all changes of email address still have to be confirmed by clicking on the link sent to that email address.

Case-sensitive email addresses (only relevant to long-term account holders)

For those accounts that pre-date 2017 and were using different "case" spellings of the same email address to differentiate accounts, these logins will now be treated as having the same email address. When you login, if your email (regardless of case) and password match multiple accounts, then you'll be prompted for which account you want to proceed to.

Any issues, please send your questions and problems to support@testpad.com.

Importing spreadsheets of tests into Testpad

Stefan Butlin — Wed, 13 Mar 2019 11:46:00 +0000

The quickest way to get up and running with Testpad is to import existing tests, but the simplicity of doing this depends on the current formatting and layout of your tests. And this is especially true when you're copy/pasting from spreadsheets, which is what this article is all about. Read on for how this works in detail, but the impatient reader might like to skip ahead take a look at these Spreadsheet Import Examples.

Update – we now strongly encourage you to use AI for some help. We have a our own Custom GPT that can have a go at reformatting your spreadsheet test plans, or indeed, write new test plans given some details about your product.

Per Script, use the Import Dialog to copy/paste text

This article concentrates on importing test cases from spreadsheets, but it should still be relevant to importing any source of table data into Testpad, including User Scenarios, Feature Definitions, or even existing checklists.

But if you're starting from scratch, writing new tests in your own style, then you don't need the help in here - instead, just get on with writing simple prompts of things you want to remember to test and go from there!

Per Script, use the Import Dialog to copy/paste text

Testpad's main document is a Script, and importing happens a Script at a time. Make a new empty Script and look to the Edit Menu -> Import option to open the Import Dialog.

Copy/paste your text for import, select a format option, and hit the Import button.

The goal for import is a single column of text

If you paste a simple block of text into the Import Dialog, on its Plain Text setting, then it will treat each line of text as a new row in the Script. For example:

Valid user name and password work
User can login immediately after changing password
Username with unicode characters works
User can login immediately after changing username
Invalid user name is rejected
Invalid password is rejected
Blank password is rejected
Blank username is rejected

will produce:

Use indentation to give tests structure

Any leading spaces or tabs (i.e. indented) rows will be spotted and used to form title rows with blocks of (indented) content underneath. At a higher level, this is ideal for grouping tests by topic. At a lower level, it's ideal for grouping rows to describe richer test cases - more of which later.

Normal login
   Valid user name and password work
   User can login immediately after changing password
   Username with unicode characters works
   User can login immediately after changing username
Bad login
   Invalid user name is rejected
   Invalid password is rejected
   Blank password is rejected
   Blank username is rejected

will produce:

Use the Spreadsheets format option when copy/pasting from spreadsheets

If you copy/paste from a spreadsheet, the format is typically quoted (to encapsulate cells, especially when multiline) with cells separated by Tabs.

The Import Dialog can deal with the quoted cells, but you need to specify the Spreadsheets formatting option. If you try to import a copy/paste from a spreadsheet using the Plain text format setting, the " quote characters won't be removed, and you're likely to get a bizarre looking layout.

Testpad only wants one column from a spreadsheet

When copy/pasting from a spreadsheet, you need to start by only copyinga single column. Tests in Testpad are essentially a single column of test descriptions, with only results (not additional test data) appearing in multiple columns.

So what about when your spreadsheet of tests, like most test plans, has tests defined in rows across multiple columns? Maybe you've got one column for the title, another for the Steps of the test, and yet another for the Expected Results.

How do you import two or three columns into Testpad's one column?

Well... the answer is that you don't! Instead, you need to play with your spreadsheet a bit to build a new (single) column that is some aggregation of the other columns.

This is best done by creating a new column, and starting in the first row, start building up a formula that will put together the other cells into a "Testpad-friendly" single cell.

For example, if we have three columns, something like this:

Title	Steps	Expected Results
Basic login	1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter	Login succeeds and user's dashboard is displayed.
Rejected login	1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter	Login is denied with a message saying wrong username or password.

Then the trick is to create a fourth column, and fill it with formula like:

=CONCATENATE(B1,"
",B2,"
",B3)

The table will then look similar to:

Title	Steps	Expected Results
Basic login	1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter	Login succeeds and user's dashboard is displayed.	Basic login 1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter Login succeeds and user's dashboard is displayed.
Rejected login	1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter	Login is denied with a message saying wrong username or password.	Rejected login 1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter Login is denied with a message saying wrong username or password.

Now if we select the 4th column, and copy/paste that into Testpad, we get:

But we can do a bit better if we add in some indentation to better structure the new test column.

Consider a modified version of the formula from above:

=CONCATENATE(B1,"
    ",B2,"
    ",B3)

Now our table's fourth column looks a bit different:

Title	Steps	Expected Results
Basic login	1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter	Login succeeds and user's dashboard is displayed.	Basic login 1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter Login succeeds and user's dashboard is displayed.
Rejected login	1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter	Login is denied with a message saying wrong username or password.	Rejected login 1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter Login is denied with a message saying wrong username or password.

This isn't quite what we want, as only the first step has been indented. So getting a bit more clever with the formula, replacing newline characters for newline+spaces fixes this:

=CONCATENATE(B1,"
    --",REGEXREPLACE(B2,"\n","
    --"),"
    => ",B3)

Now our table's fourth column looks tidier on the indentation

Title	Steps	Expected Results
Basic login	1. Load the /login page 2. Enter valid user name 3. Enter valid password 4. Press enter	Login succeeds and user's dashboard is displayed.	Basic login --1. Load the /login page --2. Enter valid user name --3. Enter valid password --4. Press enter => Login succeeds and user's dashboard is displayed.
Rejected login	1. Load the /login page 2. Enter valid user name 3. Enter an invalid password 4. Press enter	Login is denied with a message saying wrong username or password.	Rejected login --1. Load the /login page --2. Enter valid user name --3. Enter an invalid password --4. Press enter => Login is denied with a message saying wrong username or password.

This latest version of the formula also inserts some "--" prefixes which Testpad interprets as "comment" (non-test) rows.

Whether you want to use comment rows depends on whether you mind collecting results for "steps". My own preference is it's fine, when I record a "pass" against a step, I'm recording a result to the effect "yes, did that, no problems". But lots of people like to make steps just comments and only record results against the Expected Outcomes.

And when this modified 4th column is copy/pasted into Testpad, we get something much more workable:

And getting more complicated...

Of course, your spreadsheet might have many more columns. Take for example something like this:

Which can be imported, as above, with a new column that aggregates (with modification for prefixes and indentation), to produce:

How did that work?... check out the collection of Spreadsheet Import Examples for more detail.

These examples all illustrate multiple test cases per import - it's a common misuse of Testpad to only have one test case per script - you definitely want to put multiple test cases into each script, making good use of the indentation structure to form logical groups.

Copy/paste two or three columns to set Tags and Notes

Testpad will actually accept two or three column imports, but it uses them for it's own purposes... if present, Column 2 will define the Tags to include for a tow, and Column 3 will define Notes.

Tags are part of Testpad's tags and filtering feature, where test rows can be tagged with labels that Test Runs can filter for - useful for defining subsets of tests for certain test run conditions.

And Notes are for the notes field that is "behind" every test row, displayed in the Test Details dialog. You can access the Test Details dialog by clicking on the small doc icon, or double-clicking the row ID, or typing Alt-N. These Notes are wiki-formatted and can be displayed during testing if required using the little checkbox in the Test Run execution dialog.

The Notes field (third column in multi-column imports) is another option for where to put imported test content. For example, if most of your testers are familiar with the product, then you might want to "hide" the Steps in the Notes field and only display the things to Verify in the main part of the Script. New or less experienced testers can then open the Details dialog to get the extra instruction when needed, but for everyone else, the Script is more compact and can be read through and executed more quickly.

To populate the Notes field during an import then, you need your copy/paste to span three columns, where the first column will be the main test text, the middle column empty (assuming you're not trying to tag anything yet), and the third column for the notes. This is all best achieved by adding three new columns to your spreadsheet, and setting up formulas to aggregate/copy the relevant cells into the first and third of the new columns.

Again, have a look at the Spreadsheet Import Examples for an example of a multi-column import.

CSV (Comma-Separated Values)

And lastly, a note on CSV imports. These work exactly the same as spreadsheet imports, except that the cells are separated by commas instead of tabs.

Just as for copying from spreadsheets, you need the first column to be the main test text as described (at length!) above, the second column for tags, and the third column for each test's Notes field.

Want some help?

If this is all still not making sense, or you have existing tests that you'd like some help with how to import, then don't hesitate to email some example tests and questions to support@testpad.com - always very happy to help.

Simple ways to include links to User Stories etc

Stefan Butlin — Sun, 03 Mar 2019 00:00:00 +0000

Test plans don't exist in isolation. They very often come from, or at least need to be associated with, the specs or user scenarios or plain-old requirements that were used in the creation of the product you're testing.

It's also common to want to provide the tester with additional resources in the form of links to help documentation, or other further context on the where/why/what of the topics under test.

Simple clickable links

As usual, Testpad doesn't try to be complicated with making such connections to third-party material. Instead offering a variety of methods for including clickable links that simply load up the referenced page in a new tab... basically what the hypertext in http means!

To include links in your tests, choose from:

	typed in as	displayed as
Plain links	`https://testpad.com`	"https://testpad.com"
Markdown-style links	`[TestpadHQ](https://testpad.com)`	"Testpad"
Wiki-style links	`[[https://testpad.com	Testpad]]`
Shortcodes	`US:123`	"User Story 123", linking to https://my.requirements.com/story/123

NB don't forget to enable links in Project Settings

Include links wherever they're helpful

Testpad lets you include links in most places that accept text input:

Test text titles
Test text comments
Embedded in test text
the Notes field behind every test
Script Description blocks
Note Items in Folders that sit beside links to Scripts
Comments against individual results

Plain Links

Whenever you include an obvious link (starting http:// or https://) in some text, Testpad will recognize it as a link and display it as a clickable link opening in a new tab. If the link isn't too long or complicated looking, this method is basically just for free and happens without even reading up on the details!

Markdown-style Links

If you go to Project Settings for your project, you can enable Markdown-style Links (they're off by default), which means any time you include a link with the pattern [Title](link), the "link" will be displayed as the clickable "Title". Useful for longer/complex URLs that otherwise confuse the text they're appearing in.

Wiki-style Links

Similarly, in Project Settings, you can alternatively enable Wiki-style Links, so that any time you include a link with the pattern [[ link | Title ]], the "link" will be displayed as the clickable "Title".

Short-codes for common link patterns

Lastly, and perhaps most powerfully, Testpad includes a link pattern generator which is great for when you want to include lots of links to very similar URLs. For example, if every test block needs to link to the User Story item in JIRA that it pertains to, it would be tedious to include the full JIRA path in every test title.

The Project Settings page lets you define short-codes that map a prefix:code pattern onto a link pattern. This is probably best explained by example:

The definition:

is defining a short-code "story", such that whenever some text includes "story:ABC123" (i.e. "story" followed by a colon followed by some characters), the short-code will be replaced with a link to "https://some.website/issue/ABC123" that's displayed as User Story ABC123.

Testpad's new UI sees 1m results in 3months

Stefan Butlin — Mon, 01 Oct 2018 00:00:00 +0000

Three months ago we updated Testpad's UI and website branding with a whole new look and feel, and, judging from customer emails (keep 'em coming), Testpad has never been so popular.

And it's not just the positive feedback - since June, the new UI has been used to record over 1,000,000 results, taking Testpad's total to over 15m. Sadly for the dev teams out there, not all of those have been 'passes', but at least the bugs are being found in testers rather than customers hands!

If you're new to Testpad, please don't hesitate to get in touch for help... video demos, importing existing tests, usage patterns etc.., just email support@testpad.com.

New Release: Testpad 4

Stefan Butlin — Sat, 09 Jun 2018 00:00:00 +0000

Testpad just got a major update to its look and feel. The whole design of the app, and the branding of the marketing website, has been updated with a fresh look. The functionality remains nearly identical, with only a few menu options moving around. Everything you could do before you should still be able to do in the new version.

New Pricing

At the same time, Testpad also updated its pricing. This is the first time prices have been changed (yes, raised) since Testpad launched in 2011, so a change has been well overdue for some time. The four existing plans have been replaced with three user-limited plans (for up to 3, 10 and 25 users respectively) along with a new kind of bespoke plan for enterprise customers.

Existing customers who were paying automatically either monthly or annually may continue on their current plans at their current pricing.

If you have any questions, or find problems with the new version, please don't hesitate to contact stef@testpad.com.

Writing BDD Test Scenarios with Gherkin Syntax

Stefan Butlin — Tue, 19 Dec 2017 00:00:00 +0000

Testpad has built-in syntax highlighting for writing tests in the "Given, When, Then" style, also known as Gherkin, as used in BDD automation frameworks. Despite having its origins (we think!) in the world of automation, many teams like to structure their manual test plans using the formality of Given/When/Then statements. We therefore look for test plans with lines that start with these keywords and color them in for you to make these test plans look prettier.

EDIT: The screenshots in this article pre-date the big UI update in June 2018

Behavior-driven development (BDD)

Behavior Driven Development is a software development process that is based around the desired behaviors of a system; defining a framework for collaboration that is both precise enough for developers/QA and human-readable enough for business stakeholders and non-technical team members.

Requirements are framed as user-focused scenarios (effectively acceptance criteria), composed in plain English with a descriptive grammar in the form: Given [some initial conditions], when [something happens], then [something should happen].

Scenarios often use one or more concrete example values to help define the behavior.

BDD Automation frameworks, e.g. Cucumber, jbehave

The controlled structure of BDD requirements lend themselves to test automation. Frameworks like Cucumber and jbehave start with Scenarios defined in the plain "business-readable" language and then structure the test code in and around it.

As the developers of Testpad, a tool to help you manage your manual testing, it's perhaps not obvious that we promote the idea of automating as much of your testing as is humanly/reasonably possible. If you're not automating any testing yet, stop reading and get on it!

But you can't automate everything, and probably have lots of tests that you haven't got around to automating yet... in which case, despite wanting to automate everything, you have plenty of manual BDD testing to organize. Which leads us nicely onto the new support in Testpad for writing test plans as collections of scenarios in the Gherkin syntax...

Gherkin syntax - Given/When/Then - a business-readable domain-specific language

The Gherkin language is a formalization of the Given/When/Then style of test definitions, as used by most prominently by the Cucumber automation framework among others.

Testpad now automatically looks for this formatting and colors the keywords if it finds them. If Testpad doesn't recognize your way of formatting Given/When/Then, you can force ON the syntax highlighting. Equally, if Testpad is thinking you're using Gherkin when you're not, you can force it OFF.

Formatting options to suit your style of Gherkin Syntax

By default, every row in Testpad, that isn't a title row, is a "test" that will collect a result i.e. Pass, Fail, Blocked etc, along with optional Comments, Screnshots and Bug Numbers.

When importing (or writing) BDD tests, this means rows that begin GIVEN and WHEN will also be regarded as tests looking for a result:

For lots of customers, this is just fine, and recording a "Pass" against a GIVEN statement can just be interpreted as "yep, set that up, no problems", and a "Pass" against a WHEN statement can mean "yep, made that happen, no problems".

For other customers, there is a preference to only record results against the THEN statements that define what should (and therefore might not) happen. To this end, Testpad offers a couple of options:

Use the new comment prefix -- which acts just like the // comment prefix, making a row a non-test row, except that the -- characters are hidden for a prettier display
Use cascaded indentation to make title rows out of every non-test statement

Combining Exploratory Testing with BDD/Gherkin

While Testpad's free-form layout can be used for almost any test process, Testpad excels in writing plans that are guides (whether high-level or detailed) for Exploratory Testing. The idea of exploratory testing is that you don't follow prescriptive instructions for what to test, but instead leave the human brain free to be inquisitive and tenacious in hunting down unexpected behavior. Test plans for exploratory testing are therefore "guides"; checklists of features that you don't want to forget to take a good look at.

However... BDD/Gherkin tests, on the other hand, are more proscriptive, defining in significant detail what needs to happen given/when/then this or that happens. This is of course great for Acceptance Testing; proving that the stated requirements have been met. But alone, this is then less useful for having confidence that the system is bug free.

So why not have your cake and eat it?

Copy/paste your Gherkin tests into Testpad, tweak the formatting if required, and then extend the tests with ideas, details and edge-cases to explore in and around the given scenario.

Test plans in Testpad are a free-form checklist document. So while you can structure your requirements using Gherkin syntax, there's nothing to stop you adding further lists (sub-checklists) to each BDD Scenario.

If bugs crop up in the field after Release 1.0, go back to your Scripts (checklists) in Testpad and add tests/ideas/notes to the relevant scenarios to protect against regressions next time.

Any problems, questions or further suggestions to improve these ideas, please email stef@testpad.com.

Folders for Simpler Release Management

Stefan Butlin — Fri, 17 Nov 2017 00:00:00 +0000

With the recent success of the new folders feature, here's a usage pattern that lots of customers have adopted to handle releases. In essence, this pattern avoids using Templates and instead uses the previous release as an on-the-fly template for the new one. You can also copy just single scripts, but making a copy of a whole folder will make copies of all of its contained scripts – a very efficient way to prepare for your next release in just one click.

EDIT: Screenshots pre-date the big UI update in June 2018

Duplicate the previous release

Right-click on the folder for the previous release and select Duplicate
Edit the new folder name to reflect the new release version number

Update the tests

Edit the new copies of the Scripts to catch up with the latest features in the product; adding new Scripts as required, and deleting any unneeded Scripts

Archive the old release

(optional, depending on how tidy you like your Project view) Right-click the old release folder and select Archive; this puts the old folder in the Project's Archive tab. Note that this is different to archiving a whole Project which you do by right-clicking on the Project's name in the list on the left.

Do the testing

Within each Script in the new release folder, and when the product is ready for testing, make the first test runs for the release, collecting lots of passes (hopefully) and a few fails (inevitable)

Share the progress

Start sharing the folder report with stakeholders: from the Project view, right click on the folder name and select View Report. This opens the report in a new window. The contents and verbosity of the report can be configured using the button in the top-right corner, which is also where you can find the Enable Sharing button to get a share link. Alternatively, the whole report is easy to SaveAs because it is a single self-contained HTML document that can be archived as-is in your own systems (file sharing, wiki attachments, emails etc).

Retest new builds

If a new build is coming, create ReTests of the complete Test Runs. Prepare ReTest columns using the prompt when a run is first completed, or by opening the Test Run Details dialog (hover over a Test Run header and click on the Edit icon that appears), sliding the slider to Complete if it's not already, and then clicking "start a retest".

A ReTest is different to simply pressing "new test run" in that the new column takes the place of the previous run, both visually and in the progress stats. Thus you don't clutter the screen with more and more old test runs (unless you like that!), and the progress bar for the Script (and in turn, the Folder it is part of) can approach 100% pass as the fails get re-tested as working. You can get old runs back on the screen with a right-click on the header of the latest test run.

And repeating step 7 as many times as new builds need re-testing to ship the release.

Ship it!

Any questions, problems or feedback, just email stef@testpad.com

Attaching Images, Screenshots and Other Files

Stefan Butlin — Tue, 03 Oct 2017 00:00:00 +0000

Testpad's premium plans support uploading files and images for tests and results. Files are uploaded using drag'n'drop onto areas in the dialog boxes for test details and test running. This can be very useful for, in test descriptions, illustrating what a screen should look like; and in test results, for showing what a screen actually looked like.

EDIT: Screenshots pre-date the big UI update in June 2018

Images for Test Descriptions

Test descriptions can have images and files attached by opening the Test Details dialog and dragging files onto the Attachments area

The Test Details dialog is available for each row in a Script and is accessed by any of

double-clicking on the row ID
typing the shortcut Alt-T
clicking on the small triangle icon at the end of the row of text
if files already attached, clicking on the file thumbnail at the end of the row of text

For Chrome users, files can also be Pasted (Ctrl-V) from the clipboard when the Attachments area is focussed and highlighted.

Files and images can be viewed in a File Viewer dialog by clicking (or right-clicking) on the thumbnails in the Test Details dialog.

The File Viewer will stay open during testing, and will auto-update to display the files/images associated with the current test.

Right-click on thumbnails (in the Test Details dialog) for more options such as download and delete.

Images for Test Results

Test results can have images (presumably screenshots) and files attached by dragging files onto the Attachments area of the Test Run dialog. The Test Run dialog includes the Pass/Fail buttons and is displayed during a test run.

Again, for Chrome users, images can be Pasted (Ctrl-V) from the clipboard. This makes it very easy to attach screenshots when using system shortcuts such as Cmd-Opt-Shft-4 on macOS.

When images are attached to results, they are represented in the results grid as Comments and displayed when the mouse hovers over the footnote dagger icon beside the relevant result.

Attached images are displayed as clickable thumbnails in the Comments section (below each result grid) of reports.

Storage Limitations

Individual files cannot be larger than 6MB.

Files are not part of the account/project/script exports and cannot be bulk downloaded from Testpad. Testpad is not a general purpose file storage facility!

The general idea is that uploaded files are simply copies of originals already in the user's possession and can be uploaded for the convenience of running tests or recording results.

As ever, any questions or problems, please email stef@testpad.com.

Reordering Test Run Columns

Stefan Butlin — Sun, 29 Mar 2015 00:00:00 +0000

Today we introduced an oft-requested feature to provide for rearranging the order of test run columns. Work is continuing with the bigger ticket items of folders and permissions, but the re-ordering of test run columns has been requested by so many customers that we took a short break to push this smaller update.

CTRL-LEFT and CTRL-RIGHT

Typing Ctrl-Left or Ctrl-Right will move the currently selected test run one column to the left or right.

Where a test run is a retest of older test runs, the older test runs (when shown) will always stay with their latest retest. Remember you can show old test runs by right-clicking on the test run header and selecting Show Old Test Runs.

ALT-LEFT/RIGHT and CMD-LEFT/RIGHT

For some users, Ctrl-Left/Right will have other window-related actions, so Alt-Left/Right and Cmd-Left/Right are also provided as alternatives. Have a try and see which key combination works for you.

Infrastructure Updates

And in the background, we also took the chance to upgrade the versions of Django, MongoDB, and Linux that Testpad runs on to pick up the latest security updates. Thanks to the flexibility of Amazon's Web Services, together with MongoDB's seamless clustering, these updates were performed without any break in service.

Any questions on test run reordering, service updates or new feature requests, please email stef@testpad.com

Improved Filter Controls and more

Stefan Butlin — Tue, 17 Jun 2014 00:00:00 +0000

This weekend saw lots of small improvements for Testpad, the biggest of which is an upgrade to how tagging and filtering works.

Filter with OR logic

Test Runs (columns) have a Tag Filter field that defaults to "ALL" which means that run will include all the tests. If you change this to e.g. "WIN", then that run will only include tests that are tagged "WIN", and the rest will be drawn grayed out.

Multiple tags can be supplied, and as before, if separated by a comma or space, will be applied using logical AND. For example, a run with Tag Filter set to "WIN HI" will only include test rows that are tagged with both WIN AND HI. If the desire was to include all rows with either tag WIN or tag HI, then that didn't used to be possible. However, with this release, you can now use the '+' character to achieve this kind of additive filtering. E.g. a run with the Tag Filter "WIN + HI" will include all tests tagged WIN OR tagged HI.

A note on precedence: there's no support for brackets or parentheses for complex expressions, instead the space/comma (for AND logic) takes precedence over the + for OR logic. So a more complicated Tag Filter of "A B + C D" will be including all tests tagged A AND B along with all tests tagged C AND D.

The minus prefix '-' still works to negate the match, e.g. the Tag Filter "A + -B" will include all tests tagged A along with all tests NOT tagged B. Note again that because parentheses aren't supported, there's no way to negate a group; the minus prefix can only be used on a single tag at a time.

Setting and Viewing Tags

To help with the new tag filtering, tags for test rows are now displayed as labels to the right of each row. As space is limited, tags are shown in fixed width labels that show the first 5 or 6 letters of the tag, and Testpad will only attempt to show the first 5 tags for each row.

Tags are set using the Test Details dialog, which can be opened in a number of ways: double-clicking on the row ID, clicking on the small corner triangle on the right-hand end of the row, or typing Alt-T.

Tags applied to outdented (parent, or title) rows will affect all their indented child rows. This is very convenient when you want to include/exclude whole sections of a script for a particular run; it saves on having to set a tag on each and every test.

User Interface Tweaks

In addition to the tag filtering improvements, a few UI improvements were also included in this release:

blocks of test rows can be selected and copied even if the Script has been locked for editing (remember Copy/Paste works between pages/tabs)
test run emails no longer CC the sender, instead they set the Reply-To field; this is to help with testers hitting Reply on these emails and inadvertently emailing Testpad Support instead of their test manager!
new option for the Auto Advance setting when running a Test: OFF simply turns off auto-advance so that the focus stays with the current test

As always, feedback on these changes is very welcome; please email me at stef@testpad.com

Growing Customer Base means Bigger Servers

Stefan Butlin — Mon, 12 May 2014 00:00:00 +0000

This Spring has seen a signficant increase in traffic due to a growing customer base, to the point of prompting server upgrades that were just completed this weekend. The new servers have increased Testpad's capacity and reduced page loading times; with the upgrade process itself proving the convenience of technologies like MongoDB for seamless database replication and Amazon EC2 for command-line control of servers archicture.

While Testpad's customers have been busy, Testpad has been quieter on the development front. However, with these latest upgrades, and further improvements around the corner, it's set to be a busy Summer. In the short term, look for improvements to tag filtering, followed later on with the publication of much needed user guides and documentation.

The rest of this post has a strong engineering bias. Read on if you're curious about Testpad's hosting, or get back to your testing, which should now be snappier than ever!

MongoDB + AmazonEC2 = Upgrades with Zero Downtime

The upgrade saw the main application servers moving from Amazon's older generation of servers (m1) to their latest (m3) servers. As well as newer CPU architecture, the m3 servers come with SSD storage, providing a big increase in database IO performance.

Thanks to the convenience of the Amazon EC2 management interfaces, and robustness of MongoDB's replication technology, these upgrades were performed with zero downtime.

Just to be safe, the upgrade was timed for the weekend when traffic is quieter than during the week, but nevertheless, the logs showed continuous usage before, during and after the upgrade, with no interruption to service.

Broadly, the upgrades were achieved by modifying one database (MongoDB) replica and application server at a time. Once a database replica is shutdown, the live service is maintained by the surviving replicas, thus freeing that server for maintenance. As all Testpad instances have their Linux root partition on an EBS volume, the upgrade itself is as simple as using AmazonEC2 controls to Stop the instance, edit the instance type, and Start it again. When the instance boots up, it is now running on bigger and better hardware! The database folder is then moved from its previous mount point on an EBS volume to its new home on the SSD drive. Once restarted, the MongoDB replica contacts the other replicas and catches up with all the changes that happened during that server's upgrade. Seamless.

Hourly Database Snapshots

Readers familiar with AWS might spot that m3 instance SSD drives are 'ephemeral' devices that do not persist if the instance is stopped or otherwise lost. Testpad therefore still runs replicas with the data volume stored on EBS drives, which continues to enable Testpad's backup strategy of hourly snapshots and archive to AmazonS3.

More Info and Feedback

Please get in touch if you have any feedback or would like to know more about the details of this upgrade - just email stef@testpad.com.

Keyboard Shortcuts for Even Faster Testing

Stefan Butlin — Sun, 26 Jan 2014 00:00:00 +0000

Testpad now supports keyboard shortcuts to set the results of tests during testing. This was a much requested feature and one we were only too happy to implement for our own testing too (testing Testpad with Testpad gets very meta!).

EDIT: Screenshots pre-date the big UI update in June 2018, but the shortcuts are still there and can save a lot of time

When running a test, with the Test Run dialog open (pictured right), you can press:

'p' or 'space' for pass
'f' for fail
'b' for blocked
'q' for query
'x' for exclude

You'll need focus on the result buttons (also as pictured right) for these new shortcuts to work.

If you want to record comments and issue numbers, hit 'tab' to cycle through the input boxes and finish a test by setting its pass/fail status. For example, the sequence to fail a test with a comment and issue number would be:

Press 'tab' to move focus to the Comments field and type a comment
Press 'tab' to move focus to the Issue field and type an issue number
Press 'tab' to move focus back onto the result buttons
Press 'f' to fail the test and auto-advance to the next test

Really Fast Checklists

If your tests are just simple checks that mostly pass without comment, then the spacebar shortcut (as an alternative to 'p') makes for a very fast way to zap through a checklist, checking off items as you go.

Edit Tests during Testing

As before, you can continue to edit test decriptions during a test run. This is useful as you're most likely to discover a problem with the test description during a test run, and being able to edit the test right there and then saves on having to remember to come back later

Using the mouse, you can click on the test text, make the edits, then click back on the Test Run details dialog to continue testing.

Or if you prefer to stay on the keyboard, hit 'Esc' to close the Test Run dialog, hit 'Enter' to start editing the currently selected test row, make the edits, hit 'Esc' to finish editing the test row and type 'Alt-X' to resume testing.

As usual, if you've got any comments or feedback on the new shortcuts, please send me an email at stef@testpad.com.

Copy/Paste Between Testpad Scripts

Stefan Butlin — Mon, 28 Oct 2013 00:00:00 +0000

The Copy/Paste feature in Testpad's script editor has been upgraded to work between scripts. This feature now uses javascript's HTML5 localstorage feature to save the clipboard to a place that survives page loads.

Between Page Loads

This means that tests copied on one script can be pasted into another script even after navigating to another script in the same or a different project.

Between Tabs

It also means that tests copied in a script viewed on one tab can be pasted into a script open on a different tab.

The only restrictions are that it will only work within the same account and on the same browser.

Paste Above or Below

As before, you can paste copied tests above or below the current selection.

By default, Ctrl-V (or Cmd-V on a Mac) will paste after the current selection, or at the end of the script if there is no selection (press Escape to clear the selection).

Shift-Ctrl-V (or Shift-Cmd-V) will paste before the current selection, or at the top of the script if there is no selection.

Copying a row will automatically include all the child rows (indented rows) of the current selection, making it very convenient to select and copy significant portions of a script in just a few clicks.

DIY Cut Support

Ctrl-X remains unsupported, but is simple to achieve by first copying with Ctrl-C then deleting with Del or Backspace. The copied (now cut) rows remain in the clipboard after the deletion and can be pasted back to the same script or a different script after navigation or change of tabs

Browser Compatibility

HTML5 localstorage is well supported these days, so it should work in the major/modern browsers. We have tested the new copy/paste on IE9/IE10 on Windows7/8, and Safari/Firefox/Chrome on OSX, but if you have any issues, please get in touch - stef@testpad.com.

Bug tracking - multiple issues per result

Stefan Butlin — Sun, 11 Aug 2013 00:00:00 +0000

Testpad has always let you insert bug numbers against results. Typically these come from a 3rd party issue tracking tool such as Jira or Bugzilla. Further, these numbers can be a clickable link to the relevant page in the 3rd party tool if the bug-link pattern has been configured (either in project settings or account settings).

But in an update today, Testpad now lets you enter more than one bug number against one result. Simply separate numbers with a space and Testpad will treat them as separate issues when generating links in both the script-edit view and the various report views.

There isn't much space for more than a couple of numbers to be seen in the script-edit view, so the printable report has been extended to list all the issues against results, again as clickable links, in the comments section.

Upgrade to Printable Test Reports

Stefan Butlin — Sun, 24 Feb 2013 00:00:00 +0000

The printable (snapshot) reports now include a list of all test comments underneath the summary grid. The comments are those collected during testing, and can be used for any result type: pass, fail, blocked, query, or even no result.

Quite a few customers have been asking for this one, especially where they're not using a separate bug tracker and want to record (and print) any problems in Testpad.

For now this feature is always on - if there is demand to make these comments optional, please shout and we'll make it more configurable.

This change only affects the printable (snapshot) report that is an all-in-one html file that can be saved and emailed as is, as well as printed. The browseable (live) report continues to show comments when you hover over the comment symbol in a test result cell.

QR codes in web-apps to link desktops to mobiles and tablets

Stefan Butlin — Tue, 26 Jun 2012 00:00:00 +0000

This post highlights a feature of Testpad that I think could be used a lot more across web apps in general - that of using QR codes as a convenient way to move a browser session from a desktop to a mobile. It’s fairly simple to implement and is surprising it's not used more.

The idea is mainly useful for web apps (as opposed to native apps) that have both a big-screen (laptop/desktop) version and a complementary small-screen (phone/tablet) version, and the problem is one of convenience when switching between the two.

Imagine using a web app on your laptop, all logged in and in the middle of some session. Then consider the steps needed to pick up this session on your tablet's browser:

launch or switch to the browser
enter the URL or load the bookmark (requires prior step of making a bookmark)
enter username and password if not cached, remembering that this happens on a touch screen, often prompting with inappropriate spelling corrections
navigate within the app to the item/action of interest

This can easily add up to dozens of taps and tens of seconds, i.e. it's fiddly and can be very frustrating.

Testpad’s solution

Testpad is a web app for writing and running checklists to help with the manual testing of software, especially in agile development environments. It's aimed at teams looking to do better than hacking a spreadsheet/wiki but without going for heavyweight “waterfall-inspired” Test Case Management.

![Testpad Screenshots]()

The big-screen UI is for composing checklists with a slick keyboard-driven outline editor. These can then be stepped through by a human on either the same big-screen UI or on the complementary mobile phone/tablet UI.

For Testpad's users, the mobile UI makes for a very convenient way of separating the app that's under test from the app that's managing the test run.

Instead of getting the user of a mobile to login and then navigate to the relevant account/script/test run, Testpad offers a QR code as a shortcut from within the big-screen UI. The QR code contains a URL like:

https://.testpad.com/script/2/run/1?auth=

which, when loaded by the mobile browser, takes the user straight to the UI for running those tests.

Now, instead of dozens of taps, the relevant part of the mobile version of Testpad can be reached in as little as one tap - which is the tap required to launch the scanner app (and assuming the scanner goes straight to scan mode, like Optiscan does).

There are more screenshots of Testpad’s tablet and mobile UI if you scroll down a bit on the Testpad home page.

If you want to try this for yourself, take advantage of the free starter plan. Simply create an account, open the “Hello World” script and click on the QR code button as illustrated above.

Implementation Notes

The simplest way to use a QR code in your web app is to include a fixed code that acts as a mobile bookmark. Google search for “qr code generator” for several online services that can generate a static image of a QR code.

However, it’s more interesting if your app can generate dynamic QR codes that are specific to the current context and user of the app.

For several years now, the easiest option here has been to use Google’s Infographics API for QR codes. Simply serve an element with a ‘src’ attribute pointing to this API, with the desired URL encoded as a parameter (along with other options). Sadly, Google have announced the retirement of this service in April 2015 (see the deprecation notice at the top of their page). Nevertheless, it might still be worth using this API for now because its integration is so quick, and replacing it with a DIY solution if the product/feature is proving its worth in a year or two.

Alternatively, for in-browser solutions, take a look at these JavaScript generators:
http://www.d-project.com/qrcode/index.html (renders as an image with a data URL)
https://github.com/jeromeetienne/jquery-qrcode (renders in a canvas tag or table tag)

And similarly for server-side generators, there’s the Java zxing project, or a pure Python library pyqrnative. For the Python library, StackOverflow have a question on serving dynamically generated images in Django which might be helpful.

Security caution: if also encoding an authorization token in the URL that can automatically log someone in, don't forget you probably want to implement an expiry date for the token. As depending on the sensitivity of the app and its data, this is a magic key that logs in anyone in possession of (or in line of sight of) the QR code on the screen!

For bonus points, the URL you put into the QR code can easily also include tracking parameters for stats and analysis. It's always useful to know if, how, and by whom, your QR codes are being used.

Email alternative

As cool as QR codes are, there is another alternative that doesn’t even need a third party scanning app, and that's having the web app send the user an email containing a link to the relevant mobile URL. Most email clients in mobiles will let the user tap the link and cause the browser to load the page. This is not quite as instant as a QR code as you have to wait for the email to deliver, but it’s still faster than trying to get there by hand. Testpad therefore goes for both methods for transferring to mobile: the QR code or an email link.

So if you haven’t already, check it out on Testpad. The starter plan is free and takes only moments to register for.

Follow me on Twitter @testpad

Make your own backups

Stefan Butlin — Wed, 09 May 2012 00:00:00 +0000

Although the Testpad servers have got you covered with their hourly snapshots of the database, many customers have asked for ability to download all their data in one go, without having to export each project manually.

New settings tab: Backups

Well, today, Testpad got just such a feature. Account owners (i.e. you need some proper privileges for this one) can browse to the new Backups tab in the settings page (these days it's the Export option in Account Security settings), and from there download a ZIP of all the data held in the account.

The ZIP contains folders for each project, with each project containing CSV files per script. Account and project settings are also saved to "info.csv" files in the relevant folders.

The CSV files can be opened in say, MS Excel, or parsed by a script for use in another process.

Automated downloads

If you (or a friendly system administrator) would like to write a script to regularly download your whole account, then enable the "auto-login" link provided. This link includes an authentication token which allows the download without first having to log in.

All optional, of course

But if you don't feel the need, then rest assured Testpad is keeping your data very safe anyway. The database is replicated across multiple servers located in separate availability zones on Amazon's cloud infrastructure. Further, hourly snapshots are archived to Amazon's long term storage service, S3, and regularly tested for consistency.

Good luck with your testing. Any questions, please email me (stef@testpad.com)

If you haven't already, give Testpad a try with a free starter plan:

Testpad Home Page

Minor update - expand/collapse controls and more

Stefan Butlin — Mon, 19 Mar 2012 00:00:00 +0000

Small update to Testpad over the weekend, mainly in response to customer feedback... you don't get what you don't ask for! Keep that feedback rolling.

Outline Controls

There are now some subtle controls to expand/collapse the visible outline levels of the rows in a script. You get these controls on both the script editing page and the interactive version of reports. I say 'subtle' as you have to know they're there to spot them...

The options "expand all" and "close all" should be fairly self-evident. As too is opening only to a specified level. Perhaps less obvious is the expand option called "Interesting". This option will close everything and then only open branches that have "interesting" results, where "interesting" is defined as any non-pass result.

More "Visiting" Options

When running a test, Testpad will auto-advance to the next test according to the visiting mode. This release added two more useful modes: visiting everything not already passed, and visiting just results marked as queried.

Performance Enhancements

Lots of improvements behind the scenes aimed at making performance better and more consistent, with the most noticeable effect on big scripts and projects.

And that, with a few minor bug fixes, is that for this update. As ever, please keep the feedback coming.

New features - Projects, Libraries and UI

Stefan Butlin — Wed, 22 Feb 2012 00:00:00 +0000

Testpad saw some big updates today with a whole new UI for grouping scripts into projects. Previously, Testpad had a "manage scripts" page that was a flat list of active scripts. This worked fine for testing single products but became a naming-convention headache for anything bigger. Many of you pointed this out and today, I'm happy to announce the release of this major feature.

So how does it work?

In Testpad, a Script is a list of tests structured as an outlined checklist. Scripts can be used as an outline of functionality to guide exploratory testing, a suite of test cases, or just a list of items you don't want to forget during testing.

A Script also collects its results, which are themselves organized into columns called Runs. So a Script is its tests and the results of those tests.

A Project then, is a set of Scripts, and can be used to make a logical group for tracking and reporting. A Project Report is the collection of reports for its individual scripts. Project reports can be shared internally and externally as required, and as before, both as an interactive HTML page or an HTML-snapshot that can be printed and/or attached to emails whole.

Using Projects to manage releases

To keep things tidy, old stuff can be archived.

Scripts can be archived within Projects, if that makes sense for your workflow, or whole Projects can be archived. This allows for considerable flexibility in how to use Projects. I'm thinking a common convention (and this is how Testpad itself is using them) will be to setup a Project per release of a product. E.g. I've got a project called "Testpad 2.0.1" that is a collection of several scripts covering its different functional areas. When a release is completed, I setup the next release as a new Project (Testpad 2.0.2 say), and copy-forward all the scripts from the previous release. You can copy scripts by dragging them onto their new project with the Ctrl/Cmd key help down.

Copying a script in Testpad has the effect of copying everything except the results, i.e. it treats a Script as an on-the-fly template for a new one. So the new script inherits the tests and the pattern of required test runs. As the scripts evolve with the product, I can edit away in each release, knowing I'm not spoiling the consistency of old tests and their old results.

The old project (release) is then archived as a whole. Report links for archived projects continue to work, so archiving projects just helps to keep things tidy from release to release, without cluttering up the list of active projects.

Also new, libraries of templates

Templates (basically scripts without any results; patterns of tests to be re-used in new scripts) are also grouped - into Libraries. Libraries are just the Testpad equivalent of projects but for templates instead of Scripts. A Template can be dragged onto a project, and a new script will be made from that template (no need to hold down the ctrl key this time).

Libraries of templates are useful for teams who like to pick and choose different sets of tests for different products, e.g. with a customizable and modular product, a subset of templates might be selected from a library and used to prepare a Project that has a set of tests adapted to the set of modules in use.

Big UI changes

The concept of Projects has had quite a bit impact on the management UIs of Testpad, pretty much only leaving the Script-editing page 'unscathed'!

With the right-click context menus and extensive drag'n'drop, it's really efficient to shuffle scripts into place and keep your testing organized.

So check it out if you haven't seen it yet (https://testpad.com/) and as ever, please send me your thoughts and feedback: stef@testpad.com.

An Interview with Testpad

Stefan Butlin — Fri, 13 Jan 2012 00:00:00 +0000

The Software Testing Club recently interviewed me and have run it as a blog post: The Testing Planet - An Interview With Stefan Butlin, Founder of Testpad. Check it out for more background on what Testpad is and some thoughts on testing in general.

Online Payments For SaaS Billing

Stefan Butlin — Thu, 08 Dec 2011 00:00:00 +0000

Testpad recently integrated a billing solution for its subscription plans. With so many Software-as-a-Service products popping up I imagined there would be lots of off-the-shelf options to choose from and it would simply be a matter of fitting our requirements to features offered.

Well, yes and no.

Yes, there are lots of subscription-specific payment providers, but no, integration is not a simple matter. Providers vary in the way they bundle the component elements to take subscripton payments and this has big implications for the design and development effort. Even with a decent all-in-one provider, don’t underestimate the amount of additional work required designing and integrating how the subscription plans will work.

This article is based on Testpad’s experience from integrating FastSpring’s all-in-one solution for our SaaS-based software testing tool. I’m not a payments expert by any means, but hopefully these notes will prove useful to the next guy setting out on this journey.

The Basic Components

Billing for a subscription service basically comes down to a make, buy or ‘assemble’ decision with four main components:

Payment Gateway: the service that performs the actual billing of a customers credit card
Merchant Account: an account into which credit card payments are initially deposited, and back out of which any chargebacks are taken; the merchant account is separate to the company’s bank account (which in turn can be referred to as the ‘settlement account’)
Payment Method Details Collection: the service that collects and stores credit card details and uses them to initiate charges via the payment gateway. As this component handles and stores payment method details it must be PCI Compliant.
Recurring Billing business logic: the code or service that handles subscriptions; the main task of which is to trigger the payment gateway to make charges every billing period. Usually also responsible for handling payment failures, reminder emails (called ‘dunning’), payment holidays, cancellations etc.

With the payment gateway and the merchant account you’ve got little choice but to buy. You don’t necessarily have to buy these separately though as some billing solutions bundle them into a single product. Whether these are bundled or not can make a significant difference to your setup and running costs.

However, payment details collection and recurring billing logic is very much a make or buy decision. Read on for the issues!

What are your priorities really?

Now, before looking at potential payment providers and browsing my list of issues, it’s worth taking a moment to identify what your priorities are. With multiple decisions to make at each turn, knowing what your real goals are will save you time.

For Testpad, our goals had a flavor of Eric Ries’s MVP - Minimum Viable Product Payments. Actually, you could get even more minimal than what Testpad started with and elect to manually bill your first customers until you don’t have time to.

Nevertheless, Testpad’s goals in providing an automated billing solution were to

minimize development time i.e. the amount of UI and code we would have to design, code, test and maintain,
minimize upfront costs such as setup fees or fixed monthly subscriptions,
and by implication: find an all-in-one solution to minimize the points of contact with 3rd-party providers and any integration hassles between different providers.

And non-goals included:

not trying to minimize transaction fees; this will be an optimization job in the future when there is revenue to optimize
similarly, not trying to minimize foreign-exchange costs (Testpad is based in the UK)

Plus, you might have several further, more detailed, requirements that you would like from your billing solution. For Testpad, while we had some in mind (like being able to gift customers a free month if we messed up somehow!), they took a back seat compared to the main goal of minimizing dev time.

Comparison of Subscription Payment Providers

There are several companies selling subscription payment solutions. The following are the services that I checked out, offering various combinations of the basic components. All have great reputation at the time of writing. While they also compete on many detailed features, I’m comparing them based on which of the the main building blocks they provide, as for Testpad, these dominated our decision.

Service	Payment Gateway	Hosted Payment-Details Collection	Merchant Account	Subscription Logic	Available in UK
FastSpring SaaSy	yes	yes	yes	yes	yes
Braintree Payments	yes	you host, lightweight PCI compliance	yes	yes
Stripe	yes	you host, lightweight PCI compliance	yes	API only
Amazon FPS	yes	optional	yes	API only	needs a US-based credit card
Recurly		yes		yes	yes
Chargify		you host, lightweight PCI compliance		yes	yes
Spreedly		optional		yes	yes
CheddarGetter	depends on plan	yes		yes	yes
PayPal Business Web Payments Pro	yes	yes	yes	some	yes

Integration Checklist

So. Enough with the basic scene setting. Here comes the detail. All of which is worth considering as it could influence who you partner with and what does or doesn’t get implemented in version 1.0.

In the spirit of Testpad’s testing service, a ‘design test’ for the following list can be found in the example library here: Online Payments Integration Checklist

Who is hosting the payment details pages? (aka PCI compliance)

You will need to be certified as PCI Compliant if your servers receive or store any payment card details. My take on this is that it is generally considered a pain to be avoided.

The obvious way to avoid the compliance process is to not host your own payment processing pages and let your payment provider handle it. Of course, this then means you’re not in direct control of these pages and are reliant on your payment provider for how much customization is possible.

There are half-way houses too. Most of the providers listed let you host the payment forms, but have them POST their data directly to them and not via your servers, thus avoiding most, if not all, of the process of PCI compliance. With this approach, don’t forget to factor in time to design these pages (and all the other pages that go along with them such as error handling).

With the big impact this makes on how you host these pages, and what it means for the continuity of your branding, it’s worth considering this issue carefully for each of your shortlisted payment providers.

Free Trial

Are you thinking of providing a free trial? How is that going to work – is it free for a limited time, or is it free for a limited feature set?

A big decision is whether to take credit card details at the beginning during initial sign-up, or to require minimal details for the free trial and then look to convert people during the trial. This is probably best answered (in the longer term) with your own split testing. For Testpad, we went with keeping initial sign-up as simple as possible to maximize the audience giving it a try; confident that it will ‘trial well’ and be an easy buy decision later.

Some payment providers support a free first month, but can’t not take credit card details up front. If that’s the case, then you can still do a credit card-less free trial, but you will have to implement that part of the ‘plan’ manually.

Either way, if you’re deferring taking credit card details, don’t forget to design the UI flow and email nudges that encourage conversion during the free trial.

Subscription Plan Design

You probably already know what different subscription options (plans) you want to offer and how they will be priced. If not, that’s something best decided before you continue as it will have a fairly big impact on the payment integration design!

However, don’t forget to consider:

are there limits or constraints associated with subscriptions (such as number of users, or other usage metric) that need enforcing in the code?
is it even worth enforcing these limits to start with?
what is the impact on the UI for subscriptions of different levels? e.g. do you hide unavailable options or show them but with an up-selling message when clicked?
subscription period: annual pricing as well as or instead of monthly?
special deals for charities, open-source projects, academic institutions?
is the product purely subscription based, or are there add-ons outside of the recurring charges?

Chargebacks and Refund policy

Chargebacks are when a customer contacts their card-issuer (e.g. their bank) to query a payment and request a refund. The card-issuer can then forcibly take the payment back out of your merchant account. These can be contested by the various parties involved, and this is a service that some gateways (or integrated payment providers) offer.

If you think your product might have a tendency to incur lots of chargebacks, it’s worth looking into the processes and costs in some detail. On the other hand, if your customer base is less likely to initiate chargebacks, e.g. because you’re selling to businesses and offer a transparent cancellation policy then it’s only worth simply understanding the issue and fees, and not worrying about whether it seems expensive or not (yet!).

Separately to chargebacks, there is also the issue of refunds, where your customers ask you for a refund. All the payment providers have a method for giving a refund, but vary in their fees.

Also consider how cancellations work. Should your customers get a refund for unused days/months of the billing period they cancel within?

Upgrades and Downgrades

If you’re planning to allow customers to upgrade or downgrade their subscription, if that’s even relevant to your product, then consider how that will actually work with respect to the billing cycle. It’s worth checking how your shortlisted payment providers deal with upgrades and downgrades.

Monthly subscription changes are typically simply changing the amount billed on the next cycle, with the new limits/features taking effect immediately. However, annual subscription changes might be more tricky. For Testpad, we just offered what the payment provider offered: the existing annual subscription is canceled and refunded for unused months, and a new annual subscription is started (and billed) on the day of the upgrade/downgrade.

What UI features will you need to design to handle upgrades/downgrades?

Cancellation Process

How do customers cancel their subscription?

How is the cancellation actually implemented? Don’t forget you will need to effect cancellation both in your own code and with your payment provider so the customer doesn’t get billed again. It would be a disaster if you managed to cancel the account ‘locally’ but left the subscription running somehow with your payment provider.

Does cancellation happen immediately, or does the subscription continue until the next billing date? i.e. when you’re not offering partial refunds, the customer still gets what they paid for.

Do you delete canceled account data or keep it dormant for reactivation in the future?

Can you prompt to get feedback at the point of cancellation? ‘Exit feedback’ can be very revealing and helpful in improving retention.

Payment Failure Process

Payment failures are very common with credit card subscription payments (expiry, new cards issued, maxed out etc) and customers will need politely chasing up and reminding to enter their new details.

All of the main subscription-centric payment providers cover this, and in my opinion, is a big reason to use a payment provider in the first place - let someone else be good at the code that gets this right!

However, do consider what flexibility you have in terms of:

the content of the emails that get sent to your customers
the interval and how many emails go out
how is a failure finally notified to you and the customer?
during the process of chasing up a customer, does your UI look or do anything different?
what does your product and the UI do on eventual expiration/cancellation?

Discounts, Coupons and Vouchers

There are many reasons you might want to offer discounts, and the payment providers vary in the models for implementing them, so it’s worth considering what kinds of discount you want to be able to offer and see how they might be achieved with your shortlisted providers.

Consider:

granting accounts for free
indefinite % discounts
N months free or discounted
single- or multi- use coupons
coupon/voucher codes with customizable text (do they have to be ‘ugly’ strings of random characters)
how might affiliate deals work? both in tracking and the nature of the discount they might be able to offer

Migrating Beta Audience

Many services are available as a (free) beta and sign up a significant audience before launching and starting the paid subscription plans.

If you’ve got a beta audience, consider

how will these customers be converted into free-trial or paid accounts?
will these customers be given a discount?
do they get different messages (in the UI or emails) to regular sign-ups?

Currencies

There are three places to consider currencies...

the currency your customers are charged in
the currency of your merchant account(s)
the currency of your settlement account(s)

To keep it simple at the outset, you can just do everything in US dollars. However, you’re likely (but worth split testing!) to see higher conversion rates if you offer prices and charge in local currencies.

Then you’ll need to consider how the price is set in different currencies, as you probably don’t want to list $99 as £63.61; and this might need configuring on both your system (for the pricing plans page) and in the product definitions held by the payment provider.

Aside from the currency choice, Payment Gateways vary in which countries they support in the first place, so definitely check your payment provider/gateway can charge in all the countries you would like to sell to.

Sales Tax / VAT

Depending on your location and the location of your customer, there may be sales tax (or VAT) to account for both in your records and on invoice/receipts sent out to customers.

You might also have preferences for whether your prices are displayed inclusive or exclusive of these taxes.

This is definitely something to checkout with your shortlisted payment providers as their support varies from no help to completely handling it.

Testpad went with FastSpring who completely handle this, so we didn’t need to dig into the implementation details any further.

API Integration (callbacks / notifications)

Before selecting a payment provider, it’s worth looking at (or asking your engineers to look at) how their integration APIs work. For example:

how will your system be told about successful subscriptions, changes and cancellations?
how are notifications secured?
do you rely on receiving notifications or do you also poll subscription status on some pages?
how will you test notifications? It’s easy during an initial test mode, but think ahead to when your product and payment solution are live, how then will any changes in code that handle notifications be tested?

And More...

If you’re still reading, here’s a list of further details you might want to check you’ve got covered:

frequency of transferring funds from the merchant account to your settlement account
analytics and tracking: can you add your Google Analytics and Adwords IDs to the right pages?
support for other kinds of payment method, purchase orders, invoicing
don’t forget to update Terms & Conditions and Privacy Policies
payment provider Test Mode features e.g. simulating payment failure
payment provider reporting (dashboards, statements, order lists, statistics etc)
process for adding a new subscription plan (and testing it) once existing plans are live? e.g. store test modes

Conclusion

Well, there isn’t really a conclusion as everyone’s requirements will be different.

For Testpad, based in the UK, it was an easy decision to go with FastSpring’s SaaSy service. It is an all-in-one package with a web-GUI to configure products and manage the account; no merchant account setup, no gateway setup, just one company to integrate with.

Had we been based in the US, it would have been a harder decision between Braintree, Stripe and FastSpring as all-in-one offerings. Nevertheless, FastSpring have awesome feedback for their customer service, and deservedly so from my own experience.

If any of this has been helpful, please get in touch. Follow Testpad on twitter: @testpad.

And do checkout Testpad if you want a refreshingly simple tool to improve your testing (or if you want to see how well we integrated FastSpring!)

Checklists. For bringing home Apollo 13. And software.

Stefan Butlin — Thu, 24 Nov 2011 00:00:00 +0000

Houston, we have a problem” is what everyone remembers... what happened next was Commander Lovell got out a checklist for Lunar Module Systems Activation, pictured below, and used it to ensure Apollo 13 made it safely home. And if you want to own the very checklist he scribbled his notes on, it’s going up for auction on Nov 30th here (edit: too late, that was back in 2011).

Everyone knows what a checklist is. The diligent (or forgetful) among us probably even have one for what to pack for vacation. You just can’t argue with their ability to make sure you’ve remembered everything.

When it comes to shipping software, deploying a website or submitting an app to the App store, you similarly want to ensure you’re remembered to check everything. Now this, of course, is the domain of software testing, and many methodologies abound, all sparring for a medal placing on the podium of Best Practice.

But why make such a meal of it?

Why not just whip up and maintain a checklist?

A checklist is really the same as a “Test Plan”, but it just sounds simpler, somehow more approachable. It’s also inherently adaptable to a light or heavy touch when it comes to the degree of control you want to assert or complexity of the software you’re testing.

Checklists can start really simple. Just list the main features that you want to check are working. Then add more detail as time and resources allow; extend it with bugs you missed last time; fold in more detailed scenarios; or concentrate on areas you know are more risky or problematic.

You can treat checklists as a guide to steer Exploratory Testing (formalized ad-hoc testing), as a charter in Session Based Testing, or as a fully scripted Test Plan. You can even layer on a risk model like Google’s recent Attributes-Components-Capabilities approach. Whatever suits your situation.

It was with this thinking that we built Testpad. If these ideas resonate, you should definitely give Testpad a try! The hope is that it will get more projects doing their testing that bit better, and without succumbing to procrastination for fear of having to choose a complicated-sounding methodology.

As Cmdr Lovell appreciated, apart from having to do some trajectory math 200,000 miles from Earth in a cold, cramped, and oxygen-depleted environment, having a ‘simple’ checklist to follow was a lifesaver.

It’s not rocket science.... usually.

Testpad is ready for business

Stefan Butlin — Mon, 21 Nov 2011 00:00:00 +0000

I'm really excited to announce that Testpad today finished its beta phase and launched the pricing plans.

Many thanks to all of you who sent in feedback during the beta. The comments and suggestions have been really helpful in shaping Testpad so far. And please keep your comments coming! Even though Testpad has now launched officially, that doesn't mean we're going to stop making it better and better.

Testpad's pricing plans start at $29/month and are based on the number of active scripts an account is maintaining, rather than the number of users. The idea is that you shouldn't feel at all restricted in how many people you involve in testing, whether it's just one engineer, a whole test team, or a flexible mixture of testers and engineers.

We're starting with the three plans listed on https://testpad.com/plans. If you have any questions about how these will work, or if these sizes don't suit your situation, then please send me an email via support@testpad.com, I'm sure we can work something out.

UPDATE 19 Apr 2012: Testpad now has a $FREE plan and paid plans starting at $9/user/month in addition to the original script bundle plans

Testpad is using FastSpring's SaaSy service for payment processing. They have a superb customer service team with a great response rate; if you are building an online product and are looking for a payment solution, it's definitely worth checking them out. Also, watch for a longer blog post about my experiences integrating a billing solution. (Edit: now published here.)

Meanwhile, good luck with your testing!

Beta Progress and Latest Updates

Stefan Butlin — Mon, 24 Oct 2011 00:00:00 +0000

Testpad has been live in its free Beta for 5 weeks now and has been getting some great feedback. Testpad's editing speed and the mobile access seem to be going down especially well. Many thanks to those of you that have been sending in your comments and suggestions. Where possible, I've applied that feedback in the update that went live this afternoon.

Updates

So what's changed? Here are the highlights:

The plain-text 'source' behind the library scripts are now available on github. It's still very early days for the library of examples, and this is an experiment to see if it makes the submission of edits and whole new scripts simpler. If you'd like to suggest a checklist for inclusion, just fork the 'testpad/library' repository, add the new scripts, and send testpad a pull request with your deltas.
Each example in the library now has a discussion thread at end of the script. So if github isn't your bag, you can always make helpful suggestions in the comments instead.
There has been some confusion as to when exactly auto-save happens, especially with respect to whether it's safe to navigate off the current page. So to that end, the script-editing page now shows a mini-status in the top left-hand corner which shows one of 'unsaved', 'saving' or 'saved' depending on the current status. I've also added a prompt to warn you if you attempt to leave the page before edits have made it to the server. However, if you've got a half-decent network connection, auto-save should be near instantaneous and this should rarely be an issue.
Shift-Enter now makes a new row above the current row; especially useful if you want to make a new first row.
The triangles showing open/closed sections of test cases are now clickable. Plus, as before, you can use the spacebar as a shortcut to toggle them open/closed.
Some tweaks to the HTTP caching logic to try to ensure the data behind the script page (i.e. the script and its results) are not cached when you use browser-back to come back onto the script-edit page. This seems to behave perfectly in Firefox, IE and Safari so far, with just Chrome being stubborn about loading it from cache.
And many small bug fixes. Thanks to those that pointed some of these out!

Next steps

Next up, which you can probably guess if you've been following @testpad, is to move toward an official launch of Testpad complete with the pricing plans.

Meanwhile, please keep the comments coming, they all help, however detailed.

Testpad adds iPhone/iPad support for test cases

Stefan Butlin — Mon, 10 Oct 2011 00:00:00 +0000

Big update to Testpad yesterday. You can now 'delegate' testing to your own iPhone or iPad, as well as friends, co-workers and guests. It makes your mobile a remote control for Testpad that let's you pass, fail, query and comment on tests. I've found running Testpad's own tests on an iPad a really natural way to run through a test script, much like holding a clipboard and checking off items as you go.

Frees up your main display

Perhaps the biggest difference this feature makes is that it frees up the big screen for other duties and cuts down on switching windows every time you want to record a result or read the next test. My iPad (and iPhone) sit idle on my desk a lot, so it seems to make a lot of sense to take advantage of them; they're basically spare input devices.

Seamless handover with QR codes and auto-login

Once a test script is ready for testing (written using a big screen and keyboard), I've tried to make it easy to get going on a mobile. You've basically got two choices: either scan a QR code (a 2D barcode) which instantly loads the link, or email yourself a link that you click on from your mobile's email client. Either way, the embedded link includes an authorization token, so you don't even have to enter a username and password. It takes you straight to the relevant test script, ready for testing.

Testing Testpad with Testpad

Having the option to drive testing from a touchscreen has always been the plan for Testpad (and hence its name in fact), yet even I was surprised just how convenient it was to use on Testpad's own tests. Testing Testpad with Testpad, juggling test accounts, and remembering which browser is logged in where can all get quite complicated! So it's a huge benefit to put the test script on its own screen (the iPad) and leave the app under test (Testpad, but logged into a temporary account) on the big screen.

Of course, I'm biased. Try it for yourself - it has to be seen (touched? felt?) to be believed!

You can sign up here to give it a try. As always, feedback welcome.

Testpad opens its doors; give it a whirl!

Stefan Butlin — Tue, 13 Sep 2011 11:46:00 +0000

After 8 months of building, including several months of limited field trials with forgiving friends, Testpad is now 'in Beta' and ready for feedback from a wider audience. Hooray!

It won't be perfect, that's why we're keeping it in Beta, but it's pretty good and needs some real-world use to put it through its paces.

We're going to keep Testpad free during the beta and then, when the pricing plans start, give a discount to beta customers who've sent us useful feedback.

So come on in; Sign Up for a free beta account and tell us what you think! (OK, not everything you're thinking, just the thoughts that might help us improve Testpad)

Welcome to Testpad

Stefan Butlin — Tue, 13 Sep 2011 10:46:00 +0000

Welcome to Testpad and, more specifically, Testpad's blog. The plan is to use this blog to keep you up to date with what's happening with the app, its features and, for the geeks at heart, how it works. But first, a bit of context...

What is Testpad?

Testpad is a web app (i.e. you point your browser at https://testpad.com) that gives you a simple and fast way to write your test scripts. It's not to be confused with tools that help automate testing; Testpad is for the testing you have to do by hand. You can think of it as an online document editor, highly specialized to the task of writing lists of things to test, recording results and reporting on progress.

Testpad is great for testing mobile apps, websites, and software in general. In fact, Testpad would be great in any testing/checklist scenario, not just software. But that said, it has been built with the problems and language of software testing in mind, so will seem most relevant to the challenge of shipping good software.

Simple by design, and blazingly fast

It's simple to write tests, simple to run tests and simple to report on tests. Testpad's goal is to be one BIG step up from sharing around copies of spreadsheets, yet way, way cheaper than the kind of money you can spend on fully-fledged Test Case Management.

Testpad is fast. Not just fast in the sense that Google is fast at page loading, but fast in actual use. With Testpad it's very fast and convenient to write a script and run it, over and over again.

Testpad makes a lot of use of asynchronous javascript to talk to the servers. This means you can focus on typing your test cases, while Testpad does all the saving and result tracking in the background. Plus, there are lots of keyboard shortcuts so you don't even have to reach for the mouse; just keep typing.

Foundations

Testpad is built on great technology including several of Amazon's cloud services (EC2, ELB, EBS, SES, Route53), and some awesome opensource projects including MongoDB, Django, and jQuery... but that's the subject of future blog posts - stay tuned if you're interested. Meanwhile, why not...

Give it a go!

Testpad is easy to get started with, especially so if you have existing tests that you can copy'n'paste into Testpad's Import dialog. And if you don't like Testpad, it's just as easy to get your script out as text, and/or CSV if you want results as well.

You can try the interface by signing up for a free trial at https://testpad.com.

Happy Testing!