The question: Is it the developer's responsibility to design test cases, or the QA tester's? Or is it someone else's?

I am a software engineer at a small company in the United States. We have an offshore QA team. In our organization, we have a non-comprehensive suite of automated tests, which are owned by development. We try to follow an agile methodology and have recently transitioned to kanban from scrum.

When I pick up a story from 'ready to work', it must have certain data on it, including acceptance criteria. It must list out exactly how it works, who it affects, and so forth. As part of my work, I write unit tests to cover the code, integration tests to verify service-level interactions, and behavioral automated tests using cucumber/gherkin. I make sure the functionality gets deployed to a development VM and run through my automated tests plus some basic end-to-end sanity checks. Then, once I'm satisfied that the story works as it should, and it successfully passes code review, it gets passed to QA.

And the first thing QA does is kick it back and say "please provide test inputs."

Our QA team has access to everything I do. All the same supporting documentation -- the design documents, architectural documents, all of my code, the development VMs, even my gherkin features. If I were to design a test case, I would be working from the exact same pieces of data that they would be.

Are they right? Should I be writing them test cases that they are expected to repeat as rote? Is it their responsibility, mine, or someone else's? Or is this something which varies by organization?

  • 2
    Save yourself, your team, your qa guys, and your company a whole lot of stress and technical debt. Do test driven development if you are in an agile shop.
    – DevOpsEng
    Commented Jan 12, 2018 at 5:29
  • 1
    Thanks but this doesn't answer my question, and I certainly don't have the authority to enforce a paradigm shift in programming methodologies.
    – Roddy
    Commented Jan 12, 2018 at 8:08
  • It is the responsibility of the test case designer. And by that answer I mean, if you do not have that role, someone needs to take it, and that can be anyone that has the knowledge/resources to do so. I could be the CEO for all we know. Most common would be I guess, QA and/or Developer and/or Product owner Commented Jan 12, 2018 at 15:02
  • 1
    Not so much of an answer, but a piece of advice: I've been in the same situation where an offshore QA team required a lot of hand-holding (but then still didn't get any productive work done). If they aren't adding value but are requiring a lot more work from developers, track your time spent on doing things your internal QA team used to do, and time spent on communication overhead. Having this data can help show management that offshoring may very well have been a false cost savings, since that's usually the primary reason for offshoring.
    – c32hedge
    Commented Jan 12, 2018 at 19:30
  • 1
    If you are covering from unit tests, integration tests & even BDD based acceptance tests, then what is left for QA? Commented Jan 14, 2018 at 20:05

6 Answers 6


In my experience, it's down to the tester(s) for the same reason that developers can't test their own work. You can't find your own faults. That said, I don't think it'd hurt for you to test as well... but you need to draw the line somewhere.

QA are independent and, whilst you're working towards the same goal, should have a different approach. ie, you do Unit and Unit Integration testing, they can do System and System Integration testing - but also use the application like the end user, try and break the system, think of tests you wouldn't have considered, etc.

I might be able to expand on this at a later date but, personally, it sounds like you're doing too much of their job.

Edit: This post makes a good point. If you're working in a TDD environment, then you are responsible as the developer.


In our company we believe in "checks and balances", so whole process is a balancing act between following major forces:

  • business management, who requires major features and sets priorities
  • business analyst, who understands the customer needs and mental models, writes story requirements
  • developer, who understands the code, and also writes tests (unit, e2e etc)
  • DBAs and sysadmins
  • manual QA, who makes sure all parts work together and follow the process (and continuously strive to improve the process)
  • automated regression testers (also writes e2e tests)

We (QA) stress that all (even minor) changes were reviewed by at least two participants from different areas.

So, in OP's situation, developer should NOT write test cases, because it would be unchecked power. If developer misunderstood requirements, then wrote code and test according to this misunderstanding, how it would be detected?

For 90% of bugs/features/changes, business analyst creates test cases. Often they are not specific enough for actual testing, and QA works with BA to make test cases specific enough, often asking devs to provide some specific data ids for which specific functionality can be observed (users with functionality under test enabled, etc). In many cases, even if test cases are not 100% detailed, QA can fill the gaps from experience gained in previous testing, and will just confirm the specifics with BA (to make sure what QA did not introduced misunderstanding).

Of course 10% of changes are quirky enough that have to be worked differently:

  • too trivial (i.e. fixing a typo in spelling, external linked page changed URL)
  • DBA/syadmin specific (no BA involved)
  • dev-specific (i.e. library upgrade, no BA involved)

