1) What is Regression Testing?

Why is the regression test applied in each phase

of software development? Discuss.
Ans: Regression Testing is a type of software testing conducted to ensure that recent
changes, updates, or bug fixes in a software application do not negatively impact the
existing functionality. It verifies that the software still performs as expected after
modifications.

Why Regression Testing is Applied in Each Phase of Software

Development?

Regression testing is essential in all phases of software development for the following
reasons:

1.​ Verification of Fixes:

○​ Ensures that bug fixes do not introduce new defects or reintroduce old
ones.
2.​ Stability of Existing Features:
○​ Validates that new features or updates do not disrupt existing features of
the application.
3.​ Integration Testing:
○​ When new modules are integrated, regression testing checks that the
integration does not cause issues in the already developed parts.
4.​ Quality Assurance:
○​ Maintains the quality and reliability of the software throughout its lifecycle
by consistently verifying functionality after every change.
5.​ Early Detection of Issues:
○​ Helps detect issues earlier in the development lifecycle, reducing the cost
of fixing defects later.
6.​ Compatibility Check:
○​ Ensures that the software remains compatible with its environment (e.g.,
operating systems, databases, third-party libraries) after updates.
7.​ Customer Satisfaction:
○​ By ensuring that updates and fixes do not lead to unexpected issues,
regression testing helps maintain trust and satisfaction for end-users.
Importance in Each Phase:

●​ Development Phase: Verifies that new code changes or enhancements do not

affect the ongoing development and existing features.
●​ Testing Phase: Ensures the accuracy and reliability of the software after fixes
and identifies side effects of changes.
●​ Deployment Phase: Confirms that the final product is stable and that updates or
environment changes have no adverse effects.
●​ Maintenance Phase: Regular regression testing is applied during updates or
patches to prevent any negative impact on the existing system.

2) How does regression testing help in producing quality software?

Ans: Regression testing plays a pivotal role in producing quality software by ensuring
that changes made during development do not negatively impact existing functionalities.
Here are key ways in which regression testing contributes to software quality:

Early Defect Detection

One of the primary benefits of regression testing is its ability to identify defects early in
the development cycle. By frequently running regression tests, teams can catch issues
before they escalate into more significant problems, which can be costly and
time-consuming to fix later on. This proactive approach helps maintain a high standard
of software quality throughout the development process.

Improved Software Stability and Reliability

Regression testing ensures that software remains stable and reliable after
modifications. Each time developers implement changes—whether adding new
features, fixing bugs, or making enhancements—there is a risk that existing
functionalities might break. Regression tests help mitigate this risk by verifying that all
features still work as expected, thereby enhancing overall software stability24.

Cost Efficiency
By detecting defects early and preventing them from reaching production, regression
testing can significantly reduce costs associated with fixing issues post-release.
Addressing problems during the development phase is generally less expensive than
dealing with them after deployment, especially if they affect user experience or
operational efficiency.

Continuous Improvement and Scalability

As software evolves, regression testing supports continuous improvement by allowing
teams to assess the impact of changes on existing functionalities. This ongoing
evaluation ensures that new releases maintain or enhance the quality of user
experience. Additionally, regression testing aids in scalability by confirming that new
features integrate smoothly with existing systems without compromising performance
under increased loads.

Confidence in Product Quality

Regular regression testing instills confidence among development teams and
stakeholders regarding the software's quality. It reassures them that the application
meets required standards and functions correctly after updates, thus fostering trust in
the product being delivered

3) Compare regression testing with development testing. Do we perform

regression testing before the release of the software?
Ans: Regression Testing:
●​ Ensures that recent code changes (e.g., fixes, updates) do not break existing
functionality.
●​ Typically performed after changes are made, especially before release.
●​ Often done multiple times as updates occur, especially before major releases.
●​ Tests modified code and other affected areas to confirm stability.
●​ Typically automated (e.g., Selenium, JUnit)
Development Testing:
●​ Focuses on testing new features, modules, or components being developed.
●​ Conducted continuously throughout the development lifecycle.
●​ Conducted repeatedly at various stages of development to catch issues early.
●​ Tests all components of the software to ensure overall quality and compliance
with specifications.
●​ Can involve both manual and automated testing tools (e.g., Postman, JIRA).
4) What is Regression Test case selection? How can we reduce the number of test
cases in Regression Testing?
Ans: Regression test case selection is the process of identifying a subset of test cases
from the entire test suite to execute during regression testing. This selection focuses on
test cases that are most relevant to the changes made in the application to ensure
efficiency and effectiveness.

How to Reduce the Number of Test Cases in Regression Testing?

Reducing the number of test cases in regression testing can be achieved by prioritizing
and selecting only the most critical and relevant test cases. Here are some strategies:

1. Impact Analysis

●​ Identify Impacted Areas: Analyze the code changes to determine which modules
or features are affected.
●​ Select Relevant Test Cases: Choose test cases that cover the impacted areas
directly or indirectly.

2. Test Case Prioritization

●​ Prioritize Critical Test Cases: Rank test cases based on their importance to core
functionalities, customer requirements, or business goals.
●​ High-Risk Areas: Focus on test cases that validate high-risk components or
frequently used functionalities.

3. Categorize Test Cases

●​ Reusable Test Cases: Choose test cases that are reusable and cover multiple
scenarios.
●​ Functional and Non-Functional Cases: Ensure that both functional (e.g., login,
data processing) and non-functional (e.g., performance, security) requirements
are tested.

4. Eliminate Redundant Test Cases

●​ Remove Duplicates: Identify and remove duplicate or overlapping test cases.

 ●​ Archive Outdated Test Cases: Retire test cases that are no longer relevant due
to deprecated or unchanged features.

5. Focus on Frequently Failing Test Cases

●​ Test cases that have historically failed are more likely to uncover defects and
should be included.

5) What are the categories to evaluate regression test selection techniques? Why
do we use such categorization?
Ans: Categories to Evaluate Regression Test Selection Techniques

Regression test selection techniques can be evaluated based on the following

categories:

1. Inclusiveness

●​ Definition: The extent to which a selection technique includes all relevant test
cases that may uncover defects caused by recent changes.
●​ Why Important: Ensures that no critical areas are missed during regression
testing.

2. Precision

●​ Definition: The ability of the technique to exclude irrelevant test cases that are
unlikely to reveal defects.
●​ Why Important: Reduces unnecessary execution of test cases, saving time and
effort.

3. Efficiency

●​ Definition: Measures the computational cost and time required to select test cases
using the technique.
 ●​ Why Important: Ensures that the selection process itself is not overly
time-consuming or resource-intensive.

4. Effectiveness

●​ Definition: Assesses how well the selected test cases detect defects in the
software.
●​ Why Important: Ensures that the technique improves the overall defect detection
rate.

5. Generalizability

●​ Definition: The ability of the technique to be applied to various types of software

systems and domains.
●​ Why Important: Ensures the approach can be used across different projects
without significant modifications.

6. Scalability

●​ Definition: The ability of the technique to handle large and complex test suites
efficiently.
●​ Why Important: Ensures the technique remains practical as the size of the
software and test suite increases.

7. Cost-Effectiveness

●​ Definition: Balances the cost of applying the technique against the benefits gained
(e.g., defect detection, reduced testing time).
●​ Why Important: Ensures that the return on investment (ROI) for regression
testing is justified.
Why Use Such Categorization?

Categorization is essential for the following reasons:

1.​ Informed Decision-Making:

○​ Helps testers and managers select the most appropriate technique based
on the project's requirements, constraints, and resources.
2.​ Optimization of Resources:
○​ Ensures the selection of a technique that optimizes time, effort, and cost
while maximizing defect detection.
3.​ Improved Test Coverage:
○​ Balances inclusiveness and precision to achieve comprehensive coverage
without unnecessary execution.
4.​ Adaptability:
○​ Ensures that the selected technique can be scaled or generalized across
different projects and domains.
5.​ Consistency in Quality:
○​ Helps maintain a standardized approach to regression testing, ensuring
consistent quality of the software.
6.​ Risk Mitigation:
○​ Reduces the likelihood of missing critical defects due to an ineffective or
poorly chosen selection technique.

6) Explore the techniques for the selection of test cases during regression
testing. Why do we rely on the selection of test cases based on modification
traversing?
Ans: Selecting appropriate test cases for regression testing is essential to ensure that
modifications in the software do not introduce new defects. Several techniques can be
employed for this selection, each with its unique approach:

Select all test cases: In this technique, all the test cases are selected from the already existing
test suite. It is the simplest and safest technique but not very efficient.

Select test cases randomly: In this technique, test cases are selected randomly from the
existing test suite, but it is only useful if all the test cases are equally good in their fault detection
capability which is very rare. Hence, it is not used in most of the cases.
Select modification traversing test cases: In this technique, only those test cases are
selected that cover and test the modified portions of the source code and the parts that are
affected by these modifications.

Select higher priority test cases: In this technique, priority codes are assigned to each test
case of the test suite based upon their bug detection capability, customer requirements, etc.
After assigning the priority codes, test cases with the highest priorities are selected for the
process of regression testing. The test case with the highest priority has the highest rank. For
example, a test case with priority code 2 is less important than a test case with priority code 1.

Historical Data Analysis: This technique involves analyzing historical defect data to identify
areas of the application that have been prone to issues in the past. Test cases related to these
areas are selected for regression testing.

Why Do We Rely on the Selection of Test Cases Based on Modification Traversing?

Relying on modification traversing for test case selection is beneficial for several reasons:

Targeted Testing: By focusing exclusively on modified code and its affected areas, this
technique minimizes unnecessary testing of unmodified parts of the application. This targeted
approach saves time and resources while ensuring that critical changes are adequately
validated.
Efficiency: Modification traversing reduces the overall number of test cases executed during
regression testing, leading to quicker testing cycles. This efficiency is particularly important in
agile environments where rapid iterations are common.
Risk Mitigation: Since it emphasizes testing areas impacted by recent changes, modification
traversing helps identify potential regressions early in the development process, mitigating risks
associated with software updates.
Improved Focus on Critical Areas: By selecting tests based on modifications, teams can
concentrate their efforts on parts of the application most likely to be affected by changes,
enhancing defect detection in high-risk areas.
Cost-Effectiveness: Reducing the number of test cases executed translates into lower testing
costs while maintaining quality assurance standards, making it an economically viable strategy
for organizations.
7) Illustrate the use of regression testing? Explain the following with respect to
regression testing considering an Enterprise Management System.
1. Prioritization technique
2. Reducing the number of test cases.
Ans: An Enterprise Management System (EMS) is a comprehensive software solution that
helps organizations manage various business processes, including finance, human resources,
supply chain, customer relationship management, and more. Given the complexity and critical
nature of such systems, regression testing is essential to ensure that new changes,
enhancements, or bug fixes do not adversely affect existing functionalities.

1. Prioritization Technique in Regression Testing

●​ Definition: Prioritization organizes test cases in order of importance, focusing on critical

areas of the application first. This ensures critical functionalities are tested early and
resources are used efficiently.

Example in EMS:

●​ A change is made to the Payroll module in the HR system to support a new tax
calculation rule.
●​ Prioritization Steps:
○​ Critical Functionality Test Cases: Test cases related to tax computation, payroll
generation, and employee salary disbursement are executed first because they
are critical for business operations.
○​ Frequently Used Features: Test cases for commonly used HR reports (e.g.,
salary slips or tax forms) are tested next.
○​ Dependent Modules: Test cases for other modules (e.g., Finance, which
integrates with Payroll for budget management) are prioritized based on their
dependency on HR updates.
○​ Low-Risk Areas: Modules or functionalities unrelated to the Payroll module are
tested last or deprioritized.

2. Reducing the Number of Test Cases in Regression Testing

●​ Definition: This involves selecting only the most relevant test cases, reducing
redundancy, and ensuring efficient testing.
 Example in EMS:

Suppose the Finance module has been updated to introduce a new expense
tracking feature. Instead of retesting the entire EMS:

○​ Analyze Changes: Identify which components of the Finance module interact

with other parts of the system (e.g., HR for payroll deductions or Supply Chain for
vendor payments).
○​ Selection of Test Cases:
■​ Directly Impacted Areas: Choose test cases related to the expense
tracking feature and its integration with the budget module.
■​ Indirectly Impacted Areas: Select test cases for modules that depend
on Finance (e.g., reports in the executive dashboard that consolidate HR
and Finance data).
■​ Stable Areas: Exclude test cases for unrelated modules like the CRM or
Supply Chain if the analysis confirms no dependency or impact.

8) Illustrate code coverage prioritization technique in detail. Also, write the

deletion algorithm which is used to minimize and prioritize test cases.

Ans: Code Coverage Prioritization is a technique used in regression testing to select and
prioritize test cases based on the extent to which they cover the codebase. The goal is to
ensure that the most critical parts of the code are tested first, thereby maximizing the likelihood
of detecting defects early in the testing process.

