DEV Community: lisamangnani1122-sketch

Shift-Left Testing: How to Catch Bugs Before They Reach Production

lisamangnani1122-sketch — Sat, 20 Jun 2026 00:29:32 +0000

Shift-Left Testing: How to Catch Bugs Before They Reach Production

Shift-left testing means moving quality checks earlier in the development
process — testing code as it's written instead of after it's finished —
so bugs get caught when they're cheapest and fastest to fix. The earlier a
bug is found, the less it costs: a mistake caught while coding takes minutes
to fix, while the same mistake caught in production can mean a rushed
hotfix, a rollback, and a damaged customer trust.

Here's what shifting left actually looks like in practice, and how to build
a process around it.

What "shifting left" actually means

Picture a development timeline drawn left to right: design, code, test,
release, production. Traditionally, testing sat near the right side — QA
got involved once a feature was "done." Shifting left means moving testing
activities toward the left: into design discussions, into the coding phase
itself, and into every code review — instead of treating testing as a
separate phase that happens after.

It's not about removing QA. It's about giving QA (and developers) the tools
to catch problems earlier, so the formal testing phase is confirming
quality rather than discovering it for the first time.

Why catching bugs early saves money

This isn't just a philosophy — it's a well-documented cost curve. The
later a defect is found, the more expensive it is to fix, for a simple
reason: more work has been built on top of it, and more people are involved
in fixing it.

Caught while writing code: the developer fixes it immediately, no one else is involved
Caught in code review: a short conversation, minor rework
Caught in QA testing: a bug report, a reproduction step, a fix, a re-test cycle
Caught in production: an incident, a hotfix under pressure, possible customer impact, and a post-mortem

Each stage adds people, process, and risk. Shifting left isn't about
working harder — it's about resolving issues at the cheapest possible stage.

Practical shift-left techniques

Unit tests written alongside the code, not after — ideally before, if the team practices test-driven development
Static analysis and linting run automatically on every commit, catching obvious issues before a human ever reviews the code
Code review checklists that explicitly include testability and edge cases, not just style and logic
Contract or integration tests that catch breaking changes between services before they reach a shared environment
CI pipeline gates that block merges if tests fail, rather than relying on someone remembering to run them manually

Building a pre-merge QA checklist

A simple, consistently-applied checklist catches more than an elaborate
process nobody follows. A practical pre-merge checklist:

[ ] Unit tests added or updated for the new/changed behavior
[ ] Edge cases considered (empty input, max values, concurrent access)
[ ] Static analysis / linter passes with no new warnings
[ ] Existing tests still pass locally before pushing
[ ] Error handling reviewed — not just the happy path
[ ] No hardcoded secrets, credentials, or environment-specific values

This list works best when it's enforced by the CI pipeline wherever
possible, rather than relying purely on manual discipline.

Common pitfalls when shifting left

Treating it as "developers do all testing now" — shifting left adds earlier checks, it doesn't eliminate the need for dedicated QA, especially for exploratory and end-to-end testing
Slowing down development with too much process — a 40-item checklist nobody reads is worse than a 6-item one that's actually followed
Skipping it under deadline pressure — this is exactly when shifting left matters most, since rushed code is where the cost gap between early and late bug-catching is largest

How to measure if it's working

The clearest signal is the defect escape rate — the percentage of bugs
that make it past each stage and get caught later instead. A falling escape
rate into production (more bugs caught in code review or CI, fewer in
production) is the direct evidence that shifting left is working, separate
from any subjective sense that "things feel more stable."

The bottom line

Shift-left testing isn't a single tool — it's a shift in when quality
checks happen, moving them as early as possible in the development process.
The combination of automated checks (linting, unit tests, CI gates) and a
short, consistently-enforced checklist catches most issues before they ever
reach a formal QA phase, which is what actually reduces both the cost of
fixing bugs and the number that reach production in the first place.

How Machine Learning Detects Fraud: A Practical Breakdown

