MARATHAWADA MITRAMANDAL’S POLYTECHNIC,

THERGAON, PUNE-33
Academic Year

Prelim-3
Course Name: STE Model Answer Course Code: 22518

Q. Su Answer Marking
No b Scheme
. Q.
N.

1 A) Attempt all of the following: 10

a Write any two root causes of defect. 02

Answer:
1. Miscommunication of requirements introduces error in code
2. Unrealistic time schedule for development 1 for
each
3. Lack of designing experience point
4. Lack of coding practices experience (any
5. Human factors introduce errors in code two)
6. Lack of version control
7. Buggy third-party tools
8. Last minute changes in the requirement introduce error
9. Poor Software testing skill
b. Enlist any four software testing tools. 02

Answer:-
1. Test management tool ½ for
2. Bug tracking tool each(an
3. Automated testing tool y four)
4. Performance testing tool
5. Cross-browser testing tool
6. Integration testing tool
7. Unit testing tool
8. Mobile/android testing tool
9. GUI testing tool
10. Security testing tool
c Define test plan with two advantages. 02

Answer: -

1. Overview of Testing Activities: The test plan provides a comprehensive overview of all
testing activities, outlining where to begin and when to conclude the work. 1 for
2. Timeline Creation: It facilitates the development of a timeline for testing activities, each(an
allowing teams to allocate time based on estimated hours and workforce needed. y two)
3. Resource Estimation: The test plan assists in estimating the number of resources required
to complete the testing process efficiently.
4. Blueprint for Testing Activities: Serving as a detailed blueprint, the test plan
encompasses every aspect of testing from initiation to completion.
1
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

5. Problem Identification and Solutions: A well-structured test plan helps team members
proactively identify potential challenges within the project and develop solutions.
6. Rulebook for Execution: The test plan functions as a rulebook that outlines guidelines
and best practices to follow during each phase of the project.

d State any two difference between manual and automated testing. 02

Answer:
Aspect Manual Testing Automated Testing
Execution of Test Cases Executed by human testers Executed by software tools 1 for
each(an
Time Consumption Time-consuming Faster than manual testing y two)
Requires automation tools
Resource Usage Takes up human resources
and trained staff
Not as reliable due to human More reliable due to
Reliability
errors automated tools and scripts
Difficult or impractical for Effective for performance
Performance Testing
performance testing testing (load, stress testing)
No need for programming Requires programming
Programming Knowledge
knowledge knowledge

e State any four defect reporting guidelines. 02

Answer:
1. Be Specific:
Specify the exact action (e.g., "Click ButtonB" instead of "Select ButtonB").
State the exact path taken (e.g., "Do ‘A and X’ to get D").
½ for
Avoid vague pronouns by clarifying what they refer to.
each(an
2. Be Detailed: y four)
Include all relevant information without omitting anything.
3. Be Objective:
Stick to factual statements and avoid subjective opinions.
4. Reproduce the Defect:
Replicate the defect consistently before reporting it.
5. Review the Report:
Proofread for typos before submitting the report.

Q 1 Attempt all of the following: 20

2

2
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

a) Enlist any four attributes of defect. Describe them with suitable example. 04

Answer:-
• Defect ID: A unique identifier for each defect, as there can be many defects identified
in the system (e.g., D1, D2, etc.).
• Defect Name: A brief and descriptive name for the defect (e.g., "Login Error").
• Project Name: The name of the project in which the defect is found.
• Module/Sub-module Name: The specific module or sub-module where the defect is
identified.
• Defect Type: The classification of the defect (e.g., security defect, functional defect,
GUI defect, etc.).
• Severity: The impact level of the defect, usually declared in the test plan (e.g., high,
medium, low).
• Priority: The order in which defects are scheduled for fixing, based on project For
decisions. Attribut
• Summary: A concise description of the defect. es 2
Marks
• Description: A detailed explanation of the defect.
and for
• Status: A dynamic field that indicates the current state of the defect (e.g., open, example
assigned, resolved, closed, on hold, deferred, or reopened). 2 marks.
• Reported By/Reported On: The name of the person who reported the defect and the
date it was reported.
• Assigned To: The team member to whom the defect is assigned for resolution.
Example:

• Defect ID: D1234

• Defect Name: Password Reset Error
• Project Name: Online Banking System
• Module/Sub-module Name: User Account Management
• Defect Type: Functional Defect
• Severity: High
• Priority: Urgent
• Summary: Users are unable to reset their passwords through the password recovery
feature.
• Description: When users attempt to reset their passwords using the "Forgot
Password?" link, they receive an error message stating, "An unexpected error
occurred." The issue has been replicated on multiple browsers (Chrome, Firefox) and
affects all user accounts.
• Status: Open
• Reported By/Reported On: Reported by Jane Doe on November 15, 2022.
• Assigned To: John Smith (Backend Development Team)

b. Describe defect life cycle with neat diagram. 04

3
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

Answer:-
DEFECT LIFE CYCLE (Bug Life cycle) is the journey of a defect from its identification to its
closure. The Life Cycle varies from organization to organization and is governed by the software
testing process the organization or project follows and/or the Defect tracking tool being used. Diagra
m: 2M
Explana
1. New: The bug is reported for the first time and not yet approved. -tion:
2. Open: The lead tester approves the bug as genuine, changing its status to "OPEN." 2M
3. Assigned: The bug is assigned to a specific developer or team, and its status changes to
"ASSIGNED."
4. Test/Retest: After the developer fixes the bug, the status is changed to "TEST" for the
testing team to verify the fix.
5. Deferred: The bug is postponed for future releases due to low priority or minimal impact,
changing its status to "DEFERRED."
6. Rejected: If the developer determines the bug is not valid, its status is changed to
"REJECTED."
7. Verified: The tester confirms the bug is fixed, changing its status to "VERIFIED."
8. Reopened: If the bug persists after being marked as fixed, the tester changes its status to
"REOPENED."
9. Closed: The bug is confirmed as fixed and tested, so the status changes to "CLOSED."
10. Fixed: The developer marks the bug as "FIXED" after making necessary changes.
11. Pending Retest: The bug is awaiting retesting by the testing team after being fixed.

4
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

c What do you mean by ‘Defect impact’? Explain how to estimate the defect impact. 04

Answer:-
Defect impact refers to the degree of severity that a defect (or bug) has on the development,
performance, or operation of a component or system. It assesses how much the defect affects the
functionality, reliability, and overall quality of the software or system in question. Understanding
defect impact is crucial for prioritizing fixes, managing risks, and ensuring a reliable and user-
friendly product.
04

How to Estimate Defect Impact

5
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

1. Identify Critical Risks:

o Identify and categorize potential defects that could significantly impact system
performance, usability, or quality.
2. Estimate Financial Impact:
o Quantify the financial impact of each risk in monetary terms, including costs like
lost revenue and remediation efforts.
3. Assess Probability:
o Determine the probability (P) of each risk occurring, using historical data or expert
judgment.
4. Calculate Expected Impact:
o Calculate the expected impact (E) as:
E=P×I
where:
▪ P = probability (as a decimal)
▪ I = financial impact in dollars if the risk occurs.
5. Prioritize Risks:
o Rank risks based on their expected impact to focus on the most significant threats
to project success.
6. Consider Risk Mitigation:
o Evaluate how much the expected impact can be reduced through strategies like
avoidance or reduction.
7. Assess Overall Risk Management:
o Acknowledge that estimating involves some guesswork, but focus on identifying
risks and prioritizing actions to minimize their occurrence.

Example: Estimating Defect Impact for a Web Application

An organization is developing a web application that has 1,000 function points and estimates a
high level of defect discovery and removal.
Potential Defects Calculation:
The estimated potential defects are calculated as follows:
Potential Defects = Function Points × Defect Rate

6
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

Potential Defects =1,000 × 1.5 = 1,500

Defect Removal:
If the organization can remove approximately 60% of the defects:
Removed Defects=1,500 × 0.60 = 900
Remaining Defects:
The remaining defects after removal activities would be:
Remaining Defects = Potential Defects − Removed Defects
Remaining Defects = 1,500 – 900 = 600
d) Explain defect management process with suitable diagram. 04

Answer:-

The process of finding defects and reducing them at the lowest cost is called as Defect Diagra
Management Process. m: 2M
Explana
-tion:
2M

• Defect Prevention -- Implementation of techniques, methodology and standard processes

to reduce the risk of defects.

• Deliverable Baseline -- Establishment of milestones where deliverables will be

considered complete and ready for further development work. When a deliverable is base
lined, any further changes are controlled. Errors in a deliverable are not considered defects
until after the deliverable is base lined.
• Defect Discovery -- Identification and reporting of defects for development team
acknowledgment. A defect is only termed discovered when it has been documented and
acknowledged as a valid defect by the development team member(s) responsible for the

7
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

component(s) in error.
• Defect Resolution -- Work by the development team to prioritize, schedule and fix a
defect, and document the resolution. This also includes notification back to the tester to
ensure that the resolution is verified.
• Process Improvement -- Identification and analysis of the process in which a defect
originated to identify ways to improve the process to prevent future occurrences of similar
defects. Also the validation process that should have identified the defect earlier is
analyzed to determine ways to strengthen that process.
• Management Reporting -- Analysis and reporting of defect information to assist
management with risk management, process improvement and project management.

e. Explain test management with Test Infrastructure Management and Test People Management 04

Answer:-

Test Management is a critical aspect of software quality assurance, ensuring that new or modified service
04
products meet the business requirements for which they have been developed or enhanced. This process
encompasses managing both test resources and test environments effectively.

Key Components of Test Management

1. Test Infrastructure Management
Testing requires a robust infrastructure, which should be planned upfront. This infrastructure comprises
three essential elements:
• A test case database (TCDB): A test case database captures all the relevant information about the
test cases in an organization. Some of the entities and the attributes are given in the following table
Sr. No. Test Case Purpose Attributes
1 Test Case - Test Case ID
- Test Case Name (File Name)
- Test Case Owner
- Associated Files for Test Case
2 Test Case Product Cross Reference - Test Case ID
- Module ID
3 Test Case Run History - Test Case ID
- Run Date
- Time Taken
- Run Status (Success/Failure)

8
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

4 Test Case Defect Cross Reference Test Case ID

- Defect Reference

• Defect Repository: It captures relevant details of defects. It is a tool of communication. Defects

matrices are derived from defect repository.
• Configuration management repository and tools: They keep track of change control of all the
files/entities that make up a software product. They keep track of version control of all files/entities
that makeup a software product.
2. Test People Management
People management is an integral part of project management and test planning. It requires the ability to
hire, motivate, and retain the right personnel, skills that are seldom formally taught. Testing projects
present several additional challenges. The success of a testing organization depends vitally on judicious
people management skills.
Test Lead Responsibilities and Activities:
• Identify how the test teams are formed and aligned within the organization.
• Decide the roadmap for the project.
• Identify the scope of testing using Software Requirements Specification (SRS) documents.
• Discuss the test plan and review it for approval by management and the development team.
• Identify required metrics.
• Calculate the size of the project and estimate efforts and corresponding plans.
• Identify skill gaps and balance resources with the need for training and education.
• Identify the tools for test reporting, test management, and test automation.
• Create a healthy environment for all resources to gain maximum throughput.
Test Team Responsibilities and Activities:
• Initiate the test plan for test case design.
• Conduct review meetings.
• Monitor test progress, check resource allocation, and balance workloads.
• Address delays in the schedule, discussing and resolving any risks that may arise.

Q 20
Attempt all of the following:
3

A Define metrics and measurements. State the different metrics types with its
classification.

9
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

Answer:-
1M
• Metrics: A metric is a relative measurement that reflects the status of a process or product each
by comparing two or more entities. It provides a quantitative way to evaluate aspects of Def
software development, such as quality, productivity, or performance, at different stages of
the project. 2 M for
• Measurements: Measurements are the specific values or quantities collected for a Clasfcti
particular metric. These are key elements used to control software engineering processes, on
as they provide data for analysis, decision-making, and process improvements.

Classification of Metrics

Metrics in software engineering can be classified into several types. The main categories are:

o Product Metrics: These measure various attributes of the software product at different
stages of development, such as its design, code, and final implementation. Product
metrics can be used to assess product quality, reliability, maintainability, and
performance.

• Product Metrics can be further classified as:

o Project Metrics: These metrics provide insights into how the software project is
planned, executed, and managed. Examples might include budget adherence,
timeline estimates, and resource allocation.

o Progress Metrics: These metrics track how different activities or phases of the
project are progressing. This can include monitoring milestones, deliverables, and
task completion rates.

• Progress Metrics can be subdivided into:

▪ Test Defect Metrics: These metrics help the testing team evaluate the
quality of the software product by tracking defects discovered during
testing. They assist in assessing the effectiveness of testing and identifying
areas for improvement.

▪ Development Defect Metrics: These metrics help the development team

analyze defects during the development phase, such as bug frequency,
severity, and resolution time. They support process improvement and
code quality enhancement.

o Productivity Metrics: These metrics assess the productivity of the development and
testing teams. They help in evaluating the efficiency of the team, resource utilization, and
10
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

overall performance. Examples include lines of code per developer, defects per test case,
or test execution time per feature.

o Process Metrics: These metrics measure the software development process itself,
focusing on aspects like the time it takes to complete various activities, the methodology
used, and the level of experience of the team members. Examples include cycle time,
defect density, and code review effectiveness.

b. Draw defect prevention process cycle. State working of each phase. 04

Diagra
Answer:- m: 2M
The Defect Prevention Process is a proactive approach to identify and eliminate defects early in Explana
-tion:
the software development lifecycle (SDLC). This process emphasizes addressing root causes
2M
rather than just fixing defects after they have occurred. The goal is to reduce the likelihood of
defects being introduced and, if they are introduced, to detect them early when they are easier
and cheaper to fix.

Phases of Defect Prevention

1. Identify Critical Risks

o Objective: Identify the critical risks that could potentially affect the success of the
project or system. These risks are typically defects that could jeopardize the
project’s construction, delivery, or operation.

o Action: Conduct risk assessments, identify high-impact risks, and prioritize them
based on the likelihood of occurrence and their potential impact on the project.

2. Estimate Expected Impact

o Objective: For each identified critical risk, assess its financial and operational
impact if the risk materializes. This allows teams to understand the severity of
each risk and its potential consequences on the project.

o Action: Perform a risk assessment that includes financial, time, and resource
impact to evaluate the seriousness of each risk.

3. Minimize Expected Impact

o Objective: Once the most critical risks are identified, the goal is to either

11
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

eliminate the risk entirely or reduce the likelihood of it occurring and mitigate its
potential impact.

o Action: Apply corrective actions, such as process improvements, best practices, or

technology changes, to reduce the risk. If full elimination is not possible, take
steps to minimize its impact.

C 4
Explain test reporting with executing test cases and preparing test summary report.

4M
Test Reporting is a critical aspect of software testing, as it provides insights into the testing
process, results, and the quality of the software under test. It helps stakeholders (e.g.,
developers, managers, and customers) understand the test coverage, test results, and any issues
discovered during testing. Proper reporting ensures transparency, effective communication, and
better decision-making.

Test Reporting typically consists of:

1. Executing Test Cases

