‭1. What is Software Testing? Explain its Objectives.

‭ oftware Testing‬‭is 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)‬

‭ he‬‭Software 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 product‬‭right‬‭?‬ ‭Are we building the‬‭right‬‭product?‬

‭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 Testing‬‭is 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.‬