Guided by Fun

This is actually a rewrite of my old blog post: Using Fun as your guideline. Reason being that I think the idea is good but it was poorly presented and too connected to our unique context in the old version.

Background
Documentation is generally not fun, so focusing on fun would leave us with chaos
// colleague

This summer we ran an unintended experiment in my team where almost all our time was spent testing and documentation only existed as casual notes not really stored anywhere.

What happened was we couldn't explain to stakeholders what we had done, why and what our current status was. However, we did get a lot of testing done so we pretty much failed to support stakeholders but did support programmers.

Was it fun? No! Why? It was frustrating and we felt unprofessional.

So we added some very basic documentation. When we encountered questions we couldn't answer, we first asked ourselves: Is this question really something we should be able to answer. If yes we looked at what we had to improve to be able to provide that answer, if no we politely explained this (I will touch the "it's not a choice" response in further down).

Guideline
At some point we realized that generally the better we worked the more fun we had. Turing it around would be: The more fun we had the better we seemed to work. Fun was a lot easier to relate to than "better" or "more efficient" so we stated what we felt was fun, asked ourselves if it seemed like a good way to work and, if so, tried to reinforce it. Here are our results:

• More time for testing = fun
• Understanding what we do (continuous learning) = fun
• Being able to explain our testing = required to have fun
• Knowing what is done and what is left = required to have fun

In practice we try to fulfill the bottom two requirements, in an as lightweight but sufficient way as possible so we can put as much time as possible into testing and learning (association to exploratory testing anyone?).

It's not a choice

When you don't really see a point in answering a certain question the response might be:

It's not a choice

Without going into reasons for that, both valid and invalid, let's talk about how to approach it. First, never (if possible) ask for what information someone wants, ask what questions you should be able to answer. This not only helps you find alternative information that might be sufficient but it's also something not too often asked so the stakeholder can't just go back and use the default answer.

If this isn't enough try to understand what the information/answer is used for (by asking questions, not by making assumptions). This may:

• Make it less frustrating to provide (since you understand its value)
• Help you find a better alternative
• Make the stakeholder more aware of gain compared to cost

Summary

Always trying to enforce things that make testing more fun is not a solution to every problem, it's a heuristic, it can be very useful in many situations but not all. Please also notice the opposite of fun is boring, not serious or professional. Instead I claim doing something in a boring way when there exists an equally good, or better, fun alternative, that is truly unprofessional.