I'm researching certain aspects of web-based UI regression tests of a customized closed source remote standard software.<p>I have close to no experience in software testing.
AFAIK test cases should be rather atomic and carefully consider state.<p>>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.<p>>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)<p>More specifically:
According to common best practices if I test the behaviour of several UI elements on the same page A, do I…<p>a) …Repeat the whole login and navigation process for every UI element?<p>b) …Seperately test login and navigation to A?
Does this differ for manual and automated testing?<p>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 <i>do</i> I effectively avoid such side effects? Re-deploying the customizations to a vanilla system before each test? That is not feasible.<p>I appreciate any input.