41 skills.
Use when asked to design or automate an A/B test — random traffic allocation, statistical significance, and multivariate testing — as distinct from black/white-box testing technique (see black-box-testing, white-box-testing) or UI/UX evaluation broadly (see ui-ux-testing).
Use when asked to write or run acceptance tests — verifying software meets client/user requirements before release — as distinct from behavior-driven Given/When/Then scenarios (see behavior-driven-development) or lower-level integration/system testing (see integration-testing, system-testing).
Use when asked to test whether a website or application is usable by people with disabilities — WCAG/ADA compliance, automated scanning, and manual/user testing — as distinct from screen-reader-specific verification (see screen-reader-testing) or general usability testing (see usability-testing).
Use when asked to compare a system's performance against a standard or reference point — benchmarking methodology and pitfalls — as distinct from the specific load/stress/performance techniques it often composes (see load-testing, stress-testing, performance-testing).
Use when asked to test software from the outside, based only on specifications and inputs/outputs, without knowledge of internal code — equivalence partitioning, boundary value analysis, decision tables — as distinct from white-box testing (see white-box-testing), which requires internal code knowledge.
Use when asked to test the edges of an input range or operational limit — minimum/maximum values, off-by-one errors — a specific black-box technique (see black-box-testing) worth its own focus because defects cluster at boundaries.
Use when asked about record-and-replay test tooling — recording user interactions to generate automated regression tests — as distinct from writing BDD scenarios by hand (see behavior-driven-development), which capture/playback tools can also help automate.
Use when asked to deliberately inject failure into a system to test resilience — chaos engineering, fault injection — as distinct from disaster-recovery testing (see disaster-recovery-testing), which validates a specific recovery procedure rather than exploring unknown failure modes.
Use when asked to test a CLI tool — command syntax, exit codes, stdout/stderr validation, cross-platform behavior — as distinct from terminal UI testing (see terminal-user-interface-testing), which covers interactive, layout-based terminal applications rather than single-invocation commands.
Use when asked to test whether software adheres to regulatory or policy standards (HIPAA, PCI-DSS, GDPR, SOX) — as distinct from security testing broadly (see security-testing), which compliance testing draws on but is scoped specifically to named external requirements.
Use when asked to test moving a database between environments, versions, or platforms — data integrity validation, rollback testing — as distinct from testing schema changes specifically (see database-schema-migration-testing), which is a narrower, structure-focused case.
Use when asked to test a database schema change (adding a column, renaming a table, altering a constraint) — forward-migration correctness, rollback/reversibility, and data-integrity preservation — as distinct from broader environment-to-environment database migration (see database-migration-testing).
Use when asked to verify that a codebase actually reflects a recorded architectural decision (an ADR/DR) — reviewing a decision record for testability, or checking code/CI for drift from a decision already made — as distinct from writing the decision record itself (see architecture-decision-record, decision-records).
Use when asked to test backup restoration, failover, and business-continuity recovery procedures — recovery time/point objectives (RTO/RPO) — as distinct from chaos testing (see chaos-testing), which explores unknown failure modes broadly rather than validating one defined recovery plan.
Use when asked to test a full application flow from a real user's perspective — as distinct from unit testing (see unit-testing) or integration testing (see integration-testing), which end-to-end testing sits above, exercising the whole system together rather than isolated units or component pairs.
Use when asked to test automatic switchover to a backup component, server, or network on primary failure — as a specific slice of chaos testing (see chaos-testing) and disaster recovery testing (see disaster-recovery-testing) focused specifically on redundancy activation.
Use when asked about testing software in real-world production environments rather than controlled lab conditions — real hardware, real networks, real usage patterns — as distinct from the controlled, staged environments most other testing types (unit, integration, system) run in.
Use when asked to write an architectural fitness function — an automated, ongoing check that a codebase's structure keeps meeting a specific architectural characteristic (dependency direction, cyclomatic complexity, coupling) — as distinct from a one-off architecture review or a functional/unit test verifying business behavior.
Use when asked to verify that an application's features work as specified — as the general discipline underlying more specific techniques (black-box testing, acceptance testing, UI automation) — as distinct from non-functional testing of quality attributes like performance or security (see performance-testing, security-testing).
Use when asked to fuzz an application — feeding invalid, unexpected, or random inputs to discover crashes and security vulnerabilities — coverage-guided, grammar-based, and mutation-based fuzzing, as distinct from boundary testing's targeted edge-value approach (see boundary-testing).
Use when asked to test the interaction between modules/components — big-bang, top-down, bottom-up, or hybrid integration strategies — as the layer between unit testing (see unit-testing) and system/end-to-end testing (see system-testing, end-to-end-testing).
Use when asked to test how an application performs under expected and peak user load — capacity limits, breaking points — as distinct from stress testing beyond normal capacity (see stress-testing) or sudden-spike testing (see peak-testing), which load testing's staged progression leads into.
Use when asked to test whether software has been correctly adapted for a specific language/region — UI layout with translated text, locale-specific formats, cultural appropriateness, legal compliance — as the verification counterpart to internationalization implementation (see locale).
Use when asked to test a system using randomly-sampled inputs drawn from defined probability distributions to estimate reliability statistically — as distinct from fuzz testing (see fuzz-testing), which searches for specific crashing inputs rather than estimating overall statistical reliability.
Use when asked to measure whether a test suite can actually detect faults — mutation score, killed vs. surviving mutants — as a more rigorous alternative to code coverage percentage, and a companion to test-driven development (see test-driven-development).
Use when asked to test system behavior during predictable high-traffic periods (peak business hours, seasonal spikes) — as distinct from stress testing beyond normal capacity generally (see stress-testing) or sudden unpredictable spikes specifically, which peak testing's predictable-timing focus differs from.
Use when asked to simulate an attack on a system to find security vulnerabilities — reconnaissance, scanning, exploitation, reporting — black-box vs. white-box approaches, as one specific security-testing technique among others (see security-testing). Requires proper authorization — never simulate an attack against a system without explicit permission.
Use when asked to measure application responsiveness and resource use under workload — the umbrella covering load, stress, endurance, and spike testing (see load-testing, stress-testing) — to identify bottlenecks and confirm the system meets performance requirements.
Use when asked to verify that a change hasn't broken existing functionality — test-case selection, defect reporting/resolution, retesting — the discipline that makes safe, frequent releases possible, closely tied to test-driven development's refactor-safety guarantee (see test-driven-development).
Use when asked to test a website/application with an actual screen reader (JAWS, NVDA, VoiceOver) — element announcement, keyboard navigation, multimedia accessibility — as the most specific verification layer within accessibility testing broadly (see accessibility-testing).
Use when asked to evaluate a system's security — vulnerability scanning, authentication/authorization testing, encryption verification, security configuration review — the umbrella discipline penetration testing (see penetration-testing) and compliance testing (see compliance-testing) both sit within.
Use when asked to move testing earlier in the development lifecycle — code review, static analysis, and testing-as-you-write rather than testing-after-the-fact — the strategic principle underlying test-driven development (see test-driven-development) and CI-integrated quality gates broadly.
Use when asked to compare two or more variations of a design/interface to see which performs better — the general step-by-step process (goal, variation, random allocation, data collection, analysis) shared with A/B testing (see a-b-testing), applied to UI/UX design decisions specifically.
Use when asked to test a system under extreme conditions beyond its normal capacity — finding the breaking point and recovery behavior — as one specific variant within performance testing broadly (see performance-testing), distinct from load testing at expected capacity (see load-testing).
Use when asked to evaluate an entire integrated system as a whole — combining functional, performance, security, usability, compatibility, and regression checks — as the whole-system layer between integration testing (see integration-testing) and acceptance testing (see acceptance-testing).
Use when asked to test an interactive, screen-drawing terminal application (ncurses-style, with grid/row/column layout) — simulated keystrokes, screen-scraping, escape-sequence handling — as distinct from single-invocation CLI testing (see command-line-interface-testing).
Use when asked to evaluate a user interface's usability and user satisfaction — user testing, split testing, surveys, heatmaps, eye-tracking, expert review — as a set of techniques distinct from, but overlapping with, usability testing specifically (see usability-testing) and user-centred design methodology broadly (see user-centred-design).
Use when asked to write a unit test — isolating the smallest testable part of an application (a function, method, class) and verifying it independently — the foundational layer below integration testing (see integration-testing) and the layer test-driven development operates at (see test-driven-development).
Use when asked to run a usability test — observing real users attempting real tasks to find friction points — the core user-research method within UI/UX testing (see ui-ux-testing) and user-centred design (see user-centred-design).
Use when asked to catch unintended UI appearance changes — screenshot-baseline comparison, pixel/DOM/AI-based diffing — as distinct from functional testing (see functional-testing), which validates behavior rather than appearance, and complementary to it.
Use when asked to test software using knowledge of its internal code — statement/branch/path coverage, static and dynamic analysis — as distinct from black-box testing (see black-box-testing), which tests only inputs/outputs without code knowledge.