Test Case Design

➢ 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 to 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
Test Cases in Manual Testing-
➢ A Test Case is a set of actions performed on a system to determine if it
satisfies software requirements and functions correctly.
➢ The purpose of a test case is to determine if different features within a
system are performing as expected and to confirm that the system
satisfies all related standards, guidelines and customer requirements.
➢ The process of writing a test case can also help reveal errors or defects
within the system.
➢ Test cases are typically written by members of the testing team and can
be used as step-by-step instructions for each system test.
➢ Testing begins once the development team has finished a system feature
or set of features. A sequence or collection of test cases is called a test
suite.
The components of a test case include-
✓ Test ID -> Typically a numeric or alphanumeric identifier that QA
engineers and testers use to group test cases into test suites.
✓ Test name -> A title that describes the functionality or feature that the
test is verifying.
✓ Objective -> Also called the description, this important component
describes what the test intends to verify in one to two sentences.
✓ References -> Links to user stories, design specifications or requirements
that the test is expected to verify.
✓ Prerequisites -> Any conditions that are necessary for the tester or QA
engineer to perform the test.
✓ Test steps -> Detailed descriptions of the sequential actions that must be
taken to complete the test.
✓ Test data-> The data needs to execute the test case
✓ Expected results -> An outline of how the system should respond to each
test step.
✓ Actual results -> This will the output after executing the test case
✓ Status -> This will be status of test case after execution (Pass/Fail)

Below is a format of a standard login Test cases example -

Test Test Objective Refer Prerequisit Test steps Test data Expected Actual Status
Case name ences es results results
ID
TC_0 Check Verify if AM- User 1.Go to UserID- User
1 Customer customer 1012 should able ‘Facebook.com’ ValidUser should
Login is able to to launch 2.Click on login login to
with valid login with the button Password- application
Data valid data application 3.Enter valid ValidPass successfull
username y
4.Enter valid
password
5.click on login
button
TC_0 Check Verify if AM- User 1.Go to UserID- Error
2 Customer customer 1012 should able ‘Facebook.com’ InvalidUser message
Login is not to launch 2.Click on login should be
with able to the button Password- displayed
invalid login with application 3.Enter invalid InvalidPass saying
Data invalid username ‘Invalid
data 4.Enter invalid Username/
password password’
5.click on login
button
Best Practice for writing good Test Case Example-
➢ Test Cases need to be simple and transparent:
➢ Create Test Case with End User in Mind
➢ Avoid test case repetition.
➢ Do not Assume
➢ Ensure 100% Coverage
➢ Test Cases name must be identifiable
➢ Implement Testing Techniques while writing test cases

Requirements Traceability Matrix (RTM)

➢ Requirement Traceability Matrix (RTM) is a document that maps and

traces user requirement with test cases.
➢ It captures all requirements proposed by the client and requirement
traceability in a single document, delivered at the conclusion of the
Software developement life cycle.
➢ The main purpose of Requirement Traceability Matrix is to validate that
all requirements are checked via test cases such that no functionality is
unchecked/missing during Software testing.

Types of Traceability Test Matrix

The traceability matrix can be classified into three different types which are as
follows:
➢ Forward traceability
➢ Backward or reverse traceability
➢ Bi-directional traceability

Forward traceability
The forward traceability test matrix is used to ensure that every business's needs
or requirements are executed correctly in the application and also tested
rigorously. The main objective of this is to verify whether the product
developments are going in the right direction. In this, the requirements are
mapped into the forward direction to the test cases.
Backward or reverse traceability

The reverse or backward traceability is used to check that we are not increasing
the space of the product by enhancing the design elements, code, test other
things which are not mentioned in the business needs. And the main objective
of this that the existing project remains in the correct direction. In this, the
requirements are mapped into the backward direction to the test cases.

Bi-directional traceability

It is a combination of forwarding and backward traceability matrix, which is used

to make sure that all the business needs are executed in the test cases. It also
evaluates the modification in the requirement which is occurring due to the bugs
in the application.
Parameters to include in RTM
✓ Requirement ID
✓ Requirement Type and Description
✓ Test Cases with Status

