Test cases

Test Case

Quality in a service or product is not what you put into it. It is what the client or customer gets out of it. – Peter Drucker

A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites. The following testing items have close correlation with test cases. Test Script is a detailed description of the test steps or transaction(s) to be performed to validate the system or application under test. The test script must contain the actual entries to be executed as well as the expected results. Test Step is the lowest level of a test script that performs a specific operation such as clicking a button or entering data in a text box. Test steps are created for both manual and automated tests. Each test step must be followed by a description of the ‘expected result’ of the test step, after it has been executed.

1

Test Case


Test Set is a collection of test scripts that are grouped for a specific purpose (i.e. business process, function/feature). Test Scenario is a high-level description of a business process or system functionality that will be tested. Detailed information such as input data, expected results, parameters, etc. will not be included in the test scenario, but will rather be located in the test script. Example: Check Login Functionality. Test Data Set is a specific set of values for variables in the communication space of a module, which are used in a test. Test Procedures define the activities necessary to execute a test script or set of scripts. Test procedures may contain information regarding the loading of data and executables into the test system, directions regarding sign in procedures, instructions regarding the handling of test results, and anything else required to successfully conduct the test.

2

Test Case


Test Harness is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. A test harness has two main parts: 1. Test execution engine 2. Test script repository. Test harnesses should include the following capabilities: A standard way to specify setup (i.e., creating an artificial runtime

environment) and cleanup. A method for selecting individual tests to run, or all tests. A means of analyzing output for expected (or unexpected) results. A standardized form of failure reporting.

Test Script Repository is a library of reusable test scripts (organized by business process); a location for storage of data.

3

Test Case


Test Case Template: Types of Test Cases:

S# Test Case Type Test Case Source

1 Requirement Based 1. BRS (Business Requirement Specification) Document 2. FRS (Functional Requirement Specification) Document 3. Other Requirement specifications

2 Design Based 1. HLD (High Level Design) Document i.e. Macro Designs 2. LLD (Low Level Design) Document i.e. Micro Designs 3. Other design artifacts

3 Code Based Pseudo Code, Source Code etc.

4 Extreme Boundary Conditions, Error Guessing etc.

5 Extracted & Randomized

Existing Test Cases

4

Test Case


Requirement and Design based test cases 1. Identify the basic cases that indicate program functionality.

2. Create a minimal set of tests to cover all inputs & outputs.

3. Breakdown complex cases into single cases.

4. Remove unnecessary or duplicate cases.

5. Review systematically and thoroughly.

6. Design based test cases supplement requirements based test cases.

Etc.

Code Based test cases 1. Identify test cases with that every statement in a code exercised at least once.

2. Every decision exercised over all outcomes.

Etc.

Extreme test cases 1. Looks for exceptional conditions, extremes, boundaries, and abnormalities.

Extracted and Randomized test cases 1. Extracted cases involved extracting samples of real data for the testing process.

2. Randomized cases involved using tools to generate potential data for the testing process.

5

Test Case


Positive Test Cases and Negative Test Cases:

Positive Testing = (Not showing error when not supposed to) + (Showing error when supposed to) So if either of the situations in parentheses happens you have a positive test in terms of its result - not what the test was hoping to find. The application did what it was supposed to do. Here user tends to put all positive values according to requirements. Negative Testing = (Showing error when not supposed to) + (Not showing error when supposed to)(Usually these situations crop up during boundary testing or cause-effect testing.) Here if either of the situations in parentheses happens you have a negative test in terms of its result - again, not what the test was hoping to find. The application did what it was not supposed to do. User tends to put negative values, which may crash the application.

6

Test Case


For example in Registration Form, for Name field, user should be allowed to enter only alphabets. Here for Positive Testing, tester will enter only alphabets and application should run properly and should accept only alphabets. For Negative Testing, in the same case user tries to enter numbers, special characters and if the case is executed successfully, negative testing is successful.

7

Test Case


Test Case Preparation checklist: This is used to ensure Test cases have been prepared as per specifications. For all the test responses the test case preparation review checklist test manager will assess the impact & document it as an issue to concerned parties for resolution. This can be assessed using weekly status reports or emails. S No Activity Yes No Comments

1 Is the approved Test Plan available?

2 Are the resources identified to implement test plan?

3 Are the final copy of requirements and design documents etc. available?

4

Is domain knowledge being imparted to the team members who are working on the application?

5

Have Test cases been developed considering all requirements?

6 Have all the positive and negative test cases been identified?

7 Have test case design techniques used to write test cases?

8

Have test cases been written for GUI/Hyperlink testing for Web application

9 Have test cases been written to check Date Integrity

8

Test Case


Test Case Development Process: Identify all potential Test Cases needed to fully test the business and technical requirements Document Test Procedures Document Test Data requirements Prioritize test cases Identify Test Automation Candidates Automate designated test cases

Test Case Design Methods: 1. Boundary Value Analysis 2. Equivalence Partitioning 3. Error Guessing Etc.

9

Test Case


Characteristics of good test cases:

• Simple and specific. Any one in the test team should be able to execute the test cases without the author help.

• Clear, concise, and complete

• No assumptions in test case description, steps, expected result etc.

• Non-redundant

• Reasonable probability of catching an error

• Medium complexity

• Repeatable

• Test cases that have written with the help of test case design methods

• Test cases that are easily identifiable with their names.

• Always list expected results

Etc. 10

Test Case


Test Case Guidelines: – Developed to verify that specific requirements or design are satisfied

– Each component must be tested with at least two test cases: Positive and Negative

– Real data should be used to reality test the modules after successful test data is used

11

Test Case


12

User Acceptance Testing


References: http://templateforfree.com/how-to-write-test-cases/

13

http://templateforfree.com/how-to-write-test-cases/










Career

Test cases