Skip to main content

Unit - 6

TITLE

Software Testing & Quality Assurance​

1. Software Testing Concepts​

Software Testing is a systematic process used to identify defects and ensure software meets requirements before delivery.

1.1 Definition of Testing​

  • Software Testing is the process of executing a program with the intent of finding errors

  • Ensures:

    • Correct functionality
    • Reliability
    • Performance

1.2 Objectives of Testing​

  • Detect defects and errors
  • Ensure software meets requirements
  • Improve quality and reliability
  • Validate system behavior
  • Build confidence before deployment

1.3 Testing Techniques Overview​

Software can be tested using two main approaches:

  • Black-Box Testing

    • Based on requirements
    • Focus on inputs and outputs

  • White-Box Testing

    • Based on internal logic
    • Focus on code structure

👉 Both techniques are complementary

1.4 Interface Testing Guidelines​

Interface Testing ensures correct interaction between system components.

Guidelines:

  • Check data passed between modules
  • Validate input/output formats
  • Handle invalid or unexpected data
  • Test boundary conditions
  • Ensure proper communication between interfaces

1.5 Object-Oriented Testing​

  • Testing focused on objects, classes, and interactions

Focus Areas:

  • Methods and attributes
  • Object states
  • Interaction between objects

Levels:

  • Class testing
  • Integration of objects
  • System-level behavior

1.6 CASE Tool Support​

CASE (Computer-Aided Software Engineering) tools assist in testing.

Functions:

  • Test case generation
  • Test execution automation
  • Bug tracking
  • Reporting and documentation

Benefits:

  • Improves efficiency
  • Reduces manual effort
  • Enhances accuracy

2. Psychology of Testing​

Psychology of Testing focuses on the mindset and principles that make testing effective.

2.1 Traceability to Requirements​

  • Every test should be linked to a requirement

Purpose:

  • Ensures complete coverage
  • Validates that all requirements are tested

2.2 Early Test Planning​

  • Testing should be planned before development begins

Benefits:

  • Better test coverage
  • Early defect detection
  • Improved project control

2.3 Pareto Principle​

  • Also known as the 80/20 rule

Meaning:

  • 80% of defects come from 20% of modules

Implication:

  • Focus testing on critical areas

2.4 Testing from Small to Large​

  • Begin testing at component level and move to full system

Flow:

  • Unit Testing → Integration Testing → System Testing

2.5 Exhaustive Testing Limitation​

  • Testing all possible inputs is not feasible

Reason:

  • Too many combinations
  • Time and cost constraints

👉 Therefore, use selective and smart testing techniques

2.6 Independent Testing​

  • Testing should be done by an independent team

Reason:

  • Developers may overlook their own errors

Benefit:

  • More objective and effective testing

3. Software Testing Phases​

Software testing is performed in stages, progressing from small components to the complete system.

3.1 Component Testing​

  • Testing of individual components (units) of a program
  • Done before integration

3.1.1 Developer-Based Testing​

  • Performed by developers
  • Based on their understanding of the code
  • Uses developer-created test cases

3.1.2 Unit-Level Focus​

  • Focuses on smallest testable units

Goal:

  • Verify each unit works correctly in isolation

3.2 Integration Testing​

  • Testing of combined components to form a system or subsystem

3.2.1 Subsystem Testing​

  • Groups of components are tested together

Goal:

  • Ensure modules interact correctly

3.2.2 System Specification-Based Testing​

  • Tests are based on system specifications

Goal:

  • Verify integrated system behaves as per requirements

4. Testing Process​

Testing Process defines the steps followed to test software systematically.

4.1 Test Case Design​

  • Creation of test cases to verify system behavior

Includes:

  • Input conditions
  • Expected output
  • Test scenarios

Goal:

  • Ensure maximum error detection

4.2 Test Data Preparation​

  • Preparing input data required for testing

Guidelines:

  • Use valid and invalid data
  • Include boundary values

