Guys, give me a brief overview of your projects. Why do you work without QA engineers? How does the process go?
Damon: We develop an enterprise CRM system for the sports domain. Particularly our customer considers that automation testing should lie on the shoulders of developers, while manual testing should be project stakeholders’ responsibility. We have division into the following environments: development environment for features creation, testing environment for end-to-end testing, staging for manual testing performed by stakeholders, and after these steps a developed feature goes into production.
Serge: My project is completely different from Damon's — we develop a blockchain wallet. Our client was planning to hire a QA engineer, but hasn’t done this yet. Therefore, I write both code and test scenarios myself. After I make sure that the code works properly, I show it to the product manager on the customer side, and they run tests before the release. If a bug pops up, I fix it.
Do you feel overwhelmed because of the additional workload? Do you experience difficulties when writing tests?
Damon: If you know beforehand that you are involved in testing, you include time for writing tests in your task estimation: each task includes unit testing, integration testing and end-to-end testing. Every time we go over a current testing set and check if something needs to be fixed, we perform full test coverage. But on projects aimed at serving a large number of users simultaneously (like Serge’s crypto wallet, for instance), I wish I had a tester in the team.
Serge: Whether I work in a team with a QA or not, I always check the code I write. Perhaps, with a tester some checks could be omitted, which would significantly reduce my current workload. Another thing to keep in mind, that a blockchain domain is quite specific, and you need to have an in-depth knowledge of the specifics related to working with different cryptocurrencies. Some tasks are quite complicated and tackling them may take weeks. Therefore, I physically have no time to review every single line of code I’ve written, and the help of a QA could be substantial here.
It seems that combining two roles slows down the development speed. Did you have any cases when the customer was not satisfied with the timing?
Damon: It never happened due to established processes and a highly qualified team of full-stack engineers. I would even say that keeping tests in mind helps to write clean and stable code in the result. Yes, it may seem that you spend extra time writing tests (sometimes we even do it before we write code), but the written code is in most cases bug-free. Such an approach reduces time for rework and bug-fixing, which compensates for testing time. However, test scenarios are not always evident, and you may get stuck for a while.
Serge: I neither faced customer’s dissatisfaction with our team’s working speed. The application we develop is quite big and involves fulfillment of multiple complicated tasks, which you need to delve into before you understand how exactly it should be implemented. Our customer fully acknowledges this, since is directly involved in the development and testing process.
Each of your teammates writes tests for his own code, right? Do you conduct code reviews?
Damon: Yes, the one responsible for development of a particular feature is also responsible for its test coverage. After each of us finalizes a piece of work, we launch a code review process and teammates go over each other’s code to mitigate risks of mistakes and have assurance in the quality of the entire work. But if a developed feature requires improvements, the developer who wrote the code fixes it himself or involves a teammate for a better result.
Serge: Initially, when I just started working on the project, all workload related to testing was on our customer. A little later the scope increased significantly, and we shared the responsibilities among the team of developers and the customer. For example, I test the wallet itself, other developers work with the back-end. After a piece of work is finished, we transfer it to the customer to look through. So yes, now each of our team members is responsible for cleanliness and stability of his own code, but our process does not imply code reviews. The reason is simple: the application is quite big, and we have no time to review our teammates’ code lines. Otherwise, we would have spent twice more time on any task to tackle.
Surfing the Internet and looking for the related information, I came across the statement: “To ask a developer to check his own code is the same thing as to ask a student to review his own homework”. What do you think of it?
Damon: I partially agree with the statement. Mainly because the comparison of a professional developer with a student is not entirely correct. But I agree that such a problem exists, and a developer who has written code may overlook something, especially if he is not experienced enough. One of the ways to bypass the problem is to write a test showcasing how exactly code should work before the code itself. Such an approach helps you to keep in mind negative scenarios (sometimes happens, that you go over positive scenarios and forget about negative when doing vice-versa). It’s the same reason why the process of code review is mandatory in our team. The teammates look through the developed feature, make amendments (if necessary) and approve it for deployment.
Also, it is worth mentioning that QA engineer’s tests will always be more abstract than developer’s, as they write versatile tests for all features they check. If an application contains complex business logic, where multiple scenarios must be foreseen — a tester will not always be able to help, since he does not have all implementation details and can estimate the code superficially. In such cases a developer who wrote the code will always have an advantage.
Serge: Well, I agree with the statement. For instance, you’ve written code and you know how it works. And you check exactly how it works, without looking beyond, which often results in reworking due to numerous detected bugs. That is why a QA engineer is an important specialist to check your code from his own standpoint, not from yours. Also, there is a particular need in manual QAs, because neither developers, nor automation testers are able to ensure full coverage of all application modules.
Would you like a QA engineer to have your back on the current project? On which project a tester is not a whim but a must?
Damon: In general, particularly at this moment I do not feel the critical need for a dedicated QA engineer — we successfully address the issues ourselves and ensure full test coverage for the written code. But this approach is justified in case of a similar project type and scope. If an application is cumbersome, with a bunch of integrations and has an enormous amount of users (different healthcare, insurance or fintech applications) — a developer physically has no time to ensure full test coverage and define potential problems. In this case it is reasonable to expand the team of developers (with necessary qualification) or divide a project into subprojects, or hire a tester (if not a team). But in the reverse situation, I’m sure that a highly qualified developer can easily perform a QA’s role, as he owns the context and has knowledge about the code he has written.
Serge: As I have already mentioned, within the current team we can not ensure full test coverage of the application due to its scale, so I wish I had a tester in the team to alleviate the workload a little bit and reduce time for bug-fixing. But there is a caveat in our case. A QA engineer can test only the app itself without checking the back-end and multiple related services, since the latter must be done on the server.
But in general, I agree that a high-load system, with a large number of users and requests, and a big amount of complex business rules can not do without a team of QAs – one tester is not enough in this case.
Final thoughts
Both software developers I talked to have completely different projects and development experience, but they agree on one thing: there is no “one-fits-all'' approach. In case one project can rely on software developers in terms of testing, another can’t do without a team of QA engineers. To make the right decision at an early stage (which will save you money and nerve cells in the future), you should properly assess your project: its specifics, complexity and scope; and/or consult an expert for a second opinion.