1. What is Software Testing? Explain its Objectives.
oftware Testingis the process of evaluating and verifying that a software application or
S
system performs as expected. It involves executing a program to identify gaps, errors, or
unmet requirements compared to the desired outcomes.
Objectives of Software Testing:
.
1 etect Defects: Identify errors or issues in the software.
D
2. Ensure Quality: Ensure the software meets the quality standards.
3. Verify Functionality: Confirm that the software performs its intended functions.
4. Improve User Experience: Ensure the software is user-friendly and meets end-user
requirements.
5. Ensure Reliability: Verify that the software can operate without failure under given
conditions.
.
6 Validate Requirements: Confirm that the software meets the specified requirements.
7. Reduce Costs: Identify issues early to minimize the cost of fixing them later.
8. Ensure Security: Validate that the software is secure and protected from
vulnerabilities.
2. Software Testing Life Cycle (STLC)
heSoftware Testing Life Cycle (STLC)is a systematic process for performing software
T
testing. It involves multiple stages to ensure comprehensive testing of the application.
Phases of STLC:
1. Requirement Analysis:
○ Understand the testing requirements from stakeholders.
○ Identify testable and non-testable requirements.
○ Prepare Requirement Traceability Matrix (RTM).
2. Test Planning:
○ Define the scope, objectives, and approach of testing.
○ Allocate resources, tools, and schedules.
○ Create a test plan and estimate effort.
3. Test Case Development:
○ Create detailed test cases and scripts.
○ Define test data for each test case.
4. Environment Setup:
○ Prepare the required testing environment.
○ Ensure all tools, servers, and software dependencies are ready.
5. Test Execution:
Execute test cases in the defined environment.
○
○ Log defects in a defect management tool.
6. Test Closure:
○ Prepare test summary reports.
○ Assess test coverage and learn from issues.
Diagram of STLC:
equirement Analysis → Test Planning → Test Case Development → Environment Setup →
R
Test Execution → Test Closure
3. Notes on Key Terms
● E rror: A mistake made by a developer during software development that leads to
incorrect behavior or results.
● Defect: An issue in the software that deviates from its expected behavior or
requirements. Detected during testing.
● Failure: When the software fails to perform its intended function due to defects or
errors during execution.
4. Verification vs. Validation
Aspect Verification Validation
Definition rocess of ensuring the product is
P rocess of ensuring the product
P
built according to specified fulfills the intended user needs and
requirements and design. works as expected in real use.
Focus Are we building the productright? Are we building therightproduct?
Activity Type S
tatic (reviews, inspections, ynamic (actual execution of
D
walkthroughs). software).
erformed
P Before the testing phase. After the testing phase.
When
Output I ntermediate products like inal product is validated against
F
documents, design, or code are user requirements.
verified.
Example hecking whether a design
C hecking whether the application
C
document complies with performs well under various
requirements. conditions.
5. Characteristics That Lead to Testable Software
.
1 bservability: Clear visibility into internal states and output responses.
O
2. Control: Ability to set the software to specific states.
3. Decomposability: Modular design for isolating specific components for testing.
4. Simplicity: Avoid unnecessary complexity for better testability.
5. Understandability: Well-documented and self-explanatory design.
6. Stability: Minimal changes between versions to reduce retesting efforts.
7. Automatability: Support for automation tools and scripts.
6. Test Case Components and Template
Components of a Test Case:
.
1 est Case ID: Unique identifier.
T
2. Test Description: Summary of what the test case will validate.
3. Preconditions: Requirements that need to be fulfilled before execution.
4. Steps to Execute: Step-by-step instructions for execution.
5. Expected Result: The anticipated outcome.
6. Actual Result: The observed result during execution.
7. Status: Pass/Fail.
8. Remarks: Notes or observations.
Test Case Template:
est
T est
T Precondition teps to
S Expected Actua Statu Remark
Case Descriptio s Execute Result l s s
ID n Resul
t
C00
T erify login U
V ser must 1 . Enter ser
U User Pass N/A
1 functionali have valid username successfull logge
ty credentials 2. Enter y logs in in
d
password3
. Click
"Login"
7. Basis Path Testing
asis Path Testingis a white-box testing technique that ensures all possible execution paths
B
in a program are covered at least once. It is based on the program’s control flow graph (CFG).
Steps in Basis Path Testing:
1. Create a control flow graph.
. I dentify independent paths.
2
3. Calculate Cyclomatic Complexity:
V(G)=E−N+2V(G) = E - N + 2, where EE = edges and NN = nodes.
4. Derive test cases for each path.
5. Execute and verify the test cases.
8. Black-Box Testing (BBT) vs. White-Box Testing (WBT)
Aspect Black-Box Testing (BBT) White-Box Testing (WBT)
Definition esting the functionality of the
T esting internal logic, structure,
T
software without knowledge of its and implementation of the code.
internal code.
nowledge
K o programming knowledge
N equires programming
R
Required required. knowledge.
Focus alidates software behavior based Verifies code logic and structure.
V
on requirements.
Performed By Testers, end-users. Developers or specialized testers.
echniques
T quivalence partitioning,
E asis path testing, statement
B
Used boundary value analysis, decision coverage, branch coverage,
table testing. condition coverage.
Tools Selenium, QTP, TestComplete. JUnit, NUnit, SonarQube.
Example Testing login functionality. esting loops or conditional
T
statements in the login code.
