Balance Test Automation Development

Testim

Case Study:

I’m curious - for those that are not automation specialists, how do your teams balance automation? Is it fully QA’s responsibility, partial responsibility of QA and dev, or all dev’s responsibility?

I have been the main one at my organization really pushing hard to get to automation ASAP. I was told last week that the goal from management is for QA to actually own our automation suite, and really invest in it. We’re scrappy, but I’m determined to make this successful! I’m only keeping my composure about it because we use Testim.

I can totally relate, my past project there were senior developers recommending 6-8 week code freezes as well. I could barely keep a straight face when they recommended that, I kept imagining the responses we’d get from our client about paying for that type of delay in work.

Insights:

At my previous job, it was up to the dev to create the smoke tests for the features they develop and the QA would fill it out with more edge cases. My current job has no QA, so it is all up to the developers or the product owners. Most of the tests I create right now are simple functionality tests and trying to fill in the backlog of automation.

-- Kevin Devine

Insights:

Neither my current or prior company had automation specialists or dedicated QAAt my prior company there was a web-core team that was responsible for tooling. Each team/individual contributor was responsible for testing (unit + functional) their own code.

-- Sean

Insights:

I've seen a mixed bag. Some places have had dedicated software developers in Test (SDET) who work with QA (leads usually) to identify and organize the manual test cases as automation candidates. Then the SDET wires up the automation framework (selenium or appium, for example)...and continues to work with QA to deliver the automation. I've seen a small QA team try to establish automation in the beginnings of a start up , some fail and some succeed. It seems to all depend on the determination of the QA person to get automation implemented and practiced, maintained and cared about.

Let's face it, the business side doesn't really care about how much you may struggle to learn how to automate. At the end of the day, they care if it was worth their time/money. Some places I've worked for realize they were better off executing their tests manually because no one could spare the time to teach themselves or anyone else how to use the automation tools.

-- Erin Hess

Insights:

In our case, SDET has been allotted to an Agile Team and he needs to take care of End to End Testing Beginning from Gathering Requirements, Writing Test Cases, Then Finding out Manual Test Cases which can be Automated and then automating them. Executing them on Software Builds. Like this a QA Work. and that is too much responsibility for giving bug-free release on his/her head.

-- Ajay Lunia

Insights:

We really started automated testing a lot when regressions started showing up a lot and the response from development was to code freeze EIGHT weeks before deployment on each version for regression testing. That was the straw that broke and they started a two year program to get automation testing. They brought in the best testing consultants and Ruby/Watr/Selenium/PageObjects was put into place. At the startup I am working at now, we are starting to see a lot of regressions creeping in because of the rush of new features and configuration switches so we put automated testing to a higher priority. It is useful to the business because we have less support tickets and downtime due to regressions.

-- Kevin Devine

Insights:

I haven't experienced a code freeze where I am currently, for regression testing. Or anything else really. We have been spinning up new environments for the last couple of weeks. Now we have UAT and Production. We currently run automation in our Staging environment. I'm pretty sure our Head of QA has been expecting the other environments and has hashed out pieces of new automation to run on the new environments already. We're kind of expected to know when things are coming and to be prepared and allot our time accordingly. The head of QA is incredible and I really don't know when she sleeps or gets anything else done...but she's a rockstar. She introduced me to Testim, and I fell in love immediately. From the approachable interface to the user-friendly way to create test scripts.

-- Erin Hess