I'm working with a piece of software with over 4000 automated unit/security tests.

I've been tasked with bringing requirements into an ALM. What's confusing me, is the best way to handle Test Cases.

I've written all the requirements out, which was tedious but not difficult, but these now need to trace down to test cases, and then down to execution sets.

Does anyone have experience with ALMs and automated tests? How on earth do you manage that? Given the CICD pipeline runs the tests on every single remote push (branch).

Do I need to do one Test Case document per unit test, or would it suffice to have one Test Case document, with a table that has every single test in it, and just link this one test case to all the higher level requirements?

  • 1
    What problem are you trying to solve by linking unit checks with ALM documentation? Commented Dec 16, 2019 at 9:51
  • Not sure why this was downvoted - seems like a pretty crappy thing to do for a genuine question. @JoãoFarias - all of our requirements need to have traceability to test cases, but all of these test cases are automated; so how do I prove our tests cover the requirements? That's what I just can't get my head around.
    – Trent
    Commented Dec 16, 2019 at 10:48
  • @Trent you prove your coverage by having every requirement linked to one or more test cases (possibly grouped in test goals for easier understanding). Proving that a specific test case actually does cover a specific requirement can't really be done except for going in and reading the test case, this part is usually up to the QA team to ensure as part of their responsibilities. Whether these test cases are automated or not should have no impact on the coverage of requirements.
    – Blub
    Commented Dec 16, 2019 at 12:56
  • @Trent - you mentioned a solution: "Do the aforementioned linking". What I asked is for the problem: What development problem are you trying to solve by doing such linking. If you have none, this effort would be a waste and I would suggest to move one; if the problem is, e.g., to check up that the understanding of features is covered by automated checks, you may have other alternatives, such as demos, pair programming, review, shorter integration periods. (As I said, it's an example, I have no idea of your underlaying problem). Commented Jan 1, 2020 at 21:38
  • 1
    Thank you for more details. "So we know no tests are missing" may sign a self-imposed limitation in your testing strategy which is way beyond the liking problem. A quick reading suggestion would be Michael Bolton's Breaking the Test Case Addiction, specially part 4, where he talks about FDA medical devices developsense.com/blog/2019/01/… Additionally I would suggest understanding Explicit X Tacit knowledge and the rationale behind exploratory research. Relying on such test case liking w/o awareness of these concepts may cause confirmation bias Commented Jan 4, 2020 at 10:04


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.