Often, I hear people say how they don't need testers. Thay aren't at the stage where they need to consider QA. They want to get a minimum viable product launched, and they just want something done as quickly as possible.
Sure, you may not be able to afford a dedicated QA engineer in your team: that money sometimes isbetter spent on development talent instead. But, my belief is, you can't not have some kind of QA process in your team.
First, a quick definition of 'QA' and 'Testing', so that we're both on the same page:
- QA — The practices of ensuring that the product is the best it can be. No one person is responsible for QA. It casts a wide net and includes (but is not limited to) standards compliance, accesibility, user testing and feedback, knowledge of systems, website copy, speed of application, security, and quality of code.
- Testing — The process of checking an application: this can be both automated or manually performed, usually by a Test Engineer. It's a small part in the overall QA process.
The importance of QA
Let's say, I've got myself a brand new toaster. I'm proud of this toaster. It looks awesome, it came in a really nice box, and it can toast four slices of bread at the same time.
I proudly unbox my toaster and plug it in, ready for the next morning's breakfast.
Fast forward to the next morning, I excitedly get some bread out and put it into my fancy new toaster. The bread doesn't quite fit, because the slices are pretty thick. Nevermind, with some effort I can get them in.
The dial is a bit fiddly... it's towards the bottom so I have to lift up the toaster to move it to the setting I want. But that's ok, I only need to set it once.
But it isn't ok. It's the small things, like how little effort it takes to put bread into a toaster, which make a product great. It's what makes people enjoy making their morning breakfast.
QA is the process in making sure everything is as good as possible, given constraints. That toast which was slightly too thick? QA is all about asking "But how thick is sliced bread?"
It's the same in software. You want people to enjoy using your product. Afterall, wouldn't they just go somewhere else if they didn't?
It's not like a toaster where nobody is likely to return it if it's not quite right. If I don't quite like Firefox, then I'll just dowmload and start using Chrome. If I didn't quite like Twitter, I would no longer use the service.
The importance of testing
I'm not saying that you need to carefully consider everything about your product, and to never release anything until it's perfect. It's not possible to do that. But I am saying, you need to make sure that everything works.
Don't just write code, save it, perhaps quickly check it and then deply your changes. You need to check to make sure nothing is broken. Developers are humans and very often make mistakes.
You need to test it.
Automation is no replacement for a real test engineer, but it's a pretty close second. A developer can relatively quickly write automated tests, which can (and should) be ran often. That way, if anything goes wrong, the developer will quickly find out if anything doesn't work as expected.
Automation can even have its advantages: automated tests don't get tired, hungry, grumpy, or bored.
Takeaway (aka. tl;dr)
Yes, QA can be a rabbit hole you can easily fall into if you want to. But testing is important. Crossing your fingers and hoping for the best isn't the best strategy: when you make changes, you need to make sure everything is still working as you expect.
The more consistant, and cheaper, way to do this is through automated testing.