What strategies do people use for keeping Test Cases up to date in Azure DevOps?

Occasional Visitor

At the moment test cases in my team are created per sprint. They're usually linked to a work item (but not always).

Because the functionality develops and changes as the team iterates, tests often become redundant or out of date.

I can see there is a "State" field, which might be used as part of a process of keeping things up to date.

What process do you use to keep test cases up to date as functionality evolves?

1 Reply
Rather than use the "Azure Test Plans" module (which has a silly licencing/pricing arrangement, and would complicate our use of DevOps); we use the Test Case features available with the Basic licence.
We introduced a new Work Item Type called "Test Set" as a simple way to group Test Cases (similar to a Suite, but we don't call it that to avoid confusing them).

Test Cases have State. We use it to indicated: Design(writing), Ready, or Closed (removed/withdrawn).

We get the test outcome visibility using the "Tests mini-module" that can be activated for any Item shown on the Board. This jives well with our sprint-based way of working.

Yeah keeping Test Cases up to date is a tricky part. The whole team gets value from Test Cases (especially for pre-existing / installed-user-base services they may not be familiar with yet) - but few want to write or update them lol. Alas, if team wants the output (value), they do the input (writing/maintaining), lol. It's "their product".

The key opportunities for that which we find:
1) During backlog refinement / Story make ready.
2) Throughout the sprint :)
Liaise with team to consider making "TC's Ready" part of Definition of Ready. And, "TC's up to date" part of Definition of Done.