4.3 Test Execution​

  • Running the program using test cases and test data

Activities:

  • Execute test cases
  • Observe outputs

4.4 Result Comparison​

  • Compare actual results with expected results

Outcome:

  • Match → Test Passed
  • Mismatch → Defect found

4.5 Test Reporting​

  • Documenting results of testing

Includes:

  • Test results
  • Defects found
  • Status reports

Purpose:

  • Track progress and quality of software

5. Test Planning​

Test Planning is the most important activity in testing that defines how testing will be performed.

5.1 Definition of Test Plan​

  • A test plan is a document that:

    • Defines testing scope
    • Lists tasks and milestones
    • Estimates testing effort

  • Also called:

    • Master Test Plan / Project Test Plan

5.2 Importance of Test Planning​

  • Provides clear testing direction
  • Helps track project progress
  • Ensures proper resource allocation
  • Improves test effectiveness
  • Reduces risks

5.3 Test Planning Activities​

5.3.1 Scope and Risk Identification​

  • Identify:

    • What will be tested
    • What will NOT be tested
    • Risks involved

5.3.2 Test Strategy Documentation​

  • Define overall testing approach

Includes:

  • Types of testing
  • Tools and techniques
  • Testing methods

5.3.3 Entry and Exit Criteria​

  • Entry Criteria: Conditions to start testing
  • Exit Criteria: Conditions to stop testing

5.3.4 Test Estimation​

  • Estimate:

    • Time required
    • Resources needed
    • Effort involved

5.3.5 Scheduling and Evaluation​

  • Plan:

    • When testing will occur
    • How results will be evaluated

5.3.6 Test Documentation​

  • Prepare:

    • Test cases
    • Test reports
    • Test logs

Goal:

  • Ensure repeatability and proper tracking

6. Test Case Design​

Test Case Design defines how test cases are created to effectively detect errors in software.

6.1 Purpose of Test Case Design​

  • To create test cases that:

    • Detect maximum defects
    • Cover all functionalities
    • Ensure correctness of software

Goal:

  • Increase probability of finding errors

6.2 Completeness of Testing​

  • Test cases should ensure complete coverage

Includes:

  • All functional requirements
  • All possible input conditions
  • Critical paths of execution

Note:

  • Complete (exhaustive) testing is not possible, so effective selection is required

6.3 Black-Box Testing Approach​

  • Testing based on external behavior of the system

Focus:

  • Inputs and outputs
  • Functional requirements

Characteristics:

  • No knowledge of internal code
  • Derived from specifications

Finds errors in:

  • Missing or incorrect functions
  • Interface issues
  • Data handling errors

6.4 White-Box Testing Approach​

  • Testing based on internal structure of code

Focus:

  • Control flow
  • Logic paths
  • Data structures

Characteristics:

  • Requires knowledge of code
  • Tests internal operations

Ensures:

  • All paths are executed
  • All conditions are tested
  • Loops are properly handled

7. Test Execution​

Test Execution is the process of running test cases and comparing actual results with expected results.

7.1 Execution Process​

  • Execute the program using prepared test cases and test data

Steps:

  • Run test cases
  • Capture outputs
  • Compare with expected results

7.2 Test Selection Based on Risk​

  • Select test cases based on risk and priority

Focus:

  • Critical functionalities
  • High-risk areas
  • Frequently used features

7.3 Test Assignment​

  • Assign test cases to testers

Guidelines:

  • Distribute workload properly
  • Match tasks with skill levels

7.4 Bug Reporting​

  • Report defects found during testing

Includes:

  • Bug description
  • Steps to reproduce
  • Severity and priority

7.5 Issue Resolution​

  • Fix reported defects

Process:

  • Developers analyze bugs
  • Apply fixes
  • Retest to confirm resolution

7.6 Status Reporting​

  • Track and report testing progress

Includes:

  • Test execution status
  • Number of passed/failed cases
  • Defect status

