Ndejje University | Software Quality Assurance | Assignment 3

NAME: MBONIMPA YONAH

REG: 23/1/37/D/640

COURSE: BSE

YEAR: 3

SEMSTER: 2

COURSE UNIT: SQA

COURSE UNIT STUDY: COURSE WORK

LECTURE: MR. MUCHAKE BRIAN

Page 1 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

Table of Contents

SECTION 1: SOFTWARE TESTING FUNDAMENTALS......................................................................................4

1.1 Testing Principles..............................................................................................................................................4
1.2 Verification vs. Validation................................................................................................................................4
1.3 Levels of Testing...............................................................................................................................................5
1.3.1 Unit Testing...............................................................................................................................................5
1.3.2 Integration Testing.....................................................................................................................................5
1.3.3 System Testing...........................................................................................................................................6
1.3.4 Acceptance Testing....................................................................................................................................6
1.4 Types of Testing...............................................................................................................................................7
1.4.1 Functional Testing.....................................................................................................................................7
1.4.2 Non-Functional Testing.............................................................................................................................7
1.4.3 Regression Testing.....................................................................................................................................7
1.4.4 Performance Testing..................................................................................................................................7
1.4.5 Security Testing.........................................................................................................................................8
SECTION 2: TESTING TECHNIQUES....................................................................................................................9
2.1 Black-Box Testing Techniques.........................................................................................................................9
2.1.1 Equivalence Partitioning (EP)....................................................................................................................9
2.1.2 Boundary Value Analysis (BVA)..............................................................................................................9
2.1.3 Decision Table Testing..............................................................................................................................9
2.2 White-Box Testing Techniques......................................................................................................................10
2.2.1 Statement Coverage.................................................................................................................................10
2.2.2 Branch Coverage......................................................................................................................................10
2.2.3 Path Testing.............................................................................................................................................10
2.3 Experience-Based Testing..............................................................................................................................11
SECTION 3: TEST PLANNING AND MANAGEMENT......................................................................................12
3.1 Test Strategy...................................................................................................................................................12
3.2 Test Plan Components....................................................................................................................................12
3.3 Test Case Design.............................................................................................................................................12
3.4 Test Execution................................................................................................................................................13
3.5 Defect Life Cycle............................................................................................................................................13
3.6 Test Documentation........................................................................................................................................14
3.7 Traceability Matrix.........................................................................................................................................14
SECTION 4: SOFTWARE METRICS AND MEASUREMENT............................................................................15
4.1 Product Metrics...............................................................................................................................................15
4.2 Process Metrics...............................................................................................................................................15

Page 2 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

4.3 Project Metrics................................................................................................................................................15

4.4 Defect Density................................................................................................................................................16
4.5 Code Complexity............................................................................................................................................16
4.6 Reliability Metrics..........................................................................................................................................16
4.7 Quality Cost Analysis.....................................................................................................................................17
SECTION 5: AUTOMATED TESTING AND TOOLS..........................................................................................18
5.1 Test Automation Principles.............................................................................................................................18
5.2 Unit Testing Frameworks...............................................................................................................................18
5.3 Selenium for Web Testing..............................................................................................................................18
Selenium Components......................................................................................................................................18
5.4 Continuous Integration Tools (Jenkins)..........................................................................................................19
Jenkins...............................................................................................................................................................19
5.5 Bug Tracking Tools (Jira)...............................................................................................................................19
Jira.....................................................................................................................................................................19
SECTION 6: RISK MANAGEMENT AND QUALITY IMPROVEMENT...........................................................21
6.1 Risk Identification...........................................................................................................................................21
6.2 Risk Analysis..................................................................................................................................................21
6.3 Risk Mitigation Strategies...............................................................................................................................21
6.4 Root Cause Analysis (RCA)...........................................................................................................................22
Common RCA Techniques...............................................................................................................................22
6.5 Process Improvement Techniques..................................................................................................................22
6.6 Six Sigma Basics.............................................................................................................................................22
SECTION 7: QUALITY ASSURANCE IN AGILE & DEVOPS...........................................................................24
7.1 Test-Driven Development (TDD)...................................................................................................................24
The TDD Cycle (Red-Green-Refactor).............................................................................................................24
7.2 Behaviour-Driven Development (BDD).........................................................................................................24
Gherkin Syntax (Given-When-Then)...............................................................................................................24
7.3 Continuous Testing.........................................................................................................................................24
7.4 DevOps Pipeline Quality Control...................................................................................................................25
7.5 Shift-Left Testing Approach...........................................................................................................................25
Shift-Left Practices...........................................................................................................................................25
SUMMARY REFERENCE TABLE........................................................................................................................27

Page 3 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 1: SOFTWARE TESTING FUNDAMENTALS

1.1 Testing Principles

Software testing is a systematic activity of executing a program or system with the intent of finding errors. The
goal is to evaluate quality and detect defects before software is released. The following seven internationally
accepted testing principles guide professional testers:

