Home » test case
Integration Test cases !!!

Before designing the integration test cases the testers should go through the Integration test plan. It will give complete idea of how to write integration test cases. The main aim of integration test cases is that it tests the multiple modules together. By executing these test cases the user can find out the errors in the interfaces between the Modules.

For example, in online shopping, there will be Catalog and Administration module. In catalog section the customer can track the list of products and can buy the products online. In administration module the admin can enter the product name and information related to it.

Integration Test cases

 
The tester has to execute above unit and Integration test cases after coding. And He/She has to fill the actual results and Pass/fail columns. If the test cases fail then defect report should be prepared.

Under: , ,
Unit Test Cases !!!

These are very specific to a particular unit. The basic functionality of the unit is to be understood based on the requirements and the design documents. Generally, Design document will provide a lot of information about the functionality of a unit. The Design document has to be referred before UTC is written, because it provides the actual functionality of how the system must behave, for given inputs.
For example, In the Online shopping application, If the user enters valid Email id and Username values, let us assume that Design document says, that the system must display a product details and should insert the Email id and Username in database table. If user enters invalid values the system will display appropriate error message and will not store it in database.

 Login Screen Test Conditions for the fields in the Login screen

 Email-It should be in this format (For Eg clickme@yahoo.com).
Username – It should accept only alphabets not greater than 6.Numerics and special type of characters are not allowed.

 Test Prerequisite: The user should have access to Customer Login screen form screen

 Negative Test Case:
*********************


Positive Test Case:
********************

Under: , , , , , ,
Test Case Format !!!

The test cases will have a generic format as below.

 Test case ID - The test case id must be unique across the application
Test case description - The test case description must be very brief.
Test prerequisite - The test pre-requisite clearly describes what should be present in the system, before the test can be executes.
Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system.
Test steps - The test steps are the step-by-step instructions on how to carry out the test.

 Expected Results - The expected results are the ones that say what the system must give as output or how the system must react based on the test steps.
Actual Results – The actual results are the ones that say outputs of the action for the given inputs or how the system reacts for the given inputs.
Pass/Fail - If the Expected and Actual results are same then test is Pass otherwise Fail.

 The test cases are classified into positive and negative test cases. Positive test cases are designed to prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to design the positive test cases are Specification derived tests, Equivalence partitioning and State-transition testing. The negative test cases are designed to prove that the system rejects invalid inputs and does not process them. Suitable techniques to design the negative test cases are Error guessing, Boundary value analysis, internal boundary value testing and State-transition testing. The test cases details must be very clearly specified, so that a new person can go through the test cases step and step and is able to execute it. The test cases will be explained with specific examples in the following section.

Under: ,
Test Case !!!

A test case specifies the pretest state of the IUT (Integration Unit Testing) and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment.”

 In software engineering, the most common definition of a test case is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub requirements.

 * Test cases help us discover information. Different types of tests are more effective for different classes of information.
* Test cases can be “good” in a variety of ways. No test case will be good in all of them.
* People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.

Under: ,