The Complete QA Testing Checklist for Australian Businesses

By Saima Ather, SEO Specialist · Published 25 September 2026

Key Takeaways

• A good QA checklist for Australian businesses covers eight stages: planning, functional, usability, performance, security, compatibility, accessibility and post-launch — not just "did the buttons work".
• Most teams skip entry and exit criteria — clear rules for when testing starts and when a release is actually ready — and that gap is where avoidable bugs slip through.
• Security and accessibility testing carry real legal weight in Australia, tied to the Privacy Act 1988 and disability discrimination law, not just "nice to have" polish.
• Automating the wrong tests wastes more time than automating nothing. A short, deliberate regression suite beats a large, brittle one.
• The checklist below is built to be used, not just read — copy it into your test plan and tick items off against your next release.

It tells you what to click. It doesn’t tell you when testing is actually finished, how to decide which bugs block a release and which can wait, or how much of this should run automatically instead of by hand every single time.

That gap can cause problems for small and mid-sized teams, particularly when release deadlines are tight. 

This guide gives you a checklist for QA and software testing that covers the full lifecycle: before testing starts, the eight testing types that matter, how to decide what’s automated versus manual, and what still needs checking after the software is live.

What is a QA checklist, and why does it need entry and exit criteria?

A QA checklist is a structured list of what to verify before software ships, covering functionality, performance, security and more. Entry criteria define when testing is allowed to start; exit criteria define when it’s genuinely finished — without both, "testing" has no clear finish line.

Setting entry criteria — before testing starts

• ☐ Requirements are documented and the test team has read them, not just skimmed the ticket title
• ☐ A test environment exists that’s genuinely separate from production
• ☐ Test data is ready — including realistic edge cases, not just one happy-path example
• ☐ The build being tested is stable enough to actually get through a test case without crashing immediately

Setting exit criteria — before release

• ☐ All planned test cases have been run, and their results are recorded somewhere other than someone’s memory
• ☐ No critical or high-severity bugs remain open (see the severity table below)
• ☐ Any known, accepted lower-priority bugs are documented and signed off by whoever owns that decision
• ☐ Regression testing has been run against the areas the change actually touched

The 8-stage software testing checklist

Each stage below answers a different question about the software. Skipping one doesn’t always cause a visible failure — it just means that particular risk was never actually checked.

1. Functional testing: does it do what it’s supposed to do?

Functional testing checks that every feature behaves the way the business requirements describe, using both expected inputs and the ones users will inevitably try anyway.

• ☐ User registration, login, password reset and session handling
• ☐ Every form field validated against correct and incorrect input — including Australian formats like postcodes and phone numbers
• ☐ Core business logic: pricing, calculations, workflows specific to your product
• ☐ Navigation, internal links, CTAs and page redirects all resolve correctly
• ☐ Integrations with third-party systems (payment gateways, CRMs, APIs) behave correctly on both success and failure

2. Regression testing: did fixing this break something else?

Regression testing re-checks existing features after a change, to catch the times a fix in one place quietly breaks something in another. Skipping it is the most common reason "working" software breaks right after an update.

• ☐ Re-run tests covering any feature that shares code, data or a dependency with the change
• ☐ Keep a maintained regression suite rather than rebuilding test cases from scratch each release
• ☐ Prioritise regression coverage on your highest-traffic and highest-risk user journeys first

3. Performance testing: does it hold up under real load?

Performance testing measures how the software behaves under real-world traffic and data volume, not just on a quiet afternoon with one tester in the browser.

• ☐ Page load time and time-to-interactive, measured on realistic network conditions, not just office wifi
• ☐ Load testing that simulates multiple concurrent users, not just one at a time
• ☐ Behaviour under peak conditions relevant to your business — sale periods, EOFY, campaign launches
• ☐ Mobile performance specifically, including on slower connections

4. Security testing: what happens if someone tries to break it?

Security testing checks for the vulnerabilities that let an attacker access data, disrupt the system, or impersonate a legitimate user. For web applications, the OWASP Top 10, maintained by the Open Worldwide Application Security Project, is the standard reference list of the most critical risks to check against.

• ☐ Authentication and session security — password handling, account lockout, session expiry
• ☐ Input validation against injection attacks (SQL injection, cross-site scripting)
• ☐ Data encryption in transit and at rest, particularly for anything classed as personal information
• ☐ Payment and transaction flows, including how failed transactions are handled
• ☐ Access controls — confirm users cannot view or edit data outside their permissions 

