Use Case Testing

What is Use Case Testing?

Use Case Testing is a functional black box testing technique that helps testers to
identify test scenarios that exercise the whole system on each transaction basis
from start to finish.

Characteristics of Use Case Testing:

 Use Cases capture the interactions between 'actors' and the 'system'.
 'Actors' represents user and their interactions that each user takes part into.
 Test cases based on use cases and are referred as scenarios.
 Capability to identify gaps in the system which would not be found by testing individual
components in isolation.
 Very effective in defining the scope of acceptance tests.
RTM

Why RTM is Important?

The main agenda of every tester should be to understand the client’s
requirement and make sure that the output product should be defect-free.
To achieve this goal, every QA should understand the requirement
thoroughly and create positive and negative test cases.

This would mean that the software requirements provided by the client
have to be further split into different scenarios and further to test cases.
Each of this case has to be executed individually.

A question arises here on how to make sure that the requirement is tested
considering all possible scenarios/cases? How to ensure that any
requirement is not left out of the testing cycle?

A simple way is to trace the requirement with its corresponding test

scenarios and test cases. This merely is termed as ‘Requirement
Traceability Matrix.'

The traceability matrix is typically a worksheet that contains the

requirements with its all possible test scenarios and cases and their current
state, i.e. if they have been passed or failed. This would help the testing
team to understand the level of testing activities done for the specific
product.
Types of Traceability Test Matrix
In Software Engineering, traceability matrix can be divided into three major
component as mentioned below:

 Forward traceability: This matrix is used to check whether the

project progresses in the desired direction and for the right product. It
makes sure that each requirement is applied to the product and that
each requirement is tested thoroughly. It maps requirements to test
cases.
 Backward or reverse traceability: It is used to ensure whether the
current product remains on the right track. The purpose behind this
type of traceability is to verify that we are not expanding the scope of
the project by adding code, design elements, test or other work that
is not specified in the requirements. It maps test cases to
requirements.
 Bi-directional traceability ( Forward+Backward): This traceability
matrix ensures that all requirements are covered by test cases. It
analyzes the impact of a change in requirements affected by
the Defect in a work product and vice versa.  

Advantage of Requirement Traceability Matrix

 It confirms 100% test coverage
 It highlights any requirements missing or document inconsistencies
 It shows the overall defects or execution status with a focus on
business requirements
 It helps in analyzing or estimating the impact on the QA team's work
with respect to revisiting or re-working on the test cases

Defect management process in software testing

The process of defect management usually includes four steps.

 The first step is the stage of defect detecting. We have already mentioned
that it can be conducted either by the team of developers or by the users.
Regardless of the type of testing, its main goal is to detect all bugs in the final
product or its part.
 The second step of the bug management process is dedicated to the
formulation of bug reports. These are the documents that include all
necessary information about certain bugs. Usually, they contain data on the
type of bug, and the possible ways of its correction.
 The third step is the stage of bug fixing. After the bugs are fixed, they
should be tested once more to make sure that the software works properly.
  During the final step the bug list is created. This is the document that
contains information about all bugs that occurred during the project’s
performance. The team often uses the bug list because similar bugs’
occurrence is not rare.

Bug Lifecycle

Defect/Bug Life Cycle in Software Testing

What is Defect Life Cycle?

DEFECT LIFE CYCLE or Bug Life Cycle is the specific set of states that a
Bug goes through in its entire life. The purpose of the Defect life cycle is to
easily coordinate bug status changes to various assignees and make the
bug fixing process systematic.

Bug Life Cycle Status

The number of states that a defect goes through varies from project to
project. Below lifecycle diagram, covers all possible states

 New: When a new defect is logged and posted for the first time. It is
assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the
tester approves the bug and assigns the bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and
verifies the change, he or she can make bug status as "Fixed."
 Pending retest: Once the defect is fixed the developer gives a
particular code for retesting the code to the tester. Since the software
testing remains pending from the testers end, the status assigned is
"pending retest."
 Retest: Tester does the retesting of the code at this stage to check
whether the defect is fixed by the developer or not and changes the
status to "Re-test."
 Verified: The tester re-tests the bug after it got fixed by the
developer. If there is no bug detected in the software, then the bug is
fixed and the status assigned is "verified."
 Reopen: If the bug persists even after the developer has fixed the
bug, the tester changes the status to "reopened". Once again the bug
goes through the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status
"Closed." 
 Duplicate: If the defect is repeated twice or the defect corresponds
to the same concept of the bug, the status is changed to "duplicate."
 Rejected: If the developer feels the defect is not a genuine defect
then it changes the defect to "rejected."
 Deferred: If the present bug is not of a prime priority and if it is
expected to get fixed in the next release, then status "Deferred" is
assigned to such bugs
 Not a bug:If it does not affect the functionality of the application then
the status assigned to a bug is "Not a bug".
Defect Life Cycle Explained

1. Tester finds the defect

2. Status assigned to defect- New
3. A defect is forwarded to Project Manager for analyze
4. Project Manager decides whether a defect is valid
5. Here the defect is not valid- a status is given "Rejected."
6. So, project manager assigns a status rejected. If the defect is
not rejected then the next step is to check whether it is in
scope. Suppose we have another function- email functionality
for the same application, and you find a problem with that. But
it is not a part of the current release when such defects are
assigned as a postponed or deferred status.
7. Next, the manager verifies whether a similar defect was raised
earlier. If yes defect is assigned a status duplicate.
8. If no the defect is assigned to the developer who starts fixing
the code. During this stage, the defect is assigned a status in-
progress.
9. Once the code is fixed. A defect is assigned a status fixed
 10. Next, the tester will re-test the code. In case, the Test
Case passes the defect is closed. If the test cases fail again,
the defect is re-opened and assigned to the developer.
11. Consider a situation where during the 1st release of
Flight Reservation a defect was found in Fax order that was
fixed and assigned a status closed. During the second upgrade
release the same defect again re-surfaced. In such cases, a
closed defect will be re-opened.

What is Statement coverage in testing?

Statement coverage is a white box testing technique, which involves the execution of all the
statements at least once in the source code. It is a metric, which is used to calculate and measure
the number of statements in the source code which have been executed. Using this technique we
can check what the source code is expected to do and what it should not. It can also be used to
check the quality of the code and the flow of different paths in the program. The main drawback of
this technique is that we cannot test the false condition in it.

(Statement coverage = No of statements Executed/Total no of statements in the source code * 100)