Who does your Automated Testing? QA or Development?

Monkeys and Robots usually. Sometimes we just think of something that needs to be automated and a script appears. Sometimes a more advanced civilization from the stars will visit us and automate our processes.

Seriously though QA does this at my current and former places of employment.

At former job my wife was involved with generating scripts, and still is. (she has no programming experience)

I created the framework there that she uses it to this day.

My current job I wrote the initial framework and other QA assist with updating it as needed (all QA here have OOP experience).

Primarily they are focused on created scripts.

Much like all projects it's important to recognize the individual strengths of your team members if you want to succeed.

I say this because many times it is overlooked.

For example:

I enjoy designing the framework, writing code, and maintaining that code.

I do not enjoy writing excel spreadsheets, populating data, etc..

My wife enjoys writing excel spreadsheets, populating data, etc..

My wife hates writing code, learning code, and designing processes or framework.

We could fight all day long every day about who should be involved in what, but instead it has worked very well to simply allow people to do what they are good at, and what they are interested in.

In my current position I have been working to engage developers in our automated QA, but I also recognize that it is not something they are overly interested in. And that's OK for me. I simply need them to have realistic expectations and ideas about what can and cannot be automated; For them to be available when a solution is required at the application level and not within Test Complete.

All testing procedures (except unit tests) should be a responsibility of QA 

There's a lot of variability in the market out there.  A lot of it depends, somewhat, on your strategy for automated testing.

If you're doing primarily a record/playback structure with each test case being constructed as either a keyword test or a script test, then most likely you'll find your testers doing most of the automation work.  You might find a tester or two who can write some code who can modularize some of the common code into functions/tests that can be called repeatedly.

If, however, you're going with a more advanced framework structure with tests being driven by data content and test cases not being individual keyword tests or script functions but more dynamically constructed at runtime based upon the data, then I think you'll find that there is a developer skill needed.  

I would say that, usually, the developer developing the test framework is not a developer who is developing the AUT.  That actually would be a bad idea to have the application developer developing the framework... it's for the same reason as you don't let developers test their own code... too close to the product.  

What I've implemented and seen implemented in several companies is that the work is divided.  Developing the framework and maintaining the code is relegated to one particular group of folks who have skills in both development and in automated testing.  Building the test cases within that framework then goes to actual testers and QA staff.

Now, if you're generally calling things from a "top level" structure... automated regression and functional tests is QA... automated unit testing is Development.

In my company: Developers do the unit test and QA do the automated functional regression tests in TestComplete. (And developers are responsible for the manual  functional non-regression tests together with code-review).

You need some development knowledge to do the functional tests (I am far from a developer per se), but I also think you need to have some specific skills for this specific task, which developers will spend as much time to acquire as I have spent. In my company, I do not see that task can be split into a 'coding' part and a 'non-coding' part, where the 'non-coder' defines tests (e.g. in Excel) and the 'coder' writes the basic building blocks of these tests: it will just be running the same tests again and again, but with slightly different values. So based on my experience: have a dedicated person who is has at least basic coding capabilities, but is a QA more than a developer.

I think automated testing needs to fall under the QA area of responsibility but you need to have somebody with coding skills on the team.

I think both nowadays. It may vary per contract. Let me explain...

Testing is primarily the task of QAs or Software Testers. The acceptance criteria for QAs before they should start the actual testing is that it already passed through Unit Tests...although I've also encountered some devs who just hand the codes over without unit tests at all. 

The past 3 technologies I've handled (iOS, Android and API), I've encountered some unit tests that seems to be "automated" as well. For iOS, I've encountered some unit tests in Xcode that seem to be automated (according to the dev these are unit tests that are written in Objective-C and some were in Swift) which they also asked us to run due to time constraints. For the API, I've seen some tests written in a language similar to Gherkin (BDD) which they call Spock tests being ran by dev. Any devs our there to confirm? :smileywink:

While both QA and Devs may create tests that appear to be using Automation technology, as I mentioned earlier, the official standard is that QAs have their own set of Automation tests (if applicable, since some project parts may not be worth automating). It should be different from developer's tests. This way, we will be able to filter issues that might have escaped dev's eyes. At the end of the day, it's not really dev vs. QA but what matters is that we deliver software with the least number of bugs that can be seen by the end user. I used to have a manager who said, "There's no such thing as a 100% bug free software".

I agree with some of the replies to your question. Automation testers are in the middle of a dev and manual testers. While we are not really developers, we need to have some coding skills to make the tests and an end user's mentality in mind (for UATs). I'd say, the best of both worlds :smileyhappy:

Great discussion! I'm in my first QA job, coming from my first development job. Here, we have dedicated QAs doing (almost) all of our test automation, but that is probably first and foremost due to time constraints. We have an automation backlog already, and we also have very optimistic goals for our developers. I do think someone doing test automation benefits immensely from development/scripting experience, but shouldn't be a normal feature developer, as the different perspective is important.