Are Developers as Productive as Possible When It Comes to Testing?
Tags: testingtools, code, softwaredevelopment, developer
Published: 2021-07-07 08:11:22

---
title: Are Developers as Productive as Possible When It Comes to Testing?
published: true
date: 2021-01-26 10:13:38 UTC
tags: testingtools,code,softwaredevelopment,developer
canonical_url: https://medium.com/@briananderson2209/software-developer-in-test-537ec95db3af
---

In this blog post, I describe the current testing trend among software developers from various data sources. Evidence suggests that a significant proportion of developers may not be as productive as possible when testing features/bug fixes, becoming increasingly important due to the shift-left movement. With that said, I also found a solution called [**Katalon Recorder**](https://www.katalon.com/katalon-recorder-ide/) that has made testing before handing it to QA easier. Additionally, it can help you transition into software developers in test much much more effortless.

### But first, what do I mean by testing?

Developers must test their features/bug fixes on a functional level to ensure that they do not break anything obvious before handing it off to QA. Of course, there are software developers in test that specialize in building software to test software. Such testing activity happens continuously as modifications are made to the codebase because any change can potentially affect the software’s behaviors.

For example, one must set up the precondition to test a change, such as logging in the application, navigating to a particular site where the change affects. One must also test the flow affected by the change is as expected, and repeat the entire process for the next change.

When I talk about testing in this post, I mean functional testing and not unit testing. Functional testing is essential because it directly affects the user experience.

![Who was responsible for testing in a software development team](https://cdn-images-1.medium.com/max/1024/0*xeHYi6v5scMM4A16)

### Developers are becoming more and more responsible for testing their code

According to the State of Frontend 2020 Report _[1]_, more than 70% of frontend developers state that they are responsible for testing in their software development team, either independently or together with QA specialists. Some of them are also software developers in test who build frameworks to test software. This epitomizes the shift-left testing movement that has emerged within the past few years.

Shift-left testing is an approach where testing is performed earlier in the life-cycle. This is a shift to the left in the project timeline, hence arose the name. The rationale behind this approach is the fact that problems detected downstream are much more costly to fix, compared to those found upstream.

Developers would have already moved on to other tasks by the time a problem is discovered by QA. They will have to switch contexts to fix the problem. Research showed that context switching means high cognitive cost and low performance _[2]_. On the project level, this increases the risk of not meeting commitments made to stakeholders. Recognizing such downsides, teams have started adopting the shift-left approach described above. Consequently, developers become more and more responsible for testing their own code before handing it over to testers.

### A significant portion of developers are still manual testing their code

Also, looking at the State of Frontend 2020 report [1], the importance of end-to-end testing is demonstrated, with more than 40% of developers performing UI tests themselves. This is not surprising, considering the importance of ensuring user experience to business success.

![What kinds of tests have you performed yourself](https://cdn-images-1.medium.com/max/712/1*j0MjxIH2UFFdYUq90HWIvA.png)<figcaption>What kinds of tests have you performed yourself</figcaption>

However, a different source of data gives us an interesting twist. The Front-End Tooling Survey _[3]_, conducted in 2019, revealed that almost 36% of developers currently do not use any tool to test their applications.

![Most popular front end developers’ tools](https://cdn-images-1.medium.com/max/1024/0*s1pUj_3ACmpIB2S_)<figcaption>Most popular front end developers’ tools</figcaption>

### Manual testing goes against what makes developers great at their job

The primary problem with testing manually for developers is cognitive load. Unlike QA members who specialize in such activity, developers are not trained in that domain. Of course, the exception is software developers in test. This unfamiliarity increases cognitive load, especially over the long run. Even worse, developers have to test manually again and again as they code up the feature. Doing manual testing repeatedly reduces the cognitive capacity available for software development activity. As a result, developers are not as productive as they could be.

Another explanation to his problem is the inherent bias in developers that make them good at their job: the tendency to think in terms of “How can I build it ?”. Testers are trained to have just the opposite bias: “How can I break it ?” which makes testing come more naturally for them. This doesn’t mean that developers should not test software. This simply means that testing doesn’t play well with what developers are trained for, and it further increases the cognitive load whenever they need to do it.

![Manual testing goes against what makes developers great at their job](https://cdn-images-1.medium.com/max/885/0*Nz2gJ8lxrTO1IP9o)<figcaption>Manual testing goes against what makes developers great at their job</figcaption>

The takeaway here is that manual testing is not ideal for developers. If you are looking to be more productive, chances are you need to reduce the amount of effort involved in testing while also not compromising its quality.

### Is there a better way?

I am not a software developer in test, but in my years of doing software development and testing, I realized that the force of habit is genuine. It may prevent us from even thinking of the possibility that things could be better. I have recently come across a free web extension called [**Katalon Recorder**](https://www.katalon.com/katalon-recorder-ide/), which is primarily used to generate automated tests. Still, its record-playback functionality can also be used to replace my manual testing activities.

![Katalon Recorder — a free extension to automate browsers](https://cdn-images-1.medium.com/max/1024/1*IGw9sBf3TZ7RtkstJXyHFw.png)<figcaption>Katalon Recorder — a free extension to automate browsers</figcaption>

After installing the extension, you just need to open it and click on the Record button to start generating tests. Click on the Play button to execute tests. It literally could not be any easier.

![](https://cdn-images-1.medium.com/max/1024/0*z-h3RHQt_56zP2rJ)

I like [**Katalon Recorder**](https://www.katalon.com/katalon-recorder-ide/), much more than **Selenium IDE** , is the lack of friction that Katalon Recorder provides. With Selenium IDE, you need to create a project, input URL, and only then you can start generating tests. Undoubtedly, the onboarding process may make sense for a different audience. As a developer, I am only concerned with creating cheap and fast tests to replace the actions that I would have to do myself otherwise. The frictionless feeling is crucial for my long-term adoption of Katalon Recorder because god knows I have to do it a lot.

Since my discovery of Katalon Recorder, I have become much more productive due to the amount of repetitive testing it saved me from. I believe that we can be much more productive if we are mindful of the activity that we engage in every day because only then will we consider how these activities can be improved. Better yet, there may already be a tool out there that can help us immediately.

Additionally, I think that Katalon Recorder is an excellent tool if you are looking to transition into software developers in test because it allows you to experience automated testing quickly and easily. Feel free to share the tools that help boost your productivity every day in the comment section below.

### References

[1] [State of Frontend 2020 Report](https://tsh.io/state-of-frontend/#developers)

[2] Shakeri, Zahra & Noaeen, Mohammad & Zowghi, Didar & Far, Behrouz & Barker, Ken. (2018). Two Sides of the Same Coin: Software Developers’ Perceptions of Task Switching and Task Interruption. EASE’18: Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018. 175–180. 10.1145/3210459.3214170.

[3] [The Front-End Tooling Survey](https://ashleynolan.co.uk/blog/frontend-tooling-survey-2019-results#js-testing)