You don’t need testers, here's why!
In today’s world, the competition is intense. You have to go fast, innovate to stay ahead of your competitors. That’s why quality must be there because it ensures having a functional product that meets the defined specifications and uses. As this article on the evolution of the role of the quality assurance engineer attempts to demonstrate, quality is not only the responsibility of any tester but that of the entire team, of the entire company.
At ManoMano, we cultivate a company culture that encourages developers from all horizons to write tests to achieve this ideal. This culture usually results in an abundance of unit tests. But is that enough?
Testing isolated components cannot detect all problems. We’ve all experienced a new feature that was perfectly covered but fell apart because of a cross-service incident. In the age of microservice architectures and increasingly complex distributed systems, we are encountering this kind of problem more and more frequently. And one of the ways to ensure a little more quality between the different bricks of your applications is to implement integration testing and end-to-end testing (E2E). And as I said before:
Quality is the responsibility of everyone
In this context, wouldn’t it be better if developers could also write high-level tests to ensure that users get the desired experience?
Why testing must be developer-based?
There are many pros to giving some of the test automation to the development teams. One of the primary reasons is to accelerate development. Covering the entire test pyramid by developers allows for a holistic approach to testing. It reduces the involvement of a third party in the development process and reduces the duplication of tests that extends the pipeline. There is no need to overload the build chain with an E2E test if there is an integration test (keep the E2E tests to do behavior tests and do the integration tests to test the plumbing).
The dependence on a dedicated team of testers to perform the tests reduces the responsibility of the developers. This can lead to a “not my problem” mindset. On the other hand, involving developers in the realization of tests allows them to take ownership of the entire life cycle of functionality and favors the responsibility of the team. This mechanically increases the quality of the finished product and promotes project adherence.
Having dedicated testers can lead to a “not my problem” mindset.
The fact that testing is not an add-on task, but part of the main task ensures that the functionality is truly covered before deployment. In addition, it promotes the adoption of test-driven development (TDD) and contributes to the maintainability and quality improvement of the product.
From the conception of the functionality, the testability will be taken into account. This will ensure that the delivered features are testable. This also has the pros of forcing the developer to put himself in the shoes of the user and think about the user experience.
Tests can be run at any time by anyone and as often as needed, which reduces the feedback loop and accelerates the development cycle.
Developers are not Good Testers!
Contrary to what you might think, this mindset is not innate, it takes some time to learn it at first. Generally, the person who develops a feature only sees the Happy Paths and does not want to go into details. It’s a difficult mindset to have and if you’re worried about testing at the end of the development process, it’s certain that there will be failures.
Developers always want to see their code as working properly.
But it’s not about leaving the developers alone. That’s why the teams are accompanied by Quality Coaches (at ManoMano it’s the role of the Quality Advisors = QA), who will help them, from the expression of requirements, to think about testability.
Today, development teams are asked to produce new features quickly and continuously. The speed of development has become one of the criteria that determines whether a team performs well or not. If not properly framed, this race for productivity can be detrimental to software quality. Developers dislike testing because they find it boring, repetitive, and complicated to maintain.
Yet, developers who can run test sets repeatedly are valuable to a team.
In the long run, having developers write tests reduces the number of defects visible to customers.
To summarize …
Personally, I don’t mind developers testing their own code. After all, it’s their baby. They know their code very well and know what tricks their code has.
So, yes, developers need to test because the testing activity is no longer a step in the development cycle like it used to be, but it is part of the development phase. It also allows them to better appropriate the application and to be involved by being a force of proposal on new features. It will take some time to learn at the beginning, but it will pay off later.
We also need to find the right balance. In the age of microservices, a product can be composed of several applications and we can’t ask each developer to master the whole product. This is where Quality Coaches have their added value. Quality coaches may lead communities of developers on the quality of the inter-application flows that allow the product as a whole to work properly.
The QA must accompany the developers in their quality approach at the application level and help them to grow while ensuring that the overall product still works properly. Developers must ensure that they deliver an application that still works when it integrates with the other bricks of the product.
If you recognize yourself in this mindset and wonder how we try to implement it at ManoMano, I invite you to read Olivier DENNEMONT’s excellent article on Software quality and craftsmanship at ManoMano.
We ❤️ learning and sharing
Feel free to post your feedback and (constructive) criticism below or reach out to me on LinkedIn. Whether you had a similar or totally different experience, I’d love to hear about it.
Oh, and by the way: we are hiring in France and Spain.
