The practical choice is not to automate everything or keep everything manual. Start with what could fail and the consequences, then choose a method that produces dependable evidence and can be maintained. Automate stable, repeated behavior when the expected result is clear. Preserve human exploration for changes and questions that have not yet become agreed rules.
Software Quality Assurance combines critical-journey testing, repeatable automated checks and actionable defect evidence. It does not promise zero bugs or coverage of every possible situation. The buyer needs to understand what was tested, what remains outside coverage and what that means for release.
Begin with risk, not test counts
Testing each of several dozen screens once does not establish that a journey spanning three screens works. Describe the user outcome, consequential failure, exposure to change and detection method. A small calculation rule can carry more risk than a large but rarely used page.
Classify findings as release blockers, review items or issues that may be deferred through an explicit decision. Severity alone does not determine priority: a moderate defect may become urgent if it affects the only available route for a particular group. Prioritization depends on the actual product.
Product Discovery & Requirements helps agree expected outcomes before a check is written. If the team disagrees about what a confirmed booking means, automation will not resolve the disagreement. It will repeat one interpretation more efficiently.
When does automation justify its upkeep?
It is more attractive when a check recurs, its rule is stable, its data can be prepared and a named owner will maintain it. Consider execution duration and failure diagnosis too. A test requiring human supervision every time, or failing unpredictably, may not reduce workload as its demonstration suggests.
Playwright’s guidance recommends testing user-visible behavior and isolating tests from one another. When purchasing a suite, ask what each check establishes and how it can run independently. Using a recognized tool is not an acceptance criterion by itself.
Manual exploration remains valuable when a journey changes rapidly or the question is still open. Can someone resume after interruption? Does an error explain a scheduling conflict? Repeated discoveries can later become automated cases once the expected behavior is settled.
Worked hypothetical: a booking product
Imagine a product for choosing a service, selecting a slot and confirming a booking. The team identifies 18 important items: eight duration and conflict-rule cases, six stable booking, amendment and cancellation journeys, and four exploratory sessions for a redesigned rescheduling experience. This is an illustrative set, not a recommended distribution for every product.
The eight rule cases are automated because their inputs and outputs are explicit. Four of the six repeated journeys are also automated. Two remain manual temporarily because their connected integration is changing. The four exploration sessions remain human-led while the team investigates behavior that has not yet been fully specified.
There are therefore 12 automated cases and six manual or exploratory work items. That count does not determine readiness. If the system permits two people to reserve the same slot when it should not, release may be blocked even if the other 17 items succeed. An item unavailable because of the test environment is recorded as not tested, not quietly counted as passing.
Product testability is part of the work
App Development may need to provide representative test data, isolate an external dependency or enable safe restoration of a starting state. Identify those requirements before estimating automation. Do not use sensitive production data merely because suitable test fixtures take effort to prepare.
Simulated responses can help test application behavior under known conditions. They do not independently establish that the external provider is operating correctly. Separate tests of your own logic from authorized integration checks in the appropriate environment and disclose what each approach leaves untested.
Likewise, repeatedly rerunning an unstable test until it turns green does not establish reliability. Investigate whether the product, environment, data or check itself is inconsistent. If a check is temporarily excluded, record the resulting coverage gap and the person accepting it.
Buy a suite the receiving team can operate
Request the test source, permitted fixtures, running instructions and a mapping between risks and checks. The receiving team should be able to execute the suite, interpret a failure and distinguish a product defect from an environmental or test defect.
When using Infrastructure as Code & CI/CD, decide which results block deployment and who can approve an exception. Placing a check inside a pipeline does not itself establish release authority. Name who updates tests when requirements change and how obsolete cases are deliberately retired.
Acceptance should include execution against an identified build, understandable results, reproduction of an agreed illustrative defect and evidence that an important failure cannot pass without the required decision. Plan for maintenance: writing a check once is not the full cost of owning it.
The delivery record should also distinguish planned from executed coverage. A spreadsheet containing test names is a useful asset, but it is not evidence that the tests ran against the release candidate.
Frequently asked questions
Is automated testing always faster?
Repeated execution may be faster, but data preparation, implementation, diagnosis and maintenance still consume time. Compare effort across repeated use, not just the demonstration’s run time.
Can we remove manual testing once automation exists?
Do not assume so. New behavior and exploratory questions still need appropriate review. Define the suite’s coverage before reducing another activity.
How many tests do we need?
The number follows risks, journeys and relevant data conditions. Many superficial checks can provide less useful evidence than a smaller set covering critical outcomes and boundaries.
Who repairs a test after a screen changes?
A named maintenance-team member or supplier under the agreement. First establish whether the requirement changed or a defect appeared. Do not simply adjust the check to accept any new result.
Begin with failures the next release cannot tolerate. That makes it possible to select a manual and automated mix that supports the decision, rather than buying a test count without understanding its significance.
Technical reference
- Playwright: Best Practices, reviewed 26 October 2026. The example allocation is hypothetical, not a coverage standard or quality guarantee.
