Unit 6: Software Testing

Comprehensive guide to Software Testing, covering test cases, verification, validation, unit testing, black-box, and white-box testing methodologies.

Unit 6: Software Testing

6.1 Introduction of Testing

Software testing is a critical phase in the software development life cycle (SDLC). It is the process of evaluating and verifying that a software product or application does what it is supposed to do. The primary goal of testing is to identify errors, gaps, or missing requirements in contrast to the actual requirements.

Why is Testing Necessary?

  1. Defect Identification: It helps in identifying bugs and defects introduced during the development phases.
  2. Quality Assurance: Ensures that the software meets the specified quality standards.
  3. Reliability: Confirms that the application will perform reliably under expected conditions.
  4. Security: Identifies vulnerabilities to ensure the software is safe from malicious attacks.
  5. Customer Satisfaction: Delivering a bug-free product enhances user experience and satisfaction.

Testing is not just about finding errors; it is also about ensuring that the software behaves correctly, performs adequately, and is robust enough to handle unexpected situations.

6.2 Test Cases and Test Suite

Test Cases

A test case is a specific set of conditions or variables under which a tester will determine whether an application, software system, or one of its features is working as it was originally established to do. It is a single executable test.

A well-documented test case typically includes:

  • Test Case ID: A unique identifier for the test case.
  • Test Description: A brief explanation of what is being tested.
  • Pre-conditions: The state of the system before the test is executed.
  • Test Steps: Detailed, step-by-step instructions to execute the test.
  • Test Data: The inputs required for the test.
  • Expected Result: The anticipated outcome if the software works correctly.
  • Actual Result: The observed outcome after executing the test.
  • Status: Pass, Fail, or Blocked.

Test Suite

A test suite is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. Test suites help organize tests logically, such as grouping all login-related tests into a single "Authentication Test Suite."

6.3 Introduction to Verification and Validation

Verification and Validation (often abbreviated as V&V) are two distinct but complementary processes used to check that a software system meets specifications and fulfills its intended purpose.

Verification

Verification addresses the question: "Are we building the product right?"

  • It is the process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase.
  • It is a static testing technique, meaning it involves reviewing documents, design, and code without executing the software.
  • Examples include reviews, walkthroughs, and inspections.

Validation

Validation addresses the question: "Are we building the right product?"

  • It is the process of evaluating the software during or at the end of the development process to determine whether it satisfies specified business requirements.
  • It is a dynamic testing technique, meaning it requires the actual code to be executed.
  • Examples include unit testing, integration testing, system testing, and user acceptance testing (UAT).

Key Differences

FeatureVerificationValidation
ObjectiveEnsures the software is developed according to specifications.Ensures the software meets the customer's actual needs and expectations.
ExecutionDone without executing the software.Requires execution of the software.
TargetDocuments, architecture, design, code.The actual software product.
TimingPerformed early in the development lifecycle.Performed after verification, typically towards the end.

6.4 Unit Testing

Unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use. A "unit" is the smallest testable part of an application, such as a function, method, or class.

Key Characteristics

  • Developer-driven: Unit tests are typically written and executed by the software developers themselves.
  • Isolation: Each unit is tested independently to ensure it functions correctly on its own. Mock objects and stubs are often used to simulate dependencies.
  • Automation: Unit tests are usually automated and run frequently, often as part of a Continuous Integration (CI) pipeline.

Benefits of Unit Testing

  • Early Bug Detection: Finds problems early in the development cycle, making them cheaper and easier to fix.
  • Facilitates Refactoring: Allows developers to restructure code with confidence, knowing that existing functionality is protected by unit tests.
  • Documentation: Serves as living documentation for the code, illustrating how a particular piece of functionality is intended to be used.

6.5 Black-Box Testing

Black-box testing (also known as behavioral testing) is a software testing method in which the internal structure, design, and implementation of the item being tested are not known to the tester. The tester interacts with the software's user interface, providing inputs and examining outputs without knowing how the outputs were generated.

Focus and Perspective

  • Focuses solely on the inputs and the expected outputs.
  • Conducted from the user's perspective.
  • Testers do not need programming knowledge to perform black-box testing.

Common Techniques

  • Equivalence Partitioning: Divides input data into valid and invalid partitions. Testing one value from a partition is considered equivalent to testing any other value in that partition.
  • Boundary Value Analysis: Focuses on testing the boundaries between partitions, as errors are more likely to occur at the edges of input ranges.
  • State Transition Testing: Used when the system's output depends on its previous state or history.

Advantages and Disadvantages

  • Advantages: Efficient for large segments of code; tester perspective ensures user requirements are met; code access is not required.
  • Disadvantages: Limited coverage (not all paths are tested); difficult to identify root causes of failures; tests can be redundant if the developer has already run similar tests.

6.6 White-Box Testing

White-box testing (also known as clear-box testing, glass-box testing, or structural testing) is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality. In white-box testing, an internal perspective of the system, as well as programming skills, are used to design test cases.

Focus and Perspective

  • Focuses on verifying the code structure, branches, paths, and internal logic.
  • Conducted from the developer's perspective.
  • Requires deep knowledge of the programming language and the specific implementation details.

Common Techniques

  • Statement Coverage: Ensures that every single line of code is executed at least once during testing.
  • Branch Coverage: Ensures that every possible branch (e.g., true/false outcomes of an if statement) is executed.
  • Path Coverage: Ensures that all possible paths through the code are executed.

Advantages and Disadvantages

  • Advantages: Reveals errors in hidden code; helps optimize the code; provides maximum coverage of the internal logic.
  • Disadvantages: Highly complex and time-consuming; requires highly skilled testers with programming knowledge; tightly coupled to the implementation, meaning tests may need to be rewritten if the code structure changes.

End of Unit 6