Software Quality Assurance Past Paper Solution 2022

Short Questions Answers.

### i) Process Quality and Its Impact on Product Quality

**Process Quality** refers to the adherence to predefined standards, procedures, and

best practices during the software development lifecycle. It focuses on how well the
development process is defined, managed, and implemented to ensure consistent and
high-quality outcomes.

#### Key Aspects of Process Quality:

1. **Standardization**: Using established standards and methodologies (e.g., Agile,

Waterfall, CMMI).

2. **Documentation**: Maintaining clear and comprehensive documentation for all

stages of development.

3. **Consistency**: Ensuring repeatability and uniformity in the development process.

4. **Measurement and Metrics**: Collecting and analyzing data to monitor process

performance.

5. **Continuous Improvement**: Regularly refining processes based on feedback and

performance metrics.

#### How Process Quality Impacts Product Quality:

1. **Reduced Defects**:

- **Impact**: High process quality ensures thorough planning, design, coding, and
testing practices, leading to fewer defects in the final product.

- **Example**: A well-defined code review process catches errors early, reducing bugs
in the final software.

2. **Enhanced Reliability**:
 - **Impact**: Consistent application of best practices ensures that the product
performs reliably under various conditions.

- **Example**: Regular performance testing during development helps ensure the

product can handle expected load and stress.

3. **Improved Maintainability**:

- **Impact**: Good process quality includes maintaining proper documentation and

modular design, making the software easier to maintain and update.

- **Example**: A clear coding standard and documentation make it easier for new
developers to understand and modify the codebase.

4. **Better Usability**:

- **Impact**: Including user feedback and usability testing as part of the process
ensures the final product meets user expectations.

- **Example**: Iterative usability testing sessions help identify and fix user interface
issues before the product launch.

5. **Enhanced Security**:

- **Impact**: Following security best practices throughout the development process

leads to a more secure product.

- **Example**: Regular security audits and threat modeling during development

mitigate potential security vulnerabilities.

6. **Increased Customer Satisfaction**:

- **Impact**: High process quality leads to products that meet requirements and
perform reliably, leading to greater customer satisfaction.

- **Example**: A product developed with rigorous testing and validation processes is

less likely to fail in the field, leading to higher customer trust and satisfaction.

7. **Cost Efficiency**:
 - **Impact**: Early detection and prevention of defects through a high-quality process
reduce the cost of fixing issues later.

- **Example**: Identifying design flaws during the requirements and design phases is
significantly less expensive than fixing them after the product has been deployed.

#### Example of Process Quality Impacting Product Quality:

**Scenario**: A software development company decides to adopt Agile methodologies

to improve their development process.

1. **Planning**: Detailed user stories and acceptance criteria are created and reviewed
in planning sessions.

2. **Development**: Developers adhere to coding standards and perform regular peer

reviews.

3. **Testing**: Continuous integration and automated testing ensure code quality and
catch defects early.

4. **Feedback**: Regular sprint reviews and retrospectives provide opportunities for

continuous improvement.

**Outcome**: The final product has fewer defects, higher reliability, and better user
satisfaction due to the disciplined and iterative nature of the Agile process.

### ii) Clearly Differentiate Between Verification and Validation

**Verification** and **Validation** are both crucial activities in the software

development lifecycle, but they serve different purposes:

#### Verification:

- **Definition**: Verification is the process of evaluating software to ensure it meets the

requirements and design specifications.
- **Objective**: Ensure the product is built correctly according to the specified
requirements.

- **Focus**: Focuses on processes, documentation, and intermediate products.

- **Activities**: Includes reviews, inspections, walkthroughs, and desk-checking.

- **Questions Addressed**: “Are we building the product right?”

- **Example**: Reviewing a software requirements specification document to ensure it

accurately captures all user requirements.

#### Validation:

- **Definition**: Validation is the process of evaluating the final product to ensure it

meets the user’s needs and expectations.

- **Objective**: Ensure the right product is built, fulfilling its intended purpose.

- **Focus**: Focuses on the actual product and its functionality.

- **Activities**: Includes testing (unit, integration, system, acceptance).

- **Questions Addressed**: “Are we building the right product?”

- **Example**: Conducting user acceptance testing to ensure the software performs as

expected in real-world scenarios.

### iii) Explain the Key Differences Between Software Quality Assurance and Software
Quality Control

#### Software Quality Assurance (SQA):

- **Definition**: SQA is a proactive process that focuses on ensuring the quality of the
software development process and preventing defects.

- **Objective**: Ensure the processes used to manage and create deliverables are
adequate to produce high-quality products.

- **Activities**: Process definition and implementation, audits, training, process

improvement, and standards compliance.

- **Timing**: Conducted throughout the software development lifecycle.

