Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000189TestLinkTest Specificationpublic2005-10-19 19:222008-11-07 19:46
Reporterfman 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Fixed in Version1.8 Beta 1 
Summary0000189: TL NEXT GENERATION - Test Case Specification and Test Case on Test Plan
DescriptionOne thing that may be is important is to rethink , is difference between TestCase Specs, and Test Plans.


One example with TL 1.6:

1. Create a Product with components and categories,
and TC definitions TC1(TC Specs)
2. Create Test Plans: TP1, TP2, TP3
3. Add TC1 to TP1, TP2 and TP3

You have now 4 copies of same data:

One - the TC1 spec (in table mgttestcase)
Three one for every TP (in table testcase)

May be for the Next TL version can be a better solution a good management of
TC version (something like is done in Qatraq?) and maybe Container version (Product, Component, category)

If we use a really TC version then we can do this:

1. Create V1.0 of TC1 Spec
2. LINK this SPEC to TP1,TP2 and TP3 (Link means NO STEPS DATA, EXRESULT data and so on is copied).
3. if you want a NEW version of TC1 Spec, you create a New one WITHOUT LOOSING previous versions.

4. The "Update Modified TC" featrur can control LINKED TC Version againts Last SPec version o
will all available TC SPECS version, and ask the user what version he/she wants to link to
the TP.

5. May be the Active/Inactive attribute can be added to every TC SPEC version.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Files

- Relationships

-  Notes
(0000254)
fman (administrator)
2005-10-19 19:25

I've gave a look to Qatraq version management, and seems to be similar to
TL (with a difference user can choose betweeb minor or major or both upgrade
in the generation of new version number).

I think a better approach is needed, I would like to create V 1.0 for TC1,
and made changes to it, and decide WHEN this changes must create a new version.
This way the version number will not rocket to the clouds (has happens today).

- Issue History
Date Modified Username Field Change
2005-10-19 19:22 fman New Issue
2005-10-19 19:25 fman Note Added: 0000254
2007-02-19 23:23 mhavlat Project Testlink 1.6.x => TestLink
2007-11-09 02:20 fman Status new => resolved
2007-11-09 02:20 fman Fixed in Version => next development version (1.8 Beta1)
2007-11-09 02:20 fman Resolution open => fixed
2007-11-09 02:20 fman Assigned To => fman
2007-11-14 16:40 mhavlat Severity minor => feature request
2007-11-14 16:40 mhavlat Category New Feature => Test Specification
2008-06-03 16:49 mhavlat Fixed in Version next development version (1.8 Beta1) => 1.8 Beta 1
2008-11-07 19:46 mhavlat Status resolved => closed



Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker