Note51

0.0 by Qwen

13 min read

Chapter 7: Software Testing

Why Testing is Important?

Definition

  • Software testing (meaning: the process of checking a software system to find errors and ensure it meets requirements) is a key part of software development that helps confirm quality and reliability.

Causes

  • Not specified in notes

Goals / Objectives

  • To demonstrate the presence of errors (not to prove there are none)
  • To discover faults and defects in the system
  • To validate that the system meets its requirements
  • To ensure reliability, especially for systems where failure could be dangerous or costly

Importance

  • Testing is essential for quality assurance
  • It helps prevent costly or dangerous failures in real-world use
  • It is a core part of the software development process, not an optional extra

Procedures

  • Not specified in notes

Advantages & Disadvantages

  • Advantages:

    • Helps catch bugs early, reducing repair costs
    • Builds user trust in the system
    • Supports verification and validation of requirements

  • Disadvantages:

    • Cannot prove the absence of all errors (as noted: “Can’t show NO ERRORS”)
    • Testing can be time-consuming and expensive

Impact / Effect

  • Increases software reliability and user satisfaction
  • Reduces risk of system failure after release

Examples

  • Reliability-critical systems:
    • Banking systems (must not lose transactions)
    • Medical or industrial control systems (failures could be dangerous)

Key Takeaways

  • Testing finds bugs—it doesn’t prove perfection
  • It’s about quality, safety, and meeting user needs
  • You can’t test everything, so smart testing is key

Stages in the Testing Process

Definition

  • The testing process is divided into five main stages, each focusing on a different level of the software system.

Causes

  • Needed because software is built in layers (from small parts to full system), and each layer must be checked

Goals / Objectives

  • To test components individually, then gradually combine and test them
  • To verify correctness at every level before final release

Importance

  • Ensures that errors are caught early, when they’re easier and cheaper to fix
  • Provides a structured, step-by-step approach to quality control

Procedures

  • Follow these five stages in order:
    1. Unit Testing – test individual components
    2. Module Testing – test groups of related components
    3. Sub-system Testing – test collections of modules
    4. System Testing – test the full integrated system
    5. Acceptance Testing – final test by users (also called Alpha Testing)

Advantages & Disadvantages

  • Advantages:

    • Early bug detection at the smallest level
    • Clear responsibility at each testing stage
    • Supports incremental development and integration

  • Disadvantages:

    • Requires careful planning and coordination
    • Later stages (like system testing) can reveal issues missed earlier

Impact / Effect

  • Leads to more stable and reliable software
  • Helps manage complexity by testing in layers

Examples

  • Student Registration System:
    • Unit test: a single function that validates student ID
    • Module test: the whole “registration” module
    • System test: entire website with login, payment, and confirmation
    • Acceptance test: real users try to register before launch

Key Takeaways

  • Testing happens in five clear stages, from small to big
  • Each stage builds on the last—don’t skip steps
  • Acceptance testing is the final “real-world” check before launch

Test Data Sources

Definition

  • Test data refers to the input values and scenarios used to run tests. There are two main types: live data and artificial data.

Causes

  • Needed because tests require realistic or extreme inputs to check system behavior

Goals / Objectives

  • To provide meaningful inputs that reveal bugs
  • To cover normal, edge, and error cases

Importance

  • Poor test data = missed bugs
  • Good test data = higher confidence in system correctness

Procedures

  • Live Data:
    • Extracted from real databases or normal user activities
    • Entered manually during normal operations
  • Artificial Data:
    • Generated specifically to test all combinations of formats and values
    • Created using data-generating utility programs
    • Often made by people other than developers (to avoid bias)

Advantages & Disadvantages

  • Advantages:

    • Live data reflects real usage
    • Artificial data can cover extreme or rare cases that live data misses

  • Disadvantages:

    • Live data can be hard to get and may lack error cases
    • Artificial data may feel unrealistic if not designed well

Impact / Effect

  • Determines how thorough and realistic testing is
  • Affects ability to reproduce and fix bugs

Examples

  • Live data: Customer orders from last month’s sales database
  • Artificial data: Fake user logins with very long names, special characters, or blank fields to test error handling

Key Takeaways

  • Use both live and artificial data for best results
  • Live data = real-world behavior; artificial data = stress and edge cases
  • Store all test data in a test library for reuse and consistency

Testing Techniques

Definition

  • Testing techniques are different methods used to design and run tests, depending on what part of the system is being tested and what goals you have.

Causes

  • Different parts of a system (code vs. user interface) need different testing approaches

Goals / Objectives

  • To find defects efficiently
  • To cover both structure and behavior of the software
  • To simulate real-world usage and stress

Importance

  • Choosing the right technique makes testing more effective and faster
  • Helps teams focus on what matters most at each stage

Procedures

  • Techniques are grouped by testing level and strategy:
    • Integration Testing (for combining modules):
      • Top-Down Testing
      • Bottom-Up Testing
      • Regression Testing
    • Release/System Testing:
      • Functional/Black Box Testing
      • White Box Testing
      • Performance/Stress Testing
    • Unit Testing:
      • Individual Function/Method Testing
      • Object Class Testing
      • Composite Component Testing
      • Interface Testing
    • Other Techniques:
      • Thread/Transaction Flow Testing
      • Back-to-Back Testing
      • Peak Load, Storage, Recovery, Human Factors Testing

Advantages & Disadvantages

  • Advantages:

    • Black box tests real user behavior without needing code knowledge
    • White box ensures internal logic is fully exercised
    • Regression testing catches bugs introduced by new changes
    • Stress testing reveals system limits

  • Disadvantages:

    • White box requires deep code knowledge
    • Regression testing can be expensive (rerun many tests)
    • Exhaustive testing is NOT possible (as noted in notes)

Impact / Effect

  • Directly affects software quality and stability
  • Poor technique choice can miss critical bugs

Examples

  • Top-Down Integration: Start with main menu, then test sub-menus as they’re added
  • Bottom-Up Integration: Test login function first, then build up to full user profile
  • Stress Test: Simulate all bank tellers logging in at once to check system overload
  • Back-to-Back Testing: Run same inputs on Version 1 vs. Version 2 and compare outputs

Key Takeaways

  • Black box = test what the system does (inputs → outputs)
  • White box = test how the system works (code structure)
  • Always include regression and stress tests before release
  • You can’t test everything—focus on high-risk and high-impact areas

Integration Testing Techniques

Definition

  • Integration testing checks how modules or sub-systems work together after being combined.

Causes

  • Modules may work alone but fail when connected due to interface mismatches

Goals / Objectives

  • To find interface errors
  • To ensure data and control flow correctly between parts

Importance

  • Critical for detecting hidden bugs that only appear when components interact

Procedures

  • Top-Down Testing:
    • Start from top-level modules and work downward
    • Use stubs for lower-level modules not yet built
  • Bottom-Up Testing:
    • Start from lowest-level modules and build upward
    • Use drivers to simulate higher-level calls
  • Regression Testing:
    • Rerun previous tests every time a new module is added
    • Ensures new code doesn’t break old functionality

Advantages & Disadvantages

  • Advantages:

    • Top-down finds high-level design flaws early
    • Bottom-up ensures solid foundation before adding complexity
    • Regression maintains system stability over time

  • Disadvantages:

    • Top-down delays testing of low-level details
    • Bottom-up may miss big-picture issues until late
    • Regression testing is expensive (as noted in notes)

Impact / Effect

  • Prevents integration disasters at final stages
  • Builds confidence in system cohesion

Examples

  • Top-Down: In an e-commerce app, test shopping cart first, then payment, then inventory
  • Bottom-Up: Test database connection, then product search, then full product page
  • Regression: After fixing a login bug, rerun all user profile tests to ensure nothing broke

Key Takeaways

  • Top-down = big picture first; Bottom-up = foundation first
  • Always do regression testing when adding new features
  • Integration bugs are common and costly—catch them early

