As software development practices have evolved, the lines between the role of developers and testers are becoming increasingly blurry. As testers, we are now expected to know how to setup test automation frameworks, code different types of test (e.g. integration, functional, performance) and even understand and contribute to the build and deploy pipeline process. Traditionally, there has always been a clear distinction between development and testing. In older software lifecycle models such as Waterfall and V-Model, testing only starts when development work is finished, with few if any automated tests put in place. As years passed, companies have started to adapt a more collaborative and iterative way of working where the testing process is often championed to start as early as the requirement gathering stage.
Even though development practices have evolved throughout the years, I still see, from my experience, that there is always a misconception that developers cannot write tests. This is why specialist roles such as SDET (Software Development Engineer in Test) are created – to bridge the gap between developers and manual testers. I assure you, developers are capable of writing tests. They already write most of the unit tests for their own code. So the question remains …why do some developers not test?
From the different client sites that I have worked with, the following are the main reasons that I have observed as to why this is happening:
- No one is asking them to test
If management is not pushing them to do this, then they will think that automating tests is not part of their responsibility. This initiative has to come from the top. A test architect or a technical lead who shares the same vision that developers should write tests will not be able to do this on their own.
- They don’t want to test
Most developers still have the assumption that features should be automated by testers. Once their ticket passes peer review, they believe that their work is finished. Some developers hate writing end to end tests because they believe that it is slow and flaky. Developers who do try to write tests often face the same frustrations that automation tools such as Selenium are difficult to set up.
- They lack the necessary guidance of looking at their features from an end to end perspective
Most developers work on single components, so they can often lack understanding as to how their components will integrate with the rest of the systems. Also, the requirements that are provided to them is to ensure that all positive scenarios are working as expected leaving negative scenarios missed or neglected.
How do we then help developers become testers?
How do we bridge this gap and ensure that we maximise everyone’s potential?
- Get support from management
Support needs to come from the top. Make sure that you communicate what the business benefits are if developers also become testers. Quality should be owned by everyone and not just by the testers.
- Regular knowledge sharing with the business
For developers to understand how the application that they are working on is used by the business or its customers, a simple yet effective idea is to have regular knowledge sharing sessions with the business. Another good idea is to have these sessions documented on Confluence or something similar.
- Documentation on how to contribute to the automation framework
There should be clear guidelines on how developers can help contribute to writing tests. If someone has not used tools like Cucumber and Selenium, make sure that steps on how to automate features are documented.
- Introduce pair programming when writing tests
Pair programming is a common way of working amongst developers and this can also be used when writing tests. Experienced SDETs needs to pair with a developers to share this knowledge.
- Be a teacher and educate
Point them to resources that will help them with writing tests and show them best practices. Guide them on how to do it but don’t write their tests on their behalf. Peer review their code. Be patient.
- Modify your process to include testing as part of a developer’s workflow
Before changing your ticket to done, make it a habit of including automated tests. This is especially useful for new features. Rather than writing the tests after the feature is deployed, write it during the development stage.
- Include automation tests as part of the CI/CD pipeline
The more diverse tests that are added to the pipeline, the more visible the results will be to everyone. Utilize an effective test reporting dashboard so results of all the test runs can be easily displayed. By having these tests in the pipeline, developers will have visibility if they break existing features.
- Evaluate testing tools effectively
So what happens when developers become testers? I’ve seen the benefits first hand. At the current client site where I am based, we’ve start to introduce this approach where we ask developers to write the automated tests for a new feature. Not only are we releasing new features quickly, but also knowledge sharing and collaboration between developers and QAs are better than ever before.
Developers should know about testing the same way automation testers know about coding. By getting developers involved with the testing process, we begin to utilise everyone’s knowledge and potential, as well as avoid scenarios where bottleneck occurs.
If you’d like more specific advice around how to help your developers become testers, you can get in touch with us here.