1. What is the distinction between validation and verification?

1. Verification checks if the software is built correctly, following the specified design
and requirements. It involves reviewing documents, design, code, and program, but
does not involve executing the code.
2. Validation, on the other hand, checks if the right software is built, i.e., if it meets the
customer’s requirements and expectations. It involves testing and validating the actual
product, which includes executing the code.
2. What are the advantages of inspections over testing?
Inspections have several advantages over testing in software development:
1. Early Defect Detection: Inspections can identify defects at the early stages of the
Software Development Life Cycle (SDLC), preventing defective software from
flowing down to subsequent operations.
2. Cost-Effective: Defects found later in the project not only cost more to fix, but also
result in wasted work from incorrect design and/or requirements. Inspections can
minimize the cost of solving defects to a great extent.
3. Broad Coverage: Inspections cover a greater range of development phases and can
identify various types of bugs, making them more comprehensive than testing.
4. No Execution Required: Since inspections do not require system execution,
incomplete versions of a system can be inspected without additional costs.
5. Unmasking Errors: During testing, errors can mask (hide) other errors. Because
inspection is a static process, you don’t have to be concerned with interactions
between errors.
6. Educational Benefits: Inspections are useful for educating new employees on the
product, and on the standards and procedures used in the organization
3. Briefly describe the three principal stages of testing for a commercial software system
The three principal stages of testing for a commercial software system are:
1. Development Testing: This is the first stage where the system is tested during
development to discover bugs and defects.
2. Release Testing: In this stage, a separate testing team tests a complete version of the
system before it is released to users.
3. Post-Release Testing: This is the final stage where the system is tested in the real-
world environment by the end users. It’s also known as User Acceptance Testing
(UAT). This stage helps in identifying any issues that were not found during the
development and release testing stages.

4. What tests should be included in object class testing?

Object class testing in object-oriented programming involves several techniques:

1. Fault-Based Testing: This technique allows for designing test cases based on the user
specification.
2. Class Testing Based on Method Testing: This is the simplest approach to test
classes. Each method of the class performs a well-defined cohesive function and can,
therefore, be related to unit testing of the traditional testing techniques.
3. Random Testing: It is based on developing a random test sequence that tries the
minimum number of operations.
4. Partition Testing: This method categorizes the inputs and outputs of a class in order to
test them.
In addition to these techniques, the following aspects should also be considered during object
class testing:
  List of object states to be tested.
 List of messages and operations (methods) to be tested.
 List of exceptions that may occur as the object is tested.

5. What guidelines does Whittaker suggest for defect testing?

James Whittaker, a renowned software engineer and author, has proposed a taxonomy-based
approach to software testing, which can be considered as guidelines for defect testing. Here
are some key points:
1. Use of Taxonomies: Whittaker suggests the use of taxonomies or classifications of
defects to guide the creation of test cases. This means creating test cases to discover
faults like the ones we have experienced before.
2. Fault Models: He describes a “fault model” as a list of typical defects that occur in
systems. This is also known as a defect taxonomy.
3. Two Approaches to Testing: Whittaker describes two approaches to testing:
 The first uses a “non-specific fault model”, where no defect taxonomy is used.
Using this approach, the requirements and specifications guide the creation of all
test cases.
 The second approach uses a “specific fault model”, where a taxonomy of defects
guides the creation of test cases.
4. Project Level and Software Defect Level Taxonomies: Whittaker considers two levels
of taxonomies—project level and software defect level. Of most importance in test
design are the software defect taxonomies.
5. Improvement of Development and Testing Process: The use of taxonomies can help
improve your development process, testing process, and train new testers regarding
important areas that deserve testing.
6. What is an equivalence partition? Give an example.
Equivalence Partitioning is a software testing technique that divides the input data of a
software unit into partitions of equivalent data from which test cases can be derived. This
technique tries to define test cases that uncover classes of errors, thereby reducing the total
number of test cases that must be developed. It’s also known as Equivalence Class
Partitioning (ECP).
Here’s an example of equivalence partitioning:
Consider a software application that accepts a password between 8 to 16 characters with
certain complexity criteria. The input data can be divided into three equivalence classes:
1. Passwords less than 8 characters (Invalid)
2. Passwords between 8 to 16 characters (Valid)
3. Passwords more than 16 characters (Invalid)
In this case, you would create test cases for each of these partitions. For example, you might
test a 7-character password, a 10-character password, and a 17-character password to cover
all three partitions. This way, you ensure that the software behaves correctly for all types of
input, while significantly reducing the number of test cases compared to testing every
possible input individually.

7. What are the three important classes of interface errors?

