Practical No.

2
Aim: Design and write test cases for simple calculator application

Theory:
A TEST CASE is a set of actions executed to verify a particular feature or
functionality of your software application. A Test Case contains test steps, test data,
precondition, postcondition developed for specific test scenario to verify any
requirement. The test case includes specific variables or conditions, using which a
testing engineer can compare expected and actual results to determine whether a
software product is functioning as per the requirements of the customer.

Test Scenario Vs Test Case

Test scenarios are rather vague and cover a wide range of possibilities. Testing is all
about being very specific.

For a Test Scenario: Check Login Functionality, there many possible test cases are:

Test Case 1: Check results on entering valid User Id & Password

Test Case 2: Check results on entering Invalid User ID & Password
Test Case 3: Check response when a User ID is Empty & Login Button is pressed,
and many more
This is nothing but a Test Case.

How to Create a Test Case?

Let’s create a Test Case for the scenario: Check Login Functionality

Step 1) A simple test case for the scenario would be

Test Case # Test Case Description

1 Check response when valid email and password is entered

Step 2) In order to execute the test case, you would need Test Data. Adding it below

Test Test Case Description Test Data

Case #
 1 Check response when valid email and Email: comp@email.com Password:
password is entered lNf9^Oti7^2h
Identifying test data can be time-consuming and may sometimes require creating test
data afresh. The reason it needs to be documented.

Step 3) In order to execute a test case, a tester needs to perform a specific set of
actions on the AUT. This is documented as below:
Test Test Case Description Test Steps Test Data
Case #

1 Check response when valid email and 1) Enter Email Email: comp@email.com
password is entered Address Password: lNf9^Oti7^2h
2) Enter
Password
3) Click Sign in
Many times, the Test Steps are not simple as above, hence they need documentation.
Also, the author of the test case may leave the organization or go on a vacation or is
sick and off duty or is very busy with other critical tasks. A recently hire may be
asked to execute the test case. Documented steps will help him and also facilitate
reviews by other stakeholders.

Step 4) The goal of test cases is to check behavior the AUT for an expected result.
This needs to be documented as below
Test Test Case Description Test Data Expected Result
Case #

1 Check response when valid email Email: comp@email.com Login should b

and password is entered Password: lNf9^Oti7^2h successful
During test execution time, the tester will check expected results against actual
results and assign a pass or fail status

Tes Test Case Test Data Expecte Actual Pass/F

t Descripti d Result ail
Cas on Result
e#
 1 Check Email: comp@email.com Pas Login Login Pass
response sword: lNf9^Oti7^2h should was
when be successf
valid successf ul
email and ul
password
is entered

Step 5) That apart your test case -may have a field like, Pre - Condition which
specifies things that must in place before the test can run. For our test case, a pre-
condition would be to have a browser installed to have access to the site under test.
A test case may also include Post - Conditions which specifies anything that applies
after the test case completes. For our test case, a postcondition would be time & date
of login is stored in the database

The format of Standard Test Cases

Below is a format of a standard login Test case

Tes Test Test Steps Test Expecte Actual Pass/F

t Scenar Data d Result ail
Cas io Results s
e ID

TU Check 1. Go to Userid User As Pass

01 Custo site http://demo.co = comp should Expect
mer mp.com Passw Login ed
Login 2. Enter UserId ord = into an
with 3. Enter Password pass99 applicati
valid 4. Click Submit on
Data

TU Check 1. Go to Userid User As Pass

02 Custo site http://demo.co = comp should Expect
mer mp.com Passw not ed
Login 2. Enter UserId ord = Login
 with 3. Enter Password glass9 into an
invalid 4. Click Submit 9 applicati
Data on

This entire table may be created in Word, Excel or any other Test management tool.
That's all to Test Case Design

While drafting a test case to include the following information

• The description of what requirement is being tested

• The explanation of how the system will be tested
• The test setup like a version of an application under test, software, data files,
operating system, hardware, security access, physical or logical date, time of
day, prerequisites such as other tests and any other setup information pertinent
to the requirements being tested
• Inputs and outputs or actions and expected results
• Any proofs or attachments
• Use active case language
• Test Case should not be more than 15 steps
• An automated test script is commented with inputs, purpose and expected
results
• The setup offers an alternative to pre-requisite tests
• With other tests, it should be an incorrect business scenario order

Best Practice for writing good Test Case Example.

1. Test Cases need to be simple and transparent:

Create test cases that are as simple as possible. They must be clear and concise as
the author of the test case may not execute them.

Use assertive language like go to the home page, enter data, click on this and so on.
This makes the understanding the test steps easy and tests execution faster.

2. Create Test Case with End User in Mind

The ultimate goal of any software project is to create test cases that meet customer
requirements and is easy to use and operate. A tester must create test cases keeping
in mind the end user perspective
3. Avoid test case repetition.

Do not repeat test cases. If a test case is needed for executing some other test case,
call the test case by its test case id in the pre-condition column

4. Do not Assume

Do not assume functionality and features of your software application while

preparing test case. Stick to the Specification Documents.

5. Ensure 100% Coverage

Make sure you write test cases to check all software requirements mentioned in the
specification document. Use Traceability Matrix to ensure no functions/conditions
is left untested.

6. Test Cases must be identifiable.

Name the test case id such that they are identified easily while tracking defects or
identifying a software requirement at a later stage.

7. Implement Testing Techniques

It's not possible to check every possible condition in your software application.
Software Testing techniques help you select a few test cases with the maximum
possibility of finding a defect.

