Debugging is a fundamental skill in the arsenal of any engineer. Mistakes happen, and bugs are inevitable, but a skilled debugger can catch a bug early…
“My job, in theory, is to build, test, deploy, and maintain software. My job, in reality, is more like the Sisyphus vortex.”
This is the response I received from a developer friend when I asked her to summarize her profession. If you’re not familiar with the reference, Sisyphus is a figure in Greek mythology who upset the gods and was punished with an eternally demoralizing task: rolling a large rock up a hill, only to watch it fall back down again over and over for all eternity. Sound familiar, devs?
Maybe I just caught her at the tail end of a tough day, but clearly, she feels something is askew in her workload. And, studies show that she’s right: the juggling act of writing code versus debugging appears to have reached an all-time nadir. A recent poll indicates 10-25% of a dev’s time is spent debugging, while our own research shows a staggering 75%. So, what happened? Are devs less experienced nowadays than they used to be, or is this the result of cultural changes to the software development life cycle?
Agile development has revolutionized the software world. That said, the push for regular feature updates seems to foment the mentality of ‘release now, fix later.’ Meticulous testing goes by the wayside, bugs sneak into production, and once-stable features start acting up. This then defeats the essential goals of agile development, as developers begin to spend an inordinate amount of time bogged down in unscheduled production work, sprints are interrupted, and future product releases are delayed.
When weighing the testing vs debugging dilemma, consider which scenario does more damage to a product’s reputation and causes more user churn: the user waiting a bit longer for feature delivery, or the user receiving fast, but faulty, product updates.
Establishing a thorough testing regimen has many benefits, including the following:
And testing needn’t eat up a large portion of your day. Tests that are time-consuming and highly repetitive when performed manually, like regression testing, can be automated. Here are a few examples of prominent testing automation platforms you could use:
An open-source solution for testing web apps, Selenium creates browser-based regression tests and offers a Firefox add-on that replays browser interactions.
A platform that allows simple creation of robust end-to-end tests which can be run in parallel and remain relevant even as the UI changes, a great solution we tried and loved.
Justifiably touted as one of the most diverse testing platforms, Ranorex supports testing for a range of environments and configurations. One test can be executed for multiple browsers, versions, apps, languages, devices, etc. Product updates that occur mid-test are recognized by the platform and integrated into the test process.
Considered the most widely-used test case management software, qTest Manager provides a famously simple, single dashboard for planning, defining, executing, and reviewing testing activities.
For a more complete list, check out this site that catalogs multiple options for web, GUI, and unit testing.
Of course, the above platforms might represent just another overhead budget line to executives. Software testing, on the whole, has even been referred to as a ‘cost center, not a profit center.’ But let’s not forget that testing, and its associated cost, is far cheaper than catching a bug late in the SDLC.
Devoting more time to testing vs debugging time doesn’t make a software team more old-fashioned or less agile. It simply allows a healthier balance between delivery and quality, along with many other aforementioned perks. Or in mythological terms, it lets you push the rock up the hill and then enjoy the warm and tingly sensation of watching it rest there comfortably.