The three important classes of interface errors are:
1. Syntax Errors: These errors occur when a program does not follow the rules of the
programming language.
2. Link Errors: These errors occur when there are problems with connecting or linking
different parts of a program.
 3. Run-time Errors: These errors occur during the execution of a program and usually
result from invalid input or unexpected conditions.

8. What should be the principal concerns of system testing?

The principal concerns of system testing include:
1. Testing the system as a whole to ensure that it meets the specified requirements:
This involves testing the system’s functionality and features to ensure they align with
the intended purpose and specifications.
2. Identifying and fixing any defects or bugs in the system: System testing helps in
uncovering any issues or errors in the system so that they can be resolved before
deployment.
3. Reducing risks: Even bug-free components don’t always perform well as a
system. System testing aims to identify any flaws in the integrated components of the
system.
4. Verifying the conformance of design, features, and performance with the
specifications stated in the product requirements.
5. Ensuring the system is ready for use by the end users

9. Briefly summarize the test-driven development process

Test-Driven Development (TDD) is a software development practice that emphasizes writing
tests before writing the actual code. It follows a cyclical process known as the “Red-Green-
Refactor” cycle:
1. Write a test: Add a test to the test suite for the next bit of functionality you want to
add.
2. Run all tests: Run all the tests to ensure the new test fails. This is the “Red” stage,
indicating that the code does not pass the test.
3. Write the code: Write just enough code to get that single test to pass. This is the
“Green” stage, indicating that the code passes the test.
4. Run tests and Refactor code: Improve the initial code while keeping the tests green.
This is the “Refactor” stage, where the code is improved without changing its
behavior.
This iterative process ensures the software is thoroughly tested and functional at all stages of
development. The primary intention of this technique is to modify or write new code only if
the tests fail. This helps to avoid duplication of code as we write a small amount of code at a
time in order to pass tests.

10. What is scenario testing?

Scenario testing is a software testing activity that uses scenarios, which are hypothetical
stories, to help the tester work through a complex problem or test system. The purpose of
scenario testing is to test end-to-end scenarios for a specific complex problem of the
software2.
Here are some key characteristics of scenario testing:
1. Story: Scenario tests are often given as stories or narratives that outline a certain
circumstance or environment in which the application is expected to function.
2. Motivating: A compelling scenario motivates stakeholders to actively participate,
which improves teamwork and results in a greater understanding of user requirements
and expectations.
 3. Credible: Credible scenarios boost stakeholder’s trust in the testing process as they
can see that the scenarios are meaningful and representative of actual circumstances.
4. Complex: Scenario tests are intended to be complex as they include a variety of
inputs, conditions, and interactions.
5. Easy to evaluate: Even if situations could be complex, they should be designed so that
evaluation is simple.
In scenario testing, the testers assume themselves to be the end users and find the real-world
scenarios or use cases which can be carried out on the software by the end user. The testers
take help from clients, stakeholders, and developers to create test scenarios. A test scenario is
a story which describes the usage of the software by an end user.

11. What is stress testing and why is it useful?

Stress testing is a type of performance testing where the software application is subjected to
conditions beyond the expected real-world operational load. The goal of stress testing is to
measure the robustness, stability, and reliability of the system under extreme conditions. It
helps to identify the system’s breaking point, the maximum load the system can handle, and
how the system recovers from failures.
Here are some reasons why stress testing is useful:
1. Identifying System’s Robustness and Stability: Stress testing helps in determining the
robustness and stability of the system under extreme conditions.
2. Recoverability and Error Handling: It helps stakeholders in finding the recoverability
and error handling of the application after a crash.
3. Security Vulnerabilities: Stress testing can help find security vulnerabilities that might
sneak in during continuous peak load.
4. Memory Leak Issues: With the help of stress testing, we can find the memory leak
issues, in which the memory is not released even after it is no longer required by a
program.
5. Data Integrity: It helps in measuring the data integrity of the application during
extreme load i.e., after a failure the data should be in a reliable state.
In the financial industry, stress testing is used to gauge investment risk, the adequacy of
assets, and to evaluate internal processes and controls. Regulatory bodies require financial
institutions to carry out stress tests to ensure their capital holdings and other assets are
adequate.

12. What are the three types of user testing?

The three types of user testing are:

1. Moderated Testing: In this type of user testing, a moderator with experience in
facilitation, quality assurance, and the product itself guides testers through test cases.
2. Usability Labs: Usability labs are structured sessions with recruited end-user testers
running pre-defined tests on set functions.
3. Guerilla Testing: This is an informal method of user testing where users are asked on
the spot to try using the software. The aim is to gather quick and spontaneous
feedback from users.
These methods help ensure end-user satisfaction and product improvement by providing
valuable insights into how real users interact with the system.