- **Focus**: Process-oriented.
- **Example**: Establishing a set of coding standards and performing audits to ensure
compliance.

#### Software Quality Control (SQC):

- **Definition**: SQC is a reactive process that focuses on identifying defects in the

actual products produced.

- **Objective**: Ensure the final product meets quality requirements and is free of
defects.

- **Activities**: Testing, reviews, inspections, and defect tracking.

- **Timing**: Typically conducted after the product has been developed.

- **Focus**: Product-oriented.

- **Example**: Performing system testing to find and fix defects before the product is
released.

### vi) Define Software Testing. List a Few of the Objectives of Software Testing

**Software Testing** is the process of executing a program or application with the intent
of finding defects and ensuring that the software functions as expected.

#### Objectives of Software Testing:

1. **Identify Defects**: Discover and document defects or bugs in the software.

2. **Ensure Quality**: Verify that the software meets the specified requirements and
standards.

3. **Verify Functionality**: Ensure that the software performs as intended and all
features work correctly.

4. **Enhance Reliability**: Increase confidence in the software’s reliability and stability.

5. **Validate User Expectations**: Confirm that the software meets user needs and
expectations.

6. **Prevent Defects**: Identify potential issues early to prevent defects from reaching
the production stage.
### v) Define a Test Case? When Are Test Cases Created?

#### Test Case:

A **test case** is a set of conditions or variables under which a tester determines

whether a system or software application is working correctly. It typically includes:

- **Test Case ID**: A unique identifier for the test case.

- **Test Description**: A brief description of what the test case will verify.

- **Preconditions**: Any conditions that must be met before the test can be executed.

- **Test Steps**: Detailed steps to execute the test.

- **Expected Result**: The expected outcome if the system behaves as intended.

- **Actual Result**: The actual outcome when the test is executed.

- **Status**: Indicates whether the test case passed or failed.

#### When Are Test Cases Created?

Test cases are typically created during the test design phase of the software testing life
cycle, after the requirements have been analyzed and understood. They are based on
the software requirements specification, design documents, and user stories.

### vi) What is a Walkthrough in Software Testing?

A **walkthrough** is a type of informal review in which the author of a document or

code leads the review session and presents the material to a group of peers. The
primary purpose is to gather feedback and identify defects or areas for improvement.
Walkthroughs are less formal than inspections and do not require preparation by the
participants.

#### Key Features of Walkthroughs:

- **Purpose**: To review documents or code for defects and gather feedback.

- **Participants**: Typically includes the author, reviewers (peers), and sometimes a
moderator.

- **Process**: The author presents the material step-by-step, explaining the rationale
and logic.

- **Feedback**: Reviewers provide feedback, ask questions, and suggest

improvements.

- **Formality**: Less formal than inspections, often conducted in an ad-hoc manner.

- **Output**: Notes and feedback collected during the session, which the author uses
to make improvements.

Walkthroughs help improve the quality of software artifacts by leveraging the collective
knowledge and experience of the team, identifying issues early, and facilitating
knowledge sharing.

Long Questions Answers.

Sure, let’s address each question in detail:

### Q.3: Define Quality and Software Quality. State and Briefly Explain Different Quality
Factors

**Quality**: Quality refers to the degree to which a product or service meets the
customer’s expectations, requirements, or specifications. It is often assessed based on
attributes such as reliability, usability, performance, and maintainability.

**Software Quality**: Software quality is the degree to which software meets specified
requirements, user expectations, and is free of defects. It encompasses various
attributes that contribute to the overall effectiveness and efficiency of the software.

#### Different Quality Factors:

1. **Functionality**:

- **Definition**: The degree to which the software performs its intended functions
correctly.

- **Attributes**: Suitability, accuracy, interoperability, security.

2. **Reliability**:

- **Definition**: The ability of the software to perform consistently under specified

conditions.

- **Attributes**: Maturity, fault tolerance, recoverability.

3. **Usability**:

- **Definition**: The ease with which users can learn, operate, and interact with the
software.

- **Attributes**: Understandability, learnability, operability, attractiveness.

4. **Efficiency**:

- **Definition**: The software’s ability to provide appropriate performance relative to

the amount of resources used.

- **Attributes**: Time behavior, resource utilization, capacity.

5. **Maintainability**:

- **Definition**: The ease with which the software can be modified to correct defects,
improve performance, or adapt to a changing environment.

- **Attributes**: Analyzability, changeability, stability, testability.

6. **Portability**:

- **Definition**: The ease with which the software can be transferred from one
environment to another.

- **Attributes**: Adaptability, installability, conformance, replaceability.

### Q.4: What is the Difference Between Defect and Failure in Software Testing? What is
the Cost of Defect?

