1

I work with a team of QA Engineers who do manual testing and automated testing in the form of Selenium and Postman.

We're pretty good with our manual tests, attempting to automate said tests are challenging. There are times in which our testing responsibilities are low, and we have lots of time to create and maintain our tests. Other times, we are swamped with testing which kills any progress we have made.

One solution might be to hire more QA, but I fear they would get dragged into doing more manual testing.

My ultimate goal is to have Selenium smoke tests run when developers open a new PR and nightly regression tests that have most of the tests that we are executing manually

Another solution might be for developers to write their own end-to-end test in addition to their unit tests. Any thoughts on that?

Most online sources suggest hiring dedicated test automation engineers and have manual testers write and conduct test manually and have test automation engineers automated written tests. One online source suggested the opposite that separate teams don't work

Can anyone working on at companies with separate teams chime in with advice over what direction to go and any pitfalls to avoid?

2
  • I'm confused, is there anything that says when you get hired on to a team that you have to do all the responsibilities of anything of someone on that team? Is there a reason why you couldn't hire two people to write and maintain automated tests while keeping them on the same team?
    – corsiKa
    Jan 6, 2019 at 6:03
  • There isn't, we currently have some degree of separation within various automation projects, but everyone still does manual testing. The team initially was only doing manual testing, we've started to automate repetitive tests and would like to spend more time doing so. However, we have a very large number of tests that need to be executed before deploys which means that focus on manual testing as the feature needs to be tested now.
    – atg
    Jan 6, 2019 at 6:45

1 Answer 1

1

Where I work there is an Automation team that is independent from QA & Code teams on the various projects. They work on the same iteration / sprint cycle all the other teams do. Each sprint they evaluate requests they get from various teams & prioritize what gets done. Those of us on the specific projects work with them on what the test(s) will be and they train us on how to audit the nightly results, do some basic trouble shooting, do a one-off run if needed, and how to log a request to them for updates/ corrections/changes.

The pros of that.... The Automation team is primarily coders so they are much better at efficiently & quickly writing code. I could muddle through, but what takes them a few hours/days would take me weeks.
The automation team can re-use, share and maximize effort across similar projects, where I may not even realize another team is doing something similar. We have one repository & location for all the automation & tests.

The cons.... If we are not the #1 priority our automation may not be done as quickly as we want. Similar, if we have issues, there isn't always someone immediately available for assistance.

In general I think it works well for our situation at a large company with numerous projects running at the same time. If you are a smaller shop it may not be as good a fit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.