Quality is too important to be left to QA engineers

Originally posted on my personal blog.

TL;DR — Upgrade the careers of your QA engineers to Test Automation engineers (or better yet, become one). Happiness, Velocity and Quality will head your way.

Two years ago, I fired all my QA engineers and re-hired them on the spot to be Test Automation engineers. This was an amazing change for them, being hired for a much more interesting and important position. Also, this set their career path for success.

Their careers were upgraded, but that wasn’t the reason we decided to go for it. I never liked the R&D <–> QA workflow at any company I worked with. Here’s how a typical flow would go:

[START] [ — -R&D — -][ — -QA — -][–R&D–][–QA–][-R&D-][-QA-] [FINISH]

The developers would write the entire code, almost without testing itself and “throwing it over” to the QA for testing. The Q&A would be blocked on a small bug and couldn’t really test the feature, so it went back to R&D. Rinse and repeat.

WHY I DON’T LIKE THIS PROCESS?

1. No ownership. Developers without QA write better code. Why? Because there’s no one to blame for their mistakes. This is the thing I was most passionate about.
2. There are still bugs. Manual testing never finds all the bugs. There might be less, but then we’re limited by the talent of the human testing our product.
3. Ping Pong process. Instead of finishing a feature and shipping it, you have to keep working on it long after you’ve finished. You might already be working on the next feature when the previous feature keeps coming back.
4. Unhappiness. Hate between R&D and QA teams is a regular thing. I know everyone says it’s not, but it is. I always wanted to create harmony while creating our product.
5. Repeating the same work. Every single change you make in a codebase, requires the QA team to manually re-test EVERYTHING in the product. Because software…
6. One time value. When you test something today, tomorrow that test is worthless. This process doesn’t add value to the company over time.
7. Second class employees. Nobody listens to the QA engineers and it is usually a position you transition from very fast. I want all my employees to be amazing, respected and valuable to their team mates.
8. Human errors. People make mistakes. They miss things, they have mood changes that affects their testing quality.
9. Life wasting. I really feel manual QA engineers are wasting their lives clicking buttons. Let’s change that. They’ll still be clicking keyboard buttons, but creating long lasting value with every click.

AUTOMATIC (QA) FOR THE PEOPLE

What is the answer then? That’s a good question. We’ve moved to automatic testing which consists of the following:

• Unit testing — Test that your code does what you think it does.
  Example: expect(add(2, 2)).toEqual(4)
• API Testing — Fire API calls to your endpoint, make sure they respond well.
  Example: expect(get(’/item/5’)).toEqual({item: ‘fork’})
• UI Testing — Act as a user who opens a browser/app and starts clicking away.
  Example: open(’google.com’).search(’google’).expect(’not to break internet’)

Each one of this is a world of its own. Unit testing is great for everyone writing code. Some people never run the code they write, a unit test will at least let you do it easily. The assertions are a bonus. If something breaks here, you know exactly what’s not working.

API testing is pretty simple, but you have to setup and teardown tests to bring them back to their initial state. Still, it’s inputs vs outputs which is easy to test. If something breaks here, you know where to look for it in the code.

UI Testing is the hardest. You are dependent that all systems are working during your tests. If something breaks here, you have NO idea where the problem is in your complex system.

DEVELOPING UI TESTS IS A CHALLENGE

As I found out, writing UI Tests is not an easy job. Most of the QA engineers I’ve met could write them, but they were flaky and un-maintainable.

Our developers wrote the next generation of our UI tests and it was a world of difference. We wanted to use JS for writing the tests, because that’s how the browser works. Using Java just seemed wrong. We used nightwatchjs for that and it worked magically.

Tests are written with best practices, go through code reviews and are running after each commit. If you break something, you get an email. That’s like having the best manual QA working 24/7 in best mood emailing you and protecting you.

As a developer, quality is too important for me and I am not going to “outsource” it to anyone else.

What do you think? Drop me a line on Twitter: @ketacode