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 Factor Reality Team 3 manual testers, 0 SDETs Developers 11, already stretched thin Release cadence Every 2 weeks, slipping to 3 Manual regression ~5 days of tester time per release Hiring Frozen for 2 quarters 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']: