Repeat/common Test steps in multiple test cases - to do or not to?

Question

I am trying to seek some input on what might be an efficient best practice. I have been told that end-to-end test cases might have certain steps that are being repeated on other test cases. Let's take the example of Login - 2 test cases might have steps where login is step 1.

My point being - is it good design to have test cases be very modular or decoupled so that for example login functionality is not being repeated in more than 1 test case?

Are there pros or cons to these choices?

@Phil Kirkham - The client is Risk Averse and Waterfall and wants detailed test cases but this is an Agile Pilot

@Joe Strazzere - This question pertains to manual test scripts - they are done by the same person - but in his defense he wants them detailed to avoid KT if multiple testers were to use it

Answer 1

ved, welcome to SQA. You should distinguish between testing the login functionality and merely using the login functionality. End-to-end tests are about ensuring that all the pieces fit together when someone uses the software for a specific task/workflow. If an end-to-end test requires logging in, by all means use the login functionality. However, if you have a multiple end-to-end tests, and the conditions that impact the login functionality do not vary from one test to another, it probably does not make sense to test the login functionality in every end-to-end test. If the login functionality is complicated enough, I would recommend constructing a separate (not end-to-end) login functionality test instead.

Answer 2

Time and again as a contractor, I've seen large monolithic test structures with code all over the place. Often it's because testers have copied and pasted tests, which then break and need to be fixed in dozens of places, instead of just one.

As such, yes, there's certainly benefit to re-using core functionality, as long as it's not the part you're testing.

So, if, as you suggest, login is the feature under test, and it's an aspect you use a lot (as most applicationss/sites would), have it early on in the test, and wrapped in a test case.

**Test A - tests login functionality**
result = login_to_my_site(username_from_db);
Assert(IsTrue, result);

So that way, you've got a test for login, and if it's early, you can fail if there's a problem immediately.

After that, you can re-use that functionality as it's solid and working, assuming it passed.

**Test B - tests user profile page loads**
Assert(IsTrue, login_to_my_site(username_from_db);
Assert(IsTrue, profile_page_loads());

It's rough but hopefully it helps present the idea. Modularising every 'test' of functionality allows confident reuse of code later on.

Answer 3

Like the others here, I'm in favor of decoupling and modularizing as much as possible. My preference is to have a set of independent login tests (including checking the message received for invalid login, triggering the security questions if they exist, and so forth). Those would include some valid logins like "Log in as admin", "Log in as guest" and so forth.

For the end to end tests, I have a set of equally modular test cases which get strung together to form the end to end test. So - as an example - testing ordering something from a webstore, I'd do something like this:

• Login as valid user (re-use existing test - can be parameterized or the test case can include the user details)
• Navigate to product page (re-use existing parameterized test)
• Select quantity x of product y (re-use existing parameterized test)
• Begin checkout process (re-use existing test)
• Validate cart amounts (re-use existing parameterized test)
• Enter billing/delivery addresses (re-use existing parameterized test, may be more than one test depending on the structure of the site)
• Enter valid payment information (re-use existing parameterized test)
• Validate purchase completion (re-use existing parameterized test)

As you might guess, I'm very fond of data driving my tests to within an inch of their lives. Usually I have to extend base functionality of test tools because they assume that data driving is going to be a matter of looping through a single flat structure where I tend to work with a relational structure that often ends up mirroring the database structure of the application I'm working with.

My approach is more complex to follow and takes longer to set up - but once it is set up, new end to end scenarios can be tested by plugging in different data chunks for each step.