One of my coding instructors affectionately refers to software testing as “the vegetables of coding”.
Yet more and more companies are prioritizing testing earlier in their software development lifecycles, to aim for a better user experience (i.e. shift left on the project timeline ).
But what exactly is the test and what is it used for? A recent blog post of Attila Vagovirtual presentation software vendor staff software engineer Prezionly covers this topic.
Vágó describes testing colorfully as: “The padding between your software and customer happiness. The thinner the padding, the less satisfied the user is and the more frustration you will feel.
To put it in simple terms, testing is a “combination of processes, actions and code” created for the purpose of confirming that everything that is supposed to happen on the site is happening correctly and reliably before the end user has the ability to interact with it. .
Testing answers the question: do the solutions meet the requirements?
Good. Testing can be a little sexy. Vágó came early with some facts about how the tests got a man into space. Cosmos. Sixty percent of the Apollo Guidance Computer’s development effort was software testing.
If the tests are good enough for NASA, they are good enough for the rest of us.
The test pyramid
The pyramid, made famous by Martin Fowler, does not include static tests as these were added later in the test trophy made famous by Kent C. Dodds.
Unit tests: A simple way to understand unit testing is that unit testing tests each individual unit of the application. This is great for testing functions with inputs and outputs, helper methods, objects, procedures, and modules. If it has or more input and one output, it probably needs a unit test.
Integration testing: A great way to understand integration testing is that integration testing tests how well all units fit together. This is to test a behavior rather than an output. If you click this button, does it behave as expected? Integration tests are excellent for testing isolated scopes of the user interface, but not for testing major application flaws.
End-to-end testing (E2E): Vágó calls end-to-end testing, “the great kahuna of testing”. E2E tests the overall application – all user flows against all relevant dependencies. The test environment is as close as possible to a live production environment or, in some cases, the production environment.
But which layer is the most important? It depends who you ask. There’s as much debate on the internet about this as there is on anything else on the internet. It’s so heated that Vágó calls the debate “religious fanaticism” about which layer is more important.
But in truth, no matter what tests you implement, you can’t go wrong because all three levels of the pyramid are necessary. Writing unit tests, integration tests and following them up with E2E tests to further validate its flows can greatly improve the end-user experience. A good test can reveal architectural issues and less than desirable UX. This is not an “either/or” situation.
Too much or not enough
Ignoring extreme cases creates the not-enough-tests Category. A huge percentage of production bugs result from unexpected scenarios, so test for the unexpected. If a text input expects a string, what happens if the input receives an empty string? If the string is a name, what if it’s just characters or spaces? Ride with it. If 100% of the expected results are tested, the unit is not tested at all.
There are many specific scenarios that fall under the too many tests category, but one thing they all have in common is overlap and the ability to do cost-benefit analysis (time/$$$). Consider the case where there is a large overlap between unit and integration testing. If everything fits properly, it also works as expected. It is often necessary to balance the testing tools available to properly allocate resources and priorities.
Another example highlighted in the too much testing category is a more specific instance of an application using React Testing Library and Cypress. There is a common maintenance cost involved with a heavy layer of E2E alongside an equally heavy set of integration suites. So in this case, if the app has very heavy integration testing, consider narrowing E2E down to global streams rather than testing everything.
A Culture of Quality
But that’s not my job…. Surprise! Testing is everyone’s business! The days (if ever) where the workflow was to write code and then send that code to the QA team for all testing and bug reporting are long gone. If the QA team spends twice as much time testing and writing bug reports as the developer spent writing the code, there are more problems than a few bugs.
A great way to encourage quality testing is to build time into the sprint that allows for proper testing. Twenty-five to forty percent of sprint time is recommended as the amount of time needed to prevent bugs through robust testing. Imagine what might change if testing were a foresight rather than an afterthought.
Testing should not be done alone; share tricky test cases between teams. Create an impact sheet that can track testing against bugs. Bugs are inevitable, but many of them are avoidable. Implementing good testing practices doesn’t have to be zero to 100 right away. Starting something new or even improving something takes time. Even starting with 50% coverage, the coverage will gradually increase to 70% and 70% will gradually increase to 100% in the not so distant future.
Testing and resolving unique QA issues is actually everyone’s responsibility, part of daily development best practices rather than a “bonus” effort. Vágó said it best: “Perfection is overrated, but making an effort is not.”