lisamangnani1122-sketch — Sat, 20 Jun 2026 00:27:28 +0000

How Machine Learning Detects Fraud: A Practical Breakdown

Machine learning detects fraud by learning the patterns of past fraudulent
transactions and flagging new transactions that match those patterns —
combining models trained on known fraud cases with anomaly-detection methods
that catch fraud patterns no one has seen before. Most production fraud
systems use both approaches together, not one or the other.

Here's how that actually works, and what makes fraud detection a harder
problem than it first looks.

Why traditional rule-based systems fall short

Older fraud systems ran on fixed rules: flag any transaction over $5,000,
flag any purchase from a new country, flag any card used twice in 10 minutes.
Rules are easy to understand, but they break down fast:

Fraudsters adapt to known rules almost immediately once they're public or easily inferred
Legitimate customers get blocked by rules that don't account for context (a $5,000 purchase is normal for some customers, suspicious for others)
Rules don't scale — every new fraud pattern needs a brand-new hand-written rule, and the list grows forever

Machine learning replaces fixed thresholds with learned patterns that adjust
per customer, per merchant, and per context automatically.

How supervised models learn to spot fraud

Banks and payment processors have years of transactions already labeled
fraudulent or legitimate (often confirmed by customer disputes or
investigations). A supervised model trains on that history, learning which
combinations of features tend to appear in fraud cases.

Common features fed into the model:

Transaction amount relative to the customer's typical spending
Time since the customer's last transaction
Distance between this transaction's location and the last one
Merchant category and whether the customer has used it before
Device and IP address fingerprinting
Time of day relative to the customer's normal activity pattern

The model doesn't apply a fixed rule to any single feature — it learns the
combination of signals that historically correlates with fraud, which is
why it catches cases a simple rule would miss entirely.

Why unsupervised methods matter too

Supervised models are only as good as their training data — they're built
to catch fraud patterns that have already happened before. New fraud
techniques won't be in the training data, which is exactly where
unsupervised anomaly detection earns its place.

Unsupervised models don't need a label called "fraud." Instead, they learn
what normal behavior looks like for a customer or system, and flag
anything that deviates significantly — whether or not it matches a known
fraud pattern. This is what catches genuinely new fraud techniques before
enough labeled examples exist to train a supervised model on them.

The real-time challenge

Fraud decisions for card transactions typically need to happen in well under
a second — the transaction is either approved or declined before the
customer's payment terminal moves on. This puts real constraints on the
system:

Models need to be fast enough to score a transaction in milliseconds
Features need to be pre-computed or cheap to calculate on the fly
Complex models (like large neural networks) sometimes get traded for faster, simpler ones specifically because of the latency budget

Balancing false positives and false negatives

Every fraud system makes a trade-off:

Too aggressive → legitimate customers get declined or flagged, which damages trust and costs sales
Too lenient → real fraud slips through, which costs money directly

There's no setting that eliminates both. Most systems use a risk score
rather than a binary yes/no, routing borderline transactions to additional
verification (a text message confirmation, a manual review) instead of an
outright block — reducing customer friction while still catching high-risk cases.

A simple example walkthrough

A customer who normally spends $50-$150 per transaction in their home city
suddenly has a $2,000 transaction from a country they've never shopped in,
at 3 a.m. local time, on a new device. No single feature here is
automatically fraud — large purchases, travel, and new devices all happen
legitimately. But the combination, scored against the customer's typical
pattern, produces a high risk score, and the transaction gets flagged for
extra verification rather than an automatic block.

The bottom line

Fraud detection works best as a layered system: supervised models catch
known fraud patterns with high accuracy, unsupervised models catch novel
patterns supervised models haven't seen yet, and a risk-scoring layer on top
decides whether to block, allow, or verify — balancing fraud prevention
against the cost of frustrating legitimate customers.

Supervised vs. Unsupervised Machine Learning: How to Choose the Right Approach

