Types of Software Testing

Start simple: sorting your toy box

Some toys need batteries (interactive features). Others must survive outdoor mud (durability). Sorting by job to be done mirrors testing: different question → different technique. Categories overlap—just like a remote-control car is both “motorised” and “outdoor-safe.”

Functional vs non-functional

Functional testing asks, “Does the feature do what users expect?” Example: transferring money updates balances and writes an audit row.

Non-functional testing asks, “How well does it behave under quality attributes?”—speed, reliability, usability, security resilience. Example: same transfer completes within 800 ms at peak load while masking PAN digits in logs.

Manual vs automation

Manual testing relies on humans steering scenarios—great for UX nuance, exploratory missions, and volatile prototypes.

Automation executes scripted checks via frameworks—ideal for regression, APIs with stable contracts, and data-heavy combinations humans cannot repeat flawlessly.

Reality check: automation still demands human design, maintenance, and interpretation—robots do not invent intent.

Static vs dynamic testing

Static examines artefacts without running the program—reviews, walkthroughs, linters reading source. Example: architects spot a missing index before deployment stress tests fail.

Dynamic executes software with inputs and observes outputs/logs. Example: chaos experiments terminate pods to validate retry budgets.

Testing related to change frequency

• Regression: ensures new commits did not break old behaviour—often a blended automated manual suite.
• Confirmation / retesting: verifies a specific bug fix actually works.
• Smoke / sanity: fast slices validating critical paths after builds or deployments (exact scopes vary by team jargon—Difference lessons unpack nuances later).

Worked example: mapping types for a checkout API

Expert framing: portfolios, not tribal badges

Mature programmes maintain capability maps linking business risks to testing types, tooling, and skill assignments. Instead of debating whether “API testing is functional or integration,” focus on evidence: what unknown does this suite reduce, under what assumptions, and how frequently must we refresh it as architecture evolves?

Takeaways

• Use buckets to communicate quickly; combine techniques when risks span categories.
• Static plus dynamic testing catches different defect families—skipping reviews cannot be rescued by late scripts alone.
• Automation scales repetition; humans interpret ambiguity—budget for both.