What a Test Case in Software Testing Is

The Wikipedia says “A test case, in software engineering, is a set of conditions under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do”.

Actually a test case is a set of pre-conditions designed by the tester for the purpose of testing within the given project requirement and also from outside. This will be the first step in the testing process as soon as the requirements are analyzed. This is also called test scripts.

There are two types of test cases, they are:

• Formal test cases
• Informal test cases

Formal test cases

A formal test case is where a test case is designed with a certain standard format so that it will be user-friendly to understand and all the possible tests will be covered.

• Every requirement will have the two types of testing, Positive testing and Negative testing. These two will play a vital role in completing a testing requirement satisfactorily.
  
• As a tester we need to track between the requirements and the test case where this process is called a Traceability matrix.
  
• A formal test case will have a known input along with an expected output.
  
• It is also common that the known input should test a pre-condition and the expected output should test the post condition.

Informal test cases are where test cases are not at all designed at all during the execution of testing but the results and activities will be made as a report once the process is finished. In these informal test cases the tester thinking level is complex and analytical. They will test it with a specified number of possibilities to test a specific scenario. There is no restrictions for testing except the timing given for testing. We can say an informal test case will be totally different from the formula test case format.

• Test Suite ID: Test Suite number for which the test case is referred.
  
• Test case ID: This will be the ID of the respected test case.
  
• Test case Summary: A basic summary about the requirements for which the test case is designed.
  
• Prerequisites: If there is any pre-requirements to be handled before the execution of the test case.
  
• Related Requirement: The id number of the test case if any requirement is related to the current test case.
  
• Test Procedure: A step-by-step procedure to execute the respected test case.
  
• Test Data: Any sample data to be tested so that it will be universal for the result whoever tests it.
  
• Expected Result: What is the result expected.
  
• Actual Result: Result that we get after the execution of the test case.
  
• Status: What the status of test case is, whether Pass/Fail.
  
• Remarks: Test execution comments, if any.
  
• Created By: Name of the test case owner.
  
• Date of execution: Which date we executed (time also can be noted).
  
• Test Environment: Hardware, Software, Internet speed and so on.

Informal test cases

An informal test case is a test case that is not at all designed during the execution of the testing but the results and activities will be made as a report once the process is finished. In these informal test cases the tester thinking level is complex and analytical. They will test it with a specifeid number of possibilities to test a specific scenario. There are no restrictions for testing except the timing given for testing. We can say an informal test case will be totally different from the formla test case format.

Test Case Design Methods

• Test cases can be derived directly from requirements and also from Blackbox testing.
  
• Test cases can also be derived from structure or components of the system.
  
• The Third tye of test cases can also be derived based on the tester's experience or similar requirement knowledge or tester's intuition.

A test case is called a good test case when the following flavors are added to it.

They are:

• Each and every test case must be atomic and should not be very complicated. They must be divided into simple ones so that it will be easy to test with all the possibilities completely.
  
• Positive and Negative scenarios must be covered for each and every requirement.
  
• The exact purpose of a test case must be fulfilled.
  
• No unnecessary steps should be added and wasted.
  
• The test case must be made in a way for using repeatedly.
  
• It should also be reusable if needed.
  
• The language used must be simple and error free.
  
• The test case must match the customer's requirements step-by-step.

Conclusion

Thus there are no specifically good test cases but it's up to the varieties of techniques with the preceding specified attributes to make good ones. Similarly all the possibilities of requirements must be divided into units that are simple base level and for each base level the test case must be designed. Only then will a test case be a good one and will create a quality product from the client's perspective.