I am looking to write extensive test cases and currently i feel this is slow i dont know should i spend time on it or not. Is it common problem ?
Thanks for your question. Could you share a bit more about what you mean by “slowness in automation”?
For example:
- Are you finding it slow to create/write automated test cases?
- Are the test executions themselves running slowly?
- Or are you concerned that the overall effort of automation is taking longer than expected compared to manual testing?
It would also help to know:
- What type of application you’re testing (web, mobile, API, desktop)?
- Which automation tool you’re using?
- Approximately how many test cases you’re planning to automate?
With a bit more context, the community can better determine whether this is a common challenge and suggest ways to improve the process.
What do you mean by : It is slow. Could you be more specific
Your question is too ambiguous to answer.
Please disclose more concrete information how your test runs and make your question more specific.
Please show us an example execution log of your test which includes timestamp information. And please annotate which step you regard too slow. For example, if a step of openBrowser() took 3 minutes you would want to annotate “this is slow, isn’t it?”. In that case, I think, everyone would agree with you. But if a step of openBrowser() took 10 seconds and you feel it’s too slow, then many would disagree.
Please clarify your question to get help here in the community.
As you are saying - you are looking to write extensive test cases, so do you mean complex and lengthy test scripts.
Yes, it’s quite common. In the beginning, automation often feels slower than manual testing because you’re spending time building the framework, creating reusable components, and dealing with issues you haven’t encountered before.
In my experience, the time investment starts to pay off once you have a solid base and a growing regression suite. I would focus on automating the most important test cases first rather than trying to automate everything at once. That usually gives the best return.
Kindly explain what is slow? katalon or AUT? kindly provide maximum information for further help
If you are employed, then management would see the value in having the test automation happen. As an example, when the time comes, I click a button and in fewer minutes than someone manually doing the test, voila, I can get results. Yes, as @henrryy.edward says, it takes a while to build the framework and sometimes rebuilding it for improvements, but the outcome is a very good return.
Automation testing does have issues if your application is dynamic or not, as dynamic is truly a beast and “painfully” slow to build stability for the page objects–dynamic means the identification of an object can change each time the application starts, so hopefully, you can see that as a headache just awaiting.
If you are not employed and just want to write extensive test cases, then it is a good way to pass the time and learn something, like XPath or CSS pathways to your objects. And, you can get a lot of walking done to think about what you are doing.
It is incredibly common to feel this way. In fact, almost every developer or QA engineer goes through this exact crisis of faith. Writing extensive test cases does feel slow initially, and when you are staring at a mountain of scenarios, it is completely normal to wonder, “Is this actually worth my time?”
The short answer is yes, it is worth it, but with a massive caveat: you need to shift your approach so you aren’t burning out on the creation process or getting bogged down by slow execution times.
Here is a comprehensive guide on why you are feeling this way, how to prioritize your writing, and how to supercharge your test execution speed.
Part 1: Why Writing Feels Slow (The “Testing Tax”)
When you write code or build a product, you get instant gratification—you see things working. When you write test cases, you are investing in an insurance policy. You don’t see the return on investment (ROI) immediately; you only see it when things don’t break later on.
The Cost vs. Value Curve
-
Without Test Cases: Development is fast at the beginning. But as the project grows, bugs multiply, QA takes longer, and you become terrified of changing anything. Progress slows to a crawl.
-
With Test Cases: Development feels slow upfront. However, as the project grows, you can add features with confidence because your tests catch regressions instantly. Your speed remains steady over time.
How to Streamline the Writing Process
If writing test cases feels like a grueling chore, you might be trying to test everything all at once.
-
The 80/20 Rule (Pareto Principle): Focus your time on the critical paths first—features that must work for the business to survive (e.g., login, payment processing) and high-risk, complex code. Leave obscure edge cases for later.
-
Use the Testing Pyramid: Don’t write massive, slow end-to-end (UI) tests for everything. Focus heavily on fast Unit Tests at the base, use Integration Tests for communication between modules, and save UI Tests strictly for crucial user journeys.
-
Leverage Automation and AI: Use AI assistants to generate boilerplate test code, and use parameterized tests to run the same test structure with multiple inputs rather than writing separate tests manually.
Part 2: What to Do If Test Execution Is Slow
Sometimes the frustration isn’t just writing the tests—it’s sitting around waiting hours for a bloated test suite to finish running. When execution speed drops, it kills your momentum. If the physical running of your tests is dragging you down, you can optimize your execution strategy with three powerful techniques:
1. Drop the Visuals: Go “Headless”
By default, UI testing frameworks launch a visible browser window and literally click through the app. This eats up massive amounts of CPU and memory.
-
The Fix: Switch your testing configuration to Headless Mode.
-
Why it helps: This runs the browser in the background without rendering the graphical user interface (GUI). It does the exact same work but executes up to 2x to 3x faster because it doesn’t waste time painting pixels on your screen.
2. Divide and Conquer: Run Parallel Instances
Running 100 tests one after the other (sequentially) is a massive time sink. If one test takes 10 seconds, you are waiting over 16 minutes.
-
The Fix: Spin up multiple instances of the browser to run tests concurrently.
-
Why it helps: If you split those 100 tests across 4 parallel browser instances, your total execution time cuts down to roughly 4 minutes. Most modern frameworks (like Playwright, Cypress, or Selenium) handle this with a single configuration setting.
3. Organize by Impact: Break into Logical Test Suites
You shouldn’t have to run your entire testing library every time you make a small change. Group your test cases into distinct Suites based on when and why they need to run:
| Test Suite | What’s Inside? | When to Run It? | Target Speed |
|---|---|---|---|
| Smoke Suite | 5-10 core user journeys (e.g., login, checkout). | Every single code commit. | Under 2 minutes |
| Regression Suite | Broad coverage of all main features. | Before merging code to the main branch. | Under 10 minutes |
| Extended / Nightly Suite | Deep edge cases, heavy data testing, and slow E2E flows. | Once a day (overnight) or right before a major release. | Can take hours |
The Verdict: Do not stop writing tests, but do stop trying to write exhaustive tests. Shift your mindset from “extensive coverage” to “high-impact coverage.” Use headless mode and parallel instances to keep your feedback loop fast, and use smart suites so you only run the heavy tests when absolutely necessary.
can you share the requested details
Automation felt slow but when u r running it 24 hours it surpasses human capibilities.
The Testing Tax Say it all!