---
title: "If you're looking for a QA to automate your tests, you've started to fail"
url: "https://www.5whys.com/articles/if-youre-looking-for-a-qa-to-automate-your-tests-youve-start.md"
canonical: "https://www.5whys.com/articles/if-youre-looking-for-a-qa-to-automate-your-tests-youve-start.html"
published: "2012-05-06T10:44:20+00:00"
updated: "2012-05-06T10:53:36.743000+00:00"
tags: ["Learning Phase"]
author: "Roy Osherove"
description: "Why hiring a QA person to automate tests keeps a system failing, and steps to grow developers in test automation while the team is in the learning phase."
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# If you're looking for a QA to automate your tests, you've started to fail

If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your \*developers\* should be proficient (or start learning how to) in automating the tests, creating automated tests, and overall  be able to automate the hell out of everything.

Having a separate QA department is a fail in that, there is an explicitly delegation of all those "things QA folks do" to that other department, so that devs can focus on the other things.

at the very least start with each team having a QA in the team, that is part of the team. then spread the knowledge of the QA dude to the rest of the team. 

By looking for someone to do all that "other work" is keeping the system in fail state. instead of starting to grow your devs to be able to become better, and do that work so it's part of their work. \*it is\*.

Steps I'd take(assuming the team is in the [learning phase](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)):

1. Start getting each dev/team into automation thinking mode
2. Having small goals to automate more and more things, as we write them
3. doing code reviews with an "automation" theme
4. Having "automation week" a the team level

## Read next

- [What should a good code review look and feel like?](https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.html): How a good code review should feel: short, in person, side by side, done by everyone on the team, and aimed at learning rather than tool comments.
- [Burst your team's bubble - stop protecting them from the surrounding organization](https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.html): Why, in learning mode, a team leader should stop shielding the team from the organization and let sales, marketing and support push their growth.
- [4 ways to discover a stuck team member, and what you can do about it](https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.html): Roy Osherove recalls being fired as a stuck developer and shows how standups, code reviews, test reviews and pairing help a lead spot and unblock people.


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