lisamangnani1122-sketch — Sat, 20 Jun 2026 00:24:28 +0000

Supervised vs. Unsupervised Machine Learning: How to Choose the Right Approach

Supervised learning trains a model on data that's already labeled with the
correct answer, so it learns to predict outcomes for new, unseen examples.
Unsupervised learning works on unlabeled data and finds patterns or groupings
on its own, without being told what the "right answer" looks like. Use
supervised learning when you have historical examples of the outcome you
want to predict; use unsupervised learning when you're trying to discover
structure in data you don't yet understand.

That's the short version. Here's what it actually means in practice, and how
to know which one your project needs.

What is supervised learning?

In supervised learning, every training example comes with a label — the
"correct answer" the model is trying to learn to predict. Feed a model
thousands of emails, each tagged "spam" or "not spam," and it learns the
patterns that separate the two. Once trained, it can label emails it's never
seen before.

The defining trait: you already know the outcome for your training data.
You're not asking the model to discover something new — you're asking it to
learn a pattern well enough to apply it to fresh cases.

Common supervised tasks:

Classification — sorting things into categories (spam vs. not spam, fraudulent vs. legitimate transaction)
Regression — predicting a number (home price, next month's revenue)

What is unsupervised learning?

Unsupervised learning gets raw, unlabeled data and is asked to find
structure in it — without anyone telling it what to look for. There's no
"correct answer" to check against during training.

The defining trait: you don't know the outcome in advance — you're trying
to find it. A retailer might feed customer purchase histories into an
unsupervised model not because they have a label called "customer segment"
already assigned, but because they want the model to discover natural
groupings on its own.

Common unsupervised tasks:

Clustering — grouping similar data points together (customer segments, document topics)
Dimensionality reduction — compressing many variables into fewer ones while preserving the important patterns
Anomaly detection — flagging data points that don't fit the normal pattern

Key differences at a glance

	Supervised	Unsupervised
Training data	Labeled	Unlabeled
Goal	Predict a known outcome	Discover unknown structure
Output	A specific prediction (category or number)	Groupings, patterns, or anomaly scores
Evaluation	Compare predictions to known correct answers	Harder — no ground truth to check against
Example	Predicting if a transaction is fraudulent	Segmenting customers by behavior

When to use supervised learning

Reach for supervised learning when:

You have historical data where the outcome is already known (past transactions already labeled fraud/not-fraud, past loan applications already labeled default/repaid)
The task is a clear prediction problem — you want a specific output for each new input
You can collect enough labeled examples to train on (labeling is often the expensive, manual part of this approach)

When to use unsupervised learning

Reach for unsupervised learning when:

You don't have labels, and getting them would be expensive or impossible at scale
You're exploring data to understand it before deciding what to predict
You're looking for outliers or anomalies you can't define in advance — you don't always know what "unusual" looks like until the model surfaces it

A quick decision framework

Ask one question first: do I already know the answer for my historical
data?

Yes, and I want to predict that same answer for new cases → supervised
No, I'm trying to find patterns I don't yet understand → unsupervised
I have some labels but not enough to fully train on → look into semi-supervised approaches, which blend both (worth a separate deep-dive, but good to know it exists)

Common algorithms in each category

You don't need to memorize these to make the right choice, but it helps to
recognize them:

Supervised: linear and logistic regression, decision trees, random
forests, gradient-boosted trees, support vector machines, neural networks
trained on labeled data.

Unsupervised: k-means clustering, hierarchical clustering, principal
component analysis (PCA), DBSCAN, autoencoders.

The bottom line

The choice isn't really about which technique is "better" — they solve
different problems. If your historical data already tells you the right
answer and you want to predict that answer going forward, you're in
supervised territory. If you're trying to make sense of data where no one's
defined the right answer yet, unsupervised learning is the starting point.
Many real systems end up using both: an unsupervised step to understand or
clean the data, followed by a supervised model trained for the actual
prediction task.