But in a typical software testing project, the traceability matrix would have more
than these parameters.
Advantages/Goals of Traceability Matrix
➢ It helps in tracing the documents that are developed during various
phases of SDLC.
➢ It ensures that the software completely meets the customer's
requirements.
➢ It helps in detecting the root cause of any bug.
➢ With the help of the RTM document, we can display the complete test
execution and bugs status based on requirements.
➢ It is used to show the missing requirements or conflicts in documents.
➢ In this, we can ensure the complete test coverage, which means all the
modules are tested.
➢ It will also consider the efforts of the testing teamwork towards
reworking or reconsidering on the test cases.

Black Box Testing Techniques

In order to systematically test a set of functions, it is necessary to design test
cases. Testers can create test cases from the requirement specification
document using the following Black Box Testing techniques:
✓ Equivalence Partitioning
✓ Boundary Value Analysis
✓ Decision Table Testing
✓ State Transition Testing
✓ Error Guessing
1) Equivalence Partitioning
➢ This technique is also known as Equivalence Class Partitioning (ECP).
➢ In this technique, input values to the system or application are divided
into different classes or groups based on its similarity in the outcome.
➢ Hence, instead of using each and every input value, we can now use any
one value from the group/class to test the outcome.
➢ This way, we can maintain test coverage while we can reduce the
amount of rework and most importantly the time spent.

For Example:

As present in the above image, the “AGE” text field accepts only numbers from
18 to 60. There will be three sets of classes or groups.

Two invalid classes will be:

✓ Less than or equal to 17.
✓ Greater than or equal to 61.
A valid class will be:
✓ anything between 18 and 60.

We have thus reduced the test cases to only 3 test cases based on the formed
classes thereby covering all the possibilities. So, testing with any one value
from each set of the class is sufficient to test the above scenario.

2) Boundary Value Analysis

➢ The name itself defines that in this technique, we focus on the values at
boundaries as it is found that many applications have a high amount of
issues on the boundaries.
 ➢ Boundary refers to values near the limit where the behaviour of the
system changes. In boundary value analysis, both valid and invalid inputs
are being tested to verify the issues.

For Example:

If we want to test a field where values from 1 to 100 should be accepted, then
we choose the boundary values: 1-1, 1, 1+1, 100-1, 100, and 100+1. Instead of
using all the values from 1 to 100, we just use 0, 1, 2, 99, 100, and 101.

3) Decision Table Testing

As the name itself suggests, wherever there are logical relationships like:
If
{
(Condition = True)
then action 1;
}
else

action2; /*(condition = False) */

Then a tester will identify two outputs (action1 and action2) for two conditions
(True and False). So based on the probable scenarios a Decision table is carved
to prepare a set of test cases.
For Example:
Take an example of XYZ bank that provides an interest rate for the Male senior
citizen as 10% and 9% for the rest of the people.

In this example condition, C1 has two values as true and false, C2 also has two
values as true and false. The total number of possible combinations would
then be four. This way we can derive test cases using a decision table.

4) State Transition Testing

➢ State Transition Testing is a technique that is used to test the different
states of the system under test.
➢ The state of the system changes depending upon the conditions or
events.
➢ The events trigger states which become scenarios and a tester needs to
test them.
➢ A systematic state transition diagram gives a clear view of the state
changes but it is effective for simpler applications.
➢ More complex projects may lead to more complex transition diagrams
thereby making it less effective.

For Example:
5) Error Guessing
✓ This is a classic example of Experience-Based Testing.
✓ In this technique, the tester can use his/her experience about the
application behaviour and functionalities to guess the error-prone areas.
✓ Many defects can be found using error guessing where most of the
developers usually make mistakes.

Few common mistakes that developers usually forget to handle:

✓ Divide by zero.
✓ Handling null values in text fields.
✓ Accepting the Submit button without any value.
✓ File upload without attachment.
✓ File upload with less than or more than the limit size.

Bug in Software Testing

