The new year has just begun, and it’s the right time to reflect and set ambitious, yet achievable goals for the year ahead. While taking a look at some of the “unsolved” testing problems of 2021, as seen within our community of developers, we came up with the following list of resolutions that we hope are realistic, and relatively easy to take onboard by any software developer out there.
1. Make Security Core to Any Development Toolset
The end of 2021 was marked by the finding of the disastrous log4j vulnerability, which affected nearly everyone in the industry. By itself, Log4Shell was not a big problem for most: as we remember, the library was quickly fixed, and we were able to quickly update or make sure that the vulnerable library was not in the dependencies.
Yet, that calls for the attention to the aspect of security, as one serious aspect that is often overlooked. How many more vulnerabilities are there in our codebase or in the libraries that we use? What can we do to ensure breaches in our own code happen less and less? And are there things that developers can do right away to increase security?
Most of the developers already take advantage of some Software Composition Analysis (SCA) tools. Е. g. if you are using GitHub, it will warn you automatically about known vulnerabilities in the libraries that you use. You may be using more advanced tools such as JFrog X-Ray or WhiteSource. It’s worth making sure that some kind of SCA is present in your development toolset.
Automated dependency updates are closely related to SCA. Tools like Github’s Dependabot are free and easy to deploy, but they require that you have a reliable CI pipeline that performs full program compilation and runs unit and integration tests. You should trust your CI pipeline if you’re willing to automatically update the dependencies to their latest versions on a daily basis. But as a result, the probability of having a known vulnerability in your dependencies will be close to zero.
SCA, however important and useful, will not cover all the potential security issues.
Aside from that, developers may consider adopting relatively easy Static Application Security Testing – a set of tools similar to static analysis, but focused on finding security weaknesses in your application. Must add, that while SAST tools are usually not cheap, and you must account for that in your budget planning, the risks they mitigate are worth the price!
Of course, no static analysis tools will be sufficient if developers in your organization are not taking security seriously. Internal training, making developers aware of CWE TOP 25 / OWASP TOP 10 lists, and introducing internal policies is a good approach to avoid the known top weaknesses are certainly good things worth doing for the coming months.
This is my to-do list to improve security in our team for 2022:
- Set up some Software Composition Analysis (SCA) tools to easily detect code vulnerabilities.
- Integrate Automated Dependency Updates to our CI pipeline to minimize risks caused by third party dependencies.
- Add Static application security testing (SAST) to the testing process to find any security weakness
- Provide security education materials to the team and encourage continuous learning.
2. Focus on Accessibility
We are all different and often forget that not all users of our software can see, hear and use fingers on both hands. Modern technologies are able to assist impaired people living to their full potential, but it’s completely our responsibility as developers to make sure that programs are suitable to everyone’s needs.
Moreover, in a growing number of cases this responsibility is required by law, as we can see on the official page of WWW Consortium: you won’t be able to legally operate certain websites or applications if you are not meeting the a11y requirements. Some experts believe that a11y is going to be one of the major trends that will change the front end development landscape in the near future. Getting yourself familiar with Web Accessibility Initiative standards is a good thing to be done in 2022.
Not surprisingly, following the a11y standards in many cases means better code quality. Clear semantic markup is something that’s not only good for screen readers, but also for code maintainability.
3. Use the Power of k8s and the Cloud to Build and Test Your Software
“Shorten feedback loop” is a well-known mantra of DevOps movement, which celebrates its 10 years anniversary in 2022. Still, the problems of getting fast and reliable feedback on the changes we make are with us. Of course, the implementation of general recipes proposed by DevOps vastly depends on the scale and specificity of your organization. However, as years go by, more and more tools previously relevant for large projects and big teams become relevant for smaller ones.
Kubernetes became highly popular in recent years, but still running your own Kubernetes cluster is something that can bring you more pain than gain if you cannot afford a dedicated team for this task. It is also required that your application is “cloud-native”. I’m sure that most of the people reading this are aware of these challenges and even have successfully overcome them.
But things are getting simpler. Nowadays, there are a number of decent k8s implementations in a cloud as well as a large number of experts who know how to automate things in k8s. Now more developers can utilize the power of k8s even for smaller applications.
With proper build and test pipeline, k8s makes the terms “testing / demo / staging environment” obsolete. Now we can deploy as many environments as we wish for small and medium-sized applications with a single click, running end-to-end tests, performing exploratory testing and demos. We should enable this way of building and testing for as many projects as we can in the coming year.
All this becomes possible when more developers become familiar with k8s. Just like the Unix command shell, knowing how to do things in k8s becomes an essential skill for each programmer.
So to learn k8s hard is another resolution.
4. Automate Test Coverage Computation
The impact of pushing code to production that hasn’t been properly tested can be huge. Bugs that make their way into production can lead to loss of resources and credibility, which can directly affect the company’s finances.
Now, how do we make sure we have enough automated tests, and that they cover as many test cases as possible? Code coverage is a widely used metric that computes how many lines of code are covered by your tests. It is highly recommended to keep track of your code coverage and monitor how it changes, making sure each time a developer pushes new code all the significant changes are covered.
Keeping track of code coverage is very important, but it has to be done wisely. As it happens with many concepts in software development, each situation requires a different configuration.
Few things to take into account about code coverage:
- You can't reduce the “code coverage” metric to a single percentage. Much more important is a full report showing which lines of code are covered. Looking at this report, you can find non-trivial untested code, and this is the main value of code coverage. Percent values, if they are high, are nice to show, but you should not chase a high percentage for the sake of the percentage. The story is more complex than that.
- High code coverage doesn't mean that all test cases are covered. Testing some lines such as logging statements, exceptions that don’t occur, or argument types that are not allowed is unnecessary. On the other hand, one can create dummy tests with high line coverage that don’t really test complex application logic.
- If you collect coverage for both unit and integration tests, produce separate reports. Although it’s tempting to merge these reports and get higher percentages, you’ll get more information if these reports are separate.
- Setting up quality gates based on coverage percentage is counterproductive, as they can delay time to production and make code less dynamic. If you really want to set up such gates, choose a low number (50% or less) and remember that reviewing coverage reports is more important.
And What about Data Coverage?
How do we make sure that the test input data covers as many cases as possible? There are many tools that combined, they can measure the coverage of your data. Read more about the topic here.
5. Take the Bias out of the Data
Data bias is another very important aspect for us, and more and more companies are starting to acknowledge the impact a biased AI can have in the real world and the need to develop responsible practices. Start 2022 with looking to understand how data bias works, how to identify it, how to also mitigate it.
As developers we cannot allow ourselves to fail at recognizing bias and see the bigger implications of launching this new wonderful AI application into the wild. Algorithms are a reflection of our world as they learn from the data we provide them with. Very likely, unless trained otherwise, the machine will reproduce this in the future what they are being taught and reinforce the bias, with a much greater range and much faster speed than a human would do. Is safer to assume your data is biased and checking against it, then putting in production flawed applications.
Making AI algorithms that are bias-free is easier said than done. Thile there are many possible avenues to explore. Synthesized has open sourced its Fairness Scoring and Bias Identification capabilities, a robust bias and fairness toolset to incorporate into your own development environment. The Python library is instantly accessible and available on GitHub.
There are several solutions on the market to support you on the journey of fairness and rooting out bias in AI, such as Awesome-Fairness-in-AI, Fairness-ML, IBM AI fairness 360 toolkit, ML-Fairness or Microsoft’s Fairlearn, to name a few.
