Should we care about testing the frontend of our applications?

Software is an essential part of the world we live in. If you want to keep pace, you'll have to look into ways to deliver your software faster without sacrificing its quality.

Hi, my name is Aleksandra and I am a front-end developer at matterlab. I’d like to share with you with some of my experiences as well as to introduce some basic knowledge that would help you to dive into front-end testing topic.

This really happened...

Due to an error in the radiotherapy computer-controlled machine, Therac-25, some patients received approximately 100 times the intended dose of radiation. Several patients died.

In 1996 the European Ariane 5 rocket was launched to deliver satellites into the orbit. Problems with software caused it to change it path and in consequence self-destructed. This error costed around $370 million.

The Northeast blackout of 2003 was triggered by a local outage that went undetected due to a race condition in General Electric Energy's XA/21 monitoring software.

Valve's Steam client for Linux could accidentally delete all the user's files in every directory on the computer. This happened to users that had moved Steam's installation directory. The bug is the result of unsafe shell-script programming.

If you are still wondering if you should introduce testing in your frontend applications (or software in general), let me ask you a few questions:

•             Does your app have more users than you can personally train and onboard?

•             Is your app complex or growing in complexity?

•             Does your app have a serious impact (direct or indirect) on people's lives, interests etc.?

•             Is your app subject to legal conditions?

•             Do you care about the user's metrics, for example retention and satisfaction rates?

•             Do you care about how much time you, or your team, spend on tracking and fixing the errors?

•             Do you care about your and your teams’ sleep quality, stress level and wellbeing? 😊

If you have answered ‘YES’ on at least 2 points, this article might interest you.

What are the benefits of testing the code?

You can prevent errors rather than fixing them in production environments and minimize or eliminate loss of revenue from unsatisfied customers. IBM found that the cost to fix an error found after product release was 4 to 5 times higher than if it is uncovered during the design phase, and up to 100 more expensive than if it is identified in the maintenance phase. IBM estimates that if a bug costs $100 to fix in Gathering Requirements phase, it would be $1,500 in QA testing phase, and $10,000 once in Production. Here are a few examples of the benefits of testing code:

•             Tests prevent regression (previously working functionality that now fails) when adding new or changing the old parts of software.

•             Support teams that work on the same codebase – each developer can quickly see if their work will break other people’s code.

•             Minimizes the erroneous time of introducing new developers and helps them to dive quicker into code as they see what and how is being tested. It is an additional form of documenting the code.

•             Helps to stick to best coding practices and application architecture. For example, it forces more consistent, easier and modularized code, as writing reliable tests for huge functions that contain duplicated code is... harder and more time consuming! This in turn will again have a positive impact on easiness and quickness of learning the codebase, changing and extending it.

•             And the last, but not least, as shown in real-life examples, helps to avoid brand risks, reputation consequences, criminal liability or even saves people's health and lives.

‍What are the costs of code testing?

Simply put – a good salary for a good developer. If you decide to introduce tests for your company’s code someone will have to write them. Someone who has substantial skill, or will be granted a time and space to learn it. They will need to be paid for their efforts.

It will also take time to create a strategy for introducing and writing tests. There are many things to consider when making the change that will influence the costs and benefits of a change. For example:

·       Will it be a full process change to employ Test Driven Development (TDD)?

·       Do you want to have 100% test coverage of the code, or cover only the most vital parts of it?

·       If only a portion of the code will be tested, then which?

·       What tools should you be using? Are there enough potential employees on the market that know them? Are they easy to learn and have a good community support?

·       How will you organize and prioritize tests?  

And so on...

Sometimes, the characteristics of your webapp might require some additional coding changes on the back-end (for example to create additional space for testing outcomes, such as storing or clearing requests etc.).

If you have CI/CD processes, then you would probably like to implement the testing as part of them. This would require time from your DevOps team. Depending on the process, it might take a few minutes up to few hours.

It is important to be aware that benefits will not be visible and measurable from the first written test. It takes a bit of time to make testing good and reliable and their benefits compound over time.

‍

End of Part 1

‍