Difference between test plan, test case and scenarios:

I will try to summarize the difference between test plan, test case and scenario, and give some examples of it, as well as follow the order usually applied during the project.

Everything will usually start with requirements, and the more details we have in the requirements, the easier it is to prepare these documentations and to test as well.
Usually test plans are made by the QA lead, test manager or project manager, because they are a record of the test planning process. The test plan (also called test specification) will define and describe the scope, approach, resources and schedules where testing activities should be involved. Most companies uses them as a high level documentation or a high level strategy which is usually not detailed (that is, do not cover items such as action steps or product testing), but is used to make sure that the product is tested in accordance with the specifications and design, and to verify that the QA analyst covers all specified functionality of the application as possible. Test plans are also useful as a guide to all parties involved in the testing process. Therefore, it is a decision of the company or the project to define how much detail will be covered by the test specification, as this usually demands a considerable time effort.


Example of Test Plan

  • Plan Identifier
  • (A test plan document will commence with a unique test plan identifier)

      Project Name
      Project Number
      Version Number
      Effective Date
      Project Manager
      Prepared by
  • Revision History
  • (Describe how many times the test plan was updated)

      Version
      Version Date
      Author
      Comments
  • Project Description
  • (Provide a shot description of the purpose of the project)

  • Testing Scope
  • (Indicate what is being tested, is testing for a complete system or segment of a system)

  • Testing Assumptions
  • (identify external or internal items or activities that must remain true for the testing effort to be successful. The assumptions if they turn false can impact testing schedules, testing content or create issues)

      Example: Testing data will be available on a planned date.
  • Testing Constraints
  • (List the external or internal items or activities that could constrain testing effort)

      For example: The testing environment is only available from date1 to date2.

    <Note: A constraint can become an issue when testing activity cannot occur within the constraint.

  • Testing Risks
  • (“A risk is a potential danger that could prevent testing activities from being completed effectively”)

  • Testing Objectives
  • (Identify each test objective using a Test Objective ID and tie the ID to a Test ID and Requirements ID)

  • Features to be tested
  • (features to be tested from USER point’s point of view. It should contain Low-Level non-Technical Descriptions)

  • Features not to be tested
  • (list the features not to be included in the testing process identifying the reason behind its exclusion.)

      Example: The test will cover only English version.
  • Staff Requirements
  • (Resources required)

  • Hardware Requirements
  • (List the hardware (specially configured PC, servers) required to perform testing defined in the test plan)

  • Software Requirements
  • (List non-standard software products)

      For example: Windows XP, Linux. If will have automation, which tool will need
  • Test to Execute
  • (Identify the phases and types of testing covered by the test plan. Include a description of each test phase or type)

      Example: Unit, SIT, User Acceptance, and Production Verification, performance, usability, migration, conversion, on-line, communications, regression, stress.
  • Testing Schedule
  • (Identify the projected start and stop dates for each planned test. List the test in chronological order and include the exit (success criteria) required for each test)

  • Test Deliverables
  • (The deliverables can consist of test results, test cases, reports, test log or the results of other testing activities)

  • Testing Tools Used
  • (Identify automated or other tools used for testing)

      Example: Apache JMeter (Performance Testing), QTP (Automation testing) and Quality Center (Functional testing)
  • Testing Approaches
  • (Define the procedures used in the testing process.

      Example: Validation, Retesting, Approval, and Status reporting (include timing, type or level of detail, and persons reporting and receiving reports). Identify the criteria, and participants for making a final (“Go / No Go”) decision. Define the Setup and Configuration Management procedures needed to ensure appropriate components are tested, appropriate data is used, and results are appropriately captured and stored.
  • Test Case Development Strategy
  • (Define the strategy used to develop test cases for the planned testing. Identify how each test case is tied to a functional requirement. To ensure all functional requirements are tested, build a table containing the headings “Functional Requirements ID”, “Test Case ID”, “Test Case Description” and “Test Case Priority”)

  • Testing Environment
  • (Provide information about specific requirements needed in the environment to execute the tests)

  • Approval Signatures

  • For more details, the following link presents the TEST PLAN based on IEEE Standard for Software Test Documentation (ANSI/IEEE Standard 829-1983)


    Scenarios X Test Cases

    Canonical definition of scenario (taken from Wikipedia): “scenarios are hypothetical stories to help the test analyst work through a test system”. It is easy to differentiate scenarios from test cases, as test cases usually covers single steps whereas scenarios cover a number of steps. Meaning that usually a scenario consists of a number of test cases.
    Below an example of test cases derived from a scenario.


    SCENARIO
      “The user enter into the application from login window by entering valid user name and password”

    TEST CASE

    1 – Open the login window

      Login window is open

    2 – Enter valid Username and Valid Password

      Application should be open

    3 – Enter Invalid Username and invalid Password

      Application should not be open

    One thought on “Difference between test plan, test case and scenarios

    1. It’s a great article Bianca. Such concepts must be rooted in the minds of all software testing analysts and there is nothing better than learning them with texts that make learning simple and objective.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    *
    *
    Website