Category Whitepapers and Guides
As software development practices evolve, the line between developer and tester has becoming increasingly blurred. 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.
Over the years, companies started to adopt 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 there is still, from my experience, this misconception that developers cannot write tests. This is why specialist roles such as SDET (Software Development Engineer in Test) were created – to bridge the gap between developers and manual testers. Developers are more than capable of writing tests – they already write most of the unit tests for their own code. So, then…why do some developers not test?
From the different client that I have worked with, I have observed the following reasons why this might be the case:
If management don’t push for them to do this, they will think that automating tests is not part of their responsibility. This initiative has to come from the top. Test architects and SDETs, that feel developers should help out with test automation, will not be able to convince them on their own.
Most developers still assume that features should be automated solely 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 the process is slow and flaky. Those developers who have tried to help out find tools such as Selenium difficult to set up and work with.
Most developers work on single components, so they can lack an understanding of how their components will integrate with the rest of the systems. Also, the requirements provided to them often ensure that all positive scenarios are working as expected, leaving negative scenarios missed or neglected.
How do we bridge this gap and ensure that we maximise everyone’s potential?
Support needs to come from the top. Make sure that you communicate what the business benefits are if developers help the testers. Quality should be owned by everyone and not just by the testers.
Developer should be told how the application they’re 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.
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 a “how to” guide is created.
Pair programming is a common way of working amongst developers and this can also be used when writing tests. Experienced SDETs need to pair with developers to share this knowledge.
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.
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.
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.
I’ve seen the benefits first hand. At the client where I’m based, we’ve introduced this approach where developers write the automated tests for some of the new features. Not only are we releasing new features quickly, but knowledge sharing and collaboration between developers and QAs is 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.
You can also watch Ali Hill’s recent talk at Nordic Testing Days 2019, where he spoke about sharing the testing knowledge within your team. Ali discusses testing ideas, testing early iterations and writing automated tests in a collaborative way. You can watch his talk on YouTube now.