2. Preparing the Test Summary Report

Test Case Execution:

• Test execution involves running predefined tests to check the software’s functionality,
performance, and other critical aspects.

• Testers must ensure the testing environment is correctly set up and that all test cases are
ready for execution.

• During this phase, testers follow the steps outlined in each test case, documenting the
results as pass or fail, and capturing any defects, discrepancies, or unexpected behaviors
that arise.

12
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

• Important metrics such as the number of test cases executed, pass/fail rates, defect
severity, and the time taken for each test are recorded, providing essential data for
reporting.

Test Summary Report:

• The test summary report is created after test execution to consolidate the results into a
structured document.

• This report typically includes an overview of the testing activities, objectives, and scope,
along with a summary of how many test cases passed, failed, or were blocked.

• It also provides a detailed defect summary, which covers defect severity and any patterns
observed during testing.

• The report highlights test coverage, including the percentage of planned test cases
executed and the code covered by the tests.

• Additionally, it mentions any open issues, risks, or limitations that arose during testing.

• In the conclusion, the report summarizes the overall testing status, whether the software
is ready for release, and offers recommendations for improvement.

D 4
Explain test case specification.

4M
Test case specifications are developed from the test plan and represent the second phase of the
test development life cycle. These specifications detail how the test cases, outlined in the test
plan, should be implemented. Test case specifications are essential because they clearly outline
the specification details of the items involved in testing.

The Test Case Specification should contain the following items:

1. Case No.:

o A unique three-digit identifier in the format c.s.t, where:

▪ c is the chapter number,

▪ s is the section number,

▪ t is the test case number.

This number helps in organizing and referencing test cases systematically.

13
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

2. Title:

o A brief, descriptive title of the test case.

3. Programme:

o The program or module name where the test will be executed.

4. Author:

o The name of the person who wrote the test case specification.

5. Date:

o The date of the last revision or update made to the test case.

6. Background (Objectives, Assumptions, References, Success Criteria):

o This section describes how to conduct the test and includes the test objectives,
assumptions made during testing, any references (such as documentation or
standards), and success criteria that define the test's expected outcome.

7. Expected Error(s):

o A description of any potential errors or failures expected during testing.

8. Reference(s):

o Lists any reference documentation or materials used to design the test

specification, such as requirements, design specifications, or standards.

9. Data (Tx Data, Predicted Rx Data):

o Describes the data involved in the test, including transmit (Tx) data and predicted
receive (Rx) data, which define the flow of information between the
Implementation Under Test (IUT) and the test engine.

10. Script (Pseudo Code for Coding Tests):

• Pseudo code or actual code that is used to conduct the test. It outlines the steps or logic
for automating or performing the test.

E 4
List the different techniques to detect defects. Describe any two of them.

4M
Defects in software can be detected through various techniques. These techniques are generally

14
 MARATHAWADA MITRAMANDAL’S POLYTECHNIC,
THERGAON, PUNE-33
Academic Year

categorized into three types based on their approach:

1. Preplanned Activities: Techniques specifically intended to uncover defects through

structured processes, such as inspections, reviews, and testing.

2. Accidental Detection: Defects found unexpectedly, such as by users encountering issues

during production or in real-world scenarios.

Categories of Techniques to Find Defects:

1. Static Techniques:
o These techniques involve testing the software without executing the program or
system.
o Examples include code reviews, static analysis, and walkthroughs. These
methods identify defects by analyzing the code, documentation, or requirements
before the software is run.
2. Dynamic Techniques:
o In these techniques, the system or its components are physically executed to
identify defects during runtime.
o Test case execution is an example of a dynamic technique, where the system is
tested by running various test scenarios to check for errors or unexpected
behavior.
3. Operational Techniques:
o These involve defects being identified in a live operational environment when
users, customers, or control personnel encounter failures.
o Defects are typically discovered post-deployment, often as a result of real-world
failures or user feedback.

15