A surprisingly large amount of developers have admitted to skipping writing tests so they can speed up new feature developments, a recent report has found.
42% of respondents confessed to cutting corners when it comes to developing products due to the pressure felt in producing quality software, quickly.
The research, from Diffblue conducted by Vanson Bourne suggests that manual effort alone is not enough to deal with expectations. 40% of developers sited both manual processes and unrealistic schedules to be a contributing factor to poor software quality. This suggests that organisations need to provide better support for their development teams.
The quality of the software maybe poor and unit tests may not have been done but as long as they have been agreed upon by management then that is ok. The business faces a 'balance' between how code can be so beautiful and how long it would take to finish. Let's say you have a feature that will automate a few manual tasks, but you can always ask yourself? Of which of these tasks is the most important so I can work on these first? By doing the most important first then the rest may be ok to be left later.
Asking for failure?
Mathew Lodge, Diffblue CEO responds to the findings by saying: “Asking development teams to deliver world-class software without providing the right support is asking for them to fail and become disengaged. Creating quality code shouldn’t depend on developers writing hundreds or thousands of unintuitive, uninteresting tests. When robotic tasks can be assigned to machines, they should be—not only to retain a more satisfied and effective workforce in a time when top talent can be hard to find, but also to improve the quality of the code they create.”
“Unit tests are part of a virtuous circle. Once your organization has a critical mass of them, everything else from code maintenance to bug fixing (and even the creation of new unit tests as needed) is easier. But getting enough tests in the first place is a hurdle most organisations can’t overcome manually. Hopefully, tech managers will see the challenges their developers might be facing and invest in the supporting tools their teams need.”
Mathew makes a good point on robotic tasks that can be assigned to machines can be automated first. Imagine you have a list that has 1,000 entries and the output is fairly standard coming out from the same code. As the tester or the programmer, do you think it's worth your time having to test all the 1,000 entries one by one manually? Yes it may be but it will be soul crushing for the employee. These are the tests that can be considered to be automated first.
We must ask ourselves if we were to automate these 1,000 tests now would it be worth it? Maybe. If your next release includes some changes specifically for this part of the code and platform then yes, it might be worth automating it soon. In your next release, you will not touch this section of your platform nor that piece of code, is it worth automating it right now? No.