Code Coverage Metrics: Code coverage can be measured using various metrics:

○​ Statement Coverage: Measures the percentage of executable

statements in the code that have been executed by the test cases.
○​ Branch Coverage: Measures the percentage of branches (e.g., if-else
conditions) that have been executed.
○​ Function Coverage: Measures the percentage of functions or methods
that have been called during testing.
○​ Path Coverage: Measures the percentage of possible paths through the
code that have been executed.
Steps in Code Coverage Prioritization

1.​ Identify Code Changes: Determine which parts of the code have been modified or are
likely to be affected by recent changes.
2.​ Analyze Test Cases: For each test case, analyze the code coverage it provides. This
can be done using code coverage tools that instrument the code and track which lines or
branches are executed during testing.
3.​ Calculate Coverage Metrics: Calculate the coverage metrics for each test case, such
as statement coverage, branch coverage, and function coverage.
4.​ Prioritize Test Cases: Rank the test cases based on their coverage metrics. Test cases
that cover the most critical and frequently executed code paths should be given higher
priority.
5.​ Execute Test Cases: Execute the prioritized test cases, starting with those that provide
the highest coverage of the modified code.
6.​ Iterate: After executing the tests, analyze the results and update the coverage metrics
as necessary. This process can be repeated for subsequent changes.

Deletion Algorithm for Minimizing and Prioritizing Test Cases

The deletion algorithm is a systematic approach used to minimize and prioritize test cases within
a regression test suite. This algorithm helps ensure that only relevant and effective test cases
are retained, optimizing both execution time and resource allocation.

Steps in the Deletion Algorithm

1.​ Identify Redundant Test Cases: Analyze existing test cases to identify those that
overlap in functionality or coverage. Redundant tests can be removed without losing
significant coverage.
2.​ Evaluate Test Case Effectiveness: Assess each test case based on its historical
performance (e.g., fault detection rates). Test cases that have not detected any defects
over multiple runs may be candidates for deletion.
3.​ Prioritize Remaining Test Cases: Use prioritization techniques such as code coverage
prioritization to rank remaining test cases based on their effectiveness and relevance to
recent changes in the codebase.
4.​ Remove Low-Priority Test Cases: Delete or mark for exclusion those test cases that
have low priority according to the established criteria (e.g., low coverage, low fault
exposure potential).
 5.​ Continuous Review and Maintenance: Regularly review and update the test suite as
new features are added or existing functionalities change, ensuring that only relevant
tests remain.

9) What are the different risk analysis techniques?

Ans: Risk analysis techniques in software testing help identify potential risks
associated with changes in the software and prioritize testing efforts accordingly. Here
are some common risk analysis techniques used in regression testing:

1. FMEA (Failure Mode and Effects Analysis): Identifies possible failure modes, their
causes, and their potential effects on the system.

Example: If an EMS system update can affect payroll calculations, the failure in this
module might have high severity and needs priority testing.

2. Risk-Based Testing: This technique involves identifying and prioritizing test cases
based on the risk associated with different functionalities.

High-risk areas—those that are critical to business operations or have a history of

defects—are tested first.

3. Fault Tree Analysis (FTA): FTA is a top-down approach that starts with a potential
failure and works backward to identify the root causes. It helps in understanding the
relationships between different failures and their effects on the system.

Example: Analyzing why employee attendance is not syncing with payroll.

4. Decision Tree Analysis: Visualizes risk paths and their outcomes, allowing testers to
assess the consequences of different decisions.

5. Brainstorming: Gathers insights and opinions from team members to identify and
rank risks.
10) Classify in detail Risk Analysis and give examples from Email Application.

1. High Priority and Low Severity Bug

2. Low Priority and High Severity Bug.
Ans: Risks are generally classified based on two key factors:

Severity: The impact of a defect on the application.

○​ High Severity: Critical issues affecting core functionalities.

○​ Low Severity: Minor issues causing minimal disruption.

Priority: The urgency of fixing a defect.

○​ High Priority: Needs immediate attention due to business impact.

○​ Low Priority: Can be fixed later as it has minimal effect on the user experience.

Examples from an Email Application

1. High Priority and Low Severity Bug

Definition: A bug that must be fixed immediately (high priority) but has a minimal impact on the
application's functionality (low severity).

