“A strong man doesn’t need to read the future. He makes his own.” – Solid Snake

In testing, we can’t plan for every eventuality but we can be prepared for them.

---

With that philosophy in mind, we’re heading deeper into my Test Suite structure:

Test Suite > Test Case > Test Script > Test Method

These next couple of posts are all about how my Test Scripts defines freedom with framework.

Guided Freedom

Lets go back a post, to the Test Case for Error Handling we created, and continue to use the example we had there:

Error Handling Test Case - CR1000.

CR1000A – The game does not crash to system.
CR1000B – The game does not crash and reload.
CR1000C – The game does not hang indefinitely.
CR1000D – The game does not become unresponsive during user interactions.
CR1000E – Error Logs can be retrieved.

Each line with the Test Case code (CR1000) and a letter suffix represents a unique Test Script.

While CR1000’s Expected Behaviours may be wide in their scope e.g. “The game does not self-terminate”, the Test Scripts bring that scope in to a specific type of self-termination.

It does this for two main reasons:

1. It increases the accuracy of our data by narrowing each check to a specific behaviour.
2. It reminds testers what to look for.

Let’s quickly expand on point 2.

Every new generation of testers has a lot of gaming experience. They’ve grown up with games and computers, they know how systems work better than the last generation.

Our Generic Test Suites depends on that knowledge, and so the Test Scripts (usually) don’t tell a tester what specifically to do but what they should/aim for. The tester gets to be creative with a goal in mind. However, we’re not just throwing caution to the wind, the “creativity” is logged in a Test Matrix for future reference.

What’s Inside A Script?

Lets crack open CR1000A to bring some clarity to what we just talked about. Like our Test Case, our Test Script has some similar as well as new parts:

🔹Expected Behaviour(s)
🔹Important Information
🔹QA Notes
🔹Test Method
🔹Labelling
🔹Examples of Passes and Failures

We’ll split these out and discuss them in more details next week but for now, we’ll have a quick look at the last part of the Suites chain, the Test Method.

In CR1000A, someone testing for me could expect to see something as simple as:

1. Boot the application.
2. Check throughout the entire application.

Now obviously, there would be supporting documentation in QA Notes and Important Information but that is basically it. A tester knows when they come across a crash, so this Test Script is effectively tested passively during all testing. The QA Notes, Important Information and Examples will allow a tester to apply the Test Script to any game they may be currently testing.

Hopefully, the point is really starting to come across now, the actual Test Method is quite high level but has all of the support a tester may need and that’s what we will get into next week!