HACKER Q&A
📣 danwee

Should QA engineers write unit/integration tests?


The current status of doing QA at my company is: QA engineers use either curl or something like Postman to perform "black box" high-level testing mainly on APIs. So, sometimes they have to test that one endpoint alone handles the happy path and many other secondary paths (e.g., "it throws a 400 when we pass the endpoint an invalid payload"). Sometimes they need to test a combination of endpoints in which many endpoints have to be executed one after another (e.g., "we first call endpoint A, and then endpoint B, and then when calling endpoint C the result should be X"). All these tests scenarios are not commited to any repo, so the current status of QA is a bit ad-hoc.

Now, my company is trying to adopt a new approach: they want QA engineers to write unit/integration tests for whatever API service they want to test (these tests would be commited as usual in the corresponding service repo). So far only the backend engineers are the ones writing unit/integration tests.

I can only see disadvantages with this new approach:

- QA engineers would need to learn about the domain (not just at a high-level), the language and the testing framework associated to the services they want to test. We currently use PHP, NodeJS and Go. So, that's a lot of learning if you ask me for a QA engineer

- Writing unit/integration tests is too low level. IMHO, I think QA engineers should focus on the big picture, they should be able to see the system as black box and test it accordingly. As part of my job as a backend engineer I have written thousands of unit/integration tests: you need to know the "high-level" details of the service you are testing in order to write good tests. I don't mean you need to know the implementation of functions/modules/classes; I mean you need to know that module X has interface Y with N functions with a given signature (this, if you are lucky and working with a statically typed language... good luck QA engineer figuring out what a paramter called "order" actually means). That's too much "low level" for a QA engineer if you ask me

- Writing unit/integration tests for a myriad of test scenarios is slow, both in terms of writing the tests themselves (create file + setup mocks + beforeAll + afterAll + write the code for actual N scenarios) and in terms of execution speed (e.g., jest in the Node world is slow when running integration tests)

IMHO, engineers should write good enough unit/integration tests (so that they can sleep good at night knowing their code is not totally garbage) and QA engineers should make use of tools like curl/Postman/Insomnia to actually run multiple high-level test scenarios fast. The only thing my company needs, I think, it's a bit more of organization when it comes to work on or share those curl/Postman/Insomnia scripts.

What do you think?

  👤 pledess Accepted Answer ✓
It depends on whether your company provides an efficient way to submit information about payloads and outcomes. For example, if you can submit in a simple, high-level structure that's independent of the language used by the test engine, e.g.,

Payload: EICAR Anti-Virus Test File

Endpoint: POST /new-customer

Outcome: server file \Quarantine\customer.db exists and \Data\customer.db does not exist

Expected: server file \Data\customer.db exists and \Quarantine\customer.db does not exist

then it's probably worth the effort of a QA engineer to submit that. However, if you spend only 10% of your time on a project where integration tests must be written in JavaScript and committed to a repo, and there's no way to commit until the new piece of integration test code fully complies with the Airbnb JavaScript Style Guide, then it's probably not worth the effort of a QA engineer. The tests should be committed by someone who works with the nuances of the testing framework every day.