Topic: Writing Good Test Cases and Finding Bugs effective

Writing Good Test Cases and Finding Bugs effectively
To develop bug free software application, writing good test cases is essential.

Here, we will see how to write good test cases.

Before seeing this, we should understand what is Good Test Case.

There won't be any solid definition for "Good Test Case".

I will consider a Test Case as "Good" only when a Tester feels happy to follow the steps in the Test Case which is written by another Tester.

Because, Test Cases will be useful only when it is used by the people.
If a test case is poorly written with excessive unwanted steps, then most of the Testers won't read it fully. Just they will read few lines and will execute it based on their own understanding which will be mostly wrong.

On the other hand, if it is having less details then it is difficult to execute it.

As of now, I am thinking below things for writing effective Test Cases.


    * Before start writing test cases, become familiar with the (AUT) Application Under Test. You will become familiar with Application by doing some adhoc/exploratory testing.


    * We should read the requirements clearly and completely. If we have any questions in the Requirements it should be clarified by appropriate person (e.g Customer or Business Team). And also, it is good practice to gather some basic domain knowledge before getting into reading requirements and writing Test Cases. And also, we can have discussion/meeting with developers/business team


    * Very Important thing is, we should use only simple language or style to write the Test cases so that any one can easily understand without any ambiguity


    * Give meaningful and easily understandable Test case ID/number.
      For example, if you are writing Test case for testing Login module you can Test Case ID as below.

      1a - for testing positive scenario such as entering valid username and valid password.
      1b - for testing negative scenario such as entering invalid username and invalid password.

      By giving Test Case number as above instead of giving sequential number, we can easily add any new case such as below one without needing to adjust/modify number of any other subsequent test cases.

      1c- for testing negative scenario such as entering valid username and invalid password.



    * And also, if we have any similar module we can give separate sequence number for specifying the module.

      For example, assume that we are having separate login modules for User and Admin with little changes.
      In this case we can give number as below,
      1.1-First case in User module.
      1.2-Second case in User module.
      2.1-First case in Admin module
      2.2-Second case in Admin module.

      If Test Description/Steps/Expected Results of 2.1 is mostly same as 1.1 then we should refer 1.1 in 2.1 instead writing the sample details again.

      By doing like this, we can avoid redundant details to have clear test case document.


    * Test Description should be short and it should uniquely represent the current test scenario without any ambiguity.


    * In any situation, don't use "if condition" in the Test steps. Always address only one scenario in one test case. It will be helpful to have unambiguous Expected Result.


    * Give some sample test data that will be useful for executing the test cases.


    * If the Test Case requires any Preconditions/prerequisite don't forget to mention them.
      The best way is, we should arrange/order the Test Cases such that the need for specifying precondition is minimum.

      For example, we need to write test case for testing user creation, user modification and user deletion.

      For doing user modification and user deletion we should have already created user as precondition.

      If we arrange the Test cases in below mentioned order, we can avoid the need for specifying any preconditions/prerequisites.
      1-Test case for creating user.
      2-Test case for verifying duplicate/existing user when adding another user with same username.
      3-Test case for modifying user.
      4-Test case for deleting user.

    * Keep Traceability Matrix to make sure that we have written test cases for covering all requirements.

    * Once after completing all positive scenarios, think about all possibilities of negative scenarios to have test cases which will effectively find most of the bugs.

      For doing this we can refer alternate flow section of use case document, and we can think about different data, boundary conditions, different navigations paths and multi user environment.


    * In the test case document, we can give link to screenshots explaining the steps and/or expected results with pictures. But anyway, it is not good practice to place the screenshots within the Test Case document itself unless it is very essential


    * Many tools are available to capture the screenshots with user action as video. We can make use of them to keep video explaining the steps and expected results clearly in case the test case requires any complex steps. We can give link to this video from the test case document.