But for majority of changes, BA makes the call: decides requirements, and how feature will be tested. Sometimes, after developer implemented draft proposal, BA realizes that his understanding was not complete and changes requirements, or decides to release product which implements only part of requirements (postponing rest for phase 2). This is normal.

Quality is responsibility of the whole team (not just QA), and all participants are learning and improving to work with all others to provide best quality.

So your external QA needs to "grow up" and start accumulating knowledge about how to test, and how to find the info they need to test. Is OK to ask once, but second time they should have learned it, and should ask for confirmation if they understand it correctly.

They also need to learn methods how to get the input info, exactly like you are able to find it: talk to BA, query database, etc.


No random person on the Internet can tell you what makes sense for your circumstances at your organization.

Here is a way for you to figure out what makes sense for your circumstances:

  1. Decide on how you measure success.
  2. Choose a policy (dev writes test cases, or QA writes testcases, both write test cases, etc.)
  3. Measure how well your policy works.
  4. Decide whether your policy is successful enough.
  5. If your policy is not successful enough, change it and go back to step 3.

Who owns the knowledge?

Rather than focusing on who's responsible for doing a certain piece of work. A more important question is - who should retain the knowledge about it. This isn't a question that can be answered for you, but some considerations may be:

Are requirements set by an external source, such as financial regulators? If so, perhaps you don't want developers to be the ones maintaining the knowledge - you want your test team to keep updated on the latest regulations and apply that knowledge to test creation.

Are you testing that your didn't break some functionality? If so, it could be the development team that maintains knowledge on how that internal function is meant to be run, what context it is used in etc. It would make most sense for the developer themselves to write tests - they can check it still works within the expected bounds they created it for.

Do you create a large number of similar products? In this case, each developer is likely to know only what they need for their current project - while the test team will be exposed to a huge number of similar problems. It would make sense that the test team maintains knowledge on what bugs to expect, and prepare test cases to check for them.

In most cases, I'd suggest you'll find there is not a single answer for all products and testing in your organisation. But figuring out who is best placed to maintain the knowledge of how to test each system will also answer who is best placed to write the tests using that knowledge.


From my perspective you are already doing a lot of things to check if what you created works as you think it should work. A lot of developers don't do that much...

I expect from a QA team (although I am not a favor of this remote and divided setup, to be honest) to investigate themselves if what you did is sensible and OK. And that they add tests for whatever they think is missing or doesn't fulfill the actual need of what you have build. That means they need to understand what the intent is of what has been delivered.

So to me it feels that your offside QA team wants all the details so they can replay what you did. And I have been in that place too. That adds no real value in my book.

To your question: in my view they are wrong, but - I make some personal assumptions here - that is probably how they are used to work. They check to the letter what you have done. Nothing more.

  • Honestly we (the developers) used to only do unit testing. But our ongoing difficulties with our QA group have caused us to take on a lot more work, including the taking over of the automated testing, which used to be QA's purview. I appreciate your point that this is how they are used to working and will raise this with my manager.
    – Roddy
    Commented Jan 12, 2018 at 14:55
  • 1
    As I said: I have been in that place before (working for a large bank with offshore QA). My experience is that it is a waste of time and money. I think your local team is going in the "right" (my opinion) direction to get it all done in house. Which likely means adding some testers to the mix. So you become a true agile team. We made that move ;-)
    – Ray Oei
    Commented Jan 12, 2018 at 15:02
  • Funnily enough, we used to do in-house QA. We moved to an offshore team about three or four years ago.
    – Roddy
    Commented Jan 12, 2018 at 15:04
  • And to add: as you are apparently moving a lot of work in house because of issues you have with the off-shoring: it is reasonable that your management also looks critically if it delivers them what they want.
    – Ray Oei
    Commented Jan 12, 2018 at 15:04
  • Off-shoring has been a big hype... but if I look at what is happening in my country: a lot of big companies are either 'near' shoring or getting it back in house. Also because of creating real (e.g.: sitting together in the same room) agile teams.
    – Ray Oei
    Commented Jan 12, 2018 at 15:06

Generally ,business facing Tests should be designed by the tester, and technology facing tests should be designed by the developer ,assuming testers are only involved in black box functional testing which may vary team to team.

If you are following agile, every user story should have well-defined acceptance criteria which should be enough basis to derive business facing tests.

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.