Hey,
Not finding adequate answer to my question on the internet I thought I would share it here.
If you have 3 categories to test: UI, Audio and Network.
A) Do you do 3 tests per category but then it duplicates itself like “Go to X and verify UI”, “Go to X and verify Audio”, Go to X and verify “Network”?
Or
B) Do you do 1 test per functionality and do “Go to X and verify UI, Audio and Network”
A is clearly readable and if audio fails you know that functionality X failed in audio you know exactly what happened. This is at a cost of checking same functionality 3 times but from 3 different perspectives.
B) Removes redundancy of tests but if it fails you know that X functionality failed but you don’t know what exactly failed.
The other part is I have testers per category, for audio, art, ui, network etc. so we are preparing Audio test suites, UI test suites etc. This makes it easier to maintain and we know which category is in what state instead of what functionality which is more or less natural cause we have teams dedicated to category not functionality.
Then again is it bad to have redundancy in such cases? Any thoughts how to approach it? Do you have any good materials on the subject?
Personally I would go with scenario A. I would only ever want one expected outcome per test case.
What I would ask though is do you definitely need to document test cases in this way? Is it adding value to your software delivery process?
I was going to suggest mind-maps for your scenario. It allows people to see the expectations/test strategies for the entire product, despite the fact there are multiple teams working on different areas. There are a few good resources online (Darren McMillan, Katrina Clokie) but this article is a good starting point:
“What I would ask though is do you definitely need to document test cases in this way? Is it adding value to your software delivery process?”
Seemed natural at the time. Makes it easier to maintain TC’s, easy to edit them, Testrail enables creating testplans out of sections easily so it makes it very quick and easy to maintain them but a lil bit longer to execute.
That’s fair enough, depends on your context. I’m not a lover of test cases - I feel they’re often unnecessary admin and I’m still not convinced by the value they provide when testers are following them step by step.
In saying that, I’ve still not implemented an alternative and I’ve never used Testrail! Mind-maps definitely interest me though.
I don’t favor step by step test cases either. I prefer testers be testing rather than administrating. I think step by step instructions, if needed, can be documented outside of the test case. That leaves the test case to focus on what is under evaluation - the important stuff.
For example, if the focus of the test is to explore functions around foreign currency exchange, then the test case details scenarios with set up information and a reference to a specific place in the documentation for execution. If needed, there could be expected results as well.
With respect to @gingernatt’s original question, I wanted to understand what information might be available from unit tests. This might help narrow the focus of further testing and simplify test organization.