Friday, 24 June 2011

Small mercies - why we shouldn't knock "it works on my machine"

I go to quite a few test events around the UK. Conferences, User groups and meetups. A thread of conversation that is a perennial favourite at such events is the ridiculing of programmers that, when faced with a bug in their code, claim
"It works on my machine"
Testers revel in the pointlessness of such a statement when faced with the incontrovertible evidence that we have amassed from our tests. We laugh at the futility in referencing behaviour on a development machine as compared to the evidence from our clean server and production-like test environments. Surely it is only right that we humiliate them for this. Well I say one thing to this

At least they've tried it.

At least the programmer in question has put the effort in to test their code before passing it to you. Of course this should be standard practice. More than once, however, I've encountered far worse when discussing bugs with the programmer responsible:-
"I haven't tried it out but let me know if you get any problems"
"According to the code it should work"
"I can't think of any reason why this should fail"
"You've deliberately targetted an area of code that we know has issues" (I'm not joking)
Programmers work in development environments. These are usually a far cry from the target implementation environment, hence the need for test systems (and possibly testers). The development environment is the earliest opportunity that the programmer has to run the functionality and get some feedback. If the alternative is to waste time pushing untested functionality into a build and a test harness and use up valuable testing resources on it then I'm sorry, but I will take "It works on my machine" over that any day.

Copyright (c) Adam Knight 2011 Twitter: adampknight

1 comment:

  1. Here are few tips from BBST Bug Advocacy course: 1. Test code on more than one configuration (video card, memory, processor, network peripherals) and find the configuration where a program is in its worse state
    2. Use two computers one to run the test step by step second to record the bug details as run the test
    3. Find the general configuration where the program is likely to fail.
    You are more likely to find configuration that developer is running his/her program on.


Thanks for taking the time to read this post, I appreciate any comments that you may have:-