|Anonymous | Login | Signup for a new account||2020-02-25 12:25 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001614||TestLink||Requirement Management||public||2008-07-14 20:51||2010-08-31 20:26|
|Product Version||1.8 Beta 1|
|Fixed in Version||1.9 Beta 6|
|Summary||0001614: 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'.
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
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.
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.
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).
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).
|Release BETA 6 - 20100831|
|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|