✓ The Bug is the informal name of defects, which means that software or
application is not working as per the requirement.
✓ In software testing, a software bug can also be issue, error, fault, or
failure. The bug occurred when developers made any mistake or error
while developing the product.
 ✓ The bug had various names in different companies such as error, issues,
problem, fault, and mistake, etc.

Terms Description Raised by

Defect When the application is not working as Test Engineer
per the requirement.
Bug Informal name of defect Test Engineer
Error Problem in code leads to the errors. Developer, Automation Test
Engineer
Issue When the application is not meeting the Customer
business requirement.
Mistake Problem in the document is known as a --
mistake.
Failure Lots of defect leads to failure of the --
software.

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:

➢ Wrong coding
➢ Missing coding
➢ Extra coding
Bug Report Template/Components

➢ Bug ID -> it is a unique number given to the bug.

➢ Test case name -> When we find a bug, we send a bug report, not the test
case to the concerned developer. It is used as a reference for the test
engineer.
➢ Severity -> It is the impact of a bug on the application. It can be a blocker,
critical, major, and minor.
➢ Priority -> In this, we have to decide which bug has to be fixed first. It
could be P1/P2/P3/P4, urgent, high, medium, and low.
➢ Status -> The different status of the bug which could be assigned, invalid,
duplicate, deferred, and so on.
➢ Reporter -> In this, we will mention the name of the person who found
the bug. It could be the test engineer, and sometime it may be a
developer, business analyst, customer, etc.
➢ Date -> It provides the date when the bug is found.
➢ Release/Build Version -> It provides the release number in which the bug
occurs, and also the build version of the application.
 ➢ Platform -> Mention the platform details, where we exactly find the bug.
➢ Description -> In this, we will explain the navigation steps, expected and
actual results of the particular bug.
➢ Attachments -> Attach the screenshots of the bug, which we captured
because it helps the developers to see the bug.

Let see one example of the bug report:

Bug Life Cycle

➢ As soon as the test engineer finds the bug, status is given as New, which
indicates that a bug is just found.
➢ This new bug needs to be reported to the concerned Developer by
changing the status as Assigned so that the responsible person should
take care of the bug.
➢ Then the Developer first go through the bug, which means that the
Developers read all the navigation steps to decide whether it is a valid bug
or not.
➢ Based on this, if the bug is valid, the Developer starts reproducing the bug
on the application, once the bug is successfully reproduced, the Developer
will analyse the code and does the necessary changes, and change the
status as Fixed.
➢ Once the code changes are done, and the bug is fixed, the test engineer
re-test the bug, which means that the test engineer performs the same
action once again, which is mentioned in the bug report, and changes the
status accordingly:
➢ Close, if the bug fixes properly, and functionally working according to the
requirement OR Re-open, if the bug still exists or not working properly as
per the requirement, then the bug sends it back to the Developer once
again.
 ➢ This process is going on continuously until all the bugs are fixed and
closed.

If bug is not accepted by developer, then developer needs to provide reason for
same. Developer can reject the bug based on following resolutions:
Invalid / rejected
➢ When the Test Engineer wrote an incorrect Bug Report because of
misunderstanding the requirements, then the Developer will not accept
the bug, and gave the status as Invalid and sent it back. (Sometime
Developer can also misunderstand the requirements).
➢ Reasons:
✓ Test Engineer misunderstood the requirements
✓ Developer misunderstood the requirements
Duplicate
• When the same bug has been reported multiple times by the different
test engineers are known as a duplicate bug.
• Reasons:
✓ Common features
✓ Dependent Modules

Not Reproducible
• The Developer accepts the bug, but not able to Reproduce due to some
reasons.
• Reasons
✓ Incomplete bug report
✓ Environment mismatch – Server Mismatch, Platform Mismatch,
Inconsistent bug, Build mismatch

Can't fix
➢ When Developer accepting the bug and also able to reproduce, but can't
do the necessary code changes due to some constraints
➢ Reasons
✓ No technology supports
✓ The Bug is in the core of code (framework)
✓ The cost of fixing a bug is more than keeping it.
Deferred / postponed
➢ The deferred/postpone is a status in which the bugs are postponed to the
future release due to time constraints.
➢ Reasons
✓ time constraints.
✓ Minor bugs