8. Levels of Testing​

Levels of Testing define different stages and types of testing used to evaluate software.

8.1 Functional Testing​

8.1.1 Definition​

  • Functional Testing is a type of black-box testing
  • It verifies that software functions according to specified requirements

8.1.2 Steps in Functional Testing​

  1. Identify required functionalities
  2. Create test data based on specifications
  3. Define expected outputs
  4. Execute test cases
  5. Compare actual results with expected results

8.2 Non-Functional Testing​

  • Tests non-functional aspects of software like performance, usability, and security

8.2.1 Performance Testing​

  • Measures speed, response time, and efficiency

8.2.2 Load Testing​

  • Tests system behavior under expected user load

8.2.3 Stress Testing​

  • Tests system under extreme conditions

8.2.4 Usability Testing​

  • Evaluates user-friendliness and ease of use

8.2.5 Security Testing​

  • Checks for vulnerabilities and data protection

8.2.6 Portability Testing​

  • Verifies software works across different platforms and environments

9. Unit Testing​

Unit Testing focuses on testing individual units/components of software in isolation.

9.1 Definition​

  • Unit Testing is the process of testing smallest parts of source code

  • Goal:

    • Ensure each unit works correctly
    • Validate functionality as per requirements

9.2 Developer Responsibility​

  • Performed by developers before handing over to testers

Characteristics:

  • Developers write and execute test cases
  • Based on internal knowledge of code
  • Helps detect errors early

9.3 Test Data Usage​

  • Developers use their own test data

Note:

  • Test data is usually different from QA/testing team data

Purpose:

  • Verify logic under different conditions

9.4 Isolation of Units​

  • Each unit is tested independently

Goal:

  • Isolate and identify defects easily

Challenge:

  • Dependent modules may not be available

Solution:

  • Use:

    • Drivers (simulate calling modules)
    • Stubs (simulate called modules)

10. Integration Testing​

Integration Testing verifies that combined modules work together correctly and that their interfaces behave as expected.

10.1 Definition​

  • Integration Testing is the process of testing interactions between integrated components/modules

Focus:

  • Data flow between modules
  • Interface correctness
  • Communication between components

10.2 Bottom-Up Integration​

  • Testing starts from lower-level modules and moves upward

Process:

  • Test individual units
  • Combine them into higher-level modules
  • Continue integration step-by-step

Support:

  • Uses drivers to simulate higher-level modules

Advantage:

  • Easier debugging (low-level errors found early)

10.3 Top-Down Integration​

  • Testing starts from top-level modules and moves downward

Process:

  • Test main control module first
  • Integrate lower-level modules gradually

Support:

  • Uses stubs to simulate lower-level modules

Advantage:

  • Early validation of system structure and logic

11. System Testing​

System Testing evaluates the complete, integrated system to ensure it meets all specified requirements.

11.1 Definition​

  • System Testing is the process of testing the entire system as a whole

  • Performed after:

    • Unit Testing
    • Integration Testing

11.2 Importance​

  • Verifies overall system functionality
  • Ensures all components work together correctly
  • Detects system-level defects
  • Validates both functional and technical requirements

11.3 Real Environment Testing​

  • Testing is done in an environment similar to production

Purpose:

  • Simulate real-world usage
  • Identify environment-related issues

11.4 Requirement Validation​

  • Ensures system meets user and system requirements

Includes:

  • Functional requirements
  • Performance requirements
  • Business requirements

12. Black-Box Testing​

Black-Box Testing is a technique that tests software based on its external behavior without knowing internal code.

12.1 Definition​

  • Black-Box Testing treats the program as a “black box”

  • Testing is based on:

    • Input values
    • Expected output

12.2 Characteristics​

  • No knowledge of internal logic
  • Based on specifications and requirements
  • Focus on input-output behavior
  • Can be designed early in development

12.3 Functional Testing Basis​

  • Black-Box Testing is mainly used for functional testing

Purpose:

  • Verify system performs required functions
  • Validate outputs against given inputs

12.4 Error Categories​

Black-Box Testing helps detect the following errors:

12.4.1 Missing Functions​

  • Required functionality is not implemented

12.4.2 Interface Errors​

  • Errors in interaction between modules or systems

12.4.3 Data Structure Errors​

  • Issues in:

    • Data handling
    • Database access

12.4.4 Performance Errors​

  • System behaves incorrectly under:

    • Load
    • Stress

12.4.5 Initialization Errors​

  • Errors during:

    • Startup
    • Shutdown

13. Boundary Value Analysis (BVA)​

Boundary Value Analysis is a black-box testing technique that focuses on testing values at the edges (boundaries) of input and output domains.

13.1 Definition​

  • BVA selects test cases at the boundary values rather than random values

Reason:

  • Errors are most likely to occur at boundaries

13.2 Input Domain Testing​

  • Test inputs at:

    • Minimum value
    • Maximum value
    • Just below minimum
    • Just above maximum

Example:

  • If range = 1 to 100

    • Test: 0, 1, 2, 99, 100, 101

13.3 Output Domain Testing​

  • Apply BVA to output conditions as well

Goal:

  • Ensure correct output at boundary limits

13.4 Guidelines​

13.4.1 Range Boundaries​

  • For range [a, b], test:

    • a
    • b
    • just below a
    • just above b

13.4.2 Min-Max Values​

  • Test:

    • Minimum values
    • Maximum values
    • Values just above and below them

13.4.3 Internal Data Structures​

  • Test boundaries of:

    • Arrays
    • Buffers
    • Data structures

Purpose:

  • Detect overflow, underflow, and limit-related errors

14. Pairwise Testing​

Pairwise Testing is a technique used to test software by checking all possible pairs of input parameters.

14.1 Definition​

  • Pairwise Testing is a method where every possible pair of input values is tested at least once

Goal:

  • Detect defects caused by interaction between parameters

14.2 Permutation and Combination Method​

  • Based on Permutation & Combination (P&C)

Concept:

  • Instead of testing all combinations (which is huge), test pair combinations of inputs

Benefit:

  • Reduces number of test cases significantly

14.3 Parameter Combinations​

  • For a system with multiple inputs:

    • All possible pairs of parameters are tested

Example:

  • Parameters: A, B, C

  • Test combinations:

    • (A,B), (A,C), (B,C)

14.4 Advantages​

  • Reduces number of test cases
  • High test coverage (near complete for pairs)
  • Detects interaction-based defects
  • Saves time and cost

14.5 Disadvantages​

  • May miss defects involving more than two parameters
  • Requires understanding of parameter relationships
  • Incorrect selection can reduce effectiveness

15. State-Based Testing​

State-Based Testing focuses on testing software by analyzing states of objects and transitions between them.

15.1 Object Modeling​

  • Identify objects in the system and their behavior

Includes:

  • Object states
  • Attributes
  • Interactions

Goal:

  • Understand how objects behave under different conditions

15.2 Relationship Graphs​

  • Represent system using a graph structure

Components:

  • Nodes → represent objects
  • Links → represent relationships

Purpose:

  • Visualize interactions
  • Ensure all relationships are tested

  • Graph consists of:

    • Nodes (objects)
    • Links (relationships)
    • Node weights (object properties)
    • Link weights (relationship characteristics)
  • Relationship flows in one direction only

Example:

  • A → B
  • Relationship exists in both directions

Example:

  • A ↔ B
  • Multiple relationships between the same nodes

Purpose:

  • Represent different types of interactions

15.4 Graph-Based Testing Methods​

15.4.1 Transaction Flow Modeling​

  • Nodes represent steps in a transaction
  • Links represent sequence of operations

15.4.2 Finite State Modeling​

  • Nodes represent system states
  • Links represent state transitions

Example:

  • Login → Dashboard → Logout

15.4.3 Data Flow Modeling​

  • Nodes represent data objects
  • Links represent data transformations

15.4.4 Timing Modeling​

  • Focus on execution timing between components

Includes:

  • Sequence of operations
  • Time constraints

16. White-Box Testing​

White-Box Testing is a technique that tests software based on its internal structure and logic.

16.1 Definition​

  • White-Box Testing involves testing the internal working of the program

  • Requires knowledge of:

    • Code
    • Logic
    • Control flow

16.2 Control Structure Testing​

  • Focuses on program control structures

Includes:

  • Conditions (if-else)
  • Loops
  • Branching

Goal:

  • Ensure all control paths are tested

16.3 Path Coverage​

  • Ensures all independent paths in the program are executed

Purpose:

  • Detect logical errors
  • Improve test coverage

16.4 Loop Testing​

  • Tests loops under different conditions

Cases:

  • Zero iterations
  • One iteration
  • Multiple iterations
  • Boundary conditions

16.5 Data Structure Validation​

  • Verifies correctness of internal data structures

Checks:

  • Data integrity
  • Proper initialization
  • Correct data manipulation

17. Basis Path Testing​

Basis Path Testing is a white-box testing technique that uses the program’s control flow to design a minimum set of test cases which guarantees execution of every independent path at least once.

17.1 Definition​

  • Introduced as part of structured testing techniques
  • Uses flow graphs + cyclomatic complexity

Key Idea:

  • Instead of testing all paths (impossible), test a basis set of paths

17.2 Flow Graph Notation​

A flow graph is a graphical representation of program logic.

17.2.1 Nodes​

  • Represent:

    • Single statement OR
    • Sequence of statements

Example:

  • Assignment statements grouped into one node

17.2.2 Edges​

  • Represent flow of control (execution path)

Note:

  • Every edge must connect two nodes

17.2.3 Regions​

  • Closed areas formed by nodes and edges

Important:

  • Number of regions = Cyclomatic Complexity

17.2.4 Predicate Nodes​

  • Nodes containing decision conditions

Examples:

  • if, while, for

Property:

  • Have two or more outgoing edges

17.3 Independent Paths​

  • A path that introduces at least one new edge or condition

Important Points:

  • Each new path must add new logic coverage
  • Combination of already covered paths is not independent

Example Concept:

  • If a program has 4 independent paths → minimum 4 test cases needed

17.4 Cyclomatic Complexity​

  • A metric that measures logical complexity of program

Uses:

  • Determines number of independent paths
  • Defines minimum number of test cases

17.4.1 Formula (E - N + 2)​

V(G)=E-N+2

  • E = Number of edges
  • N = Number of nodes

17.4.2 Formula (P + 1)​

V(G)=P+1

  • P = Number of predicate (decision) nodes

17.4.3 Regions Method​

  • Cyclomatic Complexity = Number of regions in flow graph

17.5 Deriving Test Cases​

This is a step-by-step process:

17.5.1 Flow Graph Creation​

  • Convert program or pseudo-code into a flow graph
  • Assign numbers to nodes

17.5.2 Complexity Calculation​

  • Compute V(G) using:

    • Edges & nodes
    • Predicate nodes
    • Regions

👉 This gives number of test cases required

17.5.3 Path Identification​

  • Identify all independent paths

Example Idea:

  • Path 1 → Straight execution
  • Path 2 → Condition true
  • Path 3 → Condition false
  • Path 4 → Loop path

17.5.4 Test Case Generation​

  • Design test cases such that:

    • Each path is executed at least once
    • Conditions are tested (true & false)

Result:

  • Ensures:

    • Complete statement coverage
    • Logical correctness
    • Reduced redundant testing

🔁 Summary Insight​

  • Cyclomatic Complexity = No. of independent paths = Minimum test cases
  • Basis Path Testing ensures maximum logic coverage with minimum effort

