Day 14 of Learning Testing: Experience-Based Test Techniques

Welcome back to Day 14 of my software testing journey! Over the past two weeks, we’ve learned how to test software using strict requirements (Black-Box Testing) and how to test it by looking at the actual code (White-Box Testing).

But what happens when the requirements are terrible, you don’t have access to the code, and your boss says, “We need to release this tomorrow!”?

You rely on the most powerful tool in your testing arsenal: your human brain.

Today, we are exploring Experience-based Test Techniques. These techniques rely heavily on the tester’s intuition, skills, and past experience to find the sneaky defects that formal techniques completely miss. Let’s look at the three most common methods!

1. Error Guessing

Have you ever looked at an app and just known exactly what to type to make it crash? That is Error Guessing.

Error guessing is a technique used to anticipate errors, defects, and failures based entirely on the tester’s knowledge. Experienced testers build up a mental library of what usually goes wrong. They base their guesses on:

• How this specific application has behaved in the past.
• The types of errors the developers on their team tend to make.
• The types of failures they’ve seen in other similar applications.

Typically, these errors relate to inputs (like missing parameters), outputs (wrong formats), logic (missing edge cases), computations, interfaces, or bad data types.

Taking it a step further: Fault Attacks

If you want to be methodical about error guessing, you can use a technique called Fault Attacks. This is where the tester creates (or acquires) a literal list of known possible errors and designs specific tests to expose those exact defects. Think of it as a “Most Wanted” list for bugs!

2. Exploratory Testing

In formal testing, you write the test cases on Monday and execute them on Tuesday.

In Exploratory Testing, tests are designed, executed, and evaluated simultaneously while the tester learns about the test object. You are exploring the app, learning how it works, and using that knowledge to dive deeper into untested areas in real-time.

To keep this from turning into aimless clicking, teams often use Session-Based Testing to give it structure:

• Time-Box: The testing is restricted to a specific timeframe (e.g., a 90-minute session).
• Test Charter: A document containing high-level test objectives to guide the tester’s focus.
• Session Sheets: A place where the tester documents the steps they took and the discoveries they made.
• Debriefing: A meeting after the session where the tester and stakeholders discuss the results.

Exploratory testing is an absolute lifesaver when you have inadequate specifications or are under extreme time pressure. It is highly effective when paired with formal techniques (like Equivalence Partitioning), but it requires a tester who is deeply curious, creative, and highly analytical.

3. Checklist-Based Testing

Just like a pilot wouldn’t fly a plane without going through a pre-flight checklist, QA engineers shouldn’t test software without one!

In Checklist-Based Testing, a tester designs and executes tests to cover conditions listed on a checklist. These lists are built based on experience, user priorities, and an understanding of how software fails.

The Rules of a Good Checklist:

• Items are often phrased as questions (e.g., “Can the user tab through the form fields?”).
• Every item must be able to be checked separately and directly.
• They can cover both functional and non-functional requirements (like Usability heuristics).

What NOT to include

Checklists should not contain items that can be checked automatically by a computer, things that belong in project entry/exit criteria, or statements that are way too general.

Maintaining the Checklist

Checklists are living documents! Over time, developers will stop making the same mistakes, making some checklist entries useless. At the same time, new severe defects will be discovered that need to be added. Checklists must be regularly updated based on defect analysis. Just be careful not to let them become hundreds of pages long!

The Trade-off

If you don’t have detailed step-by-step test cases, a high-level checklist provides fantastic guidelines and consistency. Because the instructions are high-level, different testers might execute them slightly differently. This lack of rigid repeatability is actually a good thing, it often results in greater overall coverage!

That wraps up Day 14!

In the next article, we are going to look at collaboration based test approaches. See you then!