Information Technology Dark Side

Tips for Testers
Exploratory testing is brain-engaged work. You can’t do it in a coma, at least not well. You have to be alert, focused, and INTERESTED in the application/scenario you are testing. This isn’t always easy, and the longer you test the same application the easier it becomes to slip into brain-dead testing.

There are a couple of good tricks I’ve learned over the years for staying focused, generally from Mike Kelly. Here are some I use:

• Keep test sessions under 45 minutes
• Take a short break between test sessions
• Write some code every now and then to reboot mentally and emotionally (this is especially useful if you ever get sick of testing)
• Rotate around the application, if you can (i.e. if there is major construction going on in different major areas of the app, test one area in the morning, test the other in the afternoon
• Try not to test all day, every day – there isn’t a lot you can do about test fatigue if it’s due to constant testing other than try to sleep well and get some exercise. Death march testing will reduce the quality of your testing dramatically within three days.

These are things you can do between test sessions to help keep your focus and energy, but what about during a test session?

Alternate Polarities
Jon Bach advocates an approach he calls alternating polarities. In this approach you spend several minutes testing from one polarity (or perspective), then you switch to an opposite polarity for a few minutes. Switching gears like this helps you in a couple ways:

1. It increase your mental engagement by making you more aware of how you are working
2. It increases your awareness of certain types of problems
3. It forces you to improve your skills when certain polarities expose a testing weakness

Here are the polarities Jon recommends:

• Warming up vs. cruising vs. cooling down
• Doing vs. describing
• Doing vs. thinking
• Careful vs. quick
• Data gathering vs. data analysis
• Working with the product vs. reading about the product
• Working with the product vs. working with the developer
• Product vs. project
• Solo work vs. team effort
• Your ideas vs. other peoples’ ideas

I’d like to propose another polarity to add to this list.

Being realistic vs being a goofy dork
Maybe an example is the best way to explain this.

Yesterday I was testing the lab results section of TriSano. I was starting to feel a little worn, partly because I’d made a stupid mistake that morning that impaired my productivity and distracted some devs who had to help me figure it out, and partly because I’d been testing lab results for several hours.

Anyway, lab results have some very sciencey aspects to them, and they tend to involve medical words like “hepatitis b antigen” that I’m not really familiar with, plus some I do know, like “blood sample”, “stool sample”, etc. Also, the labs that report these results tend to have very boring names, like ARUP.

The tests I was doing involved creating labs in our system, plus defining the lab test types they could report on and associating them with different diseases. Exciting right?

So here’s how I alternated between being realistic and being a dork:

I started out by using real test types and real labs, and I even did a little research to find test types I wasn’t familiar with and use them. In this polarity, I’m trying to act like a real knowledgeable user – someone who actually knows what these tests mean. To act like them, I have to learn a little bit about the domain. This is sometimes hard, as these domains can be daunting.

But then I switch over to being a goofy dork. I start making up silly lab names like “Mike’s Bar and STD Test Lab” or “Joanie’s Drive Thru Tuberculosis Clinic”. I try to be as goofy as possible, indulging that part of me that is childish and silly. Anyone who knows me has already said this, but yes, this is easy for me to do.

I also make up stupid tests, like “A bonk on the head” or “Kick him in the shins”. I also make up silly and rather morbid test results, like “You are soooo totally going to die”.

Now, to be fair, none of these values actually matter to the test. I just do it to keep my brain engaged and alert and to stop me from descending into random keystrokes for values (when you start typing asdf into everything, you know you are doing brain-dead testing). It helps me stay engaged, and I find it particularly helpful when I’ve been testing for several hours and it’s starting to wear on me.

Make your testing better by being a tiny bit malicious
If you test the same app long enough, you will get to know the dev team well. I am naturally interested (and rather decent at) figuring out what other people are not good at. Yes, I know that’s a very negative thing to be focused on, but I can’t help it. Since I’m being honest, I’ll just admit it makes me feel more confident to understand that I’m not the only person with weaknesses, and so I like to know where someone else is more likely to screw up.

I adjust my testing patterns based on this. And I find a little malicious joy every time it works. When I know who developed the code I’m testing, I adjust my approach. For example, a brilliant dev I know is capable of hugely complex re-factoring with expert skill, but give him a simple task that doesn’t require him to use 6 GB of brain memory and he is prone to make mistakes, usually simple, obvious mistakes that comfortable testers stop worrying about.

When I see that he has completed a story that seems easy, my malicious instincts perk up. I pick on it a little more than usual, looking for that silly mistake. I get excited when I find it, but I feel a tiny bit guilty when it creates anxiety for the dev.

I don’t think this is bad. I think it is simply an example of being context-driven in your testing. The traits of the person who did the work are an important part of that context. I’m not sure admitting I do this is going to be good for my relationship with the developer I’ve mentioned (he’ll know who he is if he reads this blog), but I’m going to trust in two things in this case: 1) his often-displayed above-average intelligence and maturity and 2) that he already knows about this particular tendency.

Stumble it!