System Testing

What it is

System testing validates a complete, integrated application against its specified requirements — functional and non-functional — as a black box. The whole system under test is assembled and running; testers work from requirements, not from code.

It answers the question: does this release, as a whole, meet its specification? It is the natural home for end-of-cycle verification before user acceptance.

1
  Requirements + design
2
          │
3
          ▼
4
  [ Full system under test ]  ← black box, no internal peeking
5
          │
6
          ▼
7
   Pass / fail against spec

When to use it / when to avoid it

Use it for

End-of-cycle verification against the requirements baseline
Cross-functional checks the system as a whole must satisfy
Release sign-off evidence

Avoid blurring it with neighbours:

Testing one component → component test
Whether the user accepts it → acceptance testing
The full production-like journey → end-to-end testing

System testing is broader than E2E: it covers functional requirements and non-functional expectations (performance, security, recoverability) at the system level.

Frameworks & tools

Tool	Role
Requirement-driven suites (TestRail, Zephyr, Xray)	Trace tests to requirements
Playwright / Cypress / Selenium	Drive the assembled system
Robot Framework	Keyword-driven system/acceptance suites
Postman / Newman / Karate	API-level system checks
k6 / JMeter / Gatling	Non-functional system checks
OWASP ZAP	Security checks at system level
Testcontainers / Docker Compose	Stand up the full topology deterministically

Quick setup

1
# Stand up the whole system, then run the suite against it.
2
docker compose up -d
3
npx playwright test
4
docker compose down -v

1
pip install robotframework robotframework-requests
2
robot --outputdir results tests/system/

1
# Karate runs API + UI system suites from a single runner.
2
mvn test -Dkarate.options="classpath:system"

1
npx playwright test --project=system

Example

1
// REQ-CHECKOUT-04: an out-of-stock item cannot be purchased.
2
test('REQ-CHECKOUT-04 blocks out-of-stock checkout', async ({ page }) => {
3
  await seedInventory({ sku: 'ABC', qty: 0 });
4
  await page.goto('/product/ABC');
5
  await expect(page.getByRole('button', { name: /add to cart/i }))
6
    .toBeDisabled();
7
});

1
*** Test Cases ***
2
REQ-CHECKOUT-04 Het Hang Khong The Mua
3
    [Tags]    system    requirement
4
    Seed Inventory    sku=ABC    qty=0
5
    Go To    ${BASE_URL}/product/ABC
6
    Element Should Be Disabled    css=button.add-to-cart

1
@Test
2
void reqCheckout04_outOfStockIsRejected() {
3
  given().baseUri(baseUrl)
4
    .contentType(JSON)
5
    .body("{\"sku\":\"ABC\"}")
6
  .when().post("/checkout")
7
  .then().statusCode(409);
8
}

Anti-patterns & best practices

Trace every test to a requirement. System testing is evidence against the spec; untraceable tests are noise.
Cover non-functional requirements too, not only features — performance, security, recovery at the system level.
Use a production-like environment. A system test on a toy config proves little.
Automate the regression subset; keep exploratory system testing for humans.
Do not re-prove unit logic here. System tests verify the assembled whole, not branches.