Select Page
Over thinking it – I can therefore I will

Over thinking it – I can therefore I will

At TestBash Brighton 2016 one of the superb talks was on “Building the Right Thing” with Lisa Crispin and Emma Armstrong and the talk started with a very basic task – “make something that flies through the air”. My first thought on hearing this task was, “I’ll scrunch up the paper and throw it; that would be funny” quickly followed by “but I’m sure they don’t mean that and anyway I can make superb paper planes which would be more fun”

I made a plane ready to fly and then we were told that the requirement was one of Minimum Viable Product (I hate this phrase but that’s a separate blog post!) so my initial thought would have been spot on. Gutted.

I’d completely over thought the task at hand.Paper planes

This year at TestBash Brighton in their excellent mentoring workshop Shey Crompton and Nicola Sedgewick tasked us with something similar; the task was to build an actual “paper plane” this time though so I got to make a great paper plane and be on task for the challenge. Win win!

This time I knew that as it was a mentoring workshop there would likely be a challenge to teach and learn what we created so I decided to design my plane in as simple a way as I could think of; I based it on a simple dart shape rather than complex wing design with the idea being that if I threw it hard enough and it would fly a nice long way anyway but there would be a benefit of being able to easily teach the design. As predicted it flew across the room and happy was I!

We were then told to describe the process of building our planes to a partner (nice to know my intuition was right on that).

I was also confident that I could easily describe the process for my partner to replicate my plane…

Except that what is simple for me isn’t necessarily simple for others. I understand what my mind can process, understand and retain easily but I can’t know that of someone else, especially someone I’d never met until that moment. My partner did successfully follow my instructions although it was far from as easy as I’d envisioned it – I’d have been better off making an even more simple plane that was not as detailed with the trade off in flight capability being matched in reproduction capability.

(K)eep (I)t (S)imple (S)tupid

As testers we often can’t see the wood for the trees. We look at a system or a website or an app to be tested and immediately our mind fills with the potential things we can subject the system to in order to test it. Sometimes our mind is exactly on task and the intended tests are precisely what’s needed. Other times though we over-think it and end up wasting time in convoluted tests or bug investigations that could have been much simpler and allowed us to move on to other important tests.

We also try to make judgements and estimations of others’ capabilities whether it’s in our bug reports, test scripts (ugh!) clients demand or in meetings we have with our team.

Let’s look at some practical examples:

Example #1 – “I’m going to create a tool for test data creation”

You have a website to test where many accounts can all be in differing states. You decide you need to create 10 test accounts on the system. Rather than go through the monotony of creating them all individually by hand you decide to create a snippet of JavaScript to automate it for you.

The JavaScript takes you an hour to write, debug and run successfully. Job done!

Except that an account takes 2 minutes to create and the project only has 2 days of test time so in reality you would have used 2/3 the amount of time just doing it manually for the duration of the project.

D’oh!

Example #2 – “The main banner image is missing on one specific browser”

You’re testing a website and your baseline is Google Chrome. You’re happy with your coverage on the baseline and you move on to test on other browsers. Firefox passes with flying colours, Edge is happy and so is Internet Explorer 11. Safari has a couple of minor issues that you report and the next browser on your hit list is Internet Explorer 10.

You boot the clean image test machine, clear down cookies and cache and load the page but the main banner is missing.

A quick investigation verifies that the image is declared correctly in the code and it exists on the server when the URL is added straight into the navigation bar of the browser so it seems like a rendering issue.

Better bug it!

Investigate lessExcept that you reckon you can track down the exact cause of the problem and provide the developer with a load more info than a simple “Banner image on Internet Explorer 10 does not display” bug report.

You end up spending a further hour figuring out the full problem (the CMS uses a handler that’s declaring a different mime-type than the image actually had) and you report the full details. How great is that?

Wait… you used an entire test session to investigate that? So now there’s another charter than needs to be dropped or postponed?

Maybe just bugging it after 2 mins of investigation and letting the developers investigate the actual cause was a better plan even if you were providing far less information with that bug report.

Over thought it again (and ironically thought nothing about the other charters impacted by over-thinking this one thing)

So you see as testers it’s very easy for us to get carried away with our work, over-think the task at hand and produce less value to the long term project targets in favour of short term value to that single task.

Try to be mindful of Pareto’s Principle – you’ll get 80% of the output from 20% of the input and most of the time 80% is more than adequate. If you know you can investigate further perhaps add that offer into the bug and discuss it at the next scrum or with your project manager and allow them to decide.

Fore! How to score better with your testing approach

Fore! How to score better with your testing approach

Recently I did a 99 second talk at TestBash in Brighton in which I compared golf to testing:

https://dojo.ministryoftesting.com/lessons/99-second-talks-testbash-brighton-2017

Now I know golf is a rather dull subject to many people who may have never played it so I’ll try not to bore you all too much. 😝

The thing with golf as anyone who has ever watched it on TV knows is that you only ever need a single golf club to play golf at the highest level… Rory McIlroy, Sergio Garcia, Seve Ballasteros, Tiger Woods… They all only ever used one club! Let me explain…

  • Those guys tee off using a driver to hit the ball as far as possible. BOOM and down the fairway the ball flies.
  • Then they use the driver again to punch the ball down the fairway or onto the green.
  • And if they hit it into the rough or a green side bunker guess what club they teach for? That’s right, the driver!
  • Then they’re a foot from the pin where just a nice little tap in will win the hole. What club do they use?

Driver!

Except that actually nobody uses one club all the time because at the very best professional level in golf it would be inefficient (and for the vast majority of weekend warriors it makes the game completely inaccessible and not even remotely enjoyable.)

Every golf club has a purpose and an ideal use case; some clubs have multiple purposes or several use cases but no club fits all the purposes and all the use cases and yet I’ve met testers who apply that “one tool fits all” mentality to their testing daily!

I’ve met testers who use one set of browser developer tools and never try others (even berating others without trying them!) and I’ve met testers who have a certain choice of tracking their exploratory test coverage and they never look into other possibilities:

  • Is a notepad doc sufficient, useful and logical for others to read?
  • Would Rapid Reporter give the notes more structure?
  • Is the time trade-off worth the benefit to YOUR context?
  • Should you be tracking coverage in a spreadsheet because your client is a 3rd party who requires a visual representation of the testing done?
  • Does your tool integrate directly with your issue tracker? Should it?

Do people in YOUR context regularly evaluate your testing tools and techniques to make suggestions on improvements or do you sit quietly and not question the status quo?

For a long time I myself had one single choice of Proxy software to analyse what’s being sent from and fired back to a test app. I knew what I could do with it so I never looked into others, what was the point when I knew my choice of app well?

Sometimes tools can be used for purposes other than the intended one, much like someone may choose to “bump and run” a golf ball from the fringe of the green with a club normally intended for long shots off the fairway – For that specific shot it’s a great option. For that specific test you want to do perhaps cURL + JQ is a superb option to pull in some JSON and reorder it for comparison but for the rest of your testing there may be little value in those tools.

As testers we should strive to read about tools, try tools out, make notes on how you might use those tools best in your daily testing work and then maybe leave the tool alone until the task at hand DEMANDS that tool!

Maybe that will put us in a far less biased position when it comes to using the right tool for the job and it will expose us to more tools, better tools and ultimately make us more efficient in our day to day work.

The driver is not the best club for all shots all the time.