Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001614TestLinkRequirement Managementpublic2008-07-14 20:512010-08-31 20:26
ReporterTestLink_User 
Assigned Tofman 
PrioritynormalSeverityfeature requestReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.8 Beta 1 
Fixed in Version1.9 Beta 6 
Summary0001614: Enhancement of "Requirements" funtionality (plan)
Description"Suggestions for "Requirements" in future releases"
These are suggestions for Requirements Management.

1.De-couple Requirements management from the management of Test Project/Test Suites/Test Cases. By doing so, this will provide a lot more flexibility to the way that Requirements & Design capabilities can be developed in future release of TestLink.

Note : currently, you try too hard to relate Test Suite/Case to Requirement such that Test Suite/Case is generated automatically from Requirements. This is not necessary.

Analogy : Not every test execution will result in a bug that needs to be logged to eg.Mantis (bug tracking system). Likewise, the items raised in Mantis may not necessary be from test execution, eg. I can setup Mantis for tracking requirements issues, design issues, test issues,etc,etc.


2. Strategize and develop 'Requirement and Design Management" as a standalone module with its own main page, with some integration to the existing functionality of Test Suite/Case/Plan. For example, allow for user to select which of the Requirements/Design items that they would like to generate test suites/cases.

3. Currently, a "Test Project" can be setup to refer to Integration Test or User Acceptance Test or Performance Test, etc. while they are all under the same 'Project'. For large projects, testings can become very complex such that it is difficult to classify these as 'Test Plan' in TestLink.

With the inclusion of Requirements into TestLink, there is a need to introduce a structure higher than the current meaning of Test Project. Requirements/Design can fall directly under the higher structure (Project) instead of being 'forced' under the 'Test Project'.

                            







TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Files

- Relationships
parent of 0001433closedfman Implement requirements versioning and baseline 
related to 0003019closedfman Requirement Versioning 

-  Notes
(0003801)
mhavlat (reporter)
2008-07-15 16:02
edited on: 2008-07-15 16:10

I understand your view. The currently there is no enhancement on requirements feature. The original purpose was to allow traceability between REQs and test results.
However some users start to use it also to maintain requirements. In this case you are absolutely right. Now, there is no changes in 1.8 and no plan for 1.9. We are looking to improve test specification and test results at the first place. It means that we looking for a man who can overtake enhancement of the feature.

I would like to ask potential contributor to announce his interest here or to my email.

Consider also the next proposition:

1. User should choose to use internal requirement feature (the current solution) or switch to trace external tool for collaboration (for example OSRT, Doors).
2. Requirements should support audit (define baseline for a release) and allow review process.
3. Implement REQ versions
4. Implement tree menu.
5. Consider implementation of parent-child relation between requirements in far future.
6. Implement kind of requirement

Generally I see the most important to allow collaboration between OSRT and TestLink. So, we receive solid functionality and save own resources.

(0003807)
mhavlat (reporter)
2008-07-15 17:26

Yes, it's a lot of work. I wrote it to draft a plan and overall architecture. I personally have not time to enhance it. Hopefully Kevin or somebody other could interest in.

Refinement:
4. I mean unlimited depth as test cases have.
5.,6. It's concern of deeper work with requirements. I believe that requirement engineers know such attributes. Our interest is relation to testing. For example requirement type INFO is automatically not testable and we need not to cover it by test cases. Test coverage of a parent REQ should be solved with respect to all child requirements. There should not be specific explanation, but rather in child issue (if somebody decides to implement it).
(0004036)
dzko (reporter)
2008-09-02 23:51
edited on: 2008-09-02 23:55

Existing functionality includes possibilities more or less to manage REQ's inside tests using some outside tool for REQ's management itself (hiperlinks and attachments possibilities are included). So I can agree mhavlat that for traceability between REQ's and test results it is enough and quite good (we are using this in this way too), but of course not enough for management of requirements as is even in small projects.

(Only thing - Requirements based reports should be rewrited to include optional or added execution statuses, in v.1.8 beta2 seems that these are only reports where added statuses does not work).

(0011039)
fman (administrator)
2010-08-31 20:26

Release BETA 6 - 20100831

- Issue History
Date Modified Username Field Change
2008-07-14 20:51 TestLink_User New Issue
2008-07-15 16:02 mhavlat Note Added: 0003801
2008-07-15 16:02 mhavlat Status new => feedback
2008-07-15 16:05 mhavlat Projection none => redesign
2008-07-15 16:05 mhavlat ETA none => > 1 month
2008-07-15 16:05 mhavlat Summary Suggestions for "Requirements" in future releases => Enhancement of "Requirements" funtionality (plan)
2008-07-15 16:05 mhavlat Description Updated
2008-07-15 16:09 mhavlat Relationship added parent of 0001433
2008-07-15 16:10 mhavlat Note Edited: 0003801
2008-07-15 17:26 mhavlat Note Added: 0003807
2008-09-02 23:51 dzko Note Added: 0004036
2008-09-02 23:54 dzko Note Edited: 0004036
2008-09-02 23:55 dzko Note Edited: 0004036
2009-02-14 00:32 mhavlat Status feedback => acknowledged
2009-12-27 01:30 fman Relationship added related to 0003019
2010-08-22 18:53 fman Status acknowledged => resolved
2010-08-22 18:53 fman Fixed in Version => 1.9 Beta 6
2010-08-22 18:53 fman Resolution open => fixed
2010-08-22 18:53 fman Assigned To => fman
2010-08-31 20:26 fman Note Added: 0011039
2010-08-31 20:26 fman Status resolved => closed



Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker