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?
7
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.
4
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:
- 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.
- 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.