The concept of code coverage affects any existing software application, from PC programs, mobile apps, the latest application for your SmartTV or router firmware. While it’s not a concept that depends on whether the software is connected to the Internet, it does affect us all. Let’s explain what it is and how to deal with it.
Broadly speaking, one could consider that a software lifecycle project is made up of the following stages:
- Requirement specifications
When a new program is launched, the product is at stage 5 of its lifecycle, meaning it has been thoroughly tested. However, despite the fact it’s already available to customers, and specifically when products are complex, the developer usually continues to proactively test it in further scenarios (looking for undetected errors).
Tests carried out by the developer ensure that the different parts of the code that make up the software are under constant revision. However, there are always code portions that are more often executed in tests than others. This results in some portions being more thoroughly tested.
Code coverage measures said proportion in different cases. Common code coverage measurements are blocks, or lines of code, some of which are executed during testing while others aren’t, the percentage of times a line of code is executed over the total number of lines, or the computation time used on a section of code with respect to the total time spent.
An extensive example of code measuring can be found in the famous LibreOffice Project , which uses LCOV as the measuring tool.
The result of code coverage measurements testing gives rise to certain areas of code, which are preferred over others, being more frequently executed. Given this, they are considered safer with less likelihood of unexpected errors (bugs).
Now we know a little more about code coverage, the time may have come to ask (as software users) what we can do to avoid bugs that pop up in those portions of code, which have undergone less thorough testing and consequently less coverage.
A good idea is to take advantage of personal experience with a software and not vary the way we use it. For example, if we’ve been using the same application to watch a series on our SmartTV, it’s a good idea to stick to our approach (menus, screens, buttons, etc.) as we know it works. By changing this and moving into areas with less code coverage, we just might find the application freezes, which may mean unplugging the TV (very annoying) to reboot the whole system.
Secondly, show empathy for the application developer and don’t borrow trouble! If you’re looking at a new application for the first time and you want it to go without a hitch, try scrolling through the menus and configuring it as intuitively as possible (without taking on the role of an impromptu beta-tester). You can also get a good take on the developer’s point of view by leafing through the user guide.
Applying the above code coverage and usage principles to a router in production, the ideal is to define work settings (CLI, SNMP or web), that include a prudential amount of time. This allows homogenously pre-testing for different scenarios, which ensures the widest possible code coverage for critical areas and reduces potential problems.
Due to its complexity, the software developed by Teldat undergoes exhaustive tests both prior to its launch and once released. However, as this blog post points out, it’s almost impossible to release perfect error-free software. This is why companies, such as Teldat, which professionally develop software, invest extensively in a quality support team to minimize such undetected errors.