• Boundary Value Analysis (BVA): As the name suggests it's the technique
that defines the testing of boundaries for a specified range of values.
• Equivalence Partition (EP): This technique partitions the range into equal
parts/groups that tend to have the same behavior.
• State Transition Technique: This method is used when software behavior
changes from one state to another following particular action.
• Error Guessing Technique: This is guessing/anticipating the error that may
arise while doing manual testing. This is not a formal method and takes
advantages of a tester's experience with the application

8. Self-cleaning
The test case you create must return the Test Environment to the pre-test state and
should not render the test environment unusable. This is especially true for
configuration testing.

9. Repeatable and self-standing

The test case should generate the same results every time no matter who tests it

10. Peer Review.

After creating test cases, get them reviewed by your colleagues. Your peers can
uncover defects in your test case design, which you may easily miss.

Resources Required:

Sr. Name of specification Quantity Remarks

No. Resource
1 Hardware: Computer(i3-i5
Computer preferable), Ram As per batch For all
System minimum 2 GB and size practical of
onwards, HDD free space test case
1GB or More generation
2 Operating Windows 7 or
system latest/LINUX version 5.0
or later
3 Software Any Word Processing tool
such as Libre Office,
Open Office.
Any calculator application
Test Cases For Simple Calculator Application

No. Test Test case Prerequisite Steps Input Expected Result Actual Re
Case - Objective data Result ma
ID rks/
Sta
tus

1 TC1 To add two Calculator is 1.Key in a valid 135 + 235(addition, above 235 Pass
integers and switched on integer from - 100 ten digits will be
display the 9999999999 to expressed in
result on +9999999999 exponential form)
ten-digit 2. Key in
calculator operator + 3. Key
in second
operand, a valid
integer from -
9999999999 To
+999999999

2 TC-2 To subtract Calculator is 1.Key in a valid 9876- 9420(subtraction, 9420 Pass

two integers switched on integer from - 456 above ten digits will
and display 9999999999 to be expressed in
the result on +9999999999 exponential form)
ten-digit 2. Key in
calculator operator - 3. Key
No. Test Test case Prerequisite Steps Input Expected Result Actual Re
Case - Objective data Result ma
ID rks/
Sta
tus

in second
operand, a valid
integer from -
9999999999 To
+999999999

3. TC-3 To multiply Calculator is 1.Key in a valid 50 x 2500(multiplication, 2500 Pass

two integers switched on integer from - 50 above ten digits will
and display 9999999999 to be expressed in
the result on +9999999999 exponential form)
ten-digit 2. Key in
calculator operator x 3. Key
in second
operand, a valid
integer from -
9999999999 To
+999999999
No. Test Test case Prerequisite Steps Input Expected Result Actual Re
Case - Objective data Result ma
ID rks/
Sta
tus

4. TC4 To divide Calculator is 1.Key in a valid 100 / 20(division, above 20 Pass

two integer switched on integer from - 5 ten digits will be
and display 9999999999 to expressed in
the result on +9999999999 exponential form)
ten digit 2. Key in
calculator operator / 3. Key
in second
operand, a valid
integer from -
9999999999 To
+999999999

5 TC5 To clear the Calculator is Press C 0 should appear on 0 should Pass

screen switched on screen. appear
on
screen.
 No. Test Test case Prerequisite Steps Input Expected Result Actual Re
Case - Objective data Result ma
ID rks/
Sta
tus

6 TC6 To delete Calculator is Press backspace Digit should be Digit Pass.

digits one switched on deleted. should
by one. be
deleted.

Exercise:

1. State key factors to be tested in black box testing

Key factors to be tested in black box testing:
• Black-box testing is a software testing method that tests the functionality of the ‘software’ application on
the basis of the specifications.
• It is also termed as requirements driven testing. ‘Independent testing’ team usually performs this ‘type of
testing’ during the ‘software’ testing life cycle.
• The main focus of ‘Black Box Testing’ is on the ‘functionality of the system’ as a whole. This test method
can be used to each and every level of ‘software’ testing such as ‘unit, integration, system and acceptance
testing’.
2. What are the sources of knowledge for Black box testing?

Black box testing is a technique of software testing which examines the functionality of software without
peering into its internal structure or coding. The primary source of black box testing is a specification of
requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its functionality and checks
whether the function is giving expected output or not. If the function produces correct output, then it is
passed in testing, otherwise failed. The test team reports the result to the development team and then tests the
next function. After completing testing of all functions if there are severe problems, then it is given back to
the development team for correction.

Generic steps of black box testing

• The black box test is based on the specification of requirements, so it is examined in the beginning.
• In the second step, the tester creates a positive test scenario and an adverse test scenario by selecting valid
and invalid input values to check that the software is processing them correctly or incorrectly.
• In the third step, the tester develops various test cases such as decision table, all pairs test, equivalent
division, error estimation, cause-effect graph, etc.
• The fourth phase includes the execution of all test cases.
• In the fifth step, the tester compares the expected output against the actual output.
• In the sixth and final step, if there is any flaw in the software, then it is cured and tested again.
3. State the advantages and disadvantages for Black box testing.

Advantages

a) Tests are done from a user's point of view and will help in exposing discrepancies in the specifications.
b) Tester need not know programming languages or how the software has been implemented.
c) Tests can be conducted by a body independent from the developers, allowing for an objective perspective
and avoidance of developer-bias.
d) Test cases can be designed as soon as the specifications are complete.

Disadvantages

a) Only a small number of possible inputs can be tested and many program paths will be left untested.
b) Without clear specifications, test cases will be difficult to design.
c) Tests can be redundant if the software designer/ developer has already run a test case.

Conclusion: Thus, we successfully design and write test cases for simple calculator application