| || |
What is difference between Test Plan and Test Strategy?which comes first.Shall we change the test strategy document?
Re: Test Strategy
Okay - Some may say there is no difference.
However, this is my opinion; I see them as different docs.
Test Plans can be created down to a function level and you can have many test plans within a project, for a product.
However; with that I must add, I have actually created two separate Test Plan documents - one project specific, and individual area specific.
And my Testing Strategy doc - tends to be department/team specific and it is a growing living document that transcends projects.
The Test Plan - normally is the project related one. I tend to flush out the following, keeping in mind REAL TIME, REAL THOUGHT (not some document that gets filed and forgotten, and I tend to use WIKIs for it.
What are we going to do: The approach we're going to take with the testing during this project to achieve the project goal for Quality
Why are we doing it this way: Benefits of the approach, risks, caveats, business decisions made out of my control that affect testing (like we're ONLY going to have 2 days!)
How are we going to do it: Tools, tasks assignments, sorta big bucket workload
When are we going to do - SCHEDULE!!! Milestones and requirements such as feature needs to be complete before we start testing, or taking every build and testing what we can but testing will stop on X.
What are WE not doing = this is just as important as what we are doing. Bug sweeps, Areas not being tested, approaches not going to be touched etc.
Who is going to do what: nice to know the players involved
Criteria for areas, features, functionality: Normally I do a grid here - KISS. Name of Feature, Type of Coverage (Smoke, P1 testing, P2 testing, Pass/Fail/Restart requirements)
Expectations/Requirements to fulfill the project quality - This is where I put down things like, willing to ship the product even if there are open P0 bugs because of hard deadline.
Backup plans (if [stupid is as stupid does] happens [img]/images/graemlins/wink.gif[/img])
Now for Testing Strategy - as a Department doc it is: a Working Doc, not quite - Living - as in changing rapidly, but can change as needed for the department and team.
In it I:
Define terms (this is QUITE HELPFUL, for example if ALPHA doesn't mean the same to both sides of Engineering - IT CAN and WILL become a problem)
Define Nomenclature of the product (I can't begin to tell you how many times if you all don't agree on what a text pulldown in the product is called how swirl of bug reports start to happen)
Define Processes that will be used
Define how Test cases are to be written
Define how Bug reports are to be written
Define Bug Triage flow
Define when Bug scrubs and who are the participants
Define Location of files, depositories, suites, tools used
It is where I tend to put Performance baseline numbers to keep
It is where I put links to Product docs of previous features and releases.
Normally this is multiple wiki pages linked together from a master Wiki page for nav purposes.
And I always encourage the team to collaborate and add. After all its 'OUR' Testing strategy, not just mine.
Re: Test Strategy
So- to simple answer your question: depending on what you're doing.
If you're building a team and no immediate project - Do a Strategy doc
If you're starting or in the middle of a project - Do the Test Plan - and re-use pieces of it to start your Test Strategy after the project is done.