Principle 1: Testing Shows Testing can show that defects exist but cannot prove that the software has no
Presence of Defects defects. Testing reduces the probability of undiscovered defects remaining in
the software but, even if no defects are found, testing cannot prove
correctness.
Principle 2: Exhaustive Testing everything (all combinations of inputs and preconditions) is not
Testing is Impossible feasible, except for trivial cases. Risk analysis, priorities, and techniques
should be used to focus testing efforts where they matter most.
Principle 3: Early Testing Testing activities should start as early as possible in the software development
lifecycle and should be focused on defined objectives. Starting early catches
defects when they are cheapest to fix.
Principle 4: Defect Clustering A small number of modules contain most of the defects discovered before
release or are responsible for most operational failures. This is often called the
Pareto Principle (80/20 rule) applied to software.
Principle 5: Pesticide If the same tests are repeated over and over, they will eventually no longer
Paradox find new bugs. To overcome this, test cases need to be regularly reviewed and
revised, and new, different tests need to be written.
Principle 6: Testing is Testing is done differently in different contexts. Safety-critical software, for
Context-Dependent example, is tested differently from an e-commerce site. The testing approach
must be tailored to the system and its risks.
Principle 7: Absence-of- Finding and fixing defects does not help if the system built is unusable or does
Errors Fallacy not fulfil the users' needs and expectations. Testing must verify that the right
product is built, not just that the product is built right.

1.2 Verification vs. Validation

Verification and validation are two complementary activities in quality assurance. They are often confused but
address fundamentally different questions:

Verification Are we building the product RIGHT? Verification checks that the software

Page 4 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

conforms to its specification. It is a static activity (does not require execution)

— e.g., reviews, walkthroughs, inspections, and static analysis.
Validation Are we building the RIGHT product? Validation checks that the software
meets the actual needs and expectations of the user/customer. It is a dynamic
activity — requires execution of the software (i.e., testing).

Key Distinction
Verification ensures the software matches its design documents and specifications. Validation ensures the
product actually solves the user's real-world problem. Both are necessary: you can verify a wrongly specified
product (built exactly to spec but wrong) or fail to validate a correctly specified one.

1.3 Levels of Testing

Testing is structured into levels that correspond to stages of development. Each level has distinct objectives,
scope, and responsibilities.

1.3.1 Unit Testing

Unit testing is the lowest level of testing, where individual components (functions, methods, classes, or
modules) are tested in isolation. It is typically performed by developers during the coding phase.

• Objective: Verify that each unit of code works correctly according to its design specification.
• Scope: A single function, method, or class — the smallest testable part.
• Tools: JUnit (Java), NUnit (.NET), PyTest (Python), Jest (JavaScript).
• Key Practice: Dependencies are replaced with mocks or stubs to ensure isolation.
• Benefits: Early defect detection, supports refactoring, speeds up debugging, enables test-driven
development.

Example
A function calculateDiscount(price, customerType) is unit tested with inputs like (100, 'VIP') and (50,
'REGULAR') to verify correct discount calculations in isolation, without involving the database or UI.

1.3.2 Integration Testing

Integration testing verifies that multiple components or modules work correctly when combined. It focuses on
the interfaces and interactions between components.

• Objective: Detect interface defects and interaction problems between integrated units.
• Scope: Groups of units combined together — modules, services, APIs.
• Approaches:
◦ Big Bang: All units combined and tested at once. Simple but hard to isolate failures.
◦ Top-Down: Testing starts from the topmost module down, using stubs for lower modules.
◦ Bottom-Up: Lower modules tested first, using drivers for higher modules.
◦ Sandwich/Hybrid: Combines top-down and bottom-up approaches.

Page 5 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• Common issues found: Incorrect data formats, wrong API calls, missing error handling between
components.

1.3.3 System Testing

System testing tests the complete, integrated system as a whole. It verifies that the system meets its specified
requirements (functional and non-functional) and is performed by dedicated QA testers in a staging
environment.

• Objective: Validate the entire system against the system specification.

• Scope: The complete application, including all integrated components.
• Includes: Functional testing, performance testing, security testing, usability testing, reliability testing.
• Environment: A test environment that closely mirrors the production environment.
• Responsibility: Independent QA/test team — not the developers who wrote the code.

1.3.4 Acceptance Testing

Acceptance testing is the final level of testing, performed to determine whether the system satisfies the
business requirements and is ready for delivery. It is often performed by end-users or clients.

User Acceptance Testing End-users test the system in realistic scenarios to confirm it meets their
(UAT) business needs before go-live. This is the most common form.
Alpha Testing Performed internally by the development organisation in a lab environment
before releasing to external users.
Beta Testing Performed by a limited number of real end-users in a real environment before
full commercial release. Feedback is collected.
Contract Acceptance Testing Testing against the acceptance criteria defined in the contract between client
and vendor.
Regulatory Acceptance Testing to verify compliance with legal or regulatory standards (e.g.,
Testing healthcare, finance).

Page 6 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

1.4 Types of Testing

1.4.1 Functional Testing

Functional testing verifies that the software performs its intended functions correctly. It tests what the system
does, validating each function against the specification.

• Tests user-visible behaviour and business rules.

• Based on requirements, user stories, or use cases.
• Examples: Login/logout, data entry validation, search functionality, report generation.
• Approach: Black-box — tester does not need to know the internal implementation.

1.4.2 Non-Functional Testing

Non-functional testing evaluates how well the system performs — its quality characteristics beyond mere
functionality. It answers 'how well?' rather than 'does it work?'.

Performance Testing How fast does the system respond under normal and peak load?
Load Testing How does the system behave under expected user loads?
Stress Testing What happens when the system is pushed beyond its limits?
Usability Testing Is the system easy to learn and use?
Reliability Testing Does the system perform consistently over time without failure?
Compatibility Testing Does the system work across different browsers, OS, devices?
Scalability Testing Can the system scale up to handle increased demand?

1.4.3 Regression Testing

Regression testing is re-testing of software after modifications (bug fixes, new features, or configuration
changes) to ensure that the changes have not introduced new defects or broken existing functionality.

• Critical after any code change, no matter how small.

• Often automated due to repetitive nature.
• Regression test suites should be maintained and regularly reviewed.
• Selective regression: Re-run only tests related to the changed areas to save time.
• Full regression: Re-run the entire test suite for major releases.

1.4.4 Performance Testing

Performance testing evaluates the speed, responsiveness, stability, and resource consumption of the system.
Sub-types include:

• Load Testing: Simulating expected user loads to verify system behaviour.

• Stress Testing: Testing beyond normal operational capacity to find breaking points.

Page 7 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• Spike Testing: Sudden, drastic increases in load to observe system recovery.

• Endurance/Soak Testing: Running the system under sustained load over long periods.
• Volume Testing: Testing with large amounts of data to assess performance degradation.
• Tools: Apache JMeter, Gatling, Locust, k6.

1.4.5 Security Testing

Security testing identifies vulnerabilities, threats, and risks in the software that could result in loss of
information, revenue, reputation, or unauthorised access.

Vulnerability Scanning Automated scanning of the application for known vulnerabilities using tools
like OWASP ZAP or Nessus.
Penetration Testing Ethical hacking — simulating real-world attacks to find exploitable
vulnerabilities.
SQL Injection Testing Testing input fields to ensure they are not vulnerable to SQL injection attacks.
XSS Testing Cross-Site Scripting tests to prevent script injection into web pages.
Authentication Testing Verifying that login mechanisms are secure and session management is sound.
Authorisation Testing Ensuring users can only access resources they are permitted to.

OWASP Top 10
Security testing often follows the OWASP Top 10 — a standard awareness document listing the ten most
critical web application security risks including Injection, Broken Authentication, Sensitive Data Exposure,
XML External Entities, Broken Access Control, Security Misconfiguration, XSS, Insecure Deserialisation,
Using Components with Known Vulnerabilities, and Insufficient Logging.

Page 8 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 2: TESTING TECHNIQUES

2.1 Black-Box Testing Techniques

Black-box testing techniques derive test cases from the specification, requirements, or system behaviour
without knowledge of the internal code structure. The tester treats the system as a 'black box'.

2.1.1 Equivalence Partitioning (EP)

Equivalence Partitioning divides input data into partitions (classes) where all values in a partition are expected
to be processed the same way. Testing one value from each partition is sufficient to represent the entire class.

• Reduces the number of test cases while maintaining coverage.

• Partitions can be valid (accepted by the system) or invalid (rejected by the system).
• Each input condition is divided into at least two classes: valid and invalid.

Example
For a field accepting age values 18-65: - Valid partition: 18 to 65 (test with, say, 30) - Invalid partition 1: Below
18 (test with, say, 10) - Invalid partition 2: Above 65 (test with, say, 70) Rather than testing every possible age,
one value from each partition is tested.

2.1.2 Boundary Value Analysis (BVA)

Boundary Value Analysis focuses test cases on the boundaries of equivalence partitions, since errors tend to
cluster at the edges of input ranges. For each boundary, the values at, just below, and just above are tested.

• Based on the observation that boundary conditions are where most defects occur.
• For a range [min, max], test: min-1, min, min+1, max-1, max, max+1.
• Complements Equivalence Partitioning — often used together.

Example
For a field accepting age 18-65: - Boundary test values: 17 (just below), 18 (at min), 19 (just above min), 64
(just below max), 65 (at max), 66 (just above) This catches off-by-one errors that partitioning alone would miss.

2.1.3 Decision Table Testing

Decision Table Testing is a systematic approach to testing combinations of inputs and conditions that produce
different actions or outputs. It represents the logic of business rules in a tabular format.

• Useful when the system behaviour depends on combinations of conditions.

• Columns represent test cases (rules); rows represent conditions and actions.
• 'Y' = condition is true, 'N' = condition is false, '-' = condition is irrelevant.
• Ensures all combinations of conditions and their resulting actions are covered.

Page 9 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

Example
An online discount system: Conditions: Is customer a VIP? (Y/N) | Is order > $100? (Y/N) Actions: Apply 20%
discount / Apply 10% discount / No discount Rule 1: VIP + >$100 = 20% discount Rule 2: VIP + <=100 = 10%
discount Rule 3: Not VIP + >$100 = 10% discount Rule 4: Not VIP + <=100 = No discount

2.2 White-Box Testing Techniques

White-box (also called glass-box or structural) testing techniques derive test cases from the internal structure of
the code. Testers have visibility into the code and design their tests to exercise specific paths, branches, or
statements.

2.2.1 Statement Coverage

Statement coverage (also called line coverage) measures the percentage of executable statements in the code
that have been executed by the test suite.

• Formula: (Number of executed statements / Total statements) x 100%

• 100% statement coverage means every line of code was executed at least once.
• Limitation: Does not guarantee all branches have been tested. A statement can be covered without testing
the false branch of an if condition.
• Minimum acceptable threshold in most industries: 70-80%.

2.2.2 Branch Coverage

Branch coverage (decision coverage) measures whether each possible branch of every decision point (if,
switch, loop) has been executed. It is stronger than statement coverage.

• Formula: (Number of executed branches / Total branches) x 100%

• For every IF statement, both the TRUE and FALSE outcomes must be tested.
• 100% branch coverage implies 100% statement coverage, but not vice versa.
• Achieves a higher level of confidence in code correctness than statement coverage alone.

2.2.3 Path Testing

Path testing aims to test every possible path through a program's control flow graph. It is the most thorough
form of white-box testing but also the most expensive.

• A path is a sequence of statements from the entry to exit of a program.

• Cyclomatic Complexity (M = E - N + 2P) determines the minimum number of paths: E=edges, N=nodes,
P=connected components.
• Cyclomatic Complexity also indicates code complexity and maintainability.
• Full path testing is often impractical for large programs due to combinatorial explosion.
• Basis Path Testing (by McCabe): A practical subset — tests the minimum number of linearly independent
paths.

Page 10 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

2.3 Experience-Based Testing

Experience-based testing uses the tester's knowledge, intuition, and experience with similar systems to design
test cases. While less formal, it is highly valuable and complements structured techniques.

Error Guessing Testers use experience to predict where errors are likely to occur and design
tests targeting those areas. Based on knowledge of common developer
mistakes and past defect patterns.
Exploratory Testing Simultaneous test design and execution — testers learn about the system as
they test, adapting their approach in real time. Documented via session-based
testing. Highly effective for finding unexpected issues.
Checklist-Based Testing Testers use a checklist of items (derived from experience or standards) to
verify that common conditions are tested. Balances consistency with
exploratory freedom.

Page 11 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 3: TEST PLANNING AND MANAGEMENT

3.1 Test Strategy

A test strategy is a high-level document that describes the overall testing approach for an organisation or
project. It is typically defined at the project or programme level and provides guidance on how testing will be
conducted.

• Scope of testing: What will and will not be tested.

• Testing levels and types: Which levels (unit, integration, system, acceptance) and types will be used.
• Testing tools and environments: Infrastructure and tooling decisions.
• Entry and exit criteria: Conditions to start and stop testing.
• Defect management: How defects will be tracked and resolved.
• Metrics and reporting: How progress and quality will be measured and communicated.

Test Strategy vs Test Plan

A Test Strategy is broad and defines the overall approach (often organisation-wide or programme-level). A Test
Plan is project-specific and details how the strategy will be implemented for a specific project or release. The
strategy is more stable; the plan changes with each project.

3.2 Test Plan Components

A test plan is a formal document that outlines the scope, approach, resources, and schedule for testing a
specific product or system. Key components include:

1. Test Plan Identifier Unique identifier, version, and revision history.

2. Introduction / Objectives Purpose of the test plan, project background, and testing goals.
3. Scope Features to be tested and features not to be tested, with justification.
4. Test Approach Testing levels, types, techniques, and automation strategy to be used.
5. Entry & Exit Criteria Conditions that must be met before testing begins (entry) and before testing is
considered complete (exit).
6. Test Environment Hardware, software, network, and data requirements for testing.
7. Test Schedule Timeline, milestones, and testing phases.
8. Resource Requirements Personnel, tools, and infrastructure needed.
9. Risk & Contingency Identified risks to testing and mitigation plans.
10. Deliverables Documents and artefacts to be produced (test cases, reports, defect logs).

Page 12 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

3.3 Test Case Design

A test case is a documented set of conditions or variables used to determine whether a system or feature works
as intended. A well-designed test case is clear, reusable, and traceable.

Each test case should contain the following fields:

Test Case ID Unique identifier (e.g., TC-LOGIN-001).

Test Case Name / Description Brief description of what is being tested.
Pre-conditions State the system must be in before executing the test.
Test Steps Step-by-step instructions to execute the test.
Test Data Specific input values to be used.
Expected Result The exact output or behaviour expected.
Actual Result The output observed during execution (filled in after running).
Pass/Fail Status Whether the test passed or failed.
Priority / Severity How critical this test case is.
Traceability Link to the requirement or user story being tested.

3.4 Test Execution

Test execution is the phase where planned test cases are run against the software and results are recorded. Steps
in test execution include:

• Set up the test environment and verify it is ready.

• Execute test cases in the planned order, following test steps precisely.
• Record actual results against expected results for each test case.
• Log any deviations (defects) in the defect tracking system.
• Re-execute failed tests after bug fixes (confirmation testing).
• Execute regression tests to ensure fixes have not broken other functionality.
• Prepare the test execution report summarising results, defects, and coverage.

3.5 Defect Life Cycle

The defect life cycle (also known as the bug life cycle) describes the different states a defect goes through from
discovery to closure. Understanding this cycle is critical for effective defect management.

New A defect is discovered and reported in the system for the first time.
Assigned The defect has been reviewed and assigned to a developer for investigation
and fixing.

Page 13 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

Open The developer has started investigating the defect.

Fixed The developer has made a code change to address the defect.
Pending Retest The fix has been deployed to the test environment; waiting for testers to
verify.
Retest The tester is re-executing the test case to verify the fix.
Verified The tester confirms the defect has been successfully fixed.
Closed The defect is confirmed fixed, verified, and closed in the tracking system.
Reopened If the fix was insufficient, the defect is reopened and assigned back to the
developer.
Rejected / Not a Bug The developer or product owner determines the reported issue is not actually a
defect.
Deferred The fix will be addressed in a future release due to priority or resource
constraints.

3.6 Test Documentation

Key test documentation artefacts include:

• Test Strategy: High-level approach to testing for the project/organisation.

• Test Plan: Detailed project-level testing plan (scope, schedule, resources).
• Test Cases: Individual test scenarios with steps, data, and expected results.
• Test Data: Datasets used during test execution.
• Test Scripts: Automated scripts for test execution.
• Test Execution Report: Summary of tests run, passed, failed, and blocked.
• Defect Report: Detailed log of all defects found during testing.
• Test Summary Report: End-of-cycle report summarising overall quality and testing outcome.

3.7 Traceability Matrix

A Requirements Traceability Matrix (RTM) is a document that maps and traces requirements to test cases (and
vice versa). It ensures that all requirements have been tested and helps identify gaps in test coverage.

• Forward traceability: From requirements to test cases (ensures all requirements are covered).
• Backward traceability: From test cases to requirements (ensures no orphan tests).
• Bidirectional traceability: Combines both — the gold standard.
• Columns typically include: Requirement ID, Requirement Description, Test Case ID(s), Test Status, Defect
ID(s).
• Benefits: Impact analysis for changes, audit compliance, coverage reporting.

Page 14 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 4: SOFTWARE METRICS AND MEASUREMENT

Software metrics provide quantitative measures to assess the quality of software products and the efficiency of
development processes. Without measurement, quality improvement is guesswork.

4.1 Product Metrics

Product metrics measure characteristics of the software artifact itself — its size, complexity, reliability, and
quality attributes.

Lines of Code (LOC) Physical measure of code size. Useful for estimating effort but must be used
carefully — more LOC is not necessarily better.
Code Complexity Cyclomatic complexity (see below) and Halstead metrics measure how
complex the code is.
Defect Density Number of defects per unit of size (e.g., defects per KLOC). See Section 4.4.
Code Coverage Percentage of code exercised by the test suite (statement, branch, path
coverage).
Maintainability Index A composite metric indicating how maintainable a codebase is.
Coupling & Cohesion Coupling: degree of interdependence between modules. Cohesion: degree to
which elements of a module belong together. Low coupling and high cohesion
are desirable.

4.2 Process Metrics

Process metrics measure aspects of the software development process — how efficiently and effectively the
team operates.

• Defect Detection Rate: Number of defects found per time period.

• Defect Removal Efficiency (DRE): Percentage of defects removed before delivery. Formula: Defects found
before release / (Defects found before + after release) x 100%.
• Test Coverage Progress: How coverage metrics evolve over the testing lifecycle.
• Review Effectiveness: Defects found per hour of inspection/review.
• Time to Fix Defects: Average time from defect discovery to resolution.

4.3 Project Metrics

Project metrics measure the progress and performance of the project as a whole.

• Schedule Variance: Difference between planned and actual completion dates.

Page 15 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• Cost Variance: Difference between budgeted and actual cost.

• Velocity (Agile): Number of story points completed per sprint.
• Burn-down Rate: Progress of work remaining against time.
• Test Execution Rate: Number of test cases executed per day/week.
• Test Pass Rate: Percentage of executed test cases that pass.

4.4 Defect Density

Defect density measures the number of confirmed defects in a software component relative to its size. It is a
key indicator of software quality.

Formula
Defect Density = (Number of Confirmed Defects) / (Size of Software in KLOC) Example: A module with
5,000 lines of code (5 KLOC) containing 15 confirmed defects has a defect density of 15/5 = 3 defects per
KLOC.

• Industry benchmark: Typically 1-25 defects per KLOC depending on domain.

• High defect density modules should receive additional testing attention.
• Can also be measured per function point or per component.

4.5 Code Complexity

Code complexity metrics assess how difficult code is to understand, test, and maintain. The most widely used is
Cyclomatic Complexity, introduced by Thomas McCabe.

Cyclomatic Complexity Formula

M = E - N + 2P Where: E = number of edges in the control flow graph, N = number of nodes, P = number of
connected components (usually 1 for a single program). Alternatively: M = Number of decision points (if,
while, for, case, &&, ||) + 1

1 - 10 Simple, low risk — well-structured, easy to test.

11 - 20 Moderate complexity — some risk, more test cases needed.
21 - 50 High complexity — difficult to test, refactoring recommended.
50+ Extremely complex — very high risk, very difficult to test, strong refactoring
required.

4.6 Reliability Metrics

Reliability metrics quantify how consistently and dependably software performs its intended functions over
time.

Page 16 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

MTTF (Mean Time to Average time the system operates before a failure occurs. Higher is better.
Failure)
MTTR (Mean Time to Average time to restore the system after a failure. Lower is better.
Repair)
MTBF (Mean Time Between MTBF = MTTF + MTTR. Average time between consecutive failures.
Failures)
Availability Availability = MTTF / (MTTF + MTTR) x 100%. Often expressed as 'nines':
99.9% = ~8.7 hours downtime/year.
Failure Rate (λ) λ = 1/MTTF. Rate at which failures occur.

4.7 Quality Cost Analysis

The Cost of Quality (CoQ) framework categorises all quality-related costs into four categories. Understanding
these costs justifies investment in quality activities.

Prevention Costs Costs to prevent defects from occurring: training, process improvement,
standards, reviews, planning.
Appraisal Costs Costs to detect defects: testing, inspections, audits, test tools, test environment.
Internal Failure Costs Costs of defects found before delivery: rework, retesting, debugging, failure
analysis.
External Failure Costs Costs of defects found after delivery: warranty repairs, customer complaints,
legal liability, loss of reputation. These are the most expensive.

Key Insight
The cost to fix a defect increases exponentially the later it is found. A defect found during requirements costs
~$1 to fix; the same defect found post-production can cost $100-$1,000+ to fix (including support, patches, data
recovery, and reputation damage). This is the economic justification for early and thorough testing.

Page 17 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 5: AUTOMATED TESTING AND TOOLS

5.1 Test Automation Principles

Test automation involves using software tools to execute tests, compare actual results against expected results,
and report outcomes — reducing manual effort and enabling faster feedback. Key principles include:

• Automate the right tests: Focus on stable, high-value, frequently-executed tests (regression, smoke). Not all
tests should be automated.
• Test pyramid: More unit tests (fast, cheap) at the base; fewer UI/E2E tests (slow, brittle) at the top.
• Maintainability: Write automation code as you would production code — clean, modular, version-
controlled.
• Independence: Tests should be independent and executable in any order.
• Reliable results: Tests must be deterministic — same code should always produce the same result.
• ROI: The cost of developing and maintaining automation must be less than the cost of manual testing it
replaces over time.

5.2 Unit Testing Frameworks

Unit testing frameworks provide structure, assertion libraries, test runners, and reporting for writing and
executing unit tests. Key frameworks by language:

JUnit (Java) The de facto standard for Java unit testing. Uses annotations (@Test,
@Before, @After, @BeforeClass). Version 5 (Jupiter) is current.
NUnit / MSTest / xUnit Popular testing frameworks for C# and .NET. xUnit is the modern choice for
(.NET) [Link] Core.
PyTest / unittest (Python) PyTest is the preferred Python testing framework with rich plugins and
fixtures. unittest is the built-in standard library option.
Jest / Mocha (JavaScript) Jest is the most popular for React/[Link] with built-in mocking and coverage.
Mocha is flexible and widely used.
RSpec (Ruby) Behaviour-focused unit testing for Ruby on Rails applications.

5.3 Selenium for Web Testing

