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
(A test plan document will commence with a unique test plan identifier)
- Project Name
- Project Number
- Version Number
- Effective Date
- Project Manager
- Prepared by
(Describe how many times the test plan was updated)
- Version Date
(Provide a shot description of the purpose of the project)
(Indicate what is being tested, is testing for a complete system or segment of a system)
(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.
(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.
(“A risk is a potential danger that could prevent testing activities from being completed effectively”)
(Identify each test objective using a Test Objective ID and tie the ID to a Test ID and Requirements ID)
(features to be tested from USER point’s point of view. It should contain Low-Level non-Technical Descriptions)
(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.
(List the hardware (specially configured PC, servers) required to perform testing defined in the test plan)
(List non-standard software products)
- For example: Windows XP, Linux. If will have automation, which tool will need
(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.
(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)
(The deliverables can consist of test results, test cases, reports, test log or the results of other testing activities)
(Identify automated or other tools used for testing)
- Example: Apache JMeter (Performance Testing), QTP (Automation testing) and Quality Center (Functional testing)
(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.
(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”)
(Provide information about specific requirements needed in the environment to execute the tests)
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.
“The user enter into the application from login window by entering valid user name and password”
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