4

I am a backend developer and always create tests for my applications. Recently I study and apply the interface tests (using selenium), but I doubted whether I who should create these tests, developer or QA?

How can we decide if automated interface testing should be QA responsibility, or Developer responsibility, or both?

And if both, is there a risk of creating duplicate tests?

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
ridermansb
  • 225
  • 2
  • 9
  • Very roughly, developers write unit tests, QA writes integration tests. So both write tests, just different types of tests – Panagiotis Kanavos Oct 20 '14 at 12:00
  • edited question appears to be having a thorough answer in prior one: [What is the best use case for selenium?](http://programmers.stackexchange.com/a/251076/31260) - does it cover what you're asking about? – gnat Oct 20 '14 at 12:05
  • 3
    Developers write integration tests too... at least, they do if they want to know that the code they write isn't a buggy chunk that will crash the server at the first opportunity. – philosodad Oct 20 '14 at 14:34
  • 4
    I smell a good question behind a bad wording. This depends of course on the specific organization and maybe somewhat opinionated, but there are indeed some criteria for deciding about the "best" distribution of responsibilities. Thus voting for reopening. – Doc Brown Oct 20 '14 at 16:40
  • @DocBrown regarding the part about "risk of creating duplicate tests", wasn't it covered in prior question: [Functional testing and Acceptance testing leading to redundant code](http://programmers.stackexchange.com/q/187799/31260)? – gnat Oct 20 '14 at 16:51
  • @gnat: if we are going to close every question which overlaps partly with some other, previously posted question, approximately 95% of all new questions would have to be closed. But I think this one will not be reopened either since others probably think it is too opionated, so better lets focus on other posts. – Doc Brown Oct 20 '14 at 19:55
  • @DocBrown I merely wanted to check if you believe such a partial overlap is okay or not in this particular case before casting reopen vote (just did that) – gnat Oct 20 '14 at 20:16

2 Answers2

2

This is fully up to the company or organization you are working in, so ask the persons who are responsible for defining the organizational structures. However, there are some rules of thumb which distribution of tasks will work better.

For example, if your QA department consists of people with no programming knowledge, it won't make sense to give them the task to write automated tests. If the "interface tests" you have in mind are not fully "black box" tests and need some knowledge about the internal workings of your program, it won't make much sense either.

If, however, your interface tests are black box tests, and your QA department has some programming knowledge, and they identify tedious, recurrent testing tasks, why shouldn't them automate these tasks by writing automated tests?

In some organizations the QA department focus specificially on hard-to-automate tests and don't need any programming knowledge. In such an organization, the automation of recurrent tests may be delegated back from the QA people to the devs.

Concerning the risk of creating duplicate tests: talking to each other will help! Clarify the responsibilities from time to time. And if a small amount of tests is done twice, that is much less of a problem as if necessary tests are not applied because each group thinks those tests are the responsibility of the other group.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 1
    `if your QA department consists of people with no programming knowledge, it won't make sense to give them the task to write automated tests` So if your QA department is composed of people who have no right to consider themselves a true QA department? How could you claim to do QA and not do automated testing? – maple_shaft Oct 20 '14 at 14:02
  • 1
    @maple_shaft: that's just your opinion of what a "true QA" department should be. Others may think that it is more important that the QA people creates *the right* tests and checklists, not that they can automate all of those tests by themselves. As I wrote, this is up to specific organization. – Doc Brown Oct 20 '14 at 16:18
  • @maple_shaft: ... and in some organizations, the QA department's responsibility is specificially for the tests which are not easy to automate. – Doc Brown Oct 20 '14 at 16:26
  • 2
    @maple_shaft it happens (infrequently in my experience) that manual testing is much more efficient than automated. Once upon a time I was in such a manual QA team and I saw how it reliably outperformed more effort consuming attempts at automation – gnat Oct 21 '14 at 13:34
2

Acceptance tests should be written first, before the code is written. When they pass, you know the feature is complete and does what it is supposed to do. However, most of these tests only follow the happy path. Let's consider two scenarios:

  1. Your QA department is able to handle writing their own automated tests.

In this case, you've saved them the trouble of writing happy path tests, so they can concentrate on edge cases, mutation testing, stress testing, exploratory testing, and regression testing. Also, they can remove your tests from their own test runs if they prefer to have their own acceptance testing. You've produced code that is less likely to be buggy, saved them time, and allowed them to focus on what they're good at... QA isn't about making sure the software does what it should do--you shouldn't ship code to them if there is any question of that--it's about making sure that the software doesn't do what it isn't supposed to do.

  1. Your QA department is not able to handle writing their own automated tests.

In this case, you've written automated tests which they can't write, which is helpful. Perhaps they'll learn to read the automated tests and understand what you are testing, which will help them develop a test plan. You've also shipped software that you know works on the happy path, which means that the QA department has more time to focus on exploratory, regression, etc. Their job is to break your software, not verify that you're minimally competent.

In either case, following a behavior driven development plan saves time and money and produces more robust software.

philosodad
  • 1,775
  • 10
  • 14