012 ‐ Independent Software Testing Live Project (Part 5) ‐ Test Planning - rkb-sdet/SoftwareTesting GitHub Wiki

Session 12 Recap: Independent Software Testing Live Project (Part 5) - Test Planning

This session focuses on creating a test plan document for an e-commerce web application (Tutorials Ninja Web Application)—continuing the multi-session software testing live project. Here’s a breakdown of the key content and practical concepts covered:

  • After the Project Begins, we explore the application and clear our doubts which came while exploring the application
  • After exploring the Project and clearing our doubts, we will start creating the Test Plan document
  • Test Plan is a document required for planning the test activities for delivering the quality product.
  • Test Plan (Sample Test Plan)
  • Test Plan is a Document
  • Test Plan Contains:
    • Overview/Objective
    • In Scope (Features to be Tested)
    • Out of Scope (Features not to be Tested)
    • Test Approach (i.e. Test Strategy)
    • Test Environments
    • Test Deliverables and Milestones
    • Test Resources
    • Test Schedules
    • Entry Criteria
    • Exit Criteria
    • Suspension and Resumption Criteria
    • Tools
    • Risks and Mitigations
    • Approvals
  • Finalized Test Plan

Project Recap and Progression

  • Kick-off and Domain Understanding: Started with a kick-off meeting between the client (Tutorials Ninja) and the testing team, ensuring clear agreement and project commencement.
  • Domain Knowledge: Prior sessions explored e-commerce domain essentials to understand the application’s context.
  • Functionality Exploration: Sessions 9–11 involved exploring the application in depth, noting down all functionalities (register, login, add to cart, etc.) and clarifying doubts directly with the client.

Why Test Planning Is Essential

  • Avoiding Unplanned Testing Pitfalls: Testing without a plan leads to issues and inefficiency.
  • A test plan brings structure, clarity, and agreement—setting the stage for high-quality testing activities and outcomes.

Steps in Creating the Test Plan Document

1. Customizing a Template

  • Instead of starting from scratch, use an existing test plan template, adapting it for the current application (replacing previous project details, company, and client info).

2. Defining Project Details

  • Project name: Tutorials Ninja Web Application
  • Document type: Test Plan
  • Prepared by: Your company/role (e.g., SolarTick, Test Lead)

3. Document Sections and Content

  • Scope
    • Inclusions: List all functionalities to be tested (register, login, search, add to cart, checkout, order history, categories, contact page, etc.).
    • Exclusions: Any third-party applications integrated (e.g., payment gateways) or features not requested by the client.
  • Test Environments
    • Specify browsers and OS where testing is to be performed (Chrome, Firefox, Edge, Safari, Windows, Mac, Linux, Android, iOS).
    • Clarify support for mobile devices as required by the client.
  • Strategy
    • Core Testing Approach: Functional testing using manual methods across all included features.
    • Test Design Techniques: Equivalence partitioning, boundary value analysis, decision table, state transition, use case testing.
    • Additional Practices: Error guessing, exploratory testing, end-to-end scenario flow, context-driven testing, shift-left testing.
    • Team Approach: Multiple testers working in parallel on multiple environments.
  • Problem Tracking
    • Defects found during testing will be documented (e.g., in Word, Excel, or defect tracking tools) after confirmation with team and retesting in different environments.
  • Roles and Responsibilities
    • Test Manager: Handles escalations, reviews, high-level meetings.
    • Test Lead/Senior Engineer: Creates the plan, coordinates defect reporting, collaborates with the client.
    • Test Engineers: Execute test cases, document findings, participate in daily defect reporting emails.
  • Schedule
    • Timeline for each phase: test plan creation, client review, test case creation, client approval, actual testing, report submission.
    • Example: Test plan created by Dec 14, test cases by Dec 25–26, testing starts Dec 27, final report Jan 28.
  • Deliverables
    • Test plan document, test cases, defect/issue reports, summary report.
  • Entry and Exit Criteria
    • Entry: Sufficient project/application details, requirement docs, client approval.
    • Exit: Application fully tested, reports accepted by client, no critical issues remain.
  • Suspension and Resumption Criteria
    • Flexibility to pause and resume based on client needs, ramp up/down resources as required.
  • Tools
    • Mind mapping, screenshot capture, defect tracking (e.g., Zoho), Excel/Word for documentation.
  • Risk Mitigation
    • Anticipate issues such as absentee resources, environment breakdown, rapid release cycles—solutions include backup resources, schedule adjustments, increased team size.
  • Approvals
    • Testing progresses to next phase only after explicit client approval of deliverables (test plan, test cases, reports).

Practical Takeaways

  • A detailed test plan is the foundation for structured, thorough, and client-focused software testing.
  • Each section of the plan (scope, strategy, schedule, roles) is vital for aligning expectations, communicating clearly, and delivering quality.
  • Real-world project constraints (environments, timeline, client interaction, risk management) are addressed upfront.

This session prepares you to create, review, and apply a test plan for any project—an essential skill for software testers and quality assurance professionals. ^1

⁂
⚠️ **GitHub.com Fallback** ⚠️