Construction: programming management, documentation and testing

Design is finished, and it is the turn of construction: code is written, tested and documented. This phase is usually the part of the project that needs the most people and time. Here the analyst manages and verifies rather than writing code: making sure the programmers work to the same plan, that the tests are tied to the requirements, and that the right document reaches the user. The final exam brings test levels, the difference between black-box and white-box, and the question “write the test cases for this function”.

Golden rules:

1. Test levels in order: unit → integration → system → acceptance.
2. Black-box from the specification, white-box from the code.
3. Test at the boundary: lower − 1, lower, upper, upper + 1.
4. Every alternate flow is a test case. The descriptions from week 7 are the raw material of the test plan.

Programming management

The project manager’s three jobs in this phase:

1. Assigning tasks to programmers. Modules (packages, classes) are distributed to programmers. Modules that depend heavily on each other are given to the same person or the same small team. As the team grows, the communication load grows (the $n(n-1)/2$ channels of week 3), so “adding people to a late project” doesn’t work.

2. Coordinating activities.

• Weekly meetings, short progress reports.
• Standards: naming, coding, comment rules.
• Code control (source code control / version control): who changed which file, which version was tested. Tools like Git.
• Three environments: development, test, production. Code moves from one environment to the next in a controlled way.

3. Managing the schedule. The work plan is kept up to date and delays are noticed early. Scope creep is controlled in this phase too: new requests come in via a change request.

Classic mistakes:

Documentation

The three types of user documentation:

Pros of online documentation: it is searchable, easy to update, and tied to the screen (context-sensitive help). Documents are written in the user’s language: no technical jargon, task-oriented headings (“Make a class reservation”), short steps.

Testing

The test plan

The test plan starts in analysis. Each test case contains this information:

Test levels

Types of integration testing: User interface testing (each interface function), use scenario testing (a use case end to end), data flow testing (does data flow correctly between modules), system interface testing (data exchange with external systems, e.g. the payment provider).

Integration strategies: Top-down (upper modules first, a stub in place of the lower ones), bottom-up (lower modules first, a driver in place of the upper caller), big bang (all at once; hard to find errors).

Types of system testing: requirements testing (is each requirement met), usability testing, security testing, performance testing (load, stress: the 167 requests/s target of week 12), documentation testing (do the steps in the documents really work).

Black-box and white-box

Equivalence partitioning: Divide the input space into classes expected to behave the same way, and test one value from each class. Boundary value analysis: test below each boundary, the boundary itself, and above it.

Cyclomatic complexity: The number of independent paths in the code.

$V(G) = E - N + 2 \qquad \text{or} \qquad V(G) = \text{number of decisions} + 1$

$E$ is the number of edges and $N$ the number of nodes in the flow graph. At least $V(G)$ test cases are needed for branch coverage.

Worked example: a fine calculation method

A method from the library system. The rule: 2 TL for each day late; staff pay half price; the fine cannot exceed the price of the book; if there is no delay the fine is 0.

static double fine(int daysLate, boolean isStaff, double bookPrice) {
    if (daysLate <= 0) return 0;
    double f = daysLate * 2.0;
    if (isStaff) f = f / 2;
    if (f > bookPrice) f = bookPrice;
    return f;
}

Step 1: Cyclomatic complexity. Three ifs → V(G) = 3 + 1 = 4. At least four independent paths:

Path 1: daysLate <= 0            → return 0
Path 2: >0, not staff, below the cap
Path 3: >0, staff, below the cap
Path 4: >0, not staff, above the cap

Step 2: Black-box classes and boundaries. For daysLate: ≤ 0 (no fine), ≥ 1 (there is a fine). Boundary: 0 and 1. For the fine: below the price, equal to it, above it.

Step 3: The test case table (bookPrice = 100):

When you run them all:

System.out.println("TC1 " + fine(0, false, 100));
System.out.println("TC2 " + fine(5, false, 100));
System.out.println("TC3 " + fine(5, true, 100));
System.out.println("TC4 " + fine(80, false, 100));
System.out.println("TC5 " + fine(1, false, 100));
System.out.println("TC6 " + fine(-3, false, 100));

TC1 0.0
TC2 10.0
TC3 5.0
TC4 100.0
TC5 2.0
TC6 0.0

PITFALL · testing only the “happy path”. TC2 passes on its own and makes the method look “correct”. Most errors show up at the boundaries (TC1, TC5), at the limits (TC4) and with unexpected input (TC6).

TIP · test cases from use cases. Every alternate flow in the Reserve Book description from week 7 (2a, 3a, S-1.2a, S-1.3a, 5a) is a system test case. The normal flow is one too: at least 6 test cases are ready.

Common mistakes

static double fine(int daysLate, boolean isStaff, double bookPrice) {
    if (daysLate <= 0) return 0;
    double f = daysLate * 2.0;
    if (isStaff) f = f / 2;
    if (f > bookPrice) f = bookPrice;
    return f;
}