GAO TE Report Shows Test Must Move Earlier

The GAO TE report says the quiet part plainly: DoD test policy has not fully caught up to modern product development.

GAO’s December 2025 report, Weapon Systems Testing: DOD Needs to Update Policies to Better Support Modernization Efforts, found that DoD and military department policies do not fully reflect leading practices. GAO made 13 recommendations. The practices include involving testers early, using iterative testing, applying digital twins and digital threads, and obtaining user feedback throughout development.

None of those practices are exotic. They are ordinary engineering hygiene in a software-intensive system. The problem is that they are still easy to violate on real programs.

Testers often arrive after the architecture is locked. By then, the program has already chosen interfaces, data paths, instrumentation, and operational scenarios. If those choices make testing hard, the test team can document the problem but may not be able to change it. Early tester involvement is not bureaucracy. It is a way to design systems that can be proven.

Iterative testing is just as important. A program that waits for a late operational test event is choosing to learn late. Software changes too often for that model. The team needs test evidence throughout development, especially when each increment changes user workflows, cyber posture, or mission data.

Digital twins and digital threads can help, but only when they are tied to evidence. A digital twin that lives in a briefing does not reduce test risk. A digital model connected to requirements, configuration, test results, and known limits can help the team explore conditions that are too costly or unsafe to test live.

User feedback is the other missing loop. Operators know where the mission thread breaks. Maintainers know which workflow will fail at 2 AM. Testers know which evidence will be needed later. If that feedback arrives only near IOC, the program has turned cheap learning into expensive rework.

Policy can require these loops, but engineering makes them usable. The program has to instrument the system, preserve test data, connect defects to requirements, and keep user feedback tied to release decisions. Otherwise the feedback exists in meeting notes and never changes the design.

The report is useful because it connects testing to modernization. New acquisition and delivery approaches depend on faster learning. If test policy remains late and document-heavy, software-intensive programs will keep finding critical information after the architecture is expensive to change.

Polyrhythm exists because senior engineers who treat T&E as a design input rather than a downstream tax are still rare. Test and evaluation should shape interfaces, logging, instrumentation, data rights, and simulator fidelity. It should not be a final checkpoint attached after the design is effectively done.

The GAO TE report is not asking programs to slow down. It is asking them to learn earlier. That requires test planning to sit beside architecture from the start, with users and testers present while design choices are still movable and cheap to adjust. The fix is engineering judgment applied early, not a policy memo applied late.