Software Testing and Development Blog Posts

Some notes on how I evolved my exploratory testing documentation approach.

TLDR; The learning experience that Steve Martin describes relates fairly well to many jobs, many of us don’t go the extra mile that Steve Martin attributes to his success.

TLDR: A 2008 case study in using QUnit.

Agile gets everywhere and it is not easy. It takes time. It takes practice. What will a tester do?

Back in 2001? 2002? Back whenever I noticed the ISEB certification starting, I thought “Hmm… how strange, I wonder why they would want to do this”.

I read an early draft of the syllabus online and thought “Well this seems fairly simple, but misses out a lot of stuff that I do in the real world, but what harm could it cause?”

What testing books should I read?" such a hard question to answer in a land where a testing book that has value at one point in your career ceases to have value later on.

I do have some books that I recommend to testers, entirely ignoring their context.

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.

Some notes on Brief Counselling and Therapy approaches applied to Software Testing.

A little history… As I did my best to teach a tester how to write test ideas for an Agile story I found myself wondering why I found coming up with ideas and questions a fairly easy activity and why they seemed not to find it quite so easy. Practice would have had something to do with it, but I also suspected a slightly different mental model.

In a previous post I discussed how I managed to do UAT badly in the past. Now I will discuss a generalised model formed from those (and other) experiences, which should allow me to make fewer UAT mistakes in the future.