Very few people get testing.
The mindset of a good testing person is hard to identify...
When asked to test something do they split the problem up into small parts, or do they simply test inputs and outputs...do they cover all the inputs? all the outputs? Do they only ask hard questions, and never cover the easy stuff? Do they only think of the obvious, and never broach the harder questions? Do they think of the system as a whole? Do they think of things outside the system that can affect it?
See cause a good tester hits lots of these things in turn, they identify that they've attacked a problem from one angle, go back to the beginning and attack it from another angle. This is the single hardest thing to identify, cause some people use up minutes while thinking of different paths to test, others take significantly longer.
Explaining that to other people is one of the hardest things I've ever tried to do.
Haha, explaining to other people that few people get testing is hard...hehe...sorry, back on topic.
When I explain things to other people by simplifing them, I often feel that I am dumbing it down and that those people are not going to be making informed decisions. However, if they get accessibility (to the information) instead of accuracy (details) is that enough?
I mean we don't teach math by starting with decimals...you learn integers first.
Example: In first grade we were taught 2 divided by 3 is not doable... despite the fact that .6666 is a valid decimal value. In order to teach accessibility (integers) so that kids can grasp it we left out accuracy (decimals) till after they got the first concept...
So what information about testing can be accessible (to non-testers) while perhaps not being accurate (for testers)?
Depth vs Breadth? Maintainance of test cases? Automation? Execution?
Nevermind the challenge of communication, haha.
ReplyDeleteDoes it help to explain that testers use what developers consider a handicap: ADD?
I think most aspects of testing are easily communicated. However, it may be impossible hold them up all at once and therefore the sum of it, which may be what you are trying to convey, is underestimated.
ReplyDeleteFor example, if there are many inter-dependent inputs, you could explain combinatorial calculations. (Or is that good example of a conversation you would not want to have in the hallway at the office, eh?) And the system may have fewer inputs but the user interface is also unwieldy across several screens? Also, there may be several manual interrupts in the system or timed procedures?
How do you convey the cumulative difficulty or test duration?? Well, you don't. You just slap the person and say "I am paid to handle this, it's not easy, and that's all you need to know."