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

  • Do you have to write detailed test cases? Commented Jun 5, 2013 at 0:05
  • Are your Test Cases automated scripts? Or are they written documents? If the latter, are they all executed by the same person, or are they distributed to multiple testers? Commented Jun 5, 2013 at 12:03

3 Answers 3


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.

  • thx- that's what I was leaning on - but needed some validation. This Q was born of a discussion I had with a SIT SME who is of the opinion that test cases typically need to reflect end to end functionality and should be detailed and intuitive enough for any other tester to pick it up and test. I am coming in from a Agile(..ish) mindset OR cost cutting / trimming mindset if you will and was thinking where I could cut down on manual labor. Deep modular decoupled cases and separate thin slice full E2E happy path cases seemed like a good compromise
    – ved
    Commented Jun 4, 2013 at 23:06
  • I was taught many years ago to write a test case so that someone coming in from another department could sit down and execute it. So I've kind of stuck with that all this time, but I'm not blind to it's redundancy either. Commented Jun 5, 2013 at 15:19
  • @LauraHensley - SIT SME's opinion is aligned to what youve suggested - I am trying to question the said redundancy and attempting to make it lean - yes it will have the caveat that I will NOT over design it for what ifs.
    – ved
    Commented Jun 5, 2013 at 17:29

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.


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.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.