Whose responsibility is it to design test cases?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.