Exploratory Testing and UAT

Every scripted test of Basketly's new delivery-slot booking passes. Then a tester spends an hour just using it, opening two tabs, switching networks, going back mid-payment, and finds that two customers can book the last slot. A week later, the store manager tries it and says, "This is fine, but we need slots to close two hours ahead so we can pack." Neither finding came from a script.

The rule

Exploring learns and tests at once; UAT lets real users decide.

Exploratory testing means designing and running tests at the same moment, letting what you learn from each result steer the next. It is not random clicking. It is disciplined:

• A charter gives the mission: Explore (target) with (resources or tricks) to discover (the kind of problem).
• A time box, often 60 to 90 minutes, keeps it focused.
• Notes record bugs, questions and ideas for new scripted tests.

It shines on new features, where scripts cannot yet imagine every path, and it finds the surprising bugs that scripts miss.

User acceptance testing (UAT) is done by the people the software is for: real customers, or business staff such as Basketly's store managers. They use it for realistic tasks and decide whether it meets their needs. UAT is usually the last gate before release. It answers "did we build the right thing?", while most other testing answers "did we build it right?"

The shortcut

Ask "Who is testing, and what are they trying to learn?" A skilled tester hunting for unknown problems: exploratory. The intended users deciding whether to accept it: UAT.

The trap is treating UAT as a second round of bug hunting by testers. If the users are not the ones deciding, it is not acceptance testing.

Drills

Answer fast — trust the rule.

Remember

• Exploring learns and tests at once; UAT lets real users decide.
• Charter, time box, notes: exploration with discipline.
• UAT asks "did we build the right thing?"; the users, not the testers, decide.