Anyone use Azure Devops and it’s Test Plans integration for “test case management”, mostly as it relates to manual testing? I use this term super loosely as I’m only “documenting” test cases for our more critical regression tests for our offshore team to run. I’m curious what people’s experience has been in creating test cycles in this tool that make sense. I find it rather clunky and difficult to work with. Curious what others have experienced with this? Or if they’ve just tossed in the towel and found a better means of managing the test effort? I’m not seeing much referenced on this tool which makes me wonder if it’s actually used much; Azure DevOps is definitely more included to support the CI/CD model (we have quite a ways to go on that yet). Thanks!
An example of it’s functionality that drives me batty…
I can either define test cases be query, which pulls in everything that matches that query automatically (cool if I want to add a single test case). I’m unable to remove single test cases in a suite, however, which is goofy.
On the flip side, if I have a static test suite, I’m then able to remove single test cases in a suite BUT I’m unable to add individual test cases.
I’m afraid I don’t understand your difficulties (yet). Both in static suites and in requirement based suites I can add and remove single test cases.
Oh I finally figured out what my issue was with creating test cycles and adding individual tests It’s not the most intuitive tool and I was unaware I could add single test cases to static cycles and “expected” query-based test cycles to stop adding tests when the sprint dates passed. Oi. I’ve got that now.
I am curious though how you are organizing your tests - are you using tags? If so, thoughts / tips on how to best use this method so you don’t go crazy?
I’m mostly working on setting up the test plan functionality for manual testing for some remote testers we have on contract in India, hence my questions are around that aspect currently. Thanks again!
With Azure DevOps (ADO) some prefer to use tags and queries a lot, and rely less on hierarchies and fields. “Iteration/sprint - make it a tag, system area - make it a tag, what team test this - make it a tag” etc. And then use queries to find it, and similar to build the test plans (in the tool) if needed. You can become less reliant on the “Test plan” module of the tool this way.
It basically opens up the suite as a spreadsheet for editing and adding new tests, which was great for importing some of our older tests. Creating in the Test Suite level let me bypass trying to find all my test cases back again through queries later.
We just started looking into the “Modern Requirements” add-on which looks super helpful for traceability of test cases.
I was wondering if you could expand on becoming less reliant on the “Test Plan” module. I ask because I’m new to ADO Test Plans and I am trying to create a strategy and documentation on best practices for our teams. Is there a better way to set up testing without using Test Plans? I’m intrigued. Please tell me. Thank you!
ADO’s test case work item is primarily designed to hold the preparation and description. This is seen explicitly in the state field. It has “new, Design, Ready” - but not “Passed” nor Failed. Also with the test plan module are some other features wrt tracking and test runs that might be relevant in large settings. In smaller IT shops, it might be sufficient to agree on adding a “passed” in the drop-down and then clone the tests if they are to be run more than once. Hope that helps
PS: while it seems necessary to create a “test strategy document” - make it less about how a tool is set up and more about why and the principles behind your choices. Then the rest is more a tool guidance.
It’s not the most intuitive tool and I was unaware I could add single test cases to static cycles and “expected” query-based test cycles to stop adding tests when the sprint dates passed. Oi. I’ve got that now.
Thanks again!
