How to Create effective test plan :
In General Test Plan includes the following
data.
1. Test Scope
-
In Scope
-
Out of Scope
"Areas / Functionalities that will be
included during the Test Cycle" is known as a Test Scope.
In Other words :
Test Scope is the process of defining what
features and functionalities are required to be tested and then making sure all
of defined features and functionalities are thoroughly verified.
It contain, process of analyze the product.
For example if you create a website, then , You should research clients and the
end users to know their needs and expectations from the application
- Who
will use the website?
- What
is it used for?
- How
will it work?
- What are software/ hardware the product uses?
Let me give an example,
There is a new requirement for Implementation for the smart selection from drop
down (Filtering the data based on users selection).
Now when this feature comes into the QA
pool in a new Build then, entire focus of the Test should be this feature only
and nothing else. This can be categories as a Test Scope.
Now imagine few other requirements which
are also needed to be included into the next release so, these items will be
included into the Test Scope for that release.
Further the process can be divided into
the 2 parts.
1. In Scope: - Features / Functions that
are to be tested
2. Out of Scopes: - Features / Functions
not to be tested
2. Test Schedule:
Everything that is to be tested should be
as per the schedule (proposed and approved time frame on which deliverables are
due).
Test schedule can include variety of the
phases. Some of them are listed below,
A. Requirement Understanding
B. Test Plan creation
C. Test Cases creation
D. Test Execution in Different Environments
E. QA Sign-off*
You will have to provide the Start Date
and End Date for Every Phase respectively,
Below is the description of the phases
which can be helpful for identifying the potential start and end dates for
every phase.
A. Requirement Understanding : There are few things that needs to be happen before this
stage can begin like,
1. All the requirements should be clear and
properly documented.
2. All Support document should be
available.
3. Basic structure of the given
requirements should be available,
Most of time frames for different phases
can be derived from the requirements itself, if above three things are followed
properly.
B. Test Plan Creation: How much time it will take to prepare this document itself?
For every phase of the Test Schedule "Requirement Understanding" is
the part where you will actually know the efforts it will take to get things
done.
C. Test Cases creation: Once Requirements are fixed and documented properly, you will
be able to draft test case easily from them and also be able to provide time
frame for the same.
D. Test Cases Execution: Now this is a bit tricky part as this will depend on the
details of different Environment to be tested.
for example, if you are running the one
test on Chrome, Firefox, IE and also on 5 Different devices then you will have
a one test cases which executes 8 time in one Cycle.
With that in mind and other details like,
-
How May Test Cycle you are performing?
-
What is the Scope of each Cycle?
-
Each cycle can take different amount of time to complete.
Will determine the time taken for each
test cycle.
for example, first cycle will always be somewhat longer than the second
because probability of finding the bugs/Defects are high in the first
Iteration.
As cycle changes, amount bugs/Defects found during each Iteration will get
smaller.
Based on the above details you can find
the possible start and End Date of the Test Case Execution.
E. QA Sign-off: How do you determine that testing is complete? obviously
you’ll need some kind of criteria to make sure that you’re confident that
application under test works as intended.
This criteria will be set as a pre-agreed upon exit gate definition, and once
met testing will be completed.
The overall application will include the
following testing types/techniques*:
The below list of test depth/test
techniques are used to assess application quality:
-
1. FT: Feature > Basic Feature Testing
-
2. G: GUI > Validate look and feel of the application
-
3. DB: Database > Verify DB interaction and CRUD procedures
-
4. E2E: End to End > Validate E2E business flows and system
interaction
-
5. BR: Business Rule > Validate specific business rules with
positive/negative conditions
-
6. EH: Error Handling > Validate Application Error handling
- 7.
BVA: Boundary Value Analysis > Review boundary values for feature/system
interaction
- 8.
ST: State Transition > Validate application state
(i.e. workflow, session, restful state validation, etc.)
List of all the Environments on which Test
cases will be executed.
Here you should provide description of the
features and other items to be tested along with the overall depth of testing
and test methods used to discover defects.
Exit criteria must be met before sign-off
for production release will be provided by QA.
In another words "All things that
should be done before providing the sign-off is known as an Exit Criteria"
Here are some examples of exit criteria
1. All Sprint Stories/Items Accepted by QA and it is Ready for
Production
2.
Manual Regression Tests (Blocker and Critical Test Cases) have passed
3. No Critical or Blocker defects outstanding.
4. Automation Regression Suite Successfully Passed.
5. Performance Tests executed successfully.
6. Browser Compatibility works as expected.
If Possible include all of the above and
have one field to mark if criteria are applicable or not. If yes, then mark it
"Yes" and "No" otherwise.
Also provide comments against each
criteria for better understanding.
Include all the bugs / Issues that are not fixed yet.
- Add
the appropriate linking of the issues with their description and priority.
- This
information is critical and can have an effect on if Build should go into
the next phase (Production release) or not.
Comments
Post a Comment