STQA – Software Testing & Quality Assurance Notes

Unit 1 · 20% · 8 Sessions

Software Quality Assurance Fundamentals

Quality · QA vs QC · ISO 9000 · SQA Planning · Reliability · ROCOF · MTTF · MTTR

1.1 · Quality, Quality Assurance & Quality Control

▾

What is it?

Quality means a product meets the requirements and expectations of the user without defects. In software, it means the application does what it is supposed to do — reliably, efficiently, and securely.

Quality Assurance (QA) is a process-oriented activity — it ensures the right processes are followed during development to prevent defects from appearing.

Quality Control (QC) is a product-oriented activity — it finds defects in the finished product through testing and inspection.

Detailed Explanation

Quality has two dimensions: Fitness for Purpose (does it do what users need?) and Conformance to Requirements (does it match the specification?).

QA focuses on the SDLC process. Activities: code reviews, audits, defining standards, process improvements. QA is preventive — stop bugs before they happen.

QC focuses on the final output. Activities: running tests, finding bugs, logging defects. QC is corrective — detect and fix bugs after they appear.

Key difference: QA is about process; QC is about the product. QA prevents defects; QC detects defects. QA is everyone's responsibility; QC is done by testers.

Real World Example

// CloudKitchen+ Example
// QA Activity: Define coding standards for payment module
policy: All payment functions MUST have unit tests (≥ 90% coverage)
policy: Code review mandatory before merging payment code
policy: Security audit on every sprint for transaction features

// QC Activity: Test the actual payment feature
// Test Case: Pay for an order of ₹450 using UPI
Input: Order total = ₹450, Payment method = UPI
Expected: Payment success, order confirmed, receipt generated
Actual: Payment success ✓ → QC PASSED

🍕 CloudKitchen+ Reference In CloudKitchen+, QA means defining standards like "every API must be documented" and "no code merged without review." QC means the actual testing team checking if the checkout flow works, if promo codes apply correctly, and if order status updates in real-time.

1.2 · SQA Planning & ISO 9000 Standards

▾

What is it?

SQA Planning is creating a roadmap that describes how quality will be achieved, monitored, and maintained throughout the software project.

ISO 9000 is an international standard for quality management systems. ISO 9001 specifically covers requirements for a QMS (Quality Management System) — it ensures organisations consistently deliver quality products.

Detailed Explanation

SQA Plan includes: Purpose of the plan, list of documents to be produced (SRS, design doc, test plan), standards to be followed, reviews and audits to be conducted, tools to be used, risk management approach.

ISO 9000 Family:

ISO 9000: Vocabulary and fundamentals
ISO 9001: Requirements for QMS (most widely used)
ISO 9004: Guidance for improving QMS performance

ISO 9001 Principles: Customer focus, Leadership, Engagement of people, Process approach, Improvement, Evidence-based decision making, Relationship management.

Real World Example

CloudKitchen+ SQA Plan Outline:
──────────────────────────────────────
Purpose         : Ensure app quality across all 5 sprints
Documents       : SRS, API docs, Test Plan, Release Notes
Standards       : ISO 9001, IEEE 829 for test docs
Reviews         : Sprint review (every 2 weeks)
Audits          : Monthly security audit on payment module
Tools           : JIRA (bug tracking), Selenium (automation)
Risk            : 3rd-party payment API failure → mock fallback

🍕 CloudKitchen+ Reference For ISO 9001 compliance, CloudKitchen+ maintains documented processes for how orders are processed, how customer complaints are handled, and how delivery partner integrations are tested. During an audit, the company shows these documented processes as evidence of quality management.

1.3 · SQA Activities

▾

What is it?

SQA Activities are the specific tasks performed throughout the SDLC to ensure quality is built into the software at every stage, not just tested at the end.

Detailed Explanation

Key SQA Activities:

Requirements Analysis: Check SRS for completeness and clarity
Design Review: Check if design meets architectural standards
Code Review / Walkthrough: Peer inspection of code
Testing: Unit, Integration, System, UAT
Defect Tracking: Log, assign, track, and close bugs
Configuration Management: Version control, change tracking
Process Audit: Verify team follows defined processes
Metrics Collection: Defect density, test coverage, etc.

Real World Example

CloudKitchen+ Sprint 1 SQA Activities:
Week 1: Requirements review meeting → 3 ambiguous requirements found & clarified
Week 2: Design review of payment module → Identified missing error handling
Week 3: Code walkthrough → Found SQL injection vulnerability in promo code input
Week 4: Unit testing → 45 tests written, 3 failed → fixed
Week 5: Defect tracked in JIRA → Bug #CK-101: "Order total wrong with combo offer"

1.4 · Building Blocks of SQA & 1.5 Software Quality Factors

▾

What is it?

Building Blocks of SQA are the core components that form the foundation of any SQA program. Quality Factors are measurable characteristics that determine how good the software is.

Detailed Explanation

Building Blocks of SQA:

Pre-project activities: Feasibility study, contract review
Project lifecycle activities: Reviews, testing at each phase
Infrastructure: Standards, tools, training
Management: Project management, configuration management

McCall's Quality Factors (most important for exams):

Correctness: Does it do what is required?
Reliability: Does it perform consistently without failure?
Efficiency: Does it use minimum resources?
Integrity: Is it secure from unauthorised access?
Usability: Is it easy to learn and use?
Maintainability: Can it be easily modified?
Testability: Can it be easily tested?
Portability: Can it run on different platforms?
Reusability: Can components be reused?
Interoperability: Can it work with other systems?

🍕 CloudKitchen+ Quality Factors Reliability: App handles 10,000 concurrent orders without crash. Efficiency: Menu loads in <2 seconds. Security/Integrity: Payment data encrypted with AES-256. Portability: Works on Android, iOS, and Web. Usability: Customer can place order in 4 taps.

1.6 · Software Reliability & Metrics (ROCOF, MTTF, MTTR, MTBF, POFOD, Availability)

▾

What is it?

Software Reliability is the probability that a software system will work correctly for a specified period under specified conditions. Reliability metrics measure how often software fails and how quickly it recovers.

Detailed Explanation

ROCOF (Rate Of OCcurrence Of Failures): Number of failures per unit time. Example: 3 failures/hour. Lower is better.
MTTF (Mean Time To Failure): Average time the system works before it fails. MTTF = 1/ROCOF. Example: If ROCOF = 0.02/hr, MTTF = 50 hours.
MTTR (Mean Time To Repair): Average time taken to fix the system after failure. Lower MTTR = better recovery.
MTBF (Mean Time Between Failures): MTBF = MTTF + MTTR. Average time between one failure and the next.
POFOD (Probability Of Failure On Demand): Probability that the system will fail when a request is made. Example: POFOD = 0.001 means 1 in 1000 requests may fail.
Availability: Proportion of time the system is available.
Formula: Availability = MTTF / (MTTF + MTTR)
Example: MTTF=200hr, MTTR=5hr → Availability = 200/205 = 97.6%

Real World Example

CloudKitchen+ Payment Gateway — Monthly Stats:
─────────────────────────────────────────────
Total failures in 30 days   : 6
Total uptime hours          : 720 hours
ROCOF = 6/720               = 0.0083 failures/hour
MTTF  = 1/ROCOF             = 120 hours
MTTR  (avg fix time)        = 2 hours
MTBF  = MTTF + MTTR         = 122 hours
Availability = 120/(120+2)  = 98.36%
POFOD: In 10,000 transactions, 3 failed → 0.0003

SLA Target: 99.9% availability → Team needs to improve!

🍕 CloudKitchen+ Reference The payment gateway must have 99.9% availability (MTTR must be less than 45 min). The order tracking service has POFOD of 0.0001. These metrics are monitored on the ops dashboard and trigger alerts if thresholds are breached.

📊 Unit 1 — Easy Comparison Topics

Aspect	QA (Quality Assurance)	QC (Quality Control)
Focus	Process	Product/Output
Goal	Prevent defects	Detect defects
When	Throughout SDLC	After development
Who	Everyone on team	Testing team
Example	Code review policy	Running test cases

Metric	Full Form	Meaning	Good value
MTTF	Mean Time To Failure	How long before it fails	Higher ↑
MTTR	Mean Time To Repair	How fast it is fixed	Lower ↓
MTBF	Mean Time Between Failures	MTTF + MTTR	Higher ↑
ROCOF	Rate Of Occurrence Of Failures	Failures per hour	Lower ↓
POFOD	Probability Of Failure On Demand	Chance of failing per request	Lower ↓
Availability	—	MTTF/(MTTF+MTTR)	Close to 1 ↑

Unit 2 · 20% · 10 Sessions

Software Testing Fundamentals

Testing Principles · STLC · V-Model · Levels of Testing · Test Types · Smoke & Sanity

2.1–2.3 · Definition, Objectives & Error / Bug / Fault / Failure

▾

What is it?

Testing is the process of executing a program to find errors. The goal is NOT to prove the software works, but to find where it does NOT work.

Error → Bug → Fault → Failure Chain

Error (Mistake): A human mistake made by a developer while coding. Example: Developer types price * 1.18 instead of price * 1.05 for GST.
Fault/Defect (Bug): The error stored in the code/document. The wrong line of code sitting in the program.
Failure: When the fault is executed and the system produces wrong output. Customer sees wrong bill amount.

🍕 CloudKitchen+ Example Error: Developer writes wrong discount formula. Fault: Wrong code sits in promo module. Failure: Customer applies 20% coupon but gets only 10% discount → Complaint raised.

2.5 · Seven Testing Principles

▾

What is it?

These are the 7 fundamental rules that guide all professional software testing. They are part of the ISTQB (International Software Testing Qualifications Board) standard.

The 7 Principles

1. Testing shows presence of defects: Testing can prove bugs exist, but cannot prove software is bug-free.
2. Exhaustive testing is impossible: You cannot test all input combinations. Use risk-based testing.
3. Early testing saves cost: Find bugs in requirements phase, not after deployment. Cost of fixing grows 10x per phase.
4. Defect clustering: 80% of bugs are found in 20% of modules (Pareto principle). Focus on high-risk modules.
5. Pesticide paradox: Running the same tests repeatedly stops finding new bugs. Regularly update test cases.
6. Testing is context-dependent: Testing an ATM app is different from testing a gaming app.
7. Absence of errors fallacy: Even if testing finds no bugs, it doesn't mean the product is useful. It must meet user needs.

🍕 CloudKitchen+ — Principle 4 (Defect Clustering) In CloudKitchen+, 70% of all bugs were found in the payment module and order management module. The team applied extra testing effort there — more test cases, security scans, and load testing — rather than spending equal time on the static menu display pages.

2.6 · Software Testing Life Cycle (STLC)

▾

What is it?

STLC is the sequence of activities performed during the testing process. Just like SDLC defines how software is built, STLC defines how software is tested.

6 Phases of STLC

1. Requirement Analysis: Understand what needs to be tested. Identify testable and non-testable requirements.
2. Test Planning: Create Test Plan — scope, resources, timeline, tools, risk.
3. Test Case Development: Write detailed test cases and test scripts.
4. Test Environment Setup: Prepare servers, databases, tools, and test data.
5. Test Execution: Run tests, log results, report defects.
6. Test Closure: Test summary report, lessons learned, metrics analysis.

Real World Example

CloudKitchen+ Order Feature — STLC:
Requirement Analysis : "Customer places order" → 15 test scenarios identified
Test Planning        : 3 testers, 2 weeks, Selenium + Postman tools
Test Cases           : 80 test cases written (positive + negative)
Environment Setup    : Staging server deployed, test database seeded with 100 kitchens
Test Execution       : 72 passed, 8 failed → 8 bugs logged in JIRA
Test Closure         : Test Summary Report: 95% pass rate, 2 critical bugs fixed

2.7 · V-Model & W-Model

▾

What is it?

The V-Model (Verification & Validation Model) is a development model where each development phase has a corresponding testing phase. It's shaped like the letter "V".

V-Model Structure

Development (Left Side)         Testing (Right Side)
─────────────────────────────────────────────────────
Requirements Analysis    ←───→   Acceptance Testing (UAT)
System Design            ←───→   System Testing
Architecture Design      ←───→   Integration Testing
Module Design            ←───→   Unit Testing
         ↓
       Coding (Bottom)
─────────────────────────────────────────────────────
Verification: Are we building it right? (review docs)
Validation:   Are we building the right thing? (testing)

W-Model: An improvement over V-Model where testing activities run in parallel with development, not after. Both form a "W" shape together.

🍕 CloudKitchen+ V-Model Requirements: "User can track order" → UAT tests written NOW. System Design: Architecture for tracking service → System tests planned. Module Design: GPS module specs → Unit tests written. Coding begins at bottom. Then right side executes.

2.9 · Levels of Testing (Unit, Integration, System, UAT)

▾

What is it?

Testing happens at four levels, starting from individual code components and going up to the complete system. Each level has a different scope and objective.

The 4 Levels

Unit Testing: Test individual functions or modules in isolation. Done by developers. Tools: JUnit, PyTest, Jest.
Integration Testing: Test how modules work together. Check data flow between components. Approaches: Top-down, Bottom-up, Big-bang, Sandwich.
System Testing: Test the complete integrated system against requirements. Done by independent testers. Covers functional + non-functional testing.
UAT (User Acceptance Testing): End-users test the system to verify it meets business needs before go-live. Final gate before release.

Real World Example

CloudKitchen+ — 4 Levels:

Unit Test (Developer):
  → Test: calculateTotal(items=[Burger₹120, Fries₹60], discount=10%)
  → Expected: ₹162, Got: ₹162 ✓

Integration Test (Tester):
  → Order module + Payment module working together?
  → Place order → redirect to payment → confirm → update DB ✓

System Test (QA Team):
  → Full flow: Register → Browse kitchens → Add to cart → Pay → Track → Deliver
  → Non-functional: Load test with 5000 concurrent users

UAT (Restaurant Owner / Customer):
  → Real kitchen manager logs in and manages menu
  → Real customer places first order end-to-end

📊 Unit 2 — Easy Comparison Topics

Level	Who Tests	What is Tested	When
Unit	Developer	Single function/module	During coding
Integration	Tester/Dev	Module interactions	After unit testing
System	QA Team	Whole system	After integration
UAT	End User	Business scenarios	Before release

Aspect	Smoke Testing	Sanity Testing
Also called	Build verification test	Subset regression test
Scope	Broad – entire application	Narrow – specific functionality
When	After new build received	After a bug fix / minor change
Goal	Is build stable enough to test?	Is the specific fix working?
Depth	Shallow (surface level)	Deep (focused area)

Aspect	V-Model	Agile/TDD
Testing starts	After coding complete	Before coding (test first)
Documentation	Heavy	Light
Flexibility	Low – sequential	High – iterative
Best for	Stable, well-defined projects	Changing requirements

Unit 3 · 20% · 9 Sessions

Static & Dynamic Testing

Reviews · Walkthrough · Inspection · Black Box · White Box · Mutation · Exploratory

3.1 · Static Techniques — Reviews (Informal, Formal, Walkthrough, Inspection)

▾

What is it?

Static testing means examining the code or documents WITHOUT executing the program. You find bugs by reading, reviewing, and analyzing — not by running the software.

Types of Reviews

Informal Review: Casual review with no defined process. Developer asks colleague to look at code. No documentation required. Fast and cheap.
Walkthrough: Author explains the document/code to a group. Team asks questions. No formal entry/exit criteria. Goal: education + find issues.
Technical/Peer Review: Structured review by peers. Checklist-based. Moderator leads. Results documented.
Formal Inspection (Fagan Inspection): Most rigorous. 6 phases: Planning → Overview → Preparation → Meeting → Rework → Follow-up. Metrics tracked. Defect rates measured.

Real World Example

CloudKitchen+ Code Review Scenario:
──────────────────────────────────────────────────
Informal Review:
  Dev A: "Hey, can you glance at my payment validation code?"
  Dev B: "You're not checking for negative amounts!" → Fixed immediately.

Walkthrough:
  Lead developer presents new order management module to team (30 min)
  Team asks: "What happens if kitchen is offline when order arrives?"
  Lead: "Oh, I didn't handle that." → Added to backlog.

Formal Inspection:
  6-person review of security module
  Phase 1 Planning: 2 days prep
  Phase 3 Preparation: Each reviewer checks 200 LOC
  Phase 4 Meeting: 47 defects found in 90 minutes
  Phase 5 Rework: All fixed, verified in follow-up

🍕 CloudKitchen+ Reference A formal inspection of the payment integration code found 12 security vulnerabilities before any code was deployed. Cost: 4 hours of team time. If found in production: potential data breach and loss of customer trust. ROI = enormous.

3.3 · Black Box Testing Techniques (Equivalence Partitioning, BVA, Decision Table, State Transition)

▾

What is it?

Black Box Testing tests the software from the user's perspective — we know WHAT the software should do, but not HOW it does it internally. We test inputs and outputs only.

Techniques

1. Equivalence Partitioning (EP): Divide input data into groups (partitions) where all values in a group should behave the same. Test one value from each partition.

CloudKitchen+ Exam Score Example (from Q-Paper):
Score range: 0 to 40. Pass = 24+.
Partitions:
  Invalid LOW  : < 0      (e.g., -5)
  Valid FAIL   : 0–23     (e.g., 10)
  Valid PASS   : 24–40    (e.g., 30)
  Invalid HIGH : > 40     (e.g., 50)
→ Minimum test cases needed: 4 (one per partition)

2. Boundary Value Analysis (BVA): Bugs tend to hide at boundaries. Test values AT, just below, and just above each boundary.

BVA for same score field (0 to 40):
Boundaries: 0, 1, 23, 24, 39, 40
Test: -1 (invalid), 0 (min), 1 (min+1), 23 (fail boundary), 
      24 (pass boundary), 39 (max-1), 40 (max), 41 (invalid)

3. Decision Table Testing: For features with multiple conditions combined. List all combinations of conditions and corresponding actions.

4. State Transition Testing: Test systems that behave differently based on current state. Draw a state diagram and test all transitions.

CloudKitchen+ Order States:
PLACED → ACCEPTED → PREPARING → OUT_FOR_DELIVERY → DELIVERED
                              → CANCELLED (valid from PLACED and ACCEPTED only)
Test: Can a DELIVERED order be cancelled? → Should be REJECTED.

3.4 · White Box Testing (Statement, Branch, Path, Cyclomatic Complexity, Data Flow, Mutation)

▾

What is it?

White Box (Glass Box) Testing tests the internal structure and logic of the code. The tester can see the source code and designs tests to cover code paths.

Coverage Types

Statement Coverage: Every line of code must be executed at least once. 100% SC = all lines run.
Branch/Decision Coverage: Every branch (if-true and if-false) must be executed. Stronger than SC.
Path Coverage: Every independent path through the code must be tested. Most thorough but can be exponential.
Data Flow Testing: Tests paths from where a variable is defined to where it is used. Finds variable misuse bugs.
Mutation Testing: Artificially introduce bugs (mutations) into code and check if existing tests catch them. If tests don't fail → tests are weak.

Cyclomatic Complexity (McCabe's Metric):

Formula: V(G) = E - N + 2P
Where: E = edges, N = nodes, P = connected components (usually 1)
OR: V(G) = Number of decision points + 1

CloudKitchen+ — applyDiscount() function:
IF premium_user THEN discount = 20%
ELSE IF cart_value > 500 THEN discount = 15%
ELSE discount = 0

Decision points = 2 (two IF statements)
V(G) = 2 + 1 = 3
→ Minimum 3 test cases needed to cover all paths

Flowchart from Q-Paper — Statement & Decision Coverage

Flow: Read A,B → IF A>=2 [TRUE→Print A+B] [FALSE→Print A-B] → IF B<4 [FALSE→Print B-A] → Print "End"

Paths:
Path 1: A>=2 TRUE  → Print A+B → B<4 FALSE → Print B-A → End
Path 2: A>=2 FALSE → Print A-B → B<4 FALSE → Print B-A → End  
(Note: B<4 TRUE path leads directly to End)

100% Statement Coverage: 2 test cases (cover all statements)
100% Decision Coverage:  2 test cases (cover all T/F branches)
→ Answer: Minimum 2 test cases for both SC and DC

📊 Unit 3 — Easy Comparison Topics

Aspect	Black Box Testing	White Box Testing
Knowledge	No internal code knowledge	Full code knowledge required
Done by	Testers / end users	Developers / testers
Focus	Input/Output behavior	Internal logic, paths
Techniques	EP, BVA, Decision Table	Statement, Branch, Path coverage
Also called	Functional / Behavioral	Structural / Glass box

Technique	What it Tests	Strength
Statement Coverage	Every line executed	Basic — weakest
Branch Coverage	Every T/F branch	Stronger than SC
Path Coverage	Every independent path	Strongest — most thorough

Aspect	Static Testing	Dynamic Testing
Program execution	NOT required	Required
When	Early (before coding or after)	After code is ready
Examples	Code review, walkthrough, inspection	Unit test, integration test
Finds	Defects in docs, design, code logic	Failures in running software
Cost	Cheaper (no environment needed)	More expensive

Unit 4 · 25% · 11 Sessions

Test Management

Test Organization · IEEE 829 · Test Plan · Test Cases · Defect Life Cycle · Risk · Configuration Mgmt

4.1 · Test Organization — Roles (Tester, Test Lead, Test Manager)

▾

Roles

Tester: Writes and executes test cases, logs defects, verifies fixes. Day-to-day testing work.
Test Lead: Plans testing activities, coordinates team, tracks progress, mentors testers.
Test Manager: Owns the test strategy, manages resources, communicates with stakeholders, signs off on release.

🍕 CloudKitchen+ Team Structure Test Manager: Decides release readiness, reports to CTO. Test Lead: Manages 5 testers, handles JIRA, writes test plan. Testers: Each tester owns one module (order, payment, delivery, menu, admin).

4.2 · IEEE 829 Test Plan — All Sections in Detail

▾

What is it?

IEEE 829 is the international standard for software test documentation. The Test Plan is a document that describes the scope, approach, resources, and schedule for testing activities.

IEEE 829 Test Plan Sections

1. Test Plan Identifier: Unique ID for the plan (e.g., CK-TP-2024-V1)
2. Introduction: Purpose of the plan, project overview
3. Test Items: What software/versions are being tested
4. Features to be Tested: List of features in scope
5. Features NOT to be Tested: Explicitly state what is OUT of scope
6. Approach/Strategy: How testing will be done (manual/automated, techniques)
7. Item Pass/Fail Criteria: When is a feature considered passing?
8. Suspension Criteria: When to stop testing (e.g., >30% critical bug rate)
9. Test Deliverables: Test cases, defect reports, test summary
10. Testing Tasks: Breakdown of activities with timeline
11. Environmental Needs: Hardware, software, network setup
12. Responsibilities: Who is responsible for what
13. Staffing and Training: Team skills and training needs
14. Schedule: Timeline/milestones
15. Risks and Contingencies: Risks and mitigation plans
16. Approvals: Sign-off from stakeholders

4.7 · Defect Life Cycle & Defect Report (IEEE 829)

▾

What is it?

The Defect Life Cycle (Bug Life Cycle) describes the different states a bug goes through from discovery to resolution. Every bug follows this lifecycle until it is closed.

Defect States

NEW → ASSIGNED → OPEN → FIXED → RETEST → 
  → VERIFIED (pass) → CLOSED
  → REOPEN (fail) → back to OPEN

Other states: REJECTED (not a bug), DEFERRED (fix later), DUPLICATE

Defect Severity vs Priority:

Severity: Impact on the system. Critical/Major/Minor/Trivial
Priority: How urgently it needs to be fixed. High/Medium/Low
A typo on login page: Low Severity, High Priority (visible to all users)
Crash in rarely-used admin report: High Severity, Low Priority

📊 Unit 4 — Easy Comparison Topics

Aspect	Severity	Priority
Defined by	Tester (technical impact)	Product Owner (business urgency)
High Sev, Low Pri	Crash in rarely-used feature
Low Sev, High Pri	Typo on homepage (brand visibility)

Aspect	Project Risk	Product Risk
What	Risk to the project plan	Risk that the product has quality issues
Example	Developer quits; server delay	Payment module has security bug
Managed by	Project Manager	Test Manager / QA Team

Unit 5 · 15% · 7 Sessions

Tool Support for Testing

CAST · Selenium · JMeter · Postman · ETL Testing · JIRA

5.1 · CAST — Computer Aided Software Testing

▾

What is it?

CAST means using software tools to support, automate, or manage parts of the testing process — instead of doing everything manually.

Types of Test Tools

Test Management Tools: JIRA, TestRail — manage test cases, track defects
Test Execution Tools: Selenium, Appium — automate UI tests
Performance Tools: JMeter, Gatling — load and stress testing
API Testing Tools: Postman, REST Assured — test REST APIs
Static Analysis Tools: SonarQube, PMD — find code issues without running
ETL Testing Tools: QuerySurge — test data warehouse pipelines

Benefits of CAST: Faster execution, reusability, accuracy, regression testing efficiency, 24/7 testing possible, better coverage.

Risks of CAST: High initial cost, maintenance overhead, testers need tool training, tools may not suit all scenarios.

📊 Unit 5 — Easy Comparison Topics

Tool	Purpose	Type	Protocol
Selenium	UI browser automation	Functional	HTTP via browser
JMeter	Load & performance testing	Non-functional	HTTP/HTTPS/FTP/JDBC
Postman	API testing	Functional	REST/SOAP
JIRA	Bug tracking / project mgmt	Management	Web-based
SonarQube	Static code analysis	Static	Code scan

Aspect	Manual Testing	Automation Testing (CAST)
Speed	Slow	Fast
Initial cost	Low	High
Best for	Exploratory, UI/UX checks	Regression, load, repeated tests
Maintenance	None	Scripts need updating
Accuracy	Human error possible	Consistent

[6432]-2002 · M.C.A. · STQ-553 MJ

Software Testing and Quality Assurance · 2024 Pattern · Semester II

Time: 2½ Hours Max. Marks: 50 Total Questions: 5

Instructions:

All questions are compulsory.
Figures to the right indicate full marks.
Draw diagram wherever necessary.

Q1 — Unit 1: Software Quality Assurance Fundamentals [10 Marks]

a) Describe software quality assurance and outline its key activities. [5]

Software Quality Assurance (SQA) is a planned and systematic set of activities designed to ensure that the software development process and the final product conform to established technical standards and procedures.

Key Activities of SQA:

Requirements Analysis: Review SRS for completeness, consistency, and testability.
Design Review: Verify that the software design conforms to architectural standards.
Code Reviews/Walkthroughs: Peer examination of source code to find errors early.
Testing Oversight: Ensuring all testing phases are properly conducted.
Configuration Management: Version control, change management.
Process Auditing: Verifying the team follows defined development processes.
Metrics Collection: Defect density, test coverage, review effectiveness.
Standards Compliance: ISO 9001, IEEE, organisational standards.

b) Explain the metrics used to assess and measure reliability. [5]

Metric	Formula	Meaning	Good =
ROCOF	Failures / Time period	How frequently does the system fail?	Low ↓
MTTF	1 / ROCOF	Average time system works before failing	High ↑
MTTR	Total repair time / No. of repairs	Average time to fix a failure	Low ↓
MTBF	MTTF + MTTR	Time between one failure and the next	High ↑
POFOD	Failed requests / Total requests	Chance of failing when called	Low ↓
Availability	MTTF / (MTTF + MTTR)	% of time system is operational	Close to 1 ↑

c) Explain the term quality in software engineering and describe product revision factors. [5]

Quality in Software Engineering has two aspects: Fitness for Purpose and Conformance to Requirements.

Product Revision Factors (McCall's Model):

Maintainability: How easily can the software be corrected when faults are found?
Testability: How easily can the software be tested to confirm it works?
Flexibility: How easily can the software be modified when requirements change?

d) Describe the significance of ISO 9000 standards in SQA. [5]

Significance of ISO 9000 in SQA:

Process Standardisation: Ensures every team member follows documented, repeatable processes.
Customer Confidence: ISO 9001 certification signals quality management.
Continual Improvement: Mandates regular internal audits and management reviews.
Risk Management: Systematic identification of risks in development.
Documentation: All processes must be documented → enables training and audit trails.
Legal & Contractual: Many enterprise clients require ISO 9001 as a procurement condition.

Q2 — Unit 2: Software Testing Fundamentals [10 Marks]

a) Outline the steps in STLC, highlighting the sequence of testing phases. [5]

Phase 1 — Requirement Analysis: Study SRS, identify what is testable, prepare RTM.

Phase 2 — Test Planning: Create Test Plan (IEEE 829), define scope, strategy, resources, schedule.

Phase 3 — Test Case Development: Write detailed test cases covering positive, negative, boundary scenarios.

Phase 4 — Test Environment Setup: Configure hardware/software, seed database, install tools.

Phase 5 — Test Execution: Run test cases, log results, report defects in JIRA.

Phase 6 — Test Closure: Prepare Test Summary Report, analyse metrics, obtain sign-off.

b) Differentiate between fault, defect and failure and describe common causes of software failure. [5]

Term	Definition	Example
Error	Human mistake made by developer	Dev types wrong GST rate in code
Fault/Defect	The error stored in code or document	Wrong calculation code in billing module
Failure	Wrong output produced when fault executes	Customer billed ₹590 instead of ₹530

Common Causes of Software Failure: Poor requirements, design flaws, coding errors, insufficient testing, integration issues, environment changes, third-party dependency failures, concurrency issues.

c) Illustrate performance testing and detail three specific performance test categories. [5]

1. Load Testing: Tests system under expected normal load. Verifies performance under anticipated users. Tool: JMeter.

2. Stress Testing: Tests system beyond maximum capacity to find the breaking point. Gradually increases load until the system fails.

3. Spike Testing: Tests system with a sudden, drastic increase in load. Simulates events like flash sales or viral promotions.

d) Discuss the Integration test approaches. [5]

Approach	Starts from	Uses	Best for
Big Bang	All at once	Nothing	Small systems
Top-Down	High-level modules	Stubs	Early UI testing
Bottom-Up	Low-level modules	Drivers	Early DB/API testing
Sandwich	Both ends	Stubs + Drivers	Large systems

Q3 — Unit 3: Static & Dynamic Testing [10 Marks]

a) Equivalence Partitioning: Min score 24 to pass, max score 40. Identify partitions, minimum test cases, and specify test cases with expected outcomes. [5]

Partition	Range	Type	Expected Behaviour
EP1	< 0 (e.g., -1)	Invalid	Error: Invalid input
EP2	0 to 23 (e.g., 15)	Valid — FAIL	Display "FAIL"
EP3	24 to 40 (e.g., 30)	Valid — PASS	Display "PASS"
EP4	> 40 (e.g., 45)	Invalid	Error: Invalid input

Minimum test cases: 4 (one per partition)

b) Differentiate between static and dynamic testing. [5]

Aspect	Static Testing	Dynamic Testing
Execution	NOT required	REQUIRED
When	Early — requirements, design, coding	Later — after code is written
Finds	Defects in documents, design flaws	Failures — wrong outputs, crashes
Techniques	Reviews, Walkthroughs, Inspections	Unit, Integration, System Testing
Tools	SonarQube, PMD	Selenium, JMeter, JUnit
Cost	Cheaper — no environment needed	More expensive

c) Flowchart: Read A,B → IF A≥2 [TRUE→Print A+B | FALSE→Print A-B] → IF B<4 [FALSE→Print B-A] → Print "End". Minimum test cases for 100% SC and DC? [5]

Path 1: A=3, B=5 → A>=2 TRUE, B<4 FALSE → Print A+B, Print B-A, End
Path 2: A=1, B=2 → A>=2 FALSE, B<4 TRUE → Print A-B, End

TC1 covers: all TRUE for IF1, FALSE for IF2
TC2 covers: FALSE for IF1, TRUE for IF2
→ All statements and all branches covered with 2 test cases.

Answer: Minimum 2 test cases for BOTH 100% SC and 100% DC.

d) Discuss inspection process in detail. [5]

Roles: Moderator, Author, Reader, Reviewers (Inspectors), Scribe.

6 Phases of Fagan Inspection:

Phase 1 — Planning: Check entry criteria, schedule meeting, distribute material.
Phase 2 — Overview: Author briefs the team on context and purpose.
Phase 3 — Individual Preparation: Each reviewer studies material independently using checklists.
Phase 4 — Inspection Meeting: Group meets, reader reads, reviewers raise defects, scribe logs them. No solutions discussed.
Phase 5 — Rework: Author fixes all identified defects.
Phase 6 — Follow-up: Moderator verifies all defects are fixed. Metrics recorded.

Q4 — Unit 4: Test Management [10 Marks]

a) CloudKitchen+ — Write a test plan for IEEE 829 sections: scope, objectives, risks, strategy, approach. [10]

TEST PLAN DOCUMENT
Project: CloudKitchen+ — Online Food Ordering Platform
Document ID: CK-TP-2024-V1.0 · Standard: IEEE 829

SCOPE: In scope — Order, Payment, Tracking, Menu, Delivery integration
       Out of scope — Admin BI dashboard (v3.0 feature)

OBJECTIVES:
  · Verify 120 functional requirements implemented correctly
  · Ensure 5000 concurrent users with <2s response time
  · Validate PCI-DSS compliance for payments
  · Confirm 99.9% uptime of critical services

RISKS:
  · Payment sandbox unavailable → Use mock service
  · Incomplete promo module requirements → Defer and escalate
  · Team member unavailability → Cross-train; document test cases

STRATEGY:
  · Functional: Manual + EP/BVA techniques
  · Performance: JMeter — 1000/3000/5000 concurrent users
  · Security: OWASP Top 10 checklist
  · Regression: Selenium suite (200 cases) after every sprint

APPROACH: Sprint-aligned testing — functional (wk1-2) →
  integration (wk3) → regression + performance (wk4) →
  UAT + security sign-off (final sprint)

b) Write suitable test cases for the CloudKitchen+ application. [10]

TC ID	Scenario	Input	Expected Output	Type
CK-TC-001	Place order with valid items	Cart: Burger+Fries, UPI payment	Order confirmed, ID generated, SMS sent	Positive
CK-TC-002	Place order with empty cart	Cart: empty	Error: "Add items before ordering"	Negative
CK-TC-003	Apply valid promo code	Cart: ₹500, Code: SAVE20	Discount ₹100, Total ₹400	Positive
CK-TC-004	Apply expired promo code	Code: MONSOON23	Error: "Promo code has expired"	Negative
CK-TC-005	Cancel order within 5 minutes	Order placed 2 min ago	Cancelled, full refund initiated	Positive
CK-TC-006	Cancel order after 15 minutes	Order in PREPARING state	Error: "Kitchen is preparing your food"	Negative
CK-TC-007	Minimum order value check	Cart ₹80, Kitchen min ₹100	Error: "Add ₹20 more to place order"	Negative
CK-TC-008	Payment failure during checkout	Declined test card	Error: "Payment failed. Try another method."	Negative

Q5 — Unit 5: Tool Support for Testing [10 Marks]

a) Define CAST and explain its benefits in software testing. [5]

CAST (Computer-Aided Software Testing) refers to using software tools to support, enhance, automate, or manage aspects of the testing process.

Benefits:

Speed: Automated tests run in minutes vs hours manually.
Reusability: Test scripts reused across multiple releases.
Accuracy: Eliminates human errors in test execution.
Better Coverage: Can run thousands of combinations impractical manually.
24/7 Testing: Automated tests run overnight without human intervention.
Regression Efficiency: Full suite confirms nothing breaks after each change.

b) Describe the steps in introducing a testing tool into an organization. [5]

Step 1 — Assessment: Understand testing challenges; define success criteria.

Step 2 — Tool Evaluation (POC): Short-list 2-3 tools; run proof of concept on a small feature.

Step 3 — Tool Selection: Select based on POC results, team skill, and budget.

Step 4 — Pilot Implementation: Implement for one module first; identify challenges in a controlled way.

Step 5 — Training: Hands-on workshops, documentation, pair programming sessions.

Step 6 — Guidelines & Standards: Define coding standards for test scripts, naming conventions, templates.

Step 7 — Full Rollout: Expand to all modules; integrate with CI/CD pipeline.

Step 8 — Monitoring & Maintenance: Track metrics; update scripts when UI changes.

c) Explain the purpose of Postman in API testing. [5]

Postman is a widely-used API testing tool for designing, testing, documenting, and monitoring REST and SOAP APIs.

Key Uses: Send HTTP requests (GET/POST/PUT/DELETE), validate responses (status codes, body structure), write automated test scripts in JavaScript, group tests into collections, use environment variables to switch between dev/staging/prod, run via Newman CLI in CI/CD, generate API documentation, and create mock servers.

CloudKitchen+ — Postman Test:
GET https://api.cloudkitchen.app/v1/kitchens/5/menu

pm.test("Status 200", () => pm.response.to.have.status(200));
pm.test("Has menu items", () => {
  pm.expect(pm.response.json().items).to.be.an('array');
});

d) Discuss defect life cycle. [5]

NEW → ASSIGNED → OPEN → FIXED → RETEST →
  [Pass] → VERIFIED → CLOSED
  [Fail] → REOPENED → OPEN (cycle repeats)

Special: REJECTED · DEFERRED · DUPLICATE · CANNOT REPRODUCE

State Descriptions: New (logged by tester) → Assigned (by lead) → Open (dev working) → Fixed (dev done) → Retest (tester verifies) → Verified (fix confirmed) → Closed (official closure). Reopened if fix doesn't work.

Severity vs Priority: Severity = technical impact (Critical/Major/Minor). Priority = business urgency (High/Medium/Low). A logo misalignment: Low Severity, High Priority.

STQA Notes

CloudKitchen+ — Online Food Ordering Platform

Software Quality Assurance Fundamentals

1.1 · Quality, Quality Assurance & Quality Control

1.2 · SQA Planning & ISO 9000 Standards

1.3 · SQA Activities

1.4 · Building Blocks of SQA & 1.5 Software Quality Factors

1.6 · Software Reliability & Metrics (ROCOF, MTTF, MTTR, MTBF, POFOD, Availability)

📊 Unit 1 — Easy Comparison Topics

Software Testing Fundamentals

2.1–2.3 · Definition, Objectives & Error / Bug / Fault / Failure

2.5 · Seven Testing Principles

2.6 · Software Testing Life Cycle (STLC)

2.7 · V-Model & W-Model

2.9 · Levels of Testing (Unit, Integration, System, UAT)

📊 Unit 2 — Easy Comparison Topics

Static & Dynamic Testing

3.1 · Static Techniques — Reviews (Informal, Formal, Walkthrough, Inspection)

3.3 · Black Box Testing Techniques (Equivalence Partitioning, BVA, Decision Table, State Transition)

3.4 · White Box Testing (Statement, Branch, Path, Cyclomatic Complexity, Data Flow, Mutation)

📊 Unit 3 — Easy Comparison Topics

Test Management

4.1 · Test Organization — Roles (Tester, Test Lead, Test Manager)

4.2 · IEEE 829 Test Plan — All Sections in Detail

4.7 · Defect Life Cycle & Defect Report (IEEE 829)

📊 Unit 4 — Easy Comparison Topics

Tool Support for Testing

5.1 · CAST — Computer Aided Software Testing

📊 Unit 5 — Easy Comparison Topics

[6432]-2002 · M.C.A. · STQ-553 MJ