Use cases are a way to translating requirements into something more concrete. If you have use cases, you should test with them. You should test in other ways, too.

How you represent your test cases is up to you. Some considerations for picking a representation might be tool quality and cost, and ease of writing, revising, searching, annotating, and grouping test cases. Or course you should consider how easy it is for someone (other than the author) to interpret the test cases too.

If you are just getting started with use cases, and you aren't sure which representation is best, you might try an experiment, e.g. pick your two favorite representations, split your test cases into two groups, and try each representation with one of the groups.

Use cases are a way to translate requirements into something more concrete. If you have use cases, you should test with them. You should test in other ways, too.

How you represent your test cases is up to you. Some considerations for picking a representation might be tool quality and cost, and ease of writing, revising, searching, annotating, and grouping test cases. Of course you should consider how easy it is for someone (other than the author) to interpret the test cases too.

If you are just getting started with use cases, and you aren't sure which representation is best, you might try an experiment, e.g. pick your two favorite representations, split your test cases into two groups, and try each representation with one of the groups.