I have close to no experience in software testing. AFAIK test cases should be rather atomic and carefully consider state.
>With "branching" I mean only once executing steps different test cases commonly begin with and only then starting to execute each test cases' unique parts one after another.
>With "stacking" I mean integrating test cases that depend on each other into one "stacked" test case that reports how far it got ("until login-page", "until login as A", "until placing ABC in shopping cart" etc)
More specifically: According to common best practices if I test the behaviour of several UI elements on the same page A, do I…
a) …Repeat the whole login and navigation process for every UI element?
b) …Seperately test login and navigation to A? Does this differ for manual and automated testing?
Especially when it comes to manual testing and test cases that I do not expect to affect global state but are rather UI-focussed I thought about grouping those test cases (as in once logging in and navigating to page A and then testing all ist UI elements one-at-a-time. But it feels like a "process smell" to me. Even if I don't expect them to, I feel like "using"/"triggering"/clicking the UI elements might actually cause unexpected side effects that interfer with the result of the next UI elements' tests. But as I don't have access to the sofware's internals how do I effectively avoid such side effects? Re-deploying the customizations to a vanilla system before each test? That is not feasible.
I appreciate any input.
No comments yet.
