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.

Focus on Defocusing

Two weeks before I broke my spectacle that was bought just six months back. Now needless to say, I have to buy a new spectacle. So I went into a spectacle store. On entering the store I saw four to five sales executives with a warm smile (Yeah! Two of them were good looking girls ;)) .I was totally confused whom should I approach first. You have to believe me that I did not go to the cute looking girls, instead decided to Go to Gemba as one among them was wearing spectacle. I thought he (yea, unfortunately it is he :( ) would be the correct person to help me out in selecting the better spectacle.

I approached him, and asked for nice frames that would be within  my budget and yea,good looking too. He helped me with many of the frames displayed. He suggested with few frames that would make me to look even smarter ;). I tried out quite a little and focused on the mirror to know if I am looking smarter. I shortlisted three frames but still not able to decide on which one to select. With the confusion I went and took a seat, to get my eye power tested.

I had my previously tested power details noted, so I gave him the card that has my eye power details. The salesperson asked for my older spectacle as well to cross verify the power in it. So I handed over both the card and broken spectacle, after measuring the power, I found there was a 5 degree difference between the power details in the card and the spectacle. I remember the last spectacle was ordered with the power prescribed in that card. So I asked the salesperson why there is a difference, he said that could be a manufacturing defect, a manual or machine fault. Then I asked is the 5 degree difference a major concern, though I did not find any issues with that lens. He said it is not a major issue and up to 10 degree will not have any visual difference.

I just wondered what if people go with this mindset and then design, develop, test, maintain and use a machine that is to be used to destroy cancer cells or a MRI Scan machine, where precision is very important. So it is

Good to bring prior knowledge and experience, but not the mind-set across different projects.

Needless to say this time I checked the power again in the new spectacle at the time of delivery, I am a tester and I test every thing.

Back to the story, I was still wearing one of the new frames I shortlisted, at the time of the discussion  about power difference, I realized that the frame is not so comfortable .I felt some irritation near my ears and nose. That’s when I realized my focus on how it looks to me, made me to ignore many other important factors. When I defocused from one factor, I was able to feel\realize many other missed factors. And I didn’t even focus on comfort, just defocusing from one factor automatically helped to realize other factors. Now I focused on the comfort factor and ended in selecting a frame better frame. So before starting of testing list down the factors prioritized like Functionality, Usability, Testability, Maintainability, Reliability, Compatibility, Scalability etc., then start focusing on them one  by one based on priority.

Defocusing is as important as focusing.

But was this the better frame and will it be free from problems? I don’t know because

Problems unfold over time in ways that are often not predictable.

Here is one great example I read recently how any system cannot be defined with a boundary and how problem unfold that are often not predictable. When Denver airport was built, it was claimed that the airport would never close, even for a snowstorm. The advanced technology would permit flights to take off n land even in adverse weather. When the first big snowstorm hit, every flight got cancelled. Why? Pilots lived in mountains nearby and they could not get to airport in storm.

Happy Focusing and Defocusing!

Dhanasekar S (with new good-looking spectacle :))