"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"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.
"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)
Copyright (c) Adam Knight 2011 a-sisyphean-task.blogspot.com Twitter: adampknight
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.
Post a Comment