Bernard Woolley: But, you only need to know things on a need-to-know basis.
Sir Humphrey Appleby: (quite animated) I need to know “everything”. How else can I judge whether or not I need to know it?
Bernard Woolley: So that means you need to know things even when you don't need to know them. You need to know them not because you need to know them but because you need to know whether or not you need to know. If you don't need to know, you still need to know so that you know that there is no need to know.
Sir Humphrey Appleby: Yes!
http://www.youtube.com/watch?v=vh1eCDotdSc
(about 1.35 onwards)
The above quote comes from the popular 1980s sitcom ‘Yes Minister’ which was an amusing look at the high handed and snooty aspect of British politics at the time. The show provided a different way of looking at politics, often in a comical way. The actual scene from above has Sir Humphrey, who was the Permanent Secretary to the Cabinet Minister and is quite manipulative in his dealings with the Minister, in the aim of ensuring his own agenda is fulfilled. Alongside him is Bernard, who is the private Secretary to the Minister (a body man of sorts), loyal to the Minister and quite naïve.
When I saw this scene, it got me thinking of how this “need to know” relates to the Testing field. I have on many occasions, been asked ‘what makes a good tester’. My language I find varies dependent on audience, but a few central themes never change. Creativity, inquisitive, understands the role (as in it’s not about being a Yes person and following the ‘green bar’) and crucially, ability to focus and de-focus.
It is this final point that I want to elaborate on.
The main difference between an average tester and a good tester is that ability to appreciate how and what they are testing and how that relates to the bigger picture. Too many testers can test their feature/application/story at that time and see it almost as an individual entity. That’s fine, there is value in that aspect (they can focus).
However, the really good testers will do that AND be able to place it into the bigger puzzle (defocus).
In other words, ‘I am testing feature x, ok that works, great (focus). Now, what about feature y and application z, they have dependencies on feature x and there is a knock on from application abc, as that feeds into feature x. Ok, I need to pull together a map/compass as to how I am going to test those dependencies. Oh, also, a customer might do d, e and f that rely and interact with feature x. I need to test that too’ (defocus)
Remember what service a tester provides. The tester provides information on a feature/application/software. That information shouldn’t just relate to the feature/application/software in isolation, it should also be information on as many aspects of that feature/application/software as possible, in the time allowed.
Now, an average tester might say ‘oh, I didn’t know I had to do that and I am testing the story/feature as that’s what the requirement is, I don’t need to know what feature y and application z do’.
My counter to that is ‘you should want to know everything, how else will you judge what you need to know’. Sir Humphrey was right in this instance.