If your software collects personal information from Australian customers, security testing isn’t optional polish — it sits directly under your obligations as an APP entity under the Privacy Act 1988, enforced by the Office of the Australian Information Commissioner.

5. Usability testing: can people actually use it without help?

Usability testing checks whether real users can complete common tasks without confusion, not whether the interface looks good in a screenshot.

• ☐ A new user can complete the core task (sign-up, purchase, booking) without needing instructions
• ☐ Labelling, error messages and instructions are written in plain language
• ☐ Layout, spacing and typography are consistent across pages
• ☐ Forms give clear, specific feedback when something goes wrong — not just "an error occurred"

6. Accessibility testing: does it work for people with disability?

Accessibility testing checks that people using screen readers, keyboard navigation, or other assistive technology can actually use the product. This is a genuine legal exposure in Australia, not just good practice — the Australian Human Rights Commission has confirmed that an inaccessible website or app can breach the Disability Discrimination Act 1992, and complaints against businesses have already been upheld on this basis.

• ☐ Full keyboard navigation — every interactive element reachable and usable without a mouse
• ☐ Meaningful alt text on images conveying information, not decorative filler
• ☐ Sufficient colour contrast between text and background
• ☐ Forms and error messages that work correctly with screen readers

The Web Content Accessibility Guidelines (WCAG), referenced directly in the Australian Government’s Digital Service Standard, are the practical benchmark most Australian testing teams check against, even outside government projects.

7. Compatibility testing: does it work everywhere your customers actually are?

Compatibility testing confirms the software behaves consistently across the browsers, devices and operating systems your actual customers use — not just the one everyone on the team happens to have.

• ☐ Major browsers: Chrome, Safari, Edge and Firefox, at minimum
• ☐ iOS and Android, on at least one older and one current device
• ☐ Screen sizes from small mobile through to desktop, not just the two most common breakpoints
• ☐ Any specific environment your customers are known to use — a corporate client base often means an older browser version than you’d expect

8. Post-launch testing: is it still working now that it’s live?

Post-launch testing verifies the live product continues working correctly after release and after every subsequent update — QA doesn’t stop at go-live.

• ☐ Smoke-test critical paths (login, checkout, key forms) immediately after every deployment
• ☐ Analytics and error tracking are confirmed working, not just assumed to be
• ☐ A process exists for triaging bugs reported by real users after launch
• ☐ A rollback plan exists and has actually been tested, not just written down

How do you classify and prioritise bugs once you find them?

Bug severity measures technical impact — how badly it breaks the system. Bug priority measures business urgency — how soon it needs fixing. A cosmetic bug on your highest-traffic page can outrank a "severe" bug in a feature nobody uses yet.

Severity	What it means	Typical exit-criteria rule
Critical	System crash, data loss, security breach, payment failure	Always blocks release
High	Major feature broken, no workaround available	Usually blocks release
Medium	Feature partially broken, workaround exists	Case-by-case, with sign-off
Low	Cosmetic issue, minor inconvenience	Documented and deferred, not blocking

Expert commentary: teams that skip this classification tend to argue about every bug as if it’s equally urgent. A shared severity table turns that argument into a five-minute lookup instead of a Slack thread that drags on for a day.

Should you automate testing, and where should you start?

Automate the tests you’ll run often and that follow predictable steps — regression suites, core user flows, API checks. Leave exploratory, usability and one-off testing to a person, because automation is only worth the setup cost when a test earns its keep by running repeatedly.

Good candidates for automation

• Regression tests that run on every release
• Core user flows: login, checkout, search — the paths that would be catastrophic to break silently
• API and integration tests with predictable inputs and outputs
• Cross-browser and cross-device checks, which are tedious and repetitive by hand

Better left manual (for now)

• Exploratory testing — a person actively trying to break things creatively
• Usability testing — judging whether something feels right needs human judgement
• One-off tests for a feature unlikely to be built the same way again
• Visual design review, where subtle judgement calls matter more than pass/fail rules

Tools like Playwright, Selenium, Cypress and Appium each suit slightly different jobs — Playwright and Cypress for modern web apps, Selenium for broader legacy browser support, Appium for mobile. Cognify’s quality assurance team builds and runs automated suites across all four, matched to the stack the client is already using rather than forcing one tool everywhere.

