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.

5 thoughts on “Test[ing this] Case

  1. I’m sure all testers would have had similar experiences. It does read like my own!
    And I so agree.. that the most important or useful come while doing a real testing and not while analyzing the requirements.
    Cheat sheets or checklists should be the way to go!So that real testing actually happens!!

  2. The core idea is to keep on a constant thinking on test scenarios rather than just during the time allotted for test case authoring period right? It is a very valuable point and this constant improvement will apply not only to testing but also to all phases of SDLC and why even for the other day to day works we do.
    Constant improvement leads to perfection🙂

  3. Well I totally Agree With you that we tend to give much higher priority to writing test cases than the actual testing ,

    For a moment i Would like to be in a debating mode as a member of the opposite group and following will be my viewpoint that why detailed test cases are needed

    Its all about the Money : You get paid for what you do ,the scenario you mentioned is mostly in service industry , I have worked in both service industry and Product Industry , In service industry we would take lot of time to study the requirements ,create the test validation matrix and then write the test cases , Our customer is billed for it and in testing phase we just had to verify only those test cases already documented earlier

    But the product world is totally different ,there we dont have any written /well documented requirements ,just a rough draft ,here too the key driver is money ,here one has to think from the actual user point of view and a tester can even suggest new features which might help in selling the product .Here the actual testing is real time and new ideas keep coming while we are actually testing .

    One last thing what if the software has matured and probablity of bugs is quite less than tester only has the Detailed test cases to his rescue that he is executing those otherwise people tend to think testers are wasting time as no bugs are coming .

    1. Sumeet,
      I am seeing no posts in your blog. How about making the above comment of your into a blog post? We’ll share our thoughts there. This is how you learn writing.
      -Dhanasekar S

  4. I do agree with your post that writing detailed Test Cases are waste of time and Executing those Detailed test cases writing actual behaviour of the application for each step is really tedious job.

    But when it come to business, what is a proof for the tester to show the management that he/she has achieved tis amount of work(Specially iin case where product is stable and no more bugs has been found in test cycle).

    Also sometimes there is a problem with deployment and post deployment testing hasnt been carried out by test team (It happens in many organization where because of data security), what is the proof that teat team has teasted that particular scenario.

    I still agree with not writing detailed Test Cases and check lists or Heuristic approach is not enough in above mentioned case. Can you please guide me what else can be alternative in this case?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s