In this article, I want to talk about the difference between tester and QA and why nomenclature is so important. In our industry, people usually use QA and tester interchangeably. This situation should be undesirable for either side. For the employer/recruitment team - because they can get people that do not meet their expectations, and for QA’s and testers - to not end up in a project that doesn’t allow us to develop in our chosen direction.
So, what is the difference?
Tester - a person whose goal will be to make sure that the current version of the program looks and works as close as possible to one defined in designs/acceptance criteria.
Tester is far more concerned about finding ways to break the software than about business and processes. Tester could also be responsible for checking pieces of code to ensure there are no defects. In general, it depends on the experience and specialization of the tester. Junior testers would be focused mainly on manual tests of delivered programs. More experienced testers could be responsible for test automation, performance, security, etc. The software tester will be active at the end of a coding cycle.
The downside of being a tester may be that it mostly works based on the code already provided by the developers, so you can find defects but not prevent them.
Quality Assurance (QA) - on the other hand, QA is more focused on preventing business gaps, and as we all know, prevention is better than cure. It affects all product development phases and starts at the early beginning of the project.
Let’s talk a little bit about how it works. Imagine that the whole feature is delivered and ready to test. When you find a bug at that stage, you usually need to change the code on the backend/frontend to fix that. Now let’s imagine that this function is analyzed at the design stage by QA, so it never happens. It saves a lot of time and money. Of course, it’s impossible to prevent every bug, but it’s good to have someone who will also suggest some changes in a project/feature based on experience and connect business and tech.
But it’s not only about reviewing designs! At the beginning of the paragraph, I wrote that it affects all product development processes. So, beyond the discovery process, it will also be creating documentation, ensuring good customer experience, testing (creating a test strategy) and improving processes.
QA is like agile
QA will never be 100% compliant with the definition. Same as agile - QA is a vast concept, and only some projects will make it look the same. So, if you noticed that QA in your project looks different than in another one (maybe one that you worked on in the past?), there is nothing wrong with that. I worked on plenty of different projects, and there was not a single one that would allow the same quality principles to be implemented. And it is a most important trait - QA should have enough knowledge and be flexible enough to create a custom solution for a project, not to go with the same strategy in all undertakings.
Who we are in Appunite
In Appunite, we want to work as a business partner, not only as code writers. We are experts in our field, so to deliver the highest possible value to our clients. We have the required experience and knowledge, so we should decide about the type of tests that will be needed in every case. In most cases, this will mean working as a QA but sometimes also as a tester. It’s not like we can do only manual or automation tests. QA is about combining all test methods and selecting best suited one. Of course, it will not be possible without UI/UX, business knowledge and soft skills.
Why this approach is so important for us?
- We’re team players - so we want to make sure that we’re not only testing someone’s work but helping the rest of the team to deliver as good a product as possible
- We care not only about the code - we’re trying to be a business partner to our clients, so we’re using our experience to suggest changes that will improve the product
- You can develop in many fields - so we’re not closing our carrier paths to tech only, but we allow you to get more into the business and UX/UI
- It’s more satisfying - it makes a part of the problem-solving team, which makes a product more effective and user-friendly. We’re not just a tech team responsible for delivering feature X.
If you want to know more about QA work, and maybe you’re curious if it’s worth having one in the team, let’s check my previous article: Why is QA important in Software Development.
