Yunhao Jiao
Teams that own quality themselves work differently from organizations built around a separate QA function. Large groups can split development and testing, then require formal approval before release. Teams of four to twelve engineers usually cannot copy that model cleanly. Their workflow has to put quality responsibility inside everyday engineering work.
What does carry over is a focused group of practices. The tools stay familiar. The way the team uses them changes.
Pattern 1: The pre-merge gate is mandatory
Teams without QA often treat CI as advice. A passing build is probably fine. A failing build gets inspected, then a flaky test may simply be rerun until it passes.
In our early-access program, the teams that ship most reliably make the CI gate strict. A failing test blocks the change, rather than starting a debate about its importance. That takes enforcement: whoever can merge rejects a PR with a failing test, including a known flaky one.
The tool is not the point. The team must agree that the gate has meaning. Without QA to catch regressions before release, it is the final defense. If it can be ignored, quality can be ignored too.
Pattern 2: The developer who changes something tests it
With QA, work commonly passes from the developer who finishes a feature to the tester who checks it. Without QA, that handoff is absent, though teams may still act as if it exists. Developers write the code and tests, but deadline pressure pushes testing aside because it feels like work for a nonexistent function.
Teams that avoid this problem make testing part of the definition of done for every change. It is not a later task or another ticket. It belongs to the same work. A feature PR contains its tests. A behavior change includes tests updated for the new behavior. If the test cannot be written before merge, the feature is not finished.
This is established agile practice, not a new idea. Naming it matters because, without QA to enforce it, the team must enforce it itself. Written agreement makes that discipline easier to sustain than an unspoken assumption.
Pattern 3: Review suite health, not only feature tests
Writing tests is visible. A feature ships, tests are added, and coverage rises. Maintenance is quieter. Passing tests drift away from the product. Selectors break, assertions age, and the suite gathers tests that fail or pass for the wrong reasons.
Teams that keep a suite healthy without QA review its condition separately from feature work. Every two to four weeks, they examine recently failing tests, tests with high skip rates, and product areas with the lowest coverage. The suite is infrastructure to maintain, not an artifact written once.
The review can be brief. An hour with the team can identify the five to ten tests needing the most attention. Fix them in the next sprint alongside feature work, rather than waiting for a separate refactor sprint that never arrives.
Pattern 4: Put failures where people will see them
An unnoticed CI failure is a failure that remains unfixed. Without a dedicated QA engineer monitoring the pipeline, failures may sit there for days.
The most effective teams show CI status in the communication channel people use most. Not a separate CI channel checked only by the most diligent engineers. Put it in the main engineering channel or the PR interface, with enough context to make the failure difficult to overlook.
This is partly a culture choice, not only a tooling choice. The signal must reach a place people actually watch. If a regression breaks the build at 2pm and six engineers see it by 2:30pm, it can be fixed that day. If it lands in a channel checked once daily, it becomes background noise, and someone eventually disables its notifications.
The common thread
These four patterns reflect one principle: when there is no dedicated QA function, quality must be shared. It cannot belong to one person or one phase. It must be built into the workflow at every point, from pre-merge through deployment and ongoing maintenance.
Teams that ship consistently without a QA organization are not relying on heroics. They practice these habits repeatedly instead of treating them as one-off efforts. The habits can be learned and reused. Supporting tools, including automation for the work that drains engineers fastest, help keep those habits sustainable as the team and codebase grow.