|Anonymous | Login | Signup for a new account||2017-04-26 00:06 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007901||TestLink||Security - General||public||2017-03-27 11:42||2017-03-28 14:49|
|Product Version||1.9.14 (2015 Q3)|
|Fixed in Version|
|Summary||0007901: using ghost steps can change executed testcases|
|Description||use a ghoststep in step1 of TC1 with a references to a step1 of TC2.|
change step1 of TC2.
as you can see, step1 of TC1 will be changed to, even if TC1 has a testresult already.
if you have a testresult for a testcase, its normal that you have to create a new version of this testcase, but the ghoststeps make it possible to manipulate everything.
there are two options only.
1. eliminate ghoststeps. they can cause a lot of trouble for example recursive loops or changing the prefix of a project.
2. make sure that nobody can manipulate results with ghoststeps.
this is a real BLOCKER for TestLink
|Steps To Reproduce||i described the steps in description|
|Tags||No tags attached.|
|QA Team - Task Workflow Status||TBD|
|If you have use ghost you wants that changes on source reflects on destination.|
can you explain please. i am sorry, but i do not understand your comment.
do you speak german?
I do not speak german.
I will retyr
you use ghost because you want to do change in a place and want this change affect multiple places, that's the idea.
Then only option that is near impossible to implement is to block SOURCE MODIFICATION (the single place) when test case that point (wants to reuse) has been executed.
BUT I do not have a simple way to get this info => can not be done
hope now is clear
i understand you.
i did software developing as well and i thought the same like you thought. it is hardly impossible to implement that this source modification will be blocked, if the testcase was executed. But that means you cannot implement ghoststeps as well.
the sense of a tool like testlink is, to do a revision anytime to what have been tested. but if you can change testcases even after execution, in the way i described, you never can be sure about the testresults.
and by the way, this is the reason why executed testcases need a new version, if you like to change a testcase.
You can fix this (partially) with procedures:
1) Test Cases that are SOURCE for GHOST can not be executed.
2) Test Cases that are SOURCE for GHOST can not be edited Anymore after you have changed it's status (this can be done on TL via code)
I would like to know how other Test Case management systems that implement test case reuse cope with this problem.
Problem is worst when using ghost at test step level, because you can create a test case that uses step from several test cases.
Then idea is use ghost feature best as you can
in my opinion, using ghost steps needs an own table in database to show all relationships/dependencies AND to avoid:
- endless loops with each other calling ghoststeps
- problems with rename project prefix
- testcase changings in a version where testexecutions allready exist
i talked to all of my testmanagers and they see the same problems.
long time ago, we decided to use a comment after a ghoststep with the source of a step, to make sure that we see all ghoststeps.
maybe this will be a nice feature for a future testlink.
but the 3 mainproblems i mentioned are still the same.
This need lot of analysis before any attempt to do a new design.
An for this an sponsorship will be a must
|2017-03-27 11:42||stef-lhm||New Issue|
|2017-03-27 12:39||fman||QA Team - Task Workflow Status||=> TBD|
|2017-03-27 12:39||fman||Priority||immediate => high|
|2017-03-27 12:50||fman||Note Added: 0026204|
|2017-03-27 12:55||stef-lhm||Note Added: 0026205|
|2017-03-27 13:36||fman||Note Added: 0026206|
|2017-03-27 13:54||stef-lhm||Note Added: 0026209|
|2017-03-27 19:51||fman||Note Added: 0026212|
|2017-03-28 12:29||stef-lhm||Note Added: 0026215|
|2017-03-28 14:49||fman||Note Added: 0026216|
|Copyright © 2000 - 2017 MantisBT Team|