**Defect**: A defect is an error or bug in the software code that causes the software to
behave incorrectly or produce incorrect results. It is an issue identified during the
development or testing phases.

**Failure**: A failure occurs when the software does not perform its intended function
or deviates from the expected behavior during actual usage. Failures are the
manifestation of defects when the software is in operation.

#### Difference:

- **Defect**: Found during development and testing. Example: Incorrect

implementation of a function in the code.

- **Failure**: Encountered during actual usage by the end-user. Example: Application

crashes when a specific input is provided.

#### Cost of Defect:

The cost of a defect increases significantly the later it is found in the software
development lifecycle. The stages are:

1. **Requirements Phase**: Least expensive to fix. Errors are identified and corrected
during requirements gathering.

2. **Design Phase**: More expensive than requirements phase but still manageable.
Errors found here require changes to the design and possibly some rework.

3. **Development Phase**: More costly as it involves code changes, unit testing, and
possible rework of related components.

4. **Testing Phase**: Even more costly as defects require re-coding, re-testing, and re-
verification of the software.

5. **Post-Release**: Most expensive as defects found in the production environment

can cause user dissatisfaction, potential loss of revenue, emergency patches, and
extensive regression testing.
### Q.5: What is a Quality Standard? Describe the Characteristics of ISO 9126 for
Quality Assurance.

**Quality Standard**: A quality standard is a set of guidelines, criteria, or specifications

established by an authority to ensure that products or services meet certain quality
requirements. Standards help maintain consistency, reliability, and safety in products
and services.

#### Characteristics of ISO 9126 for Quality Assurance:

ISO 9126 is an international standard for software quality, defining a model for software
quality characteristics and sub-characteristics:

1. **Functionality**:

- **Suitability**: Appropriateness of the functions for specified tasks.

- **Accuracy**: Correctness of the functions.

- **Interoperability**: Ability to interact with specified systems.

- **Security**: Protection against unauthorized access.

- **Compliance**: Adherence to standards and regulations.

2. **Reliability**:

- **Maturity**: Frequency of software failures.

- **Fault Tolerance**: Ability to maintain performance under fault conditions.

- **Recoverability**: Ability to recover from failures.

3. **Usability**:

- **Understandability**: Ease of understanding the software.

- **Learnability**: Ease of learning to use the software.

- **Operability**: Ease of operation and control.

 - **Attractiveness**: User satisfaction with the software.

4. **Efficiency**:

- **Time Behavior**: Response and processing times.

- **Resource Utilization**: Efficient use of resources.

5. **Maintainability**:

- **Analyzability**: Ease of diagnosing defects.

- **Changeability**: Ease of making changes.

- **Stability**: Minimal impact of changes on existing functionality.

- **Testability**: Ease of testing the software.

6. **Portability**:

- **Adaptability**: Ability to adapt to different environments.

- **Installability**: Ease of installation.

- **Co-existence**: Ability to co-exist with other systems.

- **Replaceability**: Ease of replacing the software with another.

### Q.6: Compare Black Box Testing, White Box Testing, and Grey Box Testing

#### Black Box Testing:

- **Definition**: Testing the software without knowing the internal code structure.
Focuses on input and output.

- **Objective**: Validate the functionality of the software according to requirements.

- **Techniques**: Equivalence partitioning, boundary value analysis, decision table

testing.

- **Example**: Testing a login form by entering valid and invalid credentials and verifying
the outcomes.
#### White Box Testing:

- **Definition**: Testing the internal structures or workings of an application. Requires

knowledge of the code.

- **Objective**: Validate the flow of inputs through the code and identify issues in code
structure.

- **Techniques**: Path testing, statement coverage, branch coverage, loop testing.

- **Example**: Testing each function and conditional loop in the code to ensure they
work as intended.

#### Grey Box Testing:

- **Definition**: Combines elements of both black box and white box testing. Partial
knowledge of internal structures is used.

- **Objective**: Improve test coverage by focusing on both the internal logic and the
outputs.

- **Techniques**: Matrix testing, regression testing, pattern testing.

- **Example**: Testing a web application by understanding the database schema and

testing both user inputs and database queries.

#### Comparison:

- **Knowledge of Internal Structure**:

- **Black Box**: No knowledge required.

- **White Box**: Full knowledge required.

- **Grey Box**: Partial knowledge required.

- **Focus**:

- **Black Box**: Functionalities and user interfaces.

- **White Box**: Code, logic, and paths.

- **Grey Box**: Integration of functional and structural testing.

- **Techniques**:

- **Black Box**: Functional testing techniques.

- **White Box**: Structural testing techniques.

- **Grey Box**: Combination of both functional and structural techniques.

- **Tester’s Perspective**:

- **Black Box**: End-user perspective.

- **White Box**: Developer perspective.

- **Grey Box**: Integrator perspective.