DEV Community


To test or not to test - that's not a question

Senik Hakobyan
Software Engineer
・2 min read

Hello community.

I just read one post about test automation and decided to share my opinion about that.

Should you write tests? - Yes, if you are skillful enough to write valuable tests.

Manual vs Automation

You anyway have to hire someone to test things manually, to write test cases etc. And that person must test things periodically, repeatable, before and after deployment.

Test cases are necessary for both manual and automation tests. E.g. Gherkin. This means that your manual tester is already doing the ~half of the automation work.

Why you must write tests

IMHO the purpose of tests is to avoid bug leakage as much as possible. Test automation is for both developers and QA engineers. For example, pre-commit or pre-push git hook can run and pass or fail tests and help to avoid bug leakage by preventing a buggy code to be pushed and deployed.

No apologies

If your customer will leave you a feedback that your software has tone of bugs and is totally unusable, you obviously not going to share details about your company size or number of customers to "prove" him/her that you don't need a better quality because you're not large enough.

Probably "Yes"

My point is that as far as test automation helps to avoid bugs by preventing them, then the real answer to the question about the need of unit, integration and e2e tests, is probably yes.


Another question is the refactoring.

Why do you think there are projects still running on 10 years old frameworks? Because nobody wants to upgrade a large and legacy system that doesn't have test coverage. 10 years ago those projects were "small startups, that don't need test automation yet".

The Test Coverage

I said that automated tests are to prevent bug leakage. Not only...

Test automation also helps you to read a code. The test describes the usage of specific library/class/function.

If my colleague will deliver me a new component to work with, that has a test coverage, I'll simply look at unit/integration tests and won't disturb him anymore. Otherwise he'll need to spend a lot of time explaining me what the hell did he implement. And maybe not only to me, and not only once. Would be better if he spend that time to write a clear tests for everyone.

So... another purpose of test automation is to save our time!


I understand that in reality you have to do a lot of analysis about priorities, about the budget, about staff etc. But anyways, I think that test coverage must be a top priority of the QA team/department, even if QA team/department includes just 1 person.

The lack of test coverage will not make your product better.

Discussion (0)