This article is based on reporting originally published by InformationWeek. Attribution and quotes are preserved from the source material.
The Speed-Quality Tension in DevOps
DevOps was built on a promise: deliver software faster, more reliably, and with tighter collaboration between development and operations. That promise has largely been kept. But speed and quality are not automatically allies, and in practice many DevOps teams sacrifice rigorous testing in favour of rapid release cycles. The result can be outages that harm users and damage the business.
A Real-World Cautionary Tale: Slideshare’s 60,000-User Outage
Sylvain Kalache, a former operations engineer at Slideshare and later co-founder of Holberton School, recounted how a well-intentioned but under-tested change took down Slideshare.net for more than 60,000 users.
“A software engineer was working on a database-related project and trying out a tool that offered the ability to explore a MySQL database graphically. He decided to reorganize the order of the database columns in that tool so that the data would make more sense to him. What he did not know was that it was also changing the columns’ order in production on the actual database, locking it, which brought down Slideshare.net and shut out the more than 60,000 users trying to access it.”
Sylvain Kalache, co-founder of Holberton School and ex-operations engineer at Slideshare
Slideshare was acquired by LinkedIn in 2012 for $119 million—a testament to the company’s engineering execution overall. Yet even successful DevOps organisations are not immune to quality failures when risk assessments and pre-production checks are skipped.
The incident could have been avoided with a straightforward risk assessment and change-control gate before the tool touched the production database. It wasn’t an extraordinary failure—it was a common one, and Kalache is explicit that it is not unique to Slideshare.
The Systemic Problem: Continuous Release Without Continuous Quality
Many organisations that adopt DevOps focus heavily on continuous delivery pipelines while treating quality assurance as a secondary concern. A survey by Parasoft, a provider of automated testing tools, found that organisations operating in DevOps and Agile environments frequently overlook QA dimensions such as reliability, testability, availability, and application resiliency.
The underlying incentive structure is the problem. Continuous release is measurable and visible—you can count deployments per day. Software quality deficits are often invisible until a production incident makes them brutally apparent.
Why Automated Testing Alone Is Not Enough
The DevOps industry’s standard answer to the quality problem is test automation. Automated tests integrated into a CI/CD pipeline can catch regressions quickly and run repeatably at scale. John Overbaugh, a senior software development engineer at Microsoft, offered a practical framing:
“It only makes sense to use automated testing tools when the costs of acquiring the tool and building and maintaining the tests are less than the efficiency gained from the effort.”
John Overbaugh, Senior Software Development Engineer, Microsoft
That is a pragmatic bar that not every automation initiative clears. Maintaining a large automated test suite is itself a software engineering effort. Tests go stale, environments drift, and flaky tests erode confidence in the entire pipeline.
John Lunsford, senior program manager at Quality Logic—a cloud-based testing platform that combines automated tooling with human testers—makes a further distinction:
“You have to look at what you can automate, and the automation that you use must be able to demonstrate repeatability.”
John Lunsford, Senior Program Manager, Quality Logic
Lunsford argues that one of the highest-value applications of test automation in a DevOps pipeline is “sanity check” automation: verifying that links are not broken after a release, that previously working integrations still function, and that a change in one service has not caused unexpected regressions in adjacent systems.
Comprehensive testing—the kind that validates functionality, usability, security, recovery, and cross-environment compatibility—is still not consistently present in DevOps pipelines. Speed-to-market pressure remains a real force pushing teams to ship before testing is complete.
The Infrastructure Knowledge Gap
The Slideshare incident points to a deeper structural problem: many developers who work in DevOps environments have limited exposure to production infrastructure. Kalache put it directly:
“It’s important to better educate developers on the workings of infrastructure. Many of them have never been exposed to production infrastructure. You can’t expect everyone to naturally know the hidden rules.”
Sylvain Kalache
This gap is amplified by low-code and code-generator tooling. A non-technical user can assemble a working application in minutes without understanding how it will behave across different operating systems, browser versions, network conditions, or mobile devices. The application may work in the demo environment and fail in production for reasons invisible to its builder.
The same risk applies to commercial software vendors who ship continuous releases. A vendor may test exhaustively in their own standardised environment while remaining unaware of the specific configurations, integrations, or constraints present in their customers’ environments.
Practical Steps for DevOps Teams to Improve Software Quality
DevOps does not require trading quality for speed, but closing the gap demands deliberate action. The following practices are widely recommended by practitioners.
1. Educate Developers on Production Infrastructure
Engineers whose careers have been spent entirely in abstracted DevOps tooling benefit significantly from understanding the underlying infrastructure their code runs on—networking, database internals, storage I/O, operating system behaviour, and the blast radius of a misconfigured change. This knowledge directly reduces the likelihood of incidents like the Slideshare database column reordering.
2. Break Down Silos Between Developers and Systems Specialists
DevOps teams should collaborate actively with database administrators and systems engineers, not just during an incident. DBAs and platform engineers can identify risks that application developers will not see. Embedding this expertise into the development workflow—through code review, architecture review, or pair work—surfaces quality problems before they reach production.
3. Match Your Test Tooling to Your Actual Risk Profile
There is no shortage of DevOps testing tools, but the right selection depends on what your team ships. Frontend-heavy teams need tools that validate UI behaviour across browsers and devices. API-driven backends need contract testing and integration test coverage. Mobile applications need device-matrix testing. Evaluate tools against the specific failure modes your system is most susceptible to, not against a generic checklist.
4. Use Virtual and Isolated Environments for Testing
Automated environment simulation can validate behaviour across a range of configurations, but no tool covers every production scenario. Identify the scenarios your automation cannot reach, and test those manually. Maintaining a matrix of supported environments and systematically working through gaps is more effective than hoping automated coverage is complete.
5. Apply Full-Battery Testing to Customer-Facing Applications
Internal tooling and developer-facing services can tolerate some level of instability—teams can work around it. Customer-facing applications cannot. For any application that end users interact with directly, require a full test cycle that covers:
- Functionality – Does every feature work as specified?
- Usability – Is the interface coherent and accessible?
- Integration – Do all upstream and downstream dependencies behave correctly?
- Security – Are known vulnerability classes addressed?
- Recovery – Does the application degrade gracefully and recover from failure?
- Cross-environment compatibility – Does the application behave consistently across supported browsers, devices, and operating systems?
No customer-facing release should bypass this checklist. The cost of a production failure visible to customers—in reputation, churn, and support burden—almost always exceeds the cost of the additional testing time.
The Verdict: Incompatible or Just Undisciplined?
DevOps and software quality are not fundamentally incompatible—but quality does not emerge automatically from a CI/CD pipeline. It requires deliberate engineering discipline: educated developers, cross-functional collaboration, well-chosen automation, and explicit quality gates calibrated to the risk level of each application. Organisations that treat quality as an afterthought will eventually face the kind of outage that Slideshare experienced. Those that build quality into the delivery process can realise both the velocity that DevOps promises and the reliability that users expect.