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

[BenjH1205]

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?

[#2]

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.