Unit Testing Techniques

Definition

  • Unit testing checks the smallest testable parts of a system, like a single function, method, or class.

Causes

  • Small units can have logic errors even if they look simple

Goals / Objectives

  • To verify individual components work correctly in isolation
  • To test inputs, outputs, states, and interactions

Importance

  • Catches bugs at the source, making them cheap to fix
  • Forms the base of reliable software

Procedures

  • Individual Function/Method Testing:
    • Test with different input parameters
  • Object Class Testing:
    • Test attributes (e.g., setting and reading values)
    • Test operations/methods
    • Test state changes (e.g., object before/after a method call)
  • Composite Component Testing:
    • Test interaction between internal parts of a component
  • Interface Testing:
    • Test parameter passing between methods
    • Test shared memory or message passing between sub-systems
    • Test procedural interfaces (calling sequences)

Advantages & Disadvantages

  • Advantages:

    • Very fast and cheap to run
    • Easy to automate and repeat
    • Helps document expected behavior

  • Disadvantages:

    • Doesn’t catch integration or system-level bugs
    • Requires extra code (test cases, mocks, etc.)

Impact / Effect

  • Leads to more maintainable and modular code
  • Encourages better design (e.g., loosely coupled components)

Examples

  • Function test: calculateDiscount() with inputs like 0%, 50%, 100%
  • Object test: Invoice class – test Issue(), sendReminder(), and balance after acceptPayment()
  • Interface test: Check that LoginModule correctly passes user ID to ProfileModule

Key Takeaways

  • Unit tests are small, fast, and focused
  • Test functions, objects, and interfaces separately
  • They’re the first line of defense against bugs

Testing Strategies

Definition

  • A testing strategy is a general plan or approach for how testing will be done across a project—not just individual test methods.

Causes

  • Large projects need consistent, coordinated testing across teams and phases

Goals / Objectives

  • To define how, when, and what to test throughout development
  • To align testing with project goals and risks

Importance

  • Without a strategy, testing becomes chaotic or incomplete
  • Helps allocate resources wisely (time, people, tools)

Procedures

  • Two main strategic approaches:
    • Proactive Strategy: Plan tests early, based on requirements and design
    • Reactive Strategy: Design tests after development, often in response to bugs

“Testing strategy is a general approach to the testing process, rather than a method of devising (work out of) tests for a particular system or component.”

Advantages & Disadvantages

  • Advantages:

    • Proactive = catches bugs earlier, cheaper to fix
    • Reactive = may focus on real-world issues seen in use

  • Disadvantages:

    • Reactive = often too late, more expensive fixes
    • Poor strategy = wasted effort or missed critical areas

Impact / Effect

  • Determines overall testing effectiveness
  • Influences release quality and schedule

Examples

  • Proactive: Create test cases while writing requirements (e.g., for online craft store)
  • Reactive: Wait until beta users report bugs, then write tests for those cases

Key Takeaways

  • Strategy = big-picture testing plan, not just test cases
  • Proactive is better—start planning tests early
  • Strategy guides all other testing activities

Test Case Design and Planning

Definition

  • Test case design and planning is the process of creating detailed test cases and organizing them into a test plan to guide testing activities.

Causes

  • Ad-hoc testing misses bugs; structured plans yield better results

Goals / Objectives

  • To produce a clear, repeatable test plan
  • To ensure all requirements are covered by tests
  • To define what, when, and how to test

Importance

  • A good test plan is essential for reliable, efficient testing
  • Helps teams stay organized and accountable

Procedures

  • Create a test plan that includes:

    1. Testing process (unit → acceptance stages)
    2. Requirement traceability (link each test to a requirement, e.g., SRS item X)
    3. Tested items (list programs, modules, user/operator procedures)
    4. Testing schedule (e.g., Gantt chart showing when each item is tested)
    5. Testing recording procedures (how to log results, e.g., test case table)
    6. Hardware & software requirements (e.g., Samsung Galaxy Alpha, Android, 3G)
    7. Constraints (e.g., test item availability, time limits, resource limits)

  • Use test case templates with columns for:

    • Objective/Test Case
    • Test Data
    • Expected Results
    • Actual Results
    • Remarks/Comments

Advantages & Disadvantages

  • Advantages:

    • Ensures full coverage of requirements
    • Makes testing repeatable and auditable
    • Helps manage time and resources

  • Disadvantages:

    • Takes time to create
    • Can become outdated if not maintained

Impact / Effect

  • Leads to more thorough and professional testing
  • Reduces last-minute surprises before release

Examples

  • Test case example:
    • Objective: Generate monthly sales report for June–September
    • Test Data: Select “July”
    • Expected Result: Sales data for July appears
  • Test plan item: “User Procedures” must be tested with real customers during acceptance testing

Key Takeaways

  • A test plan is your testing roadmap—don’t skip it
  • Every test should link back to a requirement
  • Use standard templates to keep results clear and comparable

Testing Approaches (Based on Test Design)

Definition

  • These are three main ways to design test cases, based on different sources of information.

Causes

  • Different systems need different test design perspectives

Goals / Objectives

  • To choose the most effective way to generate test cases for a given situation

Importance

  • Determines how well your tests cover possible failures

Procedures

  • 1. Requirements-Based Testing:
    • Design tests directly from system requirements
  • 2. Partition Testing (also called Equivalence Partitioning):
    • Divide input data into valid and invalid partitions
    • Test one value from each partition (e.g., month: -1 = invalid, 6 = valid, 13 = invalid)
  • 3. Structural Testing:
    • Design tests based on program code structure (e.g., statements, branches)

Advantages & Disadvantages

  • Advantages:

    • Requirements-based ensures you meet user needs
    • Partition testing reduces number of test cases while covering key scenarios
    • Structural testing ensures code is fully exercised

  • Disadvantages:

    • Structural requires code access and technical skill
    • Partition may miss interactions between inputs

Impact / Effect

  • Better test design = higher bug detection rate
  • Helps balance effort and coverage

Examples

  • Partition Testing:
    • Input: Month number
    • Partitions: Invalid (<1), Valid (1–12), Invalid (>12)
    • Test values: 0, 6, 13
  • Requirements-Based: For “user must reset password every 90 days,” create test that checks day 91 behavior

Key Takeaways

  • Requirements-based = “Are we building the right thing?”
  • Partition testing = smart way to test inputs without trying every value
  • Structural testing = “Is every line of code checked?”

Testing Principles / Guidelines

Definition

  • Testing principles are best practices and rules that help make testing more effective.

Causes

  • Without guidelines, testing can be wasteful or misleading

Goals / Objectives

  • To improve testing quality and efficiency
  • To avoid common mistakes

Importance

  • These principles are lessons learned from real projects—they save time and money

Procedures

  • Follow these key guidelines:
    • All tests should be traceable to customer requirements
    • Start test planning early (during requirements phase)
    • Apply the Pareto Principle: 80% of errors come from 20% of the code
    • Exhaustive testing is NOT possible—focus on high-risk areas
    • Use independent testers (e.g., third-party or separate team) when possible

Advantages & Disadvantages

  • Advantages:

    • Traceability ensures nothing important is missed
    • Early planning prevents rushed, poor-quality tests
    • Independent testers find more bugs (less biased)

  • Disadvantages:

    • Independent testing may cost more
    • Pareto focus might miss rare but critical bugs

Impact / Effect

  • Leads to smarter, more focused testing
  • Reduces wasted effort on low-value tests

Examples

  • Pareto in action: Focus extra testing on the payment module (if it’s complex and error-prone)
  • Early planning: Write test cases while discussing requirements with the customer

Key Takeaways

  • Trace every test to a requirement
  • Start planning tests as soon as requirements exist
  • You can’t test everything—use Pareto to focus on the 20% that causes 80% of bugs
  • Independent testers find more bugs—use them if possible

Graph View

Backlinks