30 Practical Tips to Shift‑Left Testing and Kill Bugs Early

Last Friday night a payment glitch—money was deducted but no order created—illustrated the cost of bugs that slip into production, prompting the author to compile a practical 30‑point checklist for shift‑left testing.

1. Demand must be scrutinized

Run a joint review with product, development, and testing to surface hidden logic behind seemingly simple changes.

Write concrete acceptance criteria (e.g., "within 2 seconds a success or clear error must appear").

List edge cases such as wrong phone numbers or missing digits in card numbers.

Draw flowcharts that include exception branches (timeouts, permission errors, missing data).

Match fields between front‑end and back‑end, specifying required status, type, and unit (yuan vs. cents).

Example: a previous promotion displayed "99.9" while the actual charge was "99.9000001", causing loss and complaints.

2. Sharpen tools before coding

Configure static analysis tools like ESLint and Sonar; they warn instantly on save.

Guard against null pointers (Java NPE, Python KeyError) with explicit checks.

Mock downstream services with Postman or lightweight stubs when they are unavailable.

Log meaningful context (user ID, order number, a unique trace ID) instead of generic "operation successful".

Apply small‑scale TDD for critical logic such as money calculations.

3. While coding, keep asking “and then?”

Write unit tests that cover real branches, especially the else paths.

Stress boundary values: first/last array element, max/min numbers, empty or overly long strings.

Release resources explicitly (close files, free DB connections) rather than relying on GC.

Validate every external input—length, format, content.

Consider concurrency: will two simultaneous "抢购" actions cause overselling? Use locks or atomic operations.

Real incident: a flash‑sale without concurrency control produced negative inventory.

4. Before submitting code, hunt your own bugs

Run a self‑test checklist: does the feature work? Does it crash on bad data? What happens offline?

Conduct a thorough code review focusing on null‑pointer risks and exception handling.

Assess impact of a change beyond the obvious UI tweak.

Add feature toggles for risky new functionality to allow quick rollback.

Delete dead code and commented‑out logic; leftover code confuses future maintainers.

5. Set "roadblocks" before handing over

CI pipeline should block merges if tests or security scans fail.

Keep environments consistent (dev, test, prod) to avoid configuration‑driven bugs.

Regularly scan third‑party dependencies (e.g., Log4j) and upgrade vulnerable versions.

Monitor performance of core APIs (login, order) and flag regressions.

Never ignore classic security issues (SQL injection, XSS); use framework protections or custom safeguards.

6. Mindset and attitude matter most

Quality is a shared responsibility; blaming developers or testers harms the product.

Post‑mortems should focus on root causes, not finger‑pointing.

Provide newcomers with a "bug map" of common pitfalls.

Commit small, frequent changes rather than large, infrequent batches.

Speak up about potential risks; it’s better to be called a troublemaker than to hide a problem.

In short, the best time to eliminate bugs is the moment you type the code. Spending a few extra minutes thinking now can save hours of firefighting later.