Testing Testers Mind

White Paper

Declaration
This White Paper is written for our young Test Professional who has recently taken their new assignments and has geared-up to make Testing as their career. The intention of this paper is to guide and encourage our young testing minds to understand the value of their contribution to the project. This should also educate them about the importance of Test Cases to the success and failure of Projects. The examples articulated in this paper may not be suitable for your current assignment purview but a thorough attempt has been made to highlight the better ways of doing things and encourage the capability to investigate on development techniques and business functions for improved performance.

Quality Test Cases are critical for Project Success. We all know that But what are Quality Test Cases? What are High Level Test Cases? And why it is so critical for Project? These are some questions which we assume that we know the answers but we often fail to explain. Of Course! Quality is Relative but let us try to understand what can go wrong when we misinterpret or misunderstands these definitions? Leaving apart all Text book definitions, High Level Test cases (also called as Test Conditions or HLTC) are primarily the Questions that you ask the application to get the right Answers. Testing ensures that we get Right answers to all questions put to the system. If we dont, we report the same as a Bug. Let us take a small exercise to "Test a Testers Mind". Below mentioned are two simple questions to ask ourselves as Testing Professionals: 1. Are we asking the Right Questions?

2. Are we asking the Right Number of Questions?

If we dont have RIGHT answers to the same, WE HAVE BUG WITHIN OURSELVES. And this Bug can lead to a Project Failure. We cannot deny the fact that Bug reporting depends so much on our definition of Right Answers and still we forget to include the above two. To the first question, our answer is always YES, HLTCs are as per Functional Specification, Use Cases, Scope, Coverage etc. and we are confident about it. After all, thats our job and we feel that we have done it well. To the second question, some may have a slight confusion but still say, YES. Many may argue that even if we dont practise any said standard or method to ensure it, but at least we cover everything as a part of Question 1. But thats not the correct answer.

Let me take you through a small example: You ask a Persons name. Method 1 Question 1: What is your First Name? Question 2: Do you have a Middle Name? Question 3: What is your Middle Name? Question 4: What is your Last Name? Question 5: Is the last name is your Surname? Question 6: Is the first name is your Surname? By the time you put the Question no.7 the person might be thinking, For God sake, why did I had a Name after all But as we test the application, we feel we are right. We did ask all valid questions and nothing was wrong in it? Let us ask the question in a different way now: Method 2 Question 1: What is your name? Isnt it what we were expected to ask and get the Answer from the concerned person which we could have placed as First Name, Middle Name (if mentioned) and Last Name. Debatably, perhaps we can understand now, What is wrong? If not, to be straight forward It is the time we have consumed to get the result which was 6 times more than expected. Today, in all recent adopted methods of product development, testing is involved right from the beginning of the project which starts with walk-throughs and reviews of Requirements / Functional Specifications to understand / define the Functionality and Testability of the application.

In the beginning of the project, a manager prepares a project plan to evaluate the effort for a Resource for Test Cases Design, Execution, Defects Logging and Reporting. Provided the resource adopts Method 1, the planning ends up in over estimation for 6 times. The effort is not only lost for poor Test Case Design, but further damages the Project Plan during execution, Defect Logging and Reporting. Let us take a small exercise and correlate the development and Test Plan by taking an example from ATM: For example if the requirement states: System accepts a valid card and rejects invalid card. You can consider the Card to be invalid if Magnetic strip is demagnetised or Card is without any magnetic stripes etc. A developer will probably follow the below mentioned logical flow :

And thats what our test case should test.

1. Verify system ability to accept a Valid Card.

2. Verify system ability to reject an Invalid Card. The details pertaining to card can be elaborated together with proper pre-requisites and Details Level Test Cases (or DLTC). Dont feel bad if you have been thought to include the below mentioned HLTCs:

1. Verify system ability to reject the invalid card with demagnetised magnetic strips 2. Verify system ability to reject the invalid card with no magnetic strips etc.
With reference to the above example, provided the system accepts an Invalid Cards and we report a Bug, we have executed 4 test cases which could have been identified even with 2 test cases. The bug would details all criteria in which invalid card are accepted by the system, helping the developers get the grip of problem at one shot. How does it help testing? You gave a Bingo!!! You highlighted the exact issue by listing all failure criteria in one defect and you have reduced the defect reporting time to Half, in comparison to two defects which you would have raised in the as per above test cases. Just adding to bit of possible outcomes in defect management cycle: Your two defects reported could even get assigned to two different developers who may handle the same defect with different logical approach and may possibly even override each others fixes leading to defect re-test and re-open. By this time you would have known the impact on project timelines and delivery dates. Thats not all, with the said coverage, the effectiveness (Defects/Test Cases) of your Test Cases will also reduce to 25% from 50% with the execution of poor test cases. Conclusion Theres no simple formula or prescription for generating High Quality test cases. It still remains a gifted skill for a Tester who can articulate the Technical Algorithms and Business Requirements / Knowledge to design highly efficient Test Cases or HLTCs. Let us revisit to understand the Quality of our Test Cases which determines the Quality of our application.

Ravi Sharma Misys BankFusion Universal Banking Bangalore