The software quality landscape does not forgive slow adaptation. Development cycles are compressing. User expectations are climbing. Regulatory and security scrutiny is intensifying. And yet, many QA teams are still running their programs on practices designed for a slower, more forgiving era.
After more than a decade of leading quality engineering transformations across financial services and technology organisations, one pattern becomes unmistakable: it is rarely a lack of skill that holds testing teams back. It is habit. Specifically, the ten persistent habits outlined below.
1. Running Full Manual Regression Suites on Every Build
Every time a release candidate is cut, the team runs through the entire manual regression suite. It feels thorough. It is not.
Full manual regression in a CI/CD environment is operationally incompatible with speed. Human testers experience fatigue during repetitive execution, which degrades the quality of attention precisely where attention matters most. Meanwhile, the feedback loop stretches from hours to days, defeating the purpose of continuous integration entirely.
The alternative is a risk-stratified regression model. Identify the highest-criticality workflows and business-impact scenarios, and automate stable checks against them. Reserve human attention for exploratory sessions focused on integration boundaries, edge cases, and recently changed code paths. The result is faster feedback and smarter coverage, not a compromise between the two.
2. Treating QA as an End-of-Pipeline Event
Testing begins when development ends. The QA team receives a build, runs tests, files bugs, and waits for fixes. This cycle repeats indefinitely.
Defect cost is not linear. A requirements ambiguity caught before a line of code is written costs minutes to resolve. The same ambiguity discovered in system testing costs days. Discovered in production, it costs customers, revenue, and reputation.
QA participation should begin in the earliest phases of the product lifecycle: requirements reviews, story refinement, and design walkthroughs. This is the operational core of shift-left testing. Organizations that successfully shift left report measurable reductions in late-stage defect density and shorter overall cycle times.
3. Maintaining Exhaustive Step-by-Step Test Cases for Every Scenario
Every test scenario is documented with numbered steps, expected results, and pass/fail criteria for each micro-action. Documentation libraries grow into thousands of cases that nobody reads in full.
Detailed procedural test cases are expensive to write, expensive to maintain, and paradoxically reduce test effectiveness. They train testers to follow scripts rather than think critically. When the application changes, and it always does, the documentation becomes a liability.
Lightweight test charters and structured checklists communicate intent without constraining method. This activates tester judgment, enables adaptation to real application behavior, and dramatically reduces documentation overhead. For scenarios requiring formal traceability, modern test management platforms support flexible, tiered documentation structures that scale appropriately.
4. Treating Test Data as an Afterthought
Teams use copies of production data (sometimes unmasked), shared static datasets, or ad hoc data created by individual testers. Data inconsistencies are filed as environment issues rather than addressed as systemic risks.
Poor test data management is one of the most underacknowledged root causes of unreliable test results, environment-specific failures, and defects that are difficult to reproduce. Using real production data without proper masking creates meaningful compliance and privacy exposure, a material concern for any organization subject to GDPR, HIPAA, or SOC 2 requirements.
A formal test data management strategy addresses this directly. Synthetic data generation covers volume and edge-case scenarios. Automated masking pipelines handle any production-derived datasets. Version-controlled data sets tied to specific test environments remove a significant and chronic source of test instability.
5. Limiting Quality to Functional Verification
If the feature works as specified, testing is complete. Performance, security, accessibility, and usability are addressed separately, or not at all until something breaks in production.
Users do not experience features in isolation. They experience products. A feature that functions correctly but loads in eight seconds, contains an exploitable input field, or is inaccessible to screen reader users does not represent a quality outcome. Functional correctness is necessary but insufficient.
A holistic quality framework integrates non-functional testing throughout the development cycle rather than treating it as a separate workstream. Performance baselines, automated security scanning, accessibility validation, and usability heuristics should be defined, measured, and tracked alongside functional acceptance criteria.
6. Taking an All-or-Nothing Position on Test Automation
Either automation is avoided entirely because manual testing feels more thorough, or everything gets automated regardless of stability, value, or return on investment.
Both positions are expensive. Avoiding automation creates permanent manual bottlenecks that constrain release velocity. Automating indiscriminately produces fragile test suites that require constant maintenance and erode organizational confidence in automation as a tool.
A strategic automation portfolio prioritizes stable, high-value, high-frequency scenarios where return on investment is clear and measurable. Human expertise applies to complex user journeys, evolving features, and UX-sensitive scenarios where contextual judgment adds value that automation cannot replicate. The portfolio should be reviewed and pruned regularly, because not all automated tests deserve to remain automated indefinitely.
7. Operating in Organizational Silos
Developers develop. Testers test. Product defines. Each group operates within its own domain, communicating primarily through tickets and handoffs.
A significant proportion of production defects do not originate from technical errors. They originate from misaligned understanding of requirements, implicit assumptions that were never surfaced, and feedback loops too slow to catch divergence before it compounds. Silos are defect factories.
Three Amigos sessions bring together a developer, a tester, and a product representative before development begins to surface ambiguities and edge cases before a single line of code is written. Paired testing between developers and QA accelerates knowledge transfer and builds mutual accountability. Shared quality metrics that span the team, rather than just the testing function, reinforce that quality is an organizational output.
8. Measuring Quality Through Bug Count Metrics
Quality is reported in terms of defects found, defects resolved, and open defect backlog. More bugs found means QA is working. Fewer open bugs means quality is improving.
Bug count metrics are a proxy for quality, and a poor one. They create perverse incentives: testers who focus on easy-to-find, low-severity issues inflate counts without improving outcomes. Teams that suppress bugs to hit targets damage the credibility of quality data. None of these metrics directly measure what reaches users, how often, or with what impact.
Outcome-oriented quality metrics connect QA activity to business results. Defect escape rate, mean time to detect and resolve production incidents, deployment frequency, change failure rate, and customer-reported quality signals tell a far more accurate story. These are the metrics that make the value of quality investment visible to senior leadership and enable more informed resource allocation decisions.
9. Managing Test Environments Informally
Test environments are set up manually, maintained through institutional knowledge, and drift from production configuration over time. "It works in QA but not in prod" becomes a recurring and expensive refrain.
Environment inconsistency is a quiet destroyer of testing credibility. When test results are environment-specific, they cannot be trusted. When environment setup depends on individual knowledge, it cannot be scaled. When QA environments do not reflect production, every test result carries an implicit asterisk.
Infrastructure-as-code principles applied to test environments address this directly. Defining environment configuration declaratively and version-controlling it alongside application code ensures consistency. Containerization enforces consistent runtime behavior across development, testing, staging, and production. Automated environment provisioning eliminates configuration drift and reduces the time from code commit to testable build.
10. Prioritizing Documentation Volume Over Testing Value
More documentation signals more rigor. Test case counts are tracked. Audit trails are extensive. Testers spend a disproportionate share of their time writing and maintaining documentation rather than testing.
Documentation is a means, not an end. When it becomes the primary output of a QA function, it displaces the actual work of finding defects, assessing risk, and improving product quality. Extensive documentation that nobody reads, or that is chronically out of date, delivers no quality value.
Right-sizing documentation to the risk profile and compliance requirements of each product area is a more defensible approach. Platforms like Tuskr support structured, searchable, maintainable test case management without requiring excessive documentation overhead. Lightweight test charters, risk registers, and structured coverage maps often communicate more actionable information than thousands of detailed procedural cases ever could.
Making the Transition: A Practical Framework
Recognizing these habits is straightforward. Changing them requires deliberate organizational effort.
Start with pain, not principle. Identify the two or three habits from this list causing the most measurable friction in your current delivery process. Prioritize changes with the clearest connection to outcomes your organization already tracks: release frequency, defect escape rate, team capacity.
Involve the team in designing the solution. Changes imposed from above tend to produce compliance without commitment. Changes developed collaboratively produce ownership. Run structured retrospectives around specific habits and co-design the alternatives with the people closest to the work.
Establish baseline metrics before changing anything. Without measurement, transformation is invisible. Define the metrics that will tell you whether a change worked, and capture baseline values before you begin.
Move incrementally. Ten habits represent ten opportunities for meaningful improvement. Attempting to address all of them simultaneously is how transformation initiatives stall. Sequence changes deliberately, validate results, and let early wins build momentum for what follows.
What High-Performing QA Functions Look Like in 2026
The testing organizations that will lead over the next several years are not characterized by the size of their documentation libraries or the volume of test cases they maintain. They are characterized by four capabilities:
- Speed of feedback. How quickly does the team surface quality risk after a code change?
- Accuracy of signal. How reliably do test results reflect production reality?
- Business alignment. How clearly can the QA function articulate its contribution to business outcomes?
- Adaptive capacity. How quickly can the team respond to new risk areas, technologies, and delivery patterns?
These are organizational capabilities, not individual ones. They are built by leaders who treat quality as a systemic concern and who are willing to retire practices that no longer serve the mission, regardless of how long those practices have been in place.
Conclusion
The habits described in this article did not become problems overnight. Many of them were sound practices in earlier development contexts. The issue is that the context has changed and the practices have not.
The shift from defect detection to defect prevention, from isolated phase to continuous practice, represents a maturation of the discipline itself. Organizations that complete this transition will ship better software, faster, with fewer surprises. The ones that do not will keep discovering what those surprises cost.
