Software Testing Module 3

V Model

1. Verification (Static Testing) (Left arm of V model)

Definition: Verification is the process of checking whether the software is being developed correctly according to the requirements without executing the code.

Like: "Are we doing the job right"?

What Verification Checks

• Requirements are clear and complete
• Design matches requirements
• Code follows design standards
• Documents are correct and consistent

How Verification is Done

• Requirement reviews
• Design reviews
• Code reviews
• Walkthroughs & inspections

Key Characteristics

• Static process (no code execution)
• Done early in SDLC
• Prevents defects rather than finding them later
• Saves time and cost

Example:  If the SRS says “Password must be at least 8 characters,” verification checks whether this rule is correctly written and included in the design and code documents.

Diagram:

SRS (Requirements)

        ↓

     Design

        ↓

      Code

        ↓

   Document Reviews

1. What is Verification?

Verification is the process of checking whether the software is built correctly as per requirements and design.

2. Why is Verification needed?

It is needed to find errors early and ensure the work follows the given requirements.

3. When is Verification done?

Verification is done before testing, during requirement, design, and coding stages.

4. Who performs Verification?

Verification is performed by developers, testers, and review teams.

Activities in verification are as follow:

1. Walkthrough (informal verification model)

2. Review (formal verification model) 

Walkthrough (verification model informal)

Definition: A walkthrough is an informal review whether the author explain the documents to colleagues.

Who Participates

• Author (developer / analyst)
• Team members
• Testers
• Manager (optional)

Purpose

• To understand the document or code
• To find minor mistakes and missing points

Example: A developer explains the SRS document to the team and discusses requirements.

Key Features

• Informal process
• Led by the author
• No fixed rules
• Focus on understanding

Diagram

Author → Explains Document → Team Discussion → Suggestions

Review (verification model formal)

Definition: A review is a formal process of examining software documents or code to find errors and ensure quality without running the program.

Who Participates

• Reviewers (experts)
• Testers
• Developers
• Project manager

Purpose

• To check correctness and quality
• To ensure standards and requirements are followed

Example: Testers review the design document to find errors before coding.

Key Features

• Formal process
• Planned and structured
• Defects are recorded
• Quality focused

Diagram

Document → Reviewers → Error Detection → Improvement

MoM (Minutes of Meetings)

Definition: MoM is a written record of what was discussed, decided, and planned in a meeting.

What MoM Includes

• Meeting date and time
• Participants
• Discussion points
• Decisions taken
• Action items with responsibility

Purpose of MoM

• Keeps a clear record of the meeting
• Avoids misunderstanding
• Helps track tasks and decisions

Example: After a review meeting, MoM records the identified defects and who will fix them.

Key Features

• Short and clear
• Written after the meeting
• Used for future reference

Validation (Dynamic Testing) (Right arm of V model)

Definition: Validation is the process of checking whether the software meets user needs and expectations by actually running and testing it.

Like: "Are we doing the right job"?

Key Points

• Checks whether the right product is built
• Focuses on user needs and expectations
• Done by executing the software
• Performed during testing phases
• Finds defects in the actual working system

Diagram:

Requirements        ←→   Acceptance Testing (UAT)

      ↓

   Design            ←→   System Testing

      ↓

   Coding            ←→   Integration Testing

                          ↓

                      Unit Testing

Why Validation is Important

• Ensures software meets user requirements
• Improves user satisfaction
• Reduces risk of failure after release
• Confirms the product works in real conditions

Levels of Validation (Testing Levels)

1. Unit Testing: Testing individual units or functions of the software.

• Performed by: Developer
• Focus: Individual functions or modules
• Example: Testing a calculator’s add function

2. Integration Testing: Testing the interaction between combined modules.

• Performed by: Developer / Tester
• Focus: Interaction between modules
• Example: Checking login page connects with database

3. System Testing: Testing the complete software system as a whole.

• Performed by: Tester
• Focus: Complete system behavior
• Example: Testing full application flow (login → dashboard → logout)

4. User Acceptance Testing (UAT): Testing done by users to confirm the software meets their requirements.

• Performed by: End users / Client
• Focus: User requirements and expectations
• Example: Client testing software before final release

Alpha Testing

Definition: Alpha testing is internal testing done before releasing the software to users.

• Performed by: Developers and testers (inside the organization)
• Example: Company testers check a mobile app for bugs before public release.

Beta Testing

Definition: Beta testing is testing done by real users in a real environment.

• Performed by: End users / customers
• Example: Users test a new app version and report issues before final launch.

One-Line Difference

Alpha testing is done inside the company, while beta testing is done by real users.

Validation – End-to-End Example (Simple & Easy)

Example: Online Shopping Application

1. User logs in
→ Check if user can log in with valid username and password
2. User searches product
→ Verify product list is displayed correctly
3. User adds product to cart
→ Check item is added and price is correct
4. User makes payment
→ Verify payment is processed successfully
5. Order confirmation shown
→ Check order confirmation message/email is received