If developers could test I'd be out of a job (well, if they were any good at it). To be fair, some of them can (and do) test their own work, but there seems to be something about a tester that means they can spot problems developers don't see. There are lots of different reasons for this: independence (we act as a fresh pair of eyes), no preset technological agenda (we often don't care how a solution is constructed, just that it works), wider scope (a tester is likely to touch more parts of a product than a dev focussed on one area only) but I'm going to focus on one thing here: perspective.
Developers are, by definitions, creators. They take a blank computer screen, do their magic and (behold!) a product appears. Testers don't create - they identify areas where refinements, polish and improvements will enhance the product, but (by and large) don't actually make those changes happen.
To me that's where the biggest difference lies - developers are looking to make something that fulfils the requirements, whereas testers try to ensure that the product doesn't do things it shouldn't. It's like the product exists in a bubble of requirements; developers are firmly on the inside, making sure everything does what it should, while testers are on the outside making sure that doing the "wrong" thing doesn't cause the bubble to burst.
When I was at university, I regularly played chess against someone who was far better than I was (he could play blindfold with 60 seconds on his clock versus 5 minutes on mine and still win). In one game he casually announced "mate in 3 moves" but I played so irrationally with unexpected sacrifices and ignoring obvious threats that it took him four. "You," he said, "are a spoiler.".
Spoiler. That sums up part of the testing mindset for me - like a naughty child, we're given something to play with and we try to break it. Not in order to destroy the product (declaring something "rubbish" is not going to win you any friends, as discussed in Diplomatic Baggage), but to make it the best it can be by identifying potential issues. And there's another meaning of "spoiler" that's appropriate - the item attached to a car in order to disrupt airflow and improve performance. I like the idea of being a disrupter, breaking things up a bit to create a better product.
Of course, this isn't the whole story - you can't just charge around trying to break things. There has to be an element of positive affirmation, making sure the product does what it should, but I think most testers are constantly looking for a way to break the boundaries of what is expected, looking from the outside in. A bit like when it's revealed in "The Sixth Sense" that Bruce Willis is a ... oops, spoiler alert.
Developers are, by definitions, creators. They take a blank computer screen, do their magic and (behold!) a product appears. Testers don't create - they identify areas where refinements, polish and improvements will enhance the product, but (by and large) don't actually make those changes happen.
To me that's where the biggest difference lies - developers are looking to make something that fulfils the requirements, whereas testers try to ensure that the product doesn't do things it shouldn't. It's like the product exists in a bubble of requirements; developers are firmly on the inside, making sure everything does what it should, while testers are on the outside making sure that doing the "wrong" thing doesn't cause the bubble to burst.
When I was at university, I regularly played chess against someone who was far better than I was (he could play blindfold with 60 seconds on his clock versus 5 minutes on mine and still win). In one game he casually announced "mate in 3 moves" but I played so irrationally with unexpected sacrifices and ignoring obvious threats that it took him four. "You," he said, "are a spoiler.".
Spoiler. That sums up part of the testing mindset for me - like a naughty child, we're given something to play with and we try to break it. Not in order to destroy the product (declaring something "rubbish" is not going to win you any friends, as discussed in Diplomatic Baggage), but to make it the best it can be by identifying potential issues. And there's another meaning of "spoiler" that's appropriate - the item attached to a car in order to disrupt airflow and improve performance. I like the idea of being a disrupter, breaking things up a bit to create a better product.
Of course, this isn't the whole story - you can't just charge around trying to break things. There has to be an element of positive affirmation, making sure the product does what it should, but I think most testers are constantly looking for a way to break the boundaries of what is expected, looking from the outside in. A bit like when it's revealed in "The Sixth Sense" that Bruce Willis is a ... oops, spoiler alert.
Comments
Post a Comment