View RSS Feed


Making of a Test Strategy

Rate this Entry
by , 03-21-2014 at 01:58 AM (4399 Views)
(Note: In this post, I have used both "QA Team" & "Testing Team" terms in the post below. They both mean & represent the same - i.e. a Testing Team.)

Have you ever faced this question from somebody in your organization: What is your test strategy? ... and then does this place you in a dilemma of what to say? A test strategy is a very important artifact for a QA Team and provides an overall picture of how testing should be approached for the AUT (Application Under Test). With my experience, I have observed that most of the testers, test leads and managers typically approach creating a test strategy with simply filling a ready-made template. But, then this undermines the very need of a "well-thought of" testing approach. There is a need of lot of thought, review & caution that should be exercised in ensuring a correct Test Strategy for a QA Team.

At the end of the day, Test Strategy (although, a living document like a Project Plan) gives very important information on the testing direction of the complete QA Team for the AUT (both manual & automation. It also covers Security, Performance and any specialized testing team needs).

A test strategy helps a tester / testing team "define" the "approach" to test an application.

There are some very important aspects to come up with an approach. It depends on "What is the..."
A) Primary Business Objective?
B) Project management methodology (Waterfall, Agile, Mix of both or some other)?
C) Test design?
D) Testing Context?

A brief outlook for these is given below.
A) Primary Business Objective: A business objective is a very crucial piece of information to identify your testing approach.
For example, if your primary business objective is to "Have a very secure application use for its users", then security tests would becomes the most important & deeply designed feature in your test approach. Similarly, even during functional tests, if the primary business objective for a financial application (lets say) is to ensure the correct numbers are displayed, then ensuring the correct numbers is the most important feature in your test approach.

B) Project management methodology (Waterfall, Agile, Mix of both or some other)?
The project management methodology is important to ensure that the complete test life cycle is managed appropriate to how the SLDC is managed. If the testing team works tangentially to the overall SDLC setup, this can have a serious impact on the QA deliverable and the AUT quality shall be questionable for all milestones of the project.
To best explain this, if you consider a waterfall model to manage a project, QA teams should ensure review of the detailed documented requirement specifications as well as technical design documents with the appropriate stakeholders. Apart from this, QA teams can implement "Complete Project Life-Cycle Testing" approach to ensure, that they are involved in the requirements definition and management process right from the start of the project. This helps with a defect preventive approach right from the start of the project.

Hence, having an overall view using a project management methodology can impact on, how you "define" the testing approach for the Test Strategy.

C) Test design?
This piece is the most crucial to define & finalize the correct testing approach for any product / application. Apart from the usual test levels and having defined the test phases, the different testing types that could be considered are:
1. UI
- UI
- Usability** (Special Skill Sets are required)

2. Functional
- Positive Cases (Happy Paths)
- Negative Cases (or Validations)

3. Security
- Role Based
- Technical** (Special Skill Sets are required)

4. Performance** (Special Skill Sets are required)
- Load Tests
- Stress Tests etc...

5. Batch & Interfaces
- Internal
- External

and many more... (based on the "Project Type").

In most of the cases, where functional tests are considered (which are core tests), the below division could be helpful.
2. Functional

2.1 Positive
2.1.1 Application Flows
2.1.2 Business Flows

2.2 Negative (or Validations)
2.2.1 Field Level Single Field Multi-Field

2.2.2 Business Level Single Field Multi-Field

2.2.3 Cross Validations between Fields (for the division given in 2.2 above)

The above divisions help understand & define a testing approach for a single application. When multiple applications are integrated and there is a need to perform SIT, the testing approach needs to be broadened by considering the appropriate testing types. Specific testing types should be added to satisfy the primary business objectives Or special emphasis can be given to one of the common testing types to satisfy the primary business objective.

Considering all of the above testing types, correct grouping of test cases needs to be derived. The finalized groupings are then used to create the test scenarios or test cases. Execution can be planned after a good mix of priorities & the mapped "testing techniques", which again gets influenced by other project management parameters.

D) Testing Context?
A testing context encompasses certain factors related to the context or a setup, such as...
1. Available Testing Tools
2. Testing Team composition & maturity
3. Adoption of Testing Processes
4. Availability of Testing Environment and Support &
5. Release Management procedures
6. Test Measurement Techniques & Requirements (*Metrics Management)
7. Test Automation Framework, Architecture and Management

Considering all of the above factors, the finalized test approach is put in to derive a Test Strategy. A test strategy document apart from giving the right approach also addresses many other aspects of testing. These are the ones that you can get from an available Test Strategy Template Or I shall be commenting on these in my future posts.


vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 02:35 AM.

Copyright BetaSoft Inc.