The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. Test Spec :
a.Explains the scope.
b.Defines how the testing should be approached.
c.It covers all the environment aspects : How to set up & start the tests.
d.Pointers to all the resources & links.
e.A link to test cases template
2. Test cases template Doc:
a.Testing team takes care of filling up this template.
b.Referring the Requirement doc & all the resources given to them for grasping the product.
c.They generate the whole test cases.
There are some confusion in team asking why we need two docs?
Does combining these two would make sense?
Where I work the developers work off 'user stories' and the testers write their tests independently, which I think is slightly ridiculous as it means that the testers get two days to test and discover defects then the devs have a short amount of time to put in the fixes and get it back to the testers.
The test documentation should really be part of the specification because the developers should ensure that their code passes the tests.
Sure it's good for the testers to independently try and break the code but for goodness sake why would you put the devs and testers in a position where they are not agreeing on what the functional specification is?
Actually I do know why, the answer is one word "Agile"
“That which can be asserted without evidence, can be dismissed without evidence.”
There are no rules; you can call your documents by any name you want.
However, if I were handed two documents with the names you've given, I'd assume that:
The Test Spec doc is the overarching description of how all tests of everything should be configured/followed/whatever, and should be provided be the chief tester.
The Test cases doc contains use cases that have to be given attention when designing tests for a specific project/component/app/whatever, and should be provided by either the docs team or someone in a customer-facing role.
I wouldn't expect docs with either of those names to contain any actual tests.
I wanna be a eunuchs developer! Pass me a bread knife!
The test spec also should state the requirements for the test cases, such as coverage (both in % of code lines and input values), identify external border case values and other environmental elements, and level(s) of reporting from each test case. (Maybe you consider this part of how the test is configured, but that should extend far beyond the technical aspects of how to hook up the pipes in order to make the test run.)
You would expect a Test Spec to be just general considerations about testing at large?
I would expect a specification to give the specifics of the testing of a system. General principles and methods with no specifics about a product or test suite I refer to as a Test Framework,
I would expect a Test Spec to make concrete specifications for this specific set of test cases: For this specific product we require a minimum of 98% coverage of ordinary code lines, 90% coverage of exception handler code for "expected" errors and 80% of "not expected exceptions", for input values of T from -30 to +70, input value B from -1 to 100,000 ...
Another, high reliability project might require coverage of 99% of all exception handlers, and 99,5% of all possible branch outcomes, more specific requirements to the input space testing (border cases, combination of border case input values - in a realistic scenario, it is never possible to test all possible inout combinations - etc. etc.).
A test spec is a requirements spec for the testing. A requirements specification is product specific. So is the test specification for the same product.
(But then again: In some environments, a "Requirements specification" goes way beyond the customer's requirements, even beyond the solution architecture but sometimes far into specific code design aspects. I have fought this for many years: The real customer requirements might be far better covered by a different architecture, and certainly by another code design. So why does a requirement spec limit us, prohibit us, from satisfying those requirements in a better way, through a different architecture and code design from that which is "required"?
THis is really the same question in a slightly different area: Which information goes into which document. Today, it seems to be fully accepted that a "Requierements specification" can go as far down as to include interface definitions in one specific language, and screen dialogs created by one given UI generator tool, all stated as a "requirement". Maybe we should simply give up, letting those who have succeeded in forcing their coding style and their pet development tools through, rule. Give them the power to reject any other solution: No, the customer has required that we implement it with exactly these interfaces, with a UI that can only be realized by this tool!
But then: When the customer identifies his problems and needs for a solution, without making any specific demands for implementation tools or inteface specs or whaterver, he just details his needs for the solution, what shall we call that document? Is "Customer Wishes" a term that might be used, or will the turf warriors grab that term as well, declaring that whatever the customer says, his real wish is a solution implemented in Python, using a cloud based iPhone app, even though the customer never mentioned any of this in the consultations?)
Sounds good, however the place I works 'Agile(ish)' which means the project gets given to whoever can do it, they start, get shifted on to other things, task gets hardware, hardware needs correcting, there are lots of 'hurry up' you are a bottle neck. Eventually something goes out.
We started to go the two doc route, stopped it went back to one monolithic document that can cure insomnia, try to integrate tests to a Jira system, fail, go back to monolith that takes a small forest to print (because you must record results on paper). So in short go for two!
We used to call them as Test Plan, and Test Cases Doc.
Test Plan is what you call as Test Spec. Test Cases Doc is where the test steps for each test case are listed, along with Traceability to Requirements, and additionally it has a column Pass / Fail / Marginal. Sometimes the Test Report, the actual pass/fail/marginal report for each test is a separate Excel sheet.
There's no point in trying to have an intelligent or intellectual discussion with fatboy/munchies matt.
If you heard a whooshing noise, it was the meaning of what you said flying over his head -- but don't worry: he'll google for a wikipedia page on the subject, and instantly become the world's greatest expert on it.
Thankfully, he's the only troll that has made CP his home.
I wanna be a eunuchs developer! Pass me a bread knife!