Testings
What is difference between Test Cases vs Test Scenarios?
Difference between Test cases vs Test scenarios:
Test Case
Test case consist of test case name,
Precondition, steps / input condition,
expected result.
Test cases are low level actions and it can
be derived from test scenarios.
Test case is give detailed information about
if any pre-condition, what to test, how to
test and expected result etc.
Test case means detailed documenting the
cases which help executing while testing.
Test cases are set of steps which performed
on system to verify the expected output.
Test cases are more importance in case
where development is happening onsite and
QA is happening Off shored. It will help to
understand and make both developer and
QA in sync.
Writing test cases is one time effort which
can be used in future while executing
regression test case.
While reporting defects it will help tester to
link the defect with test case id.
Test Scenario
Test scenario consists of a detailed test
procedure. We can also say that a test
scenario has many test cases associated
with it. Before executing the test scenario
we need to think of test cases for each
scenario.
Test scenarios are the high level
classification of test requirement grouped
depending on the functionality of a module
and it can be derived from use cases.
Test scenario is one liner statement which
tell us about what to test.
Test Scenario means talking and thinking
requirements in detail.
Test scenario is thread of operations.
Test scenarios are more important when
time to write test cases is no sufficient and
team members are agree with the detailed
one liner scenario.
In new software testing generation it is new
idea and time saver activity. The addition
and modification (easy maintainability) of
test scenarios is easy and independent on
specific person.
 The detailed test case document is full proof
One of the most positive point about test
guard for new software tester. If developer
scenario is good test scenarios reduces the
missed something then it is easy to catch
complexity and repeatability of product.
while executing these full-proof test cases.

If the test scenario not detailed enough then

It requires more time and resources due to
it might take some time to discussion and
detailed test case which talks about how to
understand what test scenario is exactly
test and what to test.
talking about.

Example:

Requirement is to test your phone WiFi:

Verify that device automatically connects to Wi-Fi if user

Test Scenario
creates new profile

Test case 1: Create WiFi profile and verify that it created

successfully
Test cases

Test case 2: Verify that device is able to connect to Wi-Fi

Sample Requirement: Use case ID: UC0001 Verify and validate the end to end functionality of
e-commerce website. Only register customers should be login into site using valid credentials
and place the order.

Test Scenario:

Test Case:
Explain regression testing?

Whenever changes happen to software, regression testing is done to ensure that these do not
adversely affect the existing functionality. A regular regression testing can use multiple builds for
the test cases to be executed. However, an unchanged build is highly recommended for final
regression testing. The test cases that failed due to the defects should be included for future
regression testing.
It is necessary to perform regression testing when:

1. Change is in requirements and code is modified according to the requirement.

2. Defect fixing.
3. New feature is added to the software.

How to do Regression Testing

A test methodology for an effective regression testing made up of the following steps:
1. Performing an initial Smoke or Sanity test.
2. Understanding the criteria to select the test cases for Regression Testing.
3. Prioritization of test cases.
4. Methodology for select test cases
5. Resetting the test cases for test execution.
6. Concluding the result of a regression test cycle.
1. Performing an initial Smoke or Sanity test

A subset of the regression test cases can be set aside as smoke tests. A smoke test is a group of
test cases that establish that the system is stable and all major functionality is present and works
under normal conditions. Smoke tests are often automated, and the selection of the test cases
are broad in scope. The smoke tests might be run before deciding to proceed with further testing
(why dedicate resources to testing if the system is very unstable). The purpose of smoke tests is
to demonstrate stability, not to find bugs with the system. Sanity testing is done to test that major
functionality of the system is working or not. If sanity test fails, the build is rejected to save the
time and costs involved in a more rigorous testing

2. Criteria to select test cases for Regression Testing

It was found from industry data that good number of the defects reported by customers were due
to last minute bug fixes creating side effects and hence selecting the test case for regression
testing is an art and not that easy.

The selection of test cases for regression testing

Requires knowledge on the bug fixes and how it affect the system.
Includes the area of frequent defects.
Includes the area which has undergone many/recent code changes.
Includes the area which is highly visible to the users.
Includes the core features of the product which are mandatory requirements of the
customer.

Selection of test cases for regression testing depends more on the criticality of bug fixes than the
criticality of the defect itself. A minor defect can result in major side effect and a bug fix for an
extreme defect can have no or a just a minor side effect. So the test engineer needs to balance
these aspects for selecting the test cases for regression testing.
3. Prioritization of test cases

Prioritizing the test cases depends on the business impact, critical and frequently used
functionality. Selection of test cases based on priority will reduce the test suit. The test cases may
be classified into three categories:

Priority-0: These test cases can be called as Sanity test cases which checks the basic
functionality and are run for accepting the build for further testing. These are also run when a
project goes through major changes. These test cases deliver a very high project value to both
development teams and to customers.
Priority-1: Uses the basic and normal setup and these test cases deliver high project value to
both development teams and customers.
Priority-2: These test cases deliver moderate project value and are executed as a part of software
testing life cycle and selected for regression on need basis.

4. Methodology for selecting test cases:

Once the test cases are prioritize, test cases can be selected. There could be several approaches to
regression testing which need to be decided on case to case basis. For example:
Case 1: If criticality and impact of the defect fixes are low then it is enough to select few test
cases from Test Case DataBase (TCDB) and execute them. These can fall under any priority (0,
1, or 2).
Case 2: If the criticality and the impact of the bug fixes are Medium, then we need to execute all
Priority-0 and Priority-1 test cases. If bug fixes need additional test cases from Priority-2, then
those test cases can also selected and used for regression testing. Selecting Priority-2 test cases in
this case is desirable but not a must.
Case 3: If the criticality and impact of the bug fixes are High, then we need to execute all
Priority-0, Priority-1 and carefully selected Priority-2 test cases.
The above methodology requires Impact Analysis of bug fixes for all defects. It can be a time
consuming process. If there is not enough time and the risk of not doing Impact Analysis is low,
then the following alternative methodologies:
1. Regress All: For regression testing, all priority 0, 1, and 2 test cases are re-run.
2. Priority bases Regression: For regression testing, based on the priority, all priority 0, 1, and 2
test cases are run in order, based on the availability of time.
3. Random Regression: Random test cases are selected and executed.
4. Regress Changes: Code changes are compared to the last cycle of testing and test cases are
selected based on their impact on the code.
An effective regression strategy is usually a combination of all of the above.

5. Resetting the test cases for execution:

Resetting of the test cases needs to be done with the following considerations:

1. When there is a major change in the product.

2. Where there is a situation the expected results of the test cases could be quite different
from previous cycles.
3. Whenever existing application functionality is removed, the related test cases can be
reset.
4. When there is a change in the build procedure which affect the product.
5. Large release cycle where some test cases were not executed for a long time.
6. You are in the final regression test cycle with a few selected test cases.
6. Concluding the Result of Regression Testing:

Regression testing uses only one build for testing (if not, it is strongly recommended). It is
expected that all 100% of those test cases pass using the same build. In situations where the pass
% is not 100, the test manager can look at the previous results of the test case to conclude the
expected result.

1. If the result of a particular test case was PASS using the previous builds and FAIL in the
current build, then regression failed. We need to get a new build and start the testing from
scratch after resetting the test cases.
2. If the result of a particular test case was a FAIL using the previous builds and a PASS in
the current build, then it is easy to assume the bug fixes worked.
3. If the result of a particular test case was a FAIL using the previous builds and a FAIL in
the current build and if there are no bug fixes for this particular test case, it may mean that
the result of this test case shouldnt be considered for the pass %. This may also mean that
such test cases shouldnt be selected for regression.