one more question, on the execution of test plans.
I'd like to log the build which a test case was passed on.
Imagine you are going through a development cycle and it takes several builds to complete the whole testplan - due to its size or due to retests.
Now, some functionality breaks _after_ you have tested it.
Now you want to know which build it was successfully tested with.
Is there a way to state the build you are testing against (maybe even without entering it over and over again for each test case, but only once a day, or after installing a new build)?
In the history you might then find:
* test case "A" passed on Build 10000
* test case "A" failed on Build 10002
* test case "A" passes again on Build 10050
Same goes for different versions: How was this test case performing in v1.0, v1.1, v2.0?
Thanks
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Michael,
I've been thinking about this and it looks like there's no simple way to do what you wish with the current codebase.
I think a solution may be to associate this information to single test runs using use custom fields, but this will require a new testmanager release.
It's not so complex to implement: I'll have to wrap the testcasehistory table with a class (it is the only one lacking it at the moment) and adding support for custom fields.
I'll then need to add user interface means for reading and setting this information.
I think the right way to do it may be to be able to edit custom fields directly into the list with the status change history found at the bottom of a test case (in a plan) page.
I would also add an XML-RPC API to do it, if some wishes to do it automatically (for example at the end of each build or test automaiton run).
You may then be able to define a custom property like "build number" and another one like "version", and record success or fail infomrmation on each test run of a test case in a particular plan.
What do you think?
Ciao,
Roberto
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the prompt answer. Unfortunately, I was only able to read it today.
Changing the code base is not a big deal for me, as I'm only running the tool for the first pilot tests, and I'm the only one using it so far.
However, it would be great if the update was straight forward without too many fiddling with the database.
As indicated, it would be great if the tester did not need to enter the same data over and over again, so the build and version should be pre-populated (but maybe editable).
Best regards
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i have the same problem. Actual we have a custom field and have to enter the information several times.
This is also exhausting because of the handling of custom fields (press edit button, enter value, press ok and do the same for the other custom fields..)
So i would be happy with every improvement.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Roberto,
one more question, on the execution of test plans.
I'd like to log the build which a test case was passed on.
Imagine you are going through a development cycle and it takes several builds to complete the whole testplan - due to its size or due to retests.
Now, some functionality breaks _after_ you have tested it.
Now you want to know which build it was successfully tested with.
Is there a way to state the build you are testing against (maybe even without entering it over and over again for each test case, but only once a day, or after installing a new build)?
In the history you might then find:
* test case "A" passed on Build 10000
* test case "A" failed on Build 10002
* test case "A" passes again on Build 10050
Same goes for different versions: How was this test case performing in v1.0, v1.1, v2.0?
Thanks
Michael
Hi Michael,
I've been thinking about this and it looks like there's no simple way to do what you wish with the current codebase.
I think a solution may be to associate this information to single test runs using use custom fields, but this will require a new testmanager release.
It's not so complex to implement: I'll have to wrap the testcasehistory table with a class (it is the only one lacking it at the moment) and adding support for custom fields.
I'll then need to add user interface means for reading and setting this information.
I think the right way to do it may be to be able to edit custom fields directly into the list with the status change history found at the bottom of a test case (in a plan) page.
I would also add an XML-RPC API to do it, if some wishes to do it automatically (for example at the end of each build or test automaiton run).
You may then be able to define a custom property like "build number" and another one like "version", and record success or fail infomrmation on each test run of a test case in a particular plan.
What do you think?
Ciao,
Roberto
Hi Roberto,
thanks for the prompt answer. Unfortunately, I was only able to read it today.
Changing the code base is not a big deal for me, as I'm only running the tool for the first pilot tests, and I'm the only one using it so far.
However, it would be great if the update was straight forward without too many fiddling with the database.
As indicated, it would be great if the tester did not need to enter the same data over and over again, so the build and version should be pre-populated (but maybe editable).
Best regards
Michael
Hi,
i have the same problem. Actual we have a custom field and have to enter the information several times.
This is also exhausting because of the handling of custom fields (press edit button, enter value, press ok and do the same for the other custom fields..)
So i would be happy with every improvement.
Christian