Object Oriented Thinking for Testers
Submitted by Antony Marcano on Fri, 18/05/2007 - 23:09.
general software testing
I've been hanging out in Orlando this afternoon, following STAREast. During a conversation with James Bach where he was explaining how he distils his skills into teachable heuristics, he used an interesting example. He talked about testing a walky-talky (two way radio). You know, the kind where you depress a button to talk then release it to receive. He explained how in one specific case if the walky-talky was in its charger and you grabbed it, depressing the transmission button while it was still in the charger, then undock it and then speak, it would fail to transmit.
He explained a heuristic he arrived at, which he called "standing state testing". Now, this name was specific to his experience and helped him to remember the situation so that he might apply it in other circumstances. What was interesting to me is that as soon as he described the example, I immediately started to decomposing the testing problem. How? By thinking in objects. I realised that this is exactly what I'm doing... all the time without even realising it.
Let me illustrate what I mean with the WalkyTalky problem... I immediately thought of the button as an object. It had state, i.e. buttonDepressed could be true or false. You can change its state, i.e. depressButton() or releaseButton(). You could look at the button (or feel your finger holding it down) to determine if the button isDepressed().
The button, although an object in its own right was a member of another object, the Receiver. The Receiver responded to events fired by the button. onDepress() we want to see myReceiver.startTransmitting().
Another object, the Charger could be handed myReceiver. I immediately think... myCharger.dock(myReceiver) to make the receiver a member of myCharger. I then think... if myReceiver.isDocked() then we want to see myReceiver.stopTransmitting(). And so on.
The problem James encountered was because myReceiver.undock() did not check to see if myReceiver.button.isDepressed() so that we can make myReceiver.startTransmitting().
This immediately makes me think of interaction based testing, as applied with mock objects. The fact that I've had this sort of programming experience allows me to think in this way and I think it helps me to be an even more effective tester.
It occurred to me that testers without programming experience might benefit from being able to think in this way without worrying about the code aspects of it. Mentally modelling the system under test might be beneficial and help some testers be even more effective at testing? Does it matter whether the implementation uses an object-oriented language? I don't think so. I'm simply using OO thinking as a method of decomposing a problem and needn't describe it in code.
Jon Bach (James' brother) asked me yesterday, "so what's your next intellectual endeavour Antony?". Jon, this is it...
"Object Oriented Thinking for Testers: an approach to mentally modelling testing problems"
I can see a series of blog posts and maybe a tutorial coming on...
;-)
Watch this space...
He explained a heuristic he arrived at, which he called "standing state testing". Now, this name was specific to his experience and helped him to remember the situation so that he might apply it in other circumstances. What was interesting to me is that as soon as he described the example, I immediately started to decomposing the testing problem. How? By thinking in objects. I realised that this is exactly what I'm doing... all the time without even realising it.
Let me illustrate what I mean with the WalkyTalky problem... I immediately thought of the button as an object. It had state, i.e. buttonDepressed could be true or false. You can change its state, i.e. depressButton() or releaseButton(). You could look at the button (or feel your finger holding it down) to determine if the button isDepressed().
The button, although an object in its own right was a member of another object, the Receiver. The Receiver responded to events fired by the button. onDepress() we want to see myReceiver.startTransmitting().
Another object, the Charger could be handed myReceiver. I immediately think... myCharger.dock(myReceiver) to make the receiver a member of myCharger. I then think... if myReceiver.isDocked() then we want to see myReceiver.stopTransmitting(). And so on.
The problem James encountered was because myReceiver.undock() did not check to see if myReceiver.button.isDepressed() so that we can make myReceiver.startTransmitting().
This immediately makes me think of interaction based testing, as applied with mock objects. The fact that I've had this sort of programming experience allows me to think in this way and I think it helps me to be an even more effective tester.
It occurred to me that testers without programming experience might benefit from being able to think in this way without worrying about the code aspects of it. Mentally modelling the system under test might be beneficial and help some testers be even more effective at testing? Does it matter whether the implementation uses an object-oriented language? I don't think so. I'm simply using OO thinking as a method of decomposing a problem and needn't describe it in code.
Jon Bach (James' brother) asked me yesterday, "so what's your next intellectual endeavour Antony?". Jon, this is it...
"Object Oriented Thinking for Testers: an approach to mentally modelling testing problems"
I can see a series of blog posts and maybe a tutorial coming on...
;-)
Watch this space...