Common mistakes teams make with QA and testing

Testing only the happy path

If every test case assumes the user does everything correctly, you’ve tested the demo, not the product. Real users mistype, double-click, and hit the back button mid-form.

No defined exit criteria

Without a clear bar for "done", release timing gets decided by the calendar instead of by whether the software is actually ready.

Treating security and accessibility as optional extras

Both carry real legal exposure in Australia. Neither should be the thing cut when the schedule gets tight.

Automating everything, or automating nothing

An enormous, brittle automated suite that breaks on every UI tweak wastes more time than it saves. So does relying entirely on manual testing for a fast-moving product with weekly releases.

No regression suite tied to what actually changed

Re-testing everything on every release is slow. Re-testing nothing is risky. A regression suite mapped to what the change actually touches is the middle ground most teams never quite build.

How much does QA and software testing cost in Australia?

There’s no single figure — cost depends on whether testing is manual or automated, how many testing types are in scope, and whether it’s an ongoing engagement or a one-off pre-launch push. A small manual test pass before a single release costs far less than an ongoing automated suite maintained across every sprint.

For teams weighing whether to build QA capability in-house, bring in a dedicated provider, or add one or two testers to an existing team for a specific release, staff augmentation is often the fastest way to get experienced QA capacity without a lengthy hiring process, particularly ahead of a launch date that isn’t moving.

So where should your team start?

Pick the release you have coming up next and run it against the eight-stage checklist above, honestly. Wherever you find a stage with no real coverage — usually accessibility or security — that’s your next priority, not the next flashy feature.

A checklist only works if someone actually checks the boxes against a real release, not once as a planning exercise and then never again.

Talk it through before your next release

If a release is coming up and your team doesn’t have the QA coverage to feel confident about it, Cognify Digital’s quality assurance team can run a test pass, build an automated regression suite, or work alongside your developers for the stretch that matters most. Get in touch to talk through what your next release actually needs.

FAQ SECTION

What should be included in a software testing checklist?

A complete checklist covers functional, regression, performance, security, usability, accessibility, compatibility and post-launch testing, plus clear entry and exit criteria defining when testing starts and when a release is genuinely ready.

What is the difference between entry and exit criteria in testing?

Entry criteria are the conditions that must be met before testing can start, such as a stable build and documented requirements. Exit criteria define when testing is complete, typically no open critical bugs and all planned test cases executed.

What is the difference between bug severity and bug priority?

Severity measures how badly a bug breaks the system from a technical standpoint. Priority measures how urgently it needs fixing from a business standpoint. A low-severity bug on a high-traffic page can outrank a high-severity bug in a rarely used feature.

Is accessibility testing legally required in Australia?

The Disability Discrimination Act 1992 has been used to uphold complaints against businesses over inaccessible websites, according to the Australian Human Rights Commission. It’s a genuine legal risk, not just a best-practice recommendation.

What is regression testing and why does it matter?

Regression testing re-checks existing features after a change to confirm the fix or new feature hasn’t broken something else. It’s one of the most commonly skipped testing types, and skipping it is a leading cause of "working" software breaking after an update.

Should a small business automate its software testing?

Selectively. Automate tests that run repeatedly and follow predictable steps, such as regression suites and core user flows. Exploratory and usability testing generally still need a person’s judgement.

What is the OWASP Top 10 and why does it matter for testing?

The OWASP Top 10 is a standard, regularly updated list of the most critical web application security risks, maintained by the Open Worldwide Application Security Project. It’s a widely used reference point for structuring security testing.

How long should QA testing take before a release?

It depends on the size of the change and the risk involved, not a fixed number of days. A small bug fix might need a short regression pass; a major feature release needs full coverage across all relevant testing types before it meets exit criteria.

What testing tools does Cognify Digital use?

Cognify’s QA team works with Playwright, Selenium, Cypress and Appium for automated testing, selected based on the client’s existing stack, alongside structured manual testing for usability and exploratory coverage.

Can staff augmentation help with a QA gap before a launch?

Yes. Bringing in experienced QA testers through staff augmentation is often faster than a full hiring process, and can cover a specific release or ongoing testing capacity without a long-term commitment.