Techniques

TLDR: Every time we test something we are testing from models. Modelling is a key skill for Software Testers. Errors cannot be identified without a model to compare them. Quality Control cannot be conducted without a model.

TLDR; You can learn to detect ambiguity and then weaponize it for your testing. Do you think I meant that? What else could I mean?

TLDR; push back, ask questions, and if all else fails - plan it as a manageable set of tasks

TLDR; I avoided creating a definition of software testing for a long time because I thought it would constrain me. Instead I built a model of what I did. Eventually I generalised it to a ‘definition’ - “Testing is building and comparing models of a system to the system.”

TLDR; Tips for external public bug bash testers. This is not testing as you know it. Change your beliefs. Get ready in advance. Hit the system hard, hit it fast. Report quickly and well. Demoralise the other teams. “Congraturation! You Sucsess!”

TLDR; Look at what your GUI does. Automate that. And you’ve implemented “APP as API”

TLDR; Browsers Lie To Us

Let’s assume that the people who created the V-Model weren’t completely mental. Lets assume they had some secret mystical wisdom that over the ages has been corrupted and obscured by layers of rules.

I still remember my first real test. The first time that I purposefully designed a vector on to the system to answer a specific question and hunt for specific information.

Do you?

Any curious tester can find a number of published heuristic documents out there on the web and in blog posts. In this post I aim to show you an easy way of identifying new test ideas without recourse to heuristics, on a case by case basis, to allow you to add further depth to your own test explorations.