We've all done it - you hit a snag, stare at the screen scratching your head, find nothing on google, then turn to a colleague and ask them. No sooner is the question out of your mouth than the answer miraculously appears in your own head. You listen politely to what your colleague says, knowing you already have the answer (or a new line of attack for the problem), thank them, excuse yourself and get back to work.
Or when you are experiencing a software/hardware problem and manage to grab the attention of the local friendly IT bod, who deftly stands on the magic button next to your desk that ensures any attempt to reproduce the problem in their presence is doomed to failure, with the problem never arising again (until they have gone just out of earshot).
Frustrating, but common. But there is a technique (discovered by developers, who encounter snags much more often than testers) that can help - the elegantly named Rubber Duck Debugging. The idea is to take an inanimate object (e.g. a rubber duck) and explain the problem to it step by step (out loud unless you're in an open-plan office) and often the solution will present itself.
So, when you think you have reached a sticking point, before asking someone else, rewind back to the start and talk through all the steps taken to get where you are - you may well find a loose thread or a memory might be jogged that gives the key to the problem. Same applies to IT issues - break down what you are trying to do into a series of steps and talk yourself through them in order. If that fails, perhaps now is the time to approach someone else.
I find you get a similar effect when trying to learn something new if you attempt to teach the information to someone else (even writing something up in the style of, say, a blog post can work...). Things you think you understand suddenly become less clear when you have to find the words to explain them - and connections between areas you didn't previously link can become apparent. All of which helps consolidate the knowledge you have already taken on (and pointing out any weaknesses where further understanding is needed). So even if no-one is reading this blog post at least it has helped me to sort my thinking out.
This is also a good habit to get into when writing defect reports - it may be that the defect arose because of a specific route taken to get to the point where the fault occurs; merely reporting the final action that caused the problem might miss the key point needed to fix the problem. Giving a full account of the steps you took allows for a defect to be easily reproduced by the investigating developer, or even another tester with no previous knowledge of the product. But also remember not to make the report overly detailed, for instance by omitting steps where there is no choice - even a rubber duck has a limit to the amount of information they can deal with.
Or when you are experiencing a software/hardware problem and manage to grab the attention of the local friendly IT bod, who deftly stands on the magic button next to your desk that ensures any attempt to reproduce the problem in their presence is doomed to failure, with the problem never arising again (until they have gone just out of earshot).
Frustrating, but common. But there is a technique (discovered by developers, who encounter snags much more often than testers) that can help - the elegantly named Rubber Duck Debugging. The idea is to take an inanimate object (e.g. a rubber duck) and explain the problem to it step by step (out loud unless you're in an open-plan office) and often the solution will present itself.
So, when you think you have reached a sticking point, before asking someone else, rewind back to the start and talk through all the steps taken to get where you are - you may well find a loose thread or a memory might be jogged that gives the key to the problem. Same applies to IT issues - break down what you are trying to do into a series of steps and talk yourself through them in order. If that fails, perhaps now is the time to approach someone else.
I find you get a similar effect when trying to learn something new if you attempt to teach the information to someone else (even writing something up in the style of, say, a blog post can work...). Things you think you understand suddenly become less clear when you have to find the words to explain them - and connections between areas you didn't previously link can become apparent. All of which helps consolidate the knowledge you have already taken on (and pointing out any weaknesses where further understanding is needed). So even if no-one is reading this blog post at least it has helped me to sort my thinking out.
This is also a good habit to get into when writing defect reports - it may be that the defect arose because of a specific route taken to get to the point where the fault occurs; merely reporting the final action that caused the problem might miss the key point needed to fix the problem. Giving a full account of the steps you took allows for a defect to be easily reproduced by the investigating developer, or even another tester with no previous knowledge of the product. But also remember not to make the report overly detailed, for instance by omitting steps where there is no choice - even a rubber duck has a limit to the amount of information they can deal with.
Comments
Post a Comment