Test[ing this] Case

The first thing flashes in most software testers mind immediately on hearing software testing is Test Case. Even most of us explain our work to others and even to fellow testers something like this “I understand requirements, write test cases and test the application, log the bugs and mark the test case pass or fail based on the expected results”. I too started my testing career by explaining what a test case is and SDLC model that was (never) followed to an interviewer. But soon, I realized that it is practically not possible (or I am not intelligent enough) to write most test ideas (cases) even with detailed requirements. Most test ideas don’t popup while analyzing the requirements, but while performing the real testing on the product. The test cases written with requirement documents are only based initial abstract understandings made on theory, but the real practical ideas come while testing. But even recently many people advice to write detailed test cases, that even a layperson can understand. Are they recruiting a layperson or a smart tester? Why still the main focus is with writing detailed test cases even in agile world? Looking back the water fall model, what I can think of reason for writing detailed test cases is, there was  a phase in SDLC were developers are busy writing and developing a product for months together, before delivering into testing team. So, probably some smart manager got this idea of test case writing to keep the testers engaged during that phase. Few rituals still followed without analyzing, if those suit the context. 1.  Write detailed test cases for the projects where there is good clarity on requirements. We got clear requirements so write detailed test cases. 2.  Write detailed test cases where there are no clear requirements . The requirements are not clear let use have detailed test case document. 3.  Even if the project has very tight deadline, a certain percentage of time is allocated for test case writing instead of focusing on real testing . Because Test case documents are (mis)believed to be the only Savior of testers. 4.  I’ve even seen reverse engineering of coming up with test cases from a well functioning application, with the help of help files :-) 5.  There is something called traceability matrix, which traces all the detailed test cases back to your requirement, I think this is designed especially to say the whole world, see we’ve spent so much of man power to duplicate the requirements and here is the proof for that 6. And test cases are again considered as Savior in this job hopping era, but reality is forcing to write such detailed test cases and asking the testers to blindly execute just the documented test cases too are the also one of the reasons for job hopping. Why a similar kind of test cases is demanded everywhere for every context?Why do test case document looks similar where ever I go? :-( . The only standard that is followed more or less correctly in testing world is test case template. The problem with such detailed test cases writing and following them is, soon the application will develop resistance against bug, because testers were focused only on what is written in the test case nothing less nothing more. Any tests executed blindly by a human just against expected result is as good as (as bad as) automated test checks. Such practices never help to spot the Black Swan* [The disproportionate role of high-impact, hard to predict, and rare events that are beyond the realm of normal expectations] you have to explore more with real application to spot the Black Swan. Testing according to James Bach Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous. So, let me try to form a different Black Swam theory, as a tester our job is to predict and spot the Black Swan before the customers or client spot it. :-) Even writing test cases need exploration, but it becomes a concern when the explorations stop (or forced to stop) once test case are written. So, constantly come up with new ideas to add more value. Instead of wasting time in writing detailed test cases cheat sheets like this  Test Heuristics Cheat Sheet would cover most of the basic test cases, why to write again? If you feel You Are Not Done Yet, then check this You Are Not Done Yet. And choose SBTM or any relevant format that suits the context. Any available basic requirement document plus the above cheat sheet should be more than enough to do a good enough testing.

Testers aren’t  for documenting, they are for providing valuable information.

P.S: Can you recollect  the color of each letter of Google logo in its home page? (Of course with no doodles), the page most of  us visit every second hour. If you can’t, then you are affected with major Black Swan blindness.

Happy testing your Case!

Dhanasekar S.

* I’ve just started reading The Black Swan book by Nassim Nicholas Taleb. Yet to read it completely.

I,Me,Dad and Jerry Weinberg

I

Couple of weeks back I went to  Prism book store (Jayanagara IVth block, Bangalore) to check out if any of Gerald M Weinberg books are available. Actually I entered with no hope, because Landmark and flipkart.com could not get any of Weinberg’s books other than Perfect Software: And Other Illusions about Testing. But this book store turned out to have most of DH publications books. I jumped out in joy on seeing many Jerry Weinberg’s books there. I went to cash counter after selecting Are Your Lights On? (with Donald C. Gause), Becoming a Technical Leader, An Introduction to General Systems Thinking and Rethinking Systems Analysis and Design. While cashier was billing those books, I took Perfect Software from stands, gave that to cashier to find its price and to compare with the price I bought from flipkart.com. Mean while she billed those four books and gave the receipt. I checked if the receipt was billed correctly for the books I selected, she smiled. Then she gave me the books. I again checked if books were the same as what I selected. She again smiled and told “Sir! those were the books you bought and no other customers are here, so there won’t be any chance for mistakes to happen”. I knew she would be cursing but showed a smiling face as trained. But my checking uncovered her mistake of giving me with extra book of Perfect Software book which was not purchased. Now she showed real smile and said both sorry and thanks. Do you realize what was achieved here? I built credibility. When I went to the shop next time, I was greeted with a warm welcome. I experienced similar situations many times while shopping, either I would end up giving back extra shares or I would get back my missed shares correctly, but every time it helped to built a relationship and trust. So

I test everything, and I build credibility.

How about You?

I and Me

After attending BWST02 got an email from Pradeep addressed To all the participants with co-organizer and facilitator in the CC list. I wanted to share a Google spreadsheet with all of them. So from that email I copied all the addresses present in To field and pasted them into Google doc’s invitation, and I always believe I am smart, so I knew I need to copy contacts from CC as well, so I copied addresses from CC as well and believed that I  invited everyone. But Me never believes I is still smart enough, so after a while Me logged into the Google doc, checked if I has invited everyone. No surprises! found that I missed out inviting, the one and only Pradeep, because he was in From address :). So, Me logged a bug against I and sent a separate invite to Pradeep. So

I test everything, and I am tested by Me as well.

How about You?

Dad

I opine this characteristic of checking, validation, verification or testing was inherited from my dad. He is a shopkeeper, and so thought me the habit of testing everything. I still remember those childhood days,watched him verifying the lists customers brought in and validate the items against the list before that would be given to customers. He taught me the importance of such V and V activities politely until that became a practice to me.  So

Dad is the first and best testing Role model  for I and Me.

Who is your Role model? If answer is “Don’t know”, find one soon now

Jerry Weinberg

I was never a book worm. Lessons Learned in Software testing was the one and only technical book I read completely. I recently read four chapters in Perfect Software and I was floored! I am now starting to read all of Weinberg’s books. I am fallen in love with his books, very interesting and practical story telling style takes me to a different orbit, from there my mind just starts analysis better and grapple a lot better than ever before. And jaw-dropping insight from such stories, mind blowing…  lack of my vocabulary I use these words. Now

Yes, I am a Worm, Jerry Weinberg Worm!

What worm are You?  If answer is “Don’t know”, become one soon now

Happy Testing Yourself ! and Happy Reading!

– I and Me, a Jerry Weinberg Worm.

Share