How a Manual QA Team of Three Automated 200 Test Cases Without Writing Code

"We can't hire an automation engineer. The budget is gone, and the good ones take five months to find."
That was the CTO's answer. The QA team had a different idea.

Let's start with a number that every small QA team recognizes:

Test cases documented in the wiki:     214
Test cases automated:                    9
Test cases run manually each release:  205
Release cycle time:                   11 days

Neha, Tom, and Arun were the entire QA department at a logistics software company. They knew the product better than anyone: every edge case, every customer complaint, every "oh, that thing breaks when the warehouse has more than 500 SKUs." What they didn't have was automation code, and nobody had the time to learn a framework while also running 205 manual tests every two weeks.

This post walks through how they closed that gap: the plan, the mistakes, the scenario format, and the numbers. If you lead a small QA team, or are a small QA team, you'll leave with a concrete blueprint. Estimated reading time: 6 minutes.

The Situation

The usual advice, "just learn Selenium," ignores the real constraint. Learning a framework takes months. Maintaining a scripted suite takes ongoing engineering effort. For a three-person team already saturated with release work, that advice is a polite way of saying "do nothing."

The Real Question

Instead of asking "How do we learn to code?" Neha reframed the problem:

What is the knowledge that makes our tests valuable, and does it actually live in code?

Looking at their wiki, the answer was no. Each test case already looked like this:

TC-118: Dispatcher reassigns a delayed shipment
1. Log in as Dispatcher
2. Open the shipment list and filter by "Delayed"
3. Select shipment SH-2041 and click Reassign
4. Choose a different driver with available capacity
5. Confirm
Expected: Shipment shows the new driver; the old driver's route updates;
          customer receives a notification

That is nearly a complete automated test. The value was in the scenario, the data, and the expected outcome. The code was just plumbing. If a platform could execute scenarios written in plain language, the team's domain expertise could become automation directly.

Sizing the Opportunity

Before choosing anything, they audited the 214 test cases:

# triage_test_cases.py
import csv
from collections import Counter

# Each row: id, title, runs_per_year, avg_manual_minutes, business_risk(1-5)
with open("test_cases.csv") as f:
    rows = list(csv.DictReader(f))

def priority(r):
    annual_minutes = int(r["runs_per_year"]) * int(r["avg_manual_minutes"])
    return annual_minutes * int(r["business_risk"])

ranked = sorted(rows, key=priority, reverse=True)

print("Top 10 automation candidates:")
for r in ranked[:10]:
    print(f"  {r['id']:<8} {r['title']}")

print()
print(Counter("high" if int(r["business_risk"]) >= 4 else "other" for r in rows))

The insight: roughly 60 test cases accounted for most of the manual hours and most of the risk. They didn't need to automate 214 tests to change their life. They needed to automate the right 60 first.

Choosing a Tool: The Criteria

They wrote their requirements before looking at vendors. Here's the list, which you're welcome to copy:

MUST HAVE
[ ] Tests authored in plain English (no code needed by testers)
[ ] Covers UI AND API AND database checks (logistics data matters)
[ ] Runs in CI so developers get feedback on every merge
[ ] Maintains itself when the UI changes slightly
[ ] Readable reports a non-engineer can understand

NICE TO HAVE
[ ] Cross-browser runs
[ ] Parallel execution
[ ] Reusable steps / test data parameterization

After a short evaluation they ran a pilot using BotGauge, which you can sign up for and try here. The match with their criteria was the deciding factor: scenarios in natural language, coverage across UI, API, and database testing, and CI/CD integration. The pilot cost them an afternoon of setup, not a quarter of training.

Converting a Manual Test Into an Automated One

Here's TC-118 rewritten as an executable scenario. Notice how little changed from the wiki version:

Feature: Shipment reassignment

  Scenario: Dispatcher reassigns a delayed shipment
    Given I am logged in as a Dispatcher
    When I filter the shipment list by "Delayed"
    And I select shipment "SH-2041"
    And I reassign it to a driver with available capacity
    Then the shipment should show the new driver
    And the previous driver's route should no longer include "SH-2041"
    And the customer should receive a delay notification

And because logistics bugs often hide below the UI, they added a data-layer check with the same plain-language approach:

  Scenario: Reassignment is recorded in the database
    Given shipment "SH-2041" was reassigned to driver "D-077"
    Then the shipments table should show driver_id "D-077" for "SH-2041"
    And an audit_log entry should exist with action "REASSIGN"

The testers wrote these themselves. No developer had to be pulled off feature work.

The Rollout Plan

They resisted the temptation to convert everything at once. Here's the schedule:

Week 1   Audit the 214 cases. Pick the top 60 by priority score.
Week 2   Convert 10 cases. Validate each against a manual run.
Week 3   Convert 20 more. Share a first report with developers.
Week 4   Convert 30 more. Connect to CI on pull requests.
Week 5+  Retire manual runs for converted cases. Convert in batches of 20.

A small rule saved them from a classic trap: every converted test had to be run side by side with its manual twin once before the manual version was retired. If the automated test passed while a human saw a defect, they treated that as a gap in the scenario's assertions, not a success.

Mistakes They Made (So You Can Skip Them)

1. Vague expected results. Early scenarios said "Then it should work." The fix: every Then must describe something observable, such as a message, a value, or a record.
2. Copying every manual step literally. Manual tests often include navigation filler. Automated scenarios read better when they express intent, not clicks.
3. No ownership. For two weeks nobody owned the failing-test inbox. They assigned a rotating "test triage" role, one tester per week.
4. Skipping test data planning. Several tests assumed shipment SH-2041 existed. They added a small seeding step to guarantee fixtures.

The Results

Measured across two release cycles (illustrative numbers from the scenario):

Something unexpected happened with team morale. The testers spent less time on repetitive regression and more time on exploratory testing, which is where the weird, valuable, human-found bugs live. Arun described it as "finally getting to test like a detective instead of a checklist."

What This Means for Your Career (and Your Team)

If you're a manual tester, this isn't a threat to your role. It's the opposite. The scarce skill was never typing locators. It was knowing what to test and what "correct" looks like, and that expertise is now directly convertible into automation.

Key takeaways:

1. Your test cases are already 80% of an automated test. Scenario, data, and expected outcome are the hard parts.
2. Prioritize by hours times risk. Automate the 60, not the 214.
3. Write requirements before evaluating tools. A checklist keeps demos honest.
4. Run old and new side by side once. It's the cheapest way to trust automation.
5. Reinvest the saved time in exploratory testing. That's where humans still win.

Your Next 30 Minutes

Open your own test case list (wiki, spreadsheet, or test management tool) and run a quick version of the triage script above. Find your top ten by manual hours times risk. If you can write those ten as plain-English scenarios today, you're closer to automation than you think.

Are you on a small QA team? What's the one test you'd automate first? Let me know in the comments.