I wanted to know if is there any way of hidding the automatic number that TestLink shows when you create a new Test Case.
In my example, "idERP" is the ID of the project, but the "-1, -2..." is an automatic number that TestLink shows, and I would prefer not to see this numbers. Is it possible?
Testlink automatic test case numbering is pretty annoying.
User cannot re-order the test case number.
As far as from my own experiments and exploration of the software, there's no way you can control the test case numbering sequence or toggle even toggle it's visibility using the GUI.
The only way you can control this is to dig into the Testlink's source code and modify the code that handles the test case numbering.
As per Wikipedia, identifier of a Test Case is assigned automatically by TestLink, and cannot be changed by users. This ID composes from Test Project prefix and a counter related to the Test Project in which the Test Case is created.
Testlink v1.9.13 - Stormbringer
Related
I'm kinda new to SpecFlow but i would like to find and run all scenarios where step is used. I know about Ctrl+Shift+Alt+S option, but when it's used 20+ times on many feature files it can be hard to test it all one after another. This question came to my mind when i updated step and needed to retest it.
Specify a tag against the scenarios that contain that step - these will then appear within Test Explorer area if you filter based off 'Traits'. You can then run all scenarios with that tag.
So for example you would have
#TAGHERE
Scenario: Your Scenario
Given
When
Then
This question is about shared steps management via the user interface in Microsoft test manager VSTS2013 and/or online via the visualstudio.com version.
Say we have a bunch of test cases with some shared steps and we clone (/deep copy, not just 'copy') the test plan. The result is that all shared steps in the test cases are also cloned, which I would expect -- so no question so far.
But, when I then go to a test case and I want to add shared steps to it, the query to locate the shared steps will show all instances of a shared step (assume I am searching by Title). How can I now make the distinction which instance of the shared steps is the right one to choose for the Test plan that my test case is in?
If I choose just any one of them I'll for sure end up with test cases from one test plan linked to shared steps in another test plan, and that sounds like something we would not want (right?).
Any light on how to properly manage test cases versus their shared steps is welcome!
Thank you,
Bill.
If your (cloned) testplan is defined under a certain iteration, e.g., Project Y\Release X, and you insert a shared step, a query is opened. There you need to add an extra clause (with an And) with as Field: "Iteration Path" and Operator "Under" The Value is for this example "Release X".
Hope this helps.
I'm currently working with Test Manager Version 2010.
When running a testcase with multiple iterations in it, a list is shown in the top left corner which has the following:
Iteration 1
Iteration 2
Iteration 3
....
My question is, is it possible to change this name to any subject so that it is easier to remember the meaning behind every iteration?
For example:
Iteration1 needs to be named Cat
Iteration2 needs to be named Dog
And so on...
Yes, and no :) I've never done this from the test manager, but here is a post that says how you change the iterations using the team explorer. You can name them whatever you want, they are nothing more than strings in a hierarchy. Even though the problem is slightly different than yours the steps should apply.
How to Add/Edit the Iteration Field in Team Foundation Server Scrum v1.0 beta Workflow
The bad news is that TFS uses loose coupling on the work items. that meens that whenever you change something like this the workitems that have used the old string will still have the old value. you will either make a script to update all work items, or manually go in and select the new value for each and every work item. If you only use the new values for new test cases (or other work item types) you're good to go.
We are using VSTS2010 for logging bugs. There are weekly builds happening and the QA/DEV updates bugs to fixed/open based on build numbers.
Since there are weekly builds happening and each build has a different number, there are chances for QA/DEV to set incorrect build numbers in fixed build/tested build number.
Questions:
Is it possible to validate the build number values based on some parameters like date of fixes?
Is it possible to show approrpiate messages for the validations?
I don't think there is a build-in way to validate the build number against parameters.
At the moment I can see two possible solutions for your problem, depending on the structure and your possibilities to change the system:
Minimize the set of build numbers to choose. You could change the source list of the build field to show a list with less entries, like only the entries of the last week/month. That would need a little script, that changes your globallist. Of course that only works, if no one else needs to select older builds.
Create an invisible custom control and add it to your bug work item. Inside the custom control you have almost any freedom to change or validate date and show them the way you want to. But you would need to develop it and install it on every PC that needs to use it.
We use Vs2008/2010 with TFS 2010 for our source control, because it also lets us create custom work item types that we can use for project management, such as product backlog items and sprint backlog items.
One item thats not tracked (by machine) is build regression test tasks for release candidates. Our regression testing is part automated, part manual, and the manual part can take several days. Currently we use an excel spreadsheet with a list of all the test cases, and then the testers just fill in results and notes.
I've been proposing creating a build regression test template that contains each test case, default owner, and then when we want to do regression testing on a build, we can automatically create work items for every test in the template.
My argument is that if the regression test work is mandatory for the project, and the results should be tracked, then writing additional TFS work items make sense, especially since the work items can hold estimates, giving managers an idea of how much re-test time remains.
The argument against this is that we already have high level work items to capture the overall project test requirements, and the regression testing is basically a "re-test", so new work items would be duplicate.
My question: Is anyone else doing anything like this? Is it reasonable to use TFS to track outstanding re-test tasks?
Note: we don't own Visual Studio Test Professional
I think it's reasonable to go with your suggested solution. You should have another work item type for the "test tasks", that can be linked as children to the test requirement work items. Doing that, like you said, would allow you to track results, progress, reporting, etc. You can also add other fields like build number, tested by, tested date, etc. to the work item type for history, something that cannot be done with just one test requirement work item type.
Essentially, what you proposed is done in the ITestResult object in the Microsoft.TeamFoundation.TestManagement.Client.dll.