Performance & Security Testing Basics

Core concepts of performance testing and security testing for QA engineers.

Types of performance testing

Each performance type answers a different question about capacity and stability. Pick the type that matches the risk you are evaluating.

Load — verifies the system behaves correctly under expected traffic.
Stress — pushes beyond normal load to find the breaking point.
Soak — sustains moderate load over hours to expose leaks and degradation.
Spike — tests sudden, dramatic jumps in concurrent users.
Endurance — confirms stability under sustained use over long periods.

Key metrics

Do not judge performance by response time alone. Response time and latency percentiles show the user experience, while throughput shows how many requests the system handles per second.

p50 / p95 / p99 — the latency most, almost all and the worst users experience.
Error rate — percentage of requests failing under load.
Resource usage — CPU, memory, disk and connection saturation.
Saturation — when added load stops producing more throughput.

Tools

k6 writes load tests as code and fits naturally into CI pipelines. JMeter offers a GUI, extensive protocol support and a large legacy ecosystem. Locust drives load from Python-defined user behavior.

Modern teams favor k6 for API-focused performance checks and use Locust when scenarios need complex logic. Whichever you choose, keep the test script in version control alongside the application code.

Building a load test plan

Start from real numbers: typical users, peak concurrency and expected throughput. Define a baseline of normal load, a spike scenario and a stress scenario with the breaking point clearly separated.

Record the environment under test, test data and system resource capacity before running. Reuse realistic payloads, isolate the target system and keep one baseline dataset so every run is comparable.

Security testing basics

Security testing verifies that only authorized users can do authorized things, and that attackers cannot bypass those rules. It includes authentication, authorization, input validation and session management checks.

The OWASP Top 10 is the standard starting point: broken access control, cryptographic failures, injection, insecure design, misconfiguration, vulnerable components, and authentication and integrity failures.

Vulnerabilities testers should check

You do not need to be a penetration tester to find common weaknesses. These are the areas a QA engineer can probe during normal feature testing.

Injection — send SQL, NoSQL and command payloads through input fields.
Authentication — weak passwords, missing brute-force limits, predictable tokens.
Session — test logout invalidation, token expiry and session fixation.
CORS — verify cross-origin policies do not allow untrusted origins to read data.
Rate limiting — confirm login, reset and search endpoints throttle repeated attempts.

Where security testing fits

Security checks belong in every release cycle, not just annual audits. Integrate automated scans into CI, add authentication and authorization cases to the regression suite, and reserve manual penetration tests for major releases.

When you find a security issue, report it like a critical bug with reproduction steps and impact. Do not test destructive payloads on production; use a dedicated, isolated environment.

Related tools: Build load and security payloads with the API Response Viewer, check expected codes with the HTTP Status Reference and review headers with the HTTP Headers Reference. For endpoint checks see REST API Best Practices.