Integration Defects at the Container Terminal
A container terminal is replacing its terminal operating system eight weeks before go-live. Four suppliers provide the terminal operating system, crane control, truck appointment and gate optical-character-recognition systems. Integration testing began five weeks ago; 37 interface defects are open, 11 high severity. The interface control documents disagree on timestamp format, container-ID truncation and message acknowledgement. Each supplier blames another's implementation. There is no end-to-end test environment with production-like latency; the test rig replays recorded messages. The operations director wants to start parallel running in two weeks to protect peak season. The contract makes the terminal integrator responsible for end-to-end performance but does not define integration test entry criteria. One high-severity defect causes a crane to hold a container after a timeout; another causes duplicate gate transactions.
1. Recommend an integration strategy and the immediate actions for the next two weeks.
Read the worked answer
Stop the big-bang path and move to controlled incremental integration. The interface baseline is not stable: three ICDs disagree on basic semantics, and the test rig cannot expose latency-dependent failures such as timeouts and duplicate transactions. Adding parallel running now would move unresolved defects into live operations and make attribution harder.
Immediate actions: assign one interface authority with the power to freeze ICD versions and arbitrate semantics. Re-baseline the three disputed interfaces and publish conformance test cases. Build or borrow an environment with production-like latency and volume, even if scaled. Triage the 11 high-severity defects by operational impact and fix the two named ones first. Run daily defect reviews with all four suppliers present, and record decisions. Sequence integration by operational scenario: gate-in, yard move, crane discharge, gate-out. Set a go/no-go review before parallel running, and tell the operations director what evidence would allow it.
2. Define entry and exit criteria for integration testing and explain how you would prioritise the open defects.
Read the worked answer
Entry criteria: frozen and signed ICDs, a production-like test environment, representative test data, named supplier contacts, agreed defect severity definitions and a scenario-based test plan. Exit criteria: no open high-severity defects; medium defects closed or accepted with an operational workaround and an owner; end-to-end scenarios passed at peak message rates; performance within agreed latency; and a repeatable regression suite.
Prioritise by operational consequence and coupling, not by supplier pressure. The crane-hold defect can stop a vessel; duplicate gate transactions corrupt inventory and billing. Both outrank cosmetic or single-message format issues. Score defects by safety, revenue, data integrity and number of interfaces affected. Any defect that crosses three or more suppliers should be resolved at the interface authority level. Publish the prioritisation so accountability is visible and the terminal integrator can manage the contract.
3. How should verification and validation be distinguished here, and what evidence should support a go-live decision?
Read the worked answer
Verification shows the interfaces and systems were built to the agreed requirements: conformance tests, ICD compliance, message-format checks, latency and volume tests. Validation shows the integrated system supports the terminal's real operations: vessel discharge, gate appointments, exception handling and peak throughput with operators using it.
The go-live evidence pack should include interface verification results against the frozen ICDs, end-to-end validation scenarios run by terminal operators, performance at peak load, open-defect status with workarounds, a fallback plan and a named risk acceptor. If exit criteria are not met, recommend delaying parallel running rather than relying on supplier assurances. The terminal integrator owns end-to-end performance, so the SE lead should state clearly which risks are accepted and which are transferred, and record the decision. Go-live is a validation decision, not a defect-count decision.