18. Graph Matrices​

Graph Matrices are a tabular representation of a flow graph used to analyze control flow and program complexity.

18.1 Definition​

  • A Graph Matrix is a square matrix used to represent relationships between nodes in a flow graph

Purpose:

  • Simplify analysis of control structure
  • Help in calculating complexity

18.2 Matrix Representation​

  • Matrix size = number of nodes × number of nodes

Structure:

  • Rows → represent source nodes
  • Columns → represent destination nodes
  • Cell value → indicates connection (edge)

Example:

  • If node i connects to node j → entry (i, j) = 1
  • Each connection (edge) can have a weight

Types:

  • 1 → connection exists
  • 0 → no connection

Advanced:

  • Weights can represent:

    • Execution time
    • Probability
    • Cost

18.4 Connection Matrix​

  • A simplified graph matrix where:

    • All edges are marked as 1
    • No edge = 0

Property:

  • Each row with 2 or more 1s represents a predicate node

18.5 Complexity Calculation Using Matrix​

  • Cyclomatic Complexity can be computed using matrix:

Steps:

  1. Count connections in each row
  2. Subtract 1 from each row count
  3. Sum all values
  4. Add 1

Formula:

  • V(G) = (Total connections − number of nodes) + 1

Simplified:

  • V(G) = Sum of (connections per row − 1) + 1

🔁 Key Insight​

  • Graph Matrix = alternative to flow graph

  • Makes:

    • Complexity calculation easier
    • Control flow analysis systematic

19. Quality Concepts​

Quality Concepts define what makes software reliable, efficient, and acceptable to users.

19.1 Definition of Quality​

  • Quality is a characteristic or attribute of a product

In software:

  • It means meeting:

    • Requirements
    • Standards
    • User expectations

19.2 Quality of Design​

  • Refers to how well the software is designed according to requirements

Includes:

  • System architecture
  • Specifications
  • Design decisions

Key Point:

  • Better design → higher potential quality

19.3 Quality of Conformance​

  • Refers to how well the software follows the design specifications during implementation

Focus:

  • Coding standards
  • Implementation accuracy

Key Point:

  • Even a good design fails if implementation is poor

19.4 User Satisfaction​

  • Final measure of quality

Formula (conceptual):

  • User Satisfaction = ✔ Correct functionality ✔ Good quality ✔ Delivered on time and within budget

Goal:

  • Meet user expectations and provide reliable performance

20. Quality Control​

Quality Control (QC) focuses on detecting defects in software products through systematic activities.

20.1 Definition​

  • Quality Control is the process of:

    • Monitoring software products
    • Ensuring they meet defined specifications and standards

  • It involves:

    • Testing
    • Reviews
    • Inspections

20.2 Inspection and Review​

  • QC uses formal and informal evaluation techniques

Inspection:

  • Structured process

  • Detects defects in:

    • Code
    • Design
    • Documents

Review:

  • Less formal

  • Includes:

    • Walkthroughs
    • Peer reviews

Goal:

  • Identify defects early

20.3 Feedback Mechanism​

  • QC includes a feedback loop

Purpose:

  • Send defect information back to development

Benefits:

  • Improves process quality
  • Reduces future errors
  • Enables continuous improvement

21. Quality Assurance (QA)​

Quality Assurance focuses on preventing defects by ensuring proper processes, standards, and practices are followed.

21.1 Definition​

  • Quality Assurance is the process of:

    • Auditing and monitoring software processes
    • Ensuring compliance with standards

Key Idea:

  • QA is process-oriented (prevention, not just detection)

21.2 Role of QA​

  • Ensure development follows defined processes and standards

Activities:

  • Process monitoring
  • Audits and reviews
  • Reporting quality issues
  • Supporting improvement of development practices

Goal:

  • Achieve high-quality software

21.3 Management Responsibilities​

  • Management is responsible for:

    • Addressing issues identified by QA
    • Providing resources to fix problems
    • Enforcing quality standards

Importance:

  • QA is effective only if management takes corrective actions

22. Cost of Quality​

Cost of Quality refers to the total cost involved in ensuring software quality and the cost incurred due to poor quality.

22.1 Definition​

  • Cost of Quality includes:

    • Cost to prevent defects
    • Cost to detect defects
    • Cost due to failures

👉 Goal: Minimize total cost while maintaining high quality

22.2 Prevention Cost​

  • Cost incurred to avoid defects before they occur

Includes:

  • Quality planning
  • Training
  • Formal technical reviews
  • Test tools and equipment

Key Idea:

  • Investing here reduces overall cost

22.3 Appraisal Cost​

  • Cost of evaluating and testing software

Includes:

  • Inspections
  • Testing activities
  • Quality audits
  • Equipment calibration

Purpose:

  • Detect defects before delivery

22.4 Failure Cost​

  • Cost due to defects in software

22.4.1 Internal Failure​

  • Defects found before delivery

Examples:

  • Rework
  • Debugging
  • Retesting

22.4.2 External Failure​

  • Defects found after delivery

Examples:

  • Customer complaints
  • Product replacement
  • Maintenance and support
  • Warranty costs

🔁 Key Insight​

  • Total Cost of Quality = Prevention + Appraisal + Failure Costs

👉 Better prevention → lower failure cost → overall cost reduces

23. Software Quality Assurance (SQA)​

SQA ensures that software is developed with high quality by following proper standards, processes, and practices.

23.1 Definition​

  • Software Quality Assurance is defined as:

    • Conformance to explicitly stated requirements
    • Adherence to documented standards
    • Meeting implicit expectations of professional software

Key Idea:

  • Quality is measured against:

    • Requirements
    • Standards
    • User expectations

23.2 Key Points​

  • Requirements are the foundation of quality
  • Following standards is essential for consistency
  • Implicit requirements (like usability, reliability) also matter

Focus:

  • Prevent defects
  • Improve development process
  • Ensure product quality

23.3 SQA Group​

23.3.1 Composition​

  • SQA group consists of:

    • Software engineers
    • Project managers
    • Customers
    • Quality specialists

23.3.2 Responsibilities​

  • Prepare SQA plan
  • Define standards and procedures
  • Conduct audits and reviews
  • Monitor development process
  • Report quality issues
  • Maintain documentation

Goal:

  • Help team deliver a high-quality software product

24. Role of SQA Group​

The SQA Group ensures that software development follows defined standards and processes to achieve high quality.

24.1 SQA Plan Preparation​

  • Prepares a Software Quality Assurance (SQA) Plan during project planning

Includes:

  • Evaluations to be performed
  • Audits and reviews
  • Applicable standards
  • Error reporting procedures
  • Documents to be produced
  • Feedback mechanisms

24.2 Process Participation​

  • Participates in defining the software development process

Role:

  • Helps establish:

    • Methods
    • Procedures
    • Standards

24.3 Compliance Review​

  • Reviews development activities to ensure process compliance

Checks:

  • Adherence to standards
  • Proper implementation of procedures

24.4 Audit Activities​

  • Conducts audits of software work products

Purpose:

  • Verify compliance with defined processes
  • Identify deviations

24.5 Work Product Review​

  • Reviews selected work products such as:

    • Requirements
    • Design documents
    • Code

Goal:

  • Ensure quality and correctness
  • Detect defects early

25. Software Reliability​

Software Reliability refers to how dependably software performs without failure over a period of time in a given environment.

25.1 Definition​

  • Software Reliability is defined as the probability of failure-free operation of a program for a specified time under specified conditions

25.2 Failure Concept​

  • A failure occurs when software does not meet its requirements

Key Points:

  • Failure = deviation from expected behavior
  • Fixing one failure may sometimes introduce new errors

25.3 Importance​

  • Builds user trust
  • Reduces system crashes
  • Saves time and cost
  • Ensures consistent performance

Goal:

  • Deliver software that works correctly and reliably over time

26. Measures of Reliability and Availability​

These metrics are used to quantify software reliability and system performance over time.

26.1 MTBF (Mean Time Between Failures)​

  • MTBF represents the average time between two consecutive failures

Formula:

  • MTBF = MTTF + MTTR

Meaning:

  • Higher MTBF → more reliable system

26.2 MTTF (Mean Time to Failure)​

  • MTTF is the average time the system operates before a failure occurs

Used for:

  • Non-repairable systems

Meaning:

  • Higher MTTF → longer failure-free operation

26.3 MTTR (Mean Time to Repair)​

  • MTTR is the average time required to fix a failure

Includes:

  • Detection time
  • Repair time
  • Recovery time

Meaning:

  • Lower MTTR → faster recovery

26.4 Availability Formula​

Availability=MTTFMTTF+MTTRAvailability=\frac{MTTF}{MTTF+MTTR}

Meaning:

  • Availability shows the probability that the system is operational at a given time

🔁 Key Insight​

  • High reliability system:

    • High MTTF
    • Low MTTR
    • High Availability

27. Quality Standards​

Quality Standards define the guidelines and rules that ensure software is developed and maintained with consistent quality.

27.1 SQA Standards Classification​

SQA standards are broadly classified into two categories:

27.1.1 Management Standards​

  • Focus on organizational and managerial aspects of quality

Includes:

  • Project planning
  • Quality policies
  • Resource management
  • Organizational procedures

Purpose:

  • Ensure proper management and control of software development

27.1.2 Process Standards​

  • Focus on technical and development processes

Includes:

  • Development methodologies
  • Coding standards
  • Testing procedures
  • Documentation practices

Purpose:

  • Ensure consistency and quality in software processes

28. Quality Management Standards​

Quality Management Standards define how an organization manages processes, resources, and practices to ensure consistent software quality.

28.1 Organizational Focus​

  • Emphasis on organization-wide quality improvement

Includes:

  • Establishing quality policies
  • Continuous process improvement
  • Customer satisfaction focus

Goal:

  • Build a culture of quality across the organization

28.2 Infrastructure Requirements​

  • Requires proper supporting structure and resources

Includes:

  • Trained personnel
  • Defined processes and procedures
  • Tools and technologies
  • Documentation systems

Purpose:

  • Ensure smooth implementation of quality standards

28.3 Examples (ISO 9000, CMM)​

  • ISO 9000 Series

    • International standards for quality management systems
    • Focus on documentation and process control

  • CMM (Capability Maturity Model)

    • Framework to assess process maturity levels

    • Levels range from:

      • Initial → Repeatable → Defined → Managed → Optimizing

Goal:

  • Improve process capability and software quality

29. ISO 9001 Certification​

ISO 9001 Certification ensures that an organization follows a standardized Quality Management System (QMS).

29.1 Definition​

  • ISO 9001 is an international standard for quality management systems

Purpose:

  • Ensure consistent product/service quality
  • Improve customer satisfaction

29.2 ISO Organization​

  • ISO (International Organization for Standardization) is a global body that develops standards

Characteristics:

  • Works with national standard organizations
  • Publishes international quality standards

29.3 Standard Development Process​

  • Standards are developed through a structured process

Steps:

  1. Proposal of new standard
  2. Draft preparation
  3. Review by experts
  4. Approval and publication

Goal:

  • Ensure global acceptance and consistency

29.4 Certification Process​

  • Process to obtain ISO 9001 certification:

Steps:

  1. Develop and implement QMS
  2. Document processes and procedures
  3. Conduct internal audits
  4. Apply for certification
  5. External audit by certification body
  6. Certification granted if compliant

Outcome:

  • Organization is officially recognized for maintaining quality standards