The Black Hat!

I have been reading this book named '6 thinking hats' by Edward de Bono since last 2 days. Book says every individual can think under 6 hats or 6 categories. And this kind of thinking results in efficient usage of time and helps in a better decision making. Blue hat is the moderator hat. It will guide the thought flow process. White hat deals with facts and figures. It has no emotions attached. Wearing a green hat signifies the thinking is diverted for fresh ideas. Yellow hat signifies the thoughts which concentrates on positive aspects associated with a decision. When an individual wears the Red hat he/ she thinks with a higher emotional quotient. When someone is said to wear a Black hat on a topic that implies the individual will be cautious and will emphasize on the negative aspects.
I found this black hat very interesting and to my surprise Edward de Bono thanked only the Black Hat in his acknowledgement. My interest in the black hat is due to the kind of thinking a user switches to, when he wears this hat.User takes a stance of critic, thoughts are now concentrated on the negative aspects. The user becomes a devil's advocate.
My interest in the black hat is also due to the fact that, this is the hat which a software tester is proud and anxious to wear. While reviewing the requirement documents, while writing the test cases and so on. Because it is in our blood… to be cautious, not just being cautious but extra cautious.
This is the attitude which a tester should have order to nurture and deliver a better application or product.
But the black hat needs to be removed at once when we are talking to developer regarding a defect. We wear a white hat; show him the impact or severity of the defect. Talk in figures and facts. While we are discussing a CR or a suggestion which needs to be implemented; we wear a yellow hat.
At this point I questioned myself: Why can't a developer put a black hat while testing and then a yellow or green hat while coding? The answer is: No one will criticize oneself when:
1. one 'believes' that he is right and what he is doing is 'acceptable' (acceptable as per the requirement and design document).
2. one cannot see the broader view and overall affect when he is dealing with a smaller portion. ('Module-based' development)
Don't forget to wear the black hat next time you test!!

Testcases

3 years back, when I started my career in testing, testcases and testcase writing were something I hated the most. Now I feel it is the most basic and unavoidable entity in the testing field. Testcase writing substantiates the testing thought flow and, reviewing them solidifies those collections of thoughts or logic which were gained from the design docs and requirement docs. Testcase creation should be started from the requirement phase and will go till the coding phase. Each for one phase

Testcases should have a proper format which, of course depends upon the standards of your organization. A good testcase document should contain following information.
Module Name: For any software made or in-making should have modules or functionality.
Type of testing: Unit, System, Regression etc
1. Testcase ID: Every testcase should be identified by a unique ID. The implicit details which should be reflected through the ID are functionality, Module and sub module.
E.g. testing a “parameterized report for the delayed payment”. Here report is functionality, Module is delayed payment. We will be testing the parameters one by one.
2. Testcase Name: Name of the test case should summarize the activities of the tester.
3. Steps to reproduce: Now, this is the most important part in the testcase, the part which should be so simply and elegantly written to be understood by a layman.
4. Expected result: What is expected from the application?
5. Actual Result: What application gives to the user?
6. Pass/Fail: Is the testcase passed or failed?
7. Defect ID: If the testcase fails, log it. Enter the defect Id in the testcase document. ( This makes me happy…I am explaining it J)
8. Test Run ID: Which is the run of these testcases? First run? Second Run? Third Run? You need to know and record it.
9. Test Run date: Date at which the test run.
10. Tester’s Details: Name, ID.

What defines a good testcase document?
The testcase document which helps the tester to hunt down the maximum number of bugs can be defined as a good testcases document. It should contain both positive and negative cases. Yes, Positive testcases too, a tester is neither supposed to trust the developer nor what he “thinks”.