If every question is a test case or represents say 10 test cases, can you create 100-1000 test cases in say 20 minutes… Any James Bach student, context driven and or rapid tester will demonstrate that it is possible ….
Without any KA/KT, training, domain knowledge, no pages of documentation …? Plain vanilla testing at its best. Unbelievable right?
One might say --- that is cheating …!!! you may scream… that is not a test case. Where are steps? Where are the detailed information about application? Can a novice, low skilled tester use this? Can this be used for next five years? Can that be automated? And run in night when people are sleeping and give the results in the morning (in plain pass fail – way)?
The answer is “No”
Please note, while we create lots “frills” or decoration around real test and call it as test case – at its core a test is a question that we ask the program and program responds to it with one more answer. Some of these answers we can observe, assess, report while lot others go un-noticed. And while this happens, the environment or platform also responds to the question.
Questioning is a key attribute of a skilled tester. Questioning is also important aspect of learning. Unfortunately, right from our childhood (remember your father and mother saying “this kid is too much – asks too many questions. You will know when you grow up”!!!), through our education and now in the Job, Questioning is not encouraged.
Why?
- Questioning is considered as disrespect or contempt
- Questioning is indiscipline
- Questioning is disturbing
- Questioning is embarrassing when answer is not available
- Questioning sometime is considered as silly and stupid
- Intelligent people do not respond to silly questions
- Questioning at times make everyone think – that stalls the progress in some cases
- Questioning in a group is considered as bad
- Questioner is a labled as “trouble creater”
- Question = Trouble, more work, Road block
- Oh Gosh, we have not thought about this at all … this is terrible, what do we do now – is not easily coming response for a question
Today’s testers are forced to follow processes, documents, checklists and other “standard” things. If one were to follow the kind of thinking that Pradeep displayed – testing can happen with least information – a lot can happen in small time. I have heard testers who can not start testing (or test design) until they get specification, training and other supporting material. This is a damaging trend for testing profession.
As a famous punch-line of Café Coffee Day (popular chain of coffee joints in India) – “A lot can happen over coffee", goes, can I say “A lot of testing can happen in 20 minutes for any application”.
Just give me the *stuff* to test … I will flood you queries that can potentially lead (if investigated and answered) to an arsenal of information about application under test …
Shrini
3 comments:
Hi Shrini,
I have heard testers who can not start testing (or test design) until they get specification, training and other supporting material. This is a damaging trend for testing profession.
This is indeed a damaging trend for Software testing profession. Though no reason is good enough for not have Specifications but ironically, Software testers often find themselves in such a situations. These are the sutuations that would differentiate a passionate tester from a non passionate one . A passionate tester would find a way out of this situation by applying innovative ways (Questioning being one of them) whereas a non-passionate tester is most likely to crib and complain.
I had tried to explore the topic of testing software without requirements some years back, thats why this point struck me.
Nice post!
Regards,
Anuj Magazine
http://anujmagazine.blogspot.com
It would not be wise of me if I comment on a post of yours just because it is linked to my blog and so I take this opportunity of letting you and your readers know why I haven't commented on your previous posts - I think they are ahead of my thinking ability or I'd want to learn more on them before I ask you questions on it.
I have heard testers who can not start testing (or test design) until they get specification, training and other supporting material. This is a damaging trend for testing profession.
This is within my reach and so here it goes: I don't want to call them as "testers" anymore. They are just adding to the cost of the project and decreasing the value.
Shrini, unfortunately, a manager in such a testers' previous work experience might have set an example like that which the tester wants to follow. I am sure you are setting a very good example for testers at iGate and I am not sure which organization would be lucky to get their testers have a better role model in the coming future.
Questioning is a key attribute of a skilled tester. Questioning is also important aspect of learning.
Those who are curious - would want to learn - and shall ask questions - and those who ask questions out of curiosity - will gain a skill of questioning - and do better testing.
I am happy to read your way of expression of some of the common thoughts and ideas we share.
BTW did you wanted to link to this
post of mine as compare to the post that you linked on Why is testing monotonous? The unspoken truth!
I often read comments like, "Though no reason is good enough for not have Specifications but ironically, Software testers often find themselves in such a situations."
There are many excellent reasons for testing to start long before good specifications exist. There is plenty of literature on spiral development, evolutionary development, and agile development. All of these have had good results without detailed early specifications. In addition, in my personal experience I have seen many excellent products, including complex life-critical products, that have been created with minimal specification. Therefore, the assertion that a high level of specification is necessary is false.
Early detailed specification is a way of capturing all of the mistakes that will be corrected by future experience as the product develops. Relying on early detailed specifications is an excellent way of maximizing product risk, by basing as many development decisions as possible on mistaken decisions that could have been made later, with better information.
-- Cem Kaner
Post a Comment