●​ Example from an Email Application:

○​ Bug: The company logo on the email application’s login page is misspelled or
displayed incorrectly.
○​ Reason: While this does not affect the functionality (low severity), it impacts the
brand image and user trust, requiring immediate correction (high priority).

2. Low Priority and High Severity Bug

A bug with a significant impact on the application's functionality (high severity) but does not
require immediate attention (low priority).

Example from an Email Application:

 ●​ Bug: A crash occurs when an edge case email with over 10,000 attachments is opened.
●​ Reason: The issue is severe as it results in a crash (high severity), but such edge cases
are rare and unlikely to affect the majority of users, making it low priority.

11) Explain how a risk matrix can be used to prioritize the test cases.

Ans: A Risk Matrix is a tool that helps in prioritizing the test cases by assessing and visualizing
the potential risks associated with different features or functionalities in the application. The
matrix combines the probability (likelihood) of a risk occurring with the impact of that risk on the
system, and it categorizes risks into different levels (e.g., low, medium, high).

Using a risk matrix for prioritization helps teams focus on the areas that are most likely to cause
major issues, thus optimizing testing efforts and resources.

●​ Construct a matrix with two axes: one for Likelihood (probability of a defect
occurring) and another for Impact (severity of the defect's consequences). Each
axis can be divided into categories such as Low, Medium, and High.

Assess Test Cases: Evaluate each test case against the defined risk factors. Assign it a
position in the matrix based on its likelihood and impact.

Prioritize Test Cases: Test cases that fall into the Critical Risk and High Risk categories
should be prioritized for execution. Conversely, test cases in the Low Risk category may
be deferred or executed later.
Iterative Review: As development progresses and new features are added or modified,
regularly review and update the risk matrix to reflect changes in risk levels associated
with different test cases.

Benefits of Using a Risk Matrix for Test Case Prioritization

1.​ Focused Testing Effort: Helps in directing testing efforts to areas that are most
likely to fail and have significant consequences.
2.​ Effective Resource Allocation: Ensures that critical areas receive the most
testing resources and attention.
3.​ Efficient Test Coverage: Maximizes test coverage by focusing on the most
impactful test cases first.
4.​ Reduced Testing Time: Minimizes time spent on low-risk areas, allowing faster
release cycles.

12) Illustrate the Risk Matrix in details and put the following as per category in
matrix:

Bug 1: User is not able to login

Bug 2: Name of the company on the website is wrong
Bug 3: In the email system, .pdf attachment is not working.

Ans: Bug Analysis

1.​ User is not able to login:

●​ Likelihood: High (This is a common issue that can occur due to various reasons
such as incorrect credentials, server issues, etc.)
●​ Impact: High (If users cannot log in, they cannot access their emails, which
severely affects usability and business operations.)
●​ Matrix Position: Critical Risk
2.​ Name of the company on the website is wrong:
●​ Likelihood: Medium (This might happen occasionally during updates or changes
to branding.)
●​ Impact: Low (While this could affect brand perception, it does not impact
functionality or user access.)
 ●​ Matrix Position: Low Risk
3.​ In email system, .pdf attachment is not working:
●​ Likelihood: Medium (This could occur due to various factors such as file size
limits or compatibility issues.)
●​ Impact: High (Not being able to send or receive PDF attachments can disrupt
business communication significantly.)
●​ Matrix Position: High Risk

13) How do we assign thresholds that group the potential problems into priority
categories?

Ans: Steps to Assign Thresholds for Risk Categorization

Identify Risk Criteria: Determine the criteria that will be used to evaluate risks, typically involving
two main factors: Likelihood (the probability of the risk occurring) and Impact (the severity of
the consequences if the risk occurs). Each factor can be rated on a scale (e.g., Low, Medium,
High).

Define Threshold Levels: Establish clear definitions for what constitutes low, medium, and high
levels for both likelihood and impact. For instance:Likelihood

Create a Risk Matrix: Develop a risk matrix that visually represents the relationship between
likelihood and impact. This matrix can help categorize risks into four quadrants:Critical Risk
(High Likelihood, High Impact)

Assign Risks to Categories: Evaluate each identified risk against the defined thresholds and
place them into the appropriate category within the risk matrix.

Review and Adjust Thresholds: Periodically review the thresholds based on project changes,
new information, or after incidents occur. Adjustments may be necessary to reflect the current
state of the project or organizational priorities.