RFE (Request for Enhancement)

➢ These are the suggestions given by the test engineer towards the
enhancement of the application in the form of a bug report.
➢ If the customer says Yes, then the status should be Fix or If the customer
says no, then the status should be Close.
➢ Reasons
✓ Additional Add-ons looking at testers point of view

Severity and Priority in testing

Severity
➢ The impact of the bug on the application is known as severity.
➢ It can be a blocker, critical, major, and minor for the bug.
✓ Blocker -> if the severity of a bug is a blocker, which means we
cannot proceed to the next module, and unnecessarily test
engineer sits ideal.
✓ Critical -> if it is critical, that means the main functionality is not
working, and the test engineer cannot continue testing.
✓ Major -> If it is major, which means that the supporting
components and modules are not working fine, but test engineer
can continue the testing.
✓ Minor -> if the severity of a bug is minor, which means that all the
U.I problems are not working fine, but testing can be processed
without interruption.
Priority
➢ Priority is important for fixing the bug or which bug to be fixed first or how
soon the bug should be fixed.
➢ It can be urgent (p1), high (p2), medium (p3), and low(p4).
✓ Urgent (p1) -> It is most critical and needs to address ASAP
✓ High (p2) -> it is a major impact on the customer application, and it
has to be fixed first.
✓ Medium (p3) -> In this, the problem should be fixed before the
release of the current version in development.
✓ Low (p4) -> The flow should be fixed if there is time, but it can be
deferred with the next release.

Examples

➢ High Priority, Low Severity bug -> If the company name is misspelled in
the home page of the website, then the priority is high, and severity is low
to fix it.
➢ High Severity, Low Priority -> Web page not found when user clicks on a
link (users does not visit that page generally)
➢ Low Priority, Low Severity -> Any cosmetic or spelling issues which is
within a paragraph or in the report
➢ High Priority, High Severity -> An error which occurs on the basic
functionality of the application and will not allow the user to use the
system (E.g., user is not able to login to the application)

Entry & Exit Criteria

➢ Ideally, the QA team does not proceed with the next phase until the exit
criteria of the current phase meets. The entry criteria should include the
completion of exit criteria of the previous phase.
➢ In real time, it is not possible to wait for the next phase until the exit
criteria is met. Now, the next phase can be initiated if the critical
deliverables of the previous phase have been completed.
➢ In each phase of STLC, the entry and exit criteria should be defined.
Entry Criteria
➢ Entry Criteria for STLC phases can be defined as specific conditions; or, all
those documents which are required to start a particular phase of STLC
should be present before entering any of the STLC phase.
• Entry criteria is a set of conditions that permits a task to perform, or in
absence of any of these conditions, the task cannot be performed.
• While setting the entry criteria, it is also important to define the
timeframe when the entry criteria item is available to start the process.
• For Instance, to start the Test Cases development phase, the following
conditions should be met −
✓ The requirement document should be available.
✓ Complete understanding of the application flow is required.
✓ The Test Plan Document should be ready.

Exit Criteria
➢ Exit Criteria for STLC phases can be defined as
items/documents/actions/tasks that must be completed before
concluding the current phase and moving on to the next phase.
➢ Exit criteria is a set of expectations; this should be met before concluding
the STLC phase.
➢ For Instance, to conclude the Test Cases development phase, following
expectations should be met −
✓ Test Cases should be written and reviewed.
✓ Test Data should be identified and ready.
✓ Test automation script should be ready if applicable.
--------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------

REFERENCES
❖ HTTPS:// WWW .JAVATPOINT .COM /MANUAL- TESTING
❖ HTTPS:// WWW .GURU99.COM /MANUAL -TESTING .HTML
❖ HTTPS:// WWW .SOFTWARETESTINGMATERIAL .COM /MANUAL -TESTING -TUTORIAL
❖ HTTPS:// WWW .TUTORIALSPOINT .COM /SOFTWARE _ TESTING_ DICTIONARY /MANUAL _ TESTING .HTM

12.4M

297
C++ vs Java