Selenium is the most widely used open-source framework for automating web browsers. It supports multiple
languages (Java, Python, C#, JavaScript) and browsers (Chrome, Firefox, Safari, Edge).

Selenium Components

Page 18 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

Selenium WebDriver The core API for programmatically controlling a web browser — navigating
pages, clicking elements, filling forms, and extracting data.
Selenium Grid Enables parallel test execution across multiple browsers and operating systems
simultaneously, dramatically reducing test execution time.
Selenium IDE A browser plugin for recording and replaying user interactions. Useful for
creating quick prototypes but not for production-quality test suites.

• Key WebDriver Actions: get(url), findElement([Link]/name/xpath/css), click(), sendKeys(), getText(),

submit(), switchTo().
• Page Object Model (POM): A design pattern for Selenium where each web page has a corresponding class,
separating test logic from page interaction code. Improves maintainability.
• Selenium 4 introduced Relative Locators, enhanced CDP support, and improved Grid architecture.

5.4 Continuous Integration Tools (Jenkins)

Continuous Integration (CI) is the practice of frequently merging developer code changes into a shared
repository, automatically building and testing the software after each merge. CI tools automate this pipeline.

Jenkins
Jenkins is the most widely used open-source CI/CD automation server. It orchestrates build pipelines and
integrates with hundreds of tools.

• Key Concepts:
◦ Job/Project: A task configured in Jenkins (e.g., build and test a project).
◦ Pipeline: A sequence of stages (build, test, deploy) defined in a Jenkinsfile (declarative or scripted).
◦ Agent/Node: The machine where the pipeline runs.
◦ Plugins: 1,800+ plugins for integration with Git, Maven, Docker, Slack, Jira, etc.

• Typical Jenkins Pipeline Stages: Source (checkout from Git) → Build (compile) → Test (run
unit/integration tests) → Code Analysis (SonarQube) → Package → Deploy to Staging → Acceptance
Tests → Deploy to Production.
• Other CI/CD Tools: GitHub Actions, GitLab CI/CD, CircleCI, Azure DevOps, Travis CI.

5.5 Bug Tracking Tools (Jira)

Bug tracking tools (also called issue trackers or defect management systems) provide a centralised system for
logging, tracking, and managing defects throughout their lifecycle.

Jira
Jira (by Atlassian) is the most widely used issue and project tracking tool in software development. It supports
both waterfall and Agile methodologies.

Page 19 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• Key Features: Customisable workflows, dashboards, Agile boards (Scrum & Kanban), reporting,
integrations.
• Defect Fields in Jira: Summary, Description, Steps to Reproduce, Expected/Actual Result, Priority,
Severity, Assignee, Fix Version, Attachments (screenshots, logs).
• Jira Query Language (JQL): Powerful query language for searching and filtering issues.
• Integration: Connects with Confluence (documentation), Bitbucket (code), Jenkins (CI/CD), and Slack.
• Other Bug Tracking Tools: Bugzilla, MantisBT, Azure DevOps Boards, GitHub Issues, Linear, YouTrack.

Page 20 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 6: RISK MANAGEMENT AND QUALITY

IMPROVEMENT

6.1 Risk Identification

Risk identification is the first step in risk management — systematically finding and documenting potential
threats to the project or product quality. Sources of risk in software projects include:

• Technical risks: Complex architecture, new technology, unclear requirements, performance issues.
• Project risks: Tight deadlines, insufficient resources, scope creep, high team turnover.
• Business risks: Regulatory changes, market shifts, dependency on third-party vendors.
• Quality risks: Inadequate testing time, lack of skills, poor test environments.

Techniques for risk identification include: Brainstorming sessions, expert interviews, historical data review,
checklist analysis, SWOT analysis, and risk taxonomies.

6.2 Risk Analysis

Risk analysis evaluates identified risks in terms of their likelihood of occurrence and the potential impact if
they do occur.

Risk Priority Number (RPN)

Risk Exposure = Likelihood x Impact Both factors are typically rated on a scale (e.g., 1-5 or
Low/Medium/High/Critical). The product gives the Risk Priority Number (RPN). Example: Likelihood = 3
(Possible), Impact = 5 (Critical) → RPN = 15 (High Priority)

Risks are typically categorised in a Risk Matrix, with likelihood on one axis and impact on the other. High-
likelihood + high-impact risks receive the most attention and resources.

6.3 Risk Mitigation Strategies

Avoidance Eliminate the risk by changing the approach or plan (e.g., choose a proven
technology instead of an untested one).
Reduction / Mitigation Take actions to reduce the likelihood or impact of the risk (e.g., add more
testing resources to a complex module).
Transfer Transfer the risk to a third party (e.g., outsource a component, purchase
insurance, use a vendor SLA).
Acceptance Acknowledge the risk and prepare a contingency plan. Accept residual risk
when mitigation cost exceeds potential impact.

Page 21 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

Contingency Planning Develop specific response plans to execute if a risk materialises.

6.4 Root Cause Analysis (RCA)

Root Cause Analysis is a structured method for identifying the fundamental cause of a defect or problem, not
just its symptoms. The goal is to prevent recurrence.

Common RCA Techniques

5 Whys Ask 'Why?' five times to drill down from a symptom to its root cause.
Example: Login fails → Why? Database query returns null → Why? Input not
sanitised → Why? No validation was implemented → Why? Requirement was
not clearly specified → Why? No review process for requirements.
Fishbone / Ishikawa Diagram A cause-and-effect diagram that categorises potential causes into major
categories (People, Process, Equipment, Materials, Environment,
Management). Visually maps contributing factors.
Fault Tree Analysis A top-down deductive approach using a tree structure to identify combinations
of events that lead to a failure.
Pareto Analysis Identifies the most significant factors using the 80/20 rule. 80% of defects
typically come from 20% of causes. Focus improvement efforts on those 20%.

6.5 Process Improvement Techniques

CMMI (Capability Maturity A process improvement framework with 5 maturity levels: Initial (ad hoc) →
Model Integration) Managed → Defined → Quantitatively Managed → Optimising. Helps
organisations assess and improve their software development processes.
ISO/IEC 9126 / 25010 International standards for software product quality characteristics
(functionality, reliability, usability, efficiency, maintainability, portability).
Kaizen Japanese philosophy of continuous, incremental improvement involving all
team members. Focus on small, frequent improvements rather than large-scale
overhauls.
Retrospectives Regular team meetings (especially in Agile) to reflect on what went well, what
went wrong, and how to improve in the next iteration.
PDCA Cycle Plan-Do-Check-Act: A four-step iterative cycle for continuous improvement
of processes and products.

6.6 Six Sigma Basics

Six Sigma is a data-driven methodology for eliminating defects and reducing process variation. The goal is to
achieve no more than 3.4 defects per million opportunities (DPMO) — representing 99.99966% defect-free
performance.

Page 22 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• DMAIC (for improving existing processes):

◦ Define: Define the problem, goals, and project scope.
◦ Measure: Measure current process performance and collect data.
◦ Analyse: Analyse data to identify root causes of defects.
◦ Improve: Develop and implement solutions to eliminate root causes.
◦ Control: Monitor the improved process to sustain gains.

• DMADV / DFSS (for designing new processes): Define, Measure, Analyse, Design, Verify.
• Belt System: Green Belt (project leader), Black Belt (expert), Master Black Belt (strategic leader),
Champion (executive sponsor).
• Key Tools: Control Charts, Process Capability Analysis, Statistical Process Control (SPC), FMEA (Failure
Mode and Effects Analysis).

Page 23 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SECTION 7: QUALITY ASSURANCE IN AGILE & DEVOPS

7.1 Test-Driven Development (TDD)

Test-Driven Development is a development practice where developers write failing tests BEFORE writing the
production code. The code is then written to make the tests pass.

The TDD Cycle (Red-Green-Refactor)

1. RED — Write a Failing Write a unit test for a small piece of functionality that does not yet exist. Run
Test the test — it must fail (confirming the feature is not yet implemented).
2. GREEN — Make the Test Write the minimum amount of production code necessary to make the failing
Pass test pass. Do not over-engineer — just enough code to pass.
3. REFACTOR — Improve Clean up the code while keeping all tests green. Remove duplication, improve
the Code naming, apply design patterns. Tests provide a safety net.

• Benefits of TDD: Forces clear requirement understanding, produces self-documenting tests, enables
fearless refactoring, reduces debugging time, improves code design.
• Limitation: Learning curve, takes longer initially, can be difficult with legacy systems or complex external
dependencies.

7.2 Behaviour-Driven Development (BDD)

BDD extends TDD by writing tests in a natural language format that is understandable to both technical and
non-technical stakeholders. It focuses on the behaviour of the system from the user's perspective.

Gherkin Syntax (Given-When-Then)

BDD tests are written using the Gherkin language in a structured format:

BDD Example (Gherkin)

Feature: User Login Scenario: Successful login with valid credentials Given I am on the login page When I
enter valid username 'john@[Link]' and password 'Password123' And I click the Login button Then I
should be redirected to the dashboard And I should see the message 'Welcome, John'

• Key BDD Tools: Cucumber (Java/Ruby/JS), SpecFlow (.NET), Behave (Python), JBehave (Java).
• Benefits: Bridges communication gap between business and development, creates living documentation,
promotes shared understanding of requirements.
• BDD vs TDD: TDD is developer-focused (how does the code work?). BDD is behaviour-focused (what
should the system do from a user's perspective?).

Page 24 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

7.3 Continuous Testing

Continuous Testing is the practice of executing automated tests as part of the software delivery pipeline,
providing immediate feedback on the business risks associated with every software release candidate.

• Tests run automatically after every code commit — no manual trigger required.
• Covers multiple test types: unit, integration, functional, performance, and security — at different pipeline
stages.
• Fast feedback loop: Developers know within minutes if their change broke something.
• Requires a mature test automation suite as the foundation.
• Tools: Jenkins, GitHub Actions, GitLab CI, CircleCI, Bamboo combined with test frameworks like
Selenium, Cypress, JUnit, RestAssured.

7.4 DevOps Pipeline Quality Control

In a DevOps pipeline, quality control is embedded at every stage — not just at the end. The goal is to prevent
defects from progressing to the next stage.

Code Commit / Pre-commit Linting, code formatting checks, and static analysis run before code is
Hooks committed.
Build Stage Compilation errors caught immediately. Unit tests run. Code coverage
measured.
Integration Stage Integration tests, API tests, and contract tests run against a deployed test
environment.
Quality Gates Automated checks that must pass (e.g., minimum code coverage, zero critical
security vulnerabilities) before advancing to the next stage. SonarQube is
commonly used.
Staging/Pre-production Full regression testing, performance testing, and security scanning against a
production-like environment.
Production Deployment Blue-green deployments, canary releases, and feature flags enable safe,
controlled rollouts with monitoring.

7.5 Shift-Left Testing Approach

'Shift-Left' refers to moving testing activities earlier in the Software Development Lifecycle — to the left on a
timeline. Rather than testing only after development is complete, testing begins in the requirements and design
phases.

Shift-Left Practices
• Requirements reviews: Testers review requirements early to identify ambiguities and testability issues
before development begins.

Page 25 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

• Test design during requirements: Test cases are designed as requirements are written (requirements-based
testing).
• Developer unit testing: Developers write and run unit tests as they code (TDD is an extreme form of shift-
left).
• Static analysis: Code is analysed for defects automatically as it is written, without execution.
• Code reviews / pair programming: Peer review catches defects before they are tested.
• Early integration: Frequent integration and testing of components rather than big-bang integration.

Cost Reduction Defects found earlier are exponentially cheaper to fix.

Faster Delivery Fewer defects escaping to later stages means less rework and faster release
cycles.
Better Requirements Early tester involvement improves requirements quality and reduces rework.
Improved Quality Overall defect leakage to production is significantly reduced.

Shift-Left vs Shift-Right
Shift-Left: Test earlier in the lifecycle to prevent defects. Shift-Right: Test in production environments using
techniques like A/B testing, canary releases, chaos engineering, and monitoring to validate real-world
behaviour. Both are complementary in a mature DevOps culture — shift-left for prevention, shift-right for
resilience verification.

Page 26 of 27
 Ndejje University | Software Quality Assurance | Assignment 3

SUMMARY REFERENCE TABLE

Key Testing Levels at a Glance:

Level Scope Performed By Goal

Unit Single function/class Developers Verify code logic
Integration Combined modules/APIs Dev / QA team Verify interfaces
System Complete application QA/Test team Validate requirements
Acceptance Business scenarios Users / Clients Confirm business value

Page 27 of 27