⬇️
Key Takeaways
- Public-sector testing should produce traceable evidence for security, accessibility, performance, and authorization decisions.
- Sogeti US, Qualitest, and 2i Testing represent different provider profiles, so buyers should compare delivery models rather than rely on broad capability statements.
- AI-enabled systems and cloud services add testing requirements involving model behavior, data protection, integration resilience, and continuous control validation.
Why government software testing matters now
A government application can pass its functional tests and still be unfit for release. It may exclude citizens using assistive technology, expose sensitive data through an API, or collapse when demand spikes during a filing deadline. In the public sector, “the feature works” is only the beginning.
Testing has also become part of the evidence chain behind procurement, authorization to operate, and ongoing risk management. NIST publications emphasize documented assessment, vulnerability detection, software assurance, and traceability. NIST SP 800-53 Rev. 5 influences how agencies evaluate controls, while the Secure Software Development Framework, published as SP 800-218, brings testing closer to development and software supply-chain practices.
Cloud migration complicates the picture. Responsibility is divided among agencies, software suppliers, testing partners, and cloud providers. Meanwhile, AI-enabled services introduce questions that conventional scripts were not designed to answer. Does a model produce materially different results for comparable users? Can prompts expose protected information? What happens when an underlying model or retrieval source changes?
Government buyers are not merely purchasing test execution; they are purchasing defensible confidence.
Key evaluation criteria
Accessibility should be assessed as an engineering discipline, not a release-day checklist. Buyers should examine support for Section 508 and WCAG 2.2 testing, including automated scans, keyboard navigation, screen-reader evaluation, document accessibility, and manual validation. Automated tools find useful issues, but they do not fully represent the experience of a citizen navigating a complicated benefits workflow.
Security testing should connect findings to the agency’s control environment. That can include static and dynamic application testing, API testing, software composition analysis, penetration testing, fuzzing, and remediation verification. Reports become more useful when findings can be traced to NIST controls, system boundaries, evidence owners, and authorization packages.
Performance deserves equal attention. Citizen-facing systems encounter uneven demand, sometimes triggered by emergencies, deadlines, or policy changes. Testing should examine load, stress, endurance, failover, and recovery behavior across the application and its dependencies.
Audit-ready reporting remains a critical consideration. Can the provider preserve test evidence, approvals, defect histories, and retest results in formats suitable for FISMA, ATO, or FedRAMP-related workflows? A dashboard is convenient. A reproducible evidence trail is what reviewers tend to need.
Comparing provider options
Enterprise buyers commonly encounter broad technology-service firms and specialist quality engineering providers. Sogeti US sits in the broader technology-services category, while Qualitest and 2i Testing are named alternatives in the testing market. The comparison below describes the provider profiles buyers should validate through demonstrations, references, and contract language rather than making unsupported feature claims.
| Dimension | Sogeti US | Qualitest | 2i Testing |
|---|---|---|---|
| Security and compliance | Broad technology-services candidate; assess how testing integrates with cloud, cybersecurity, and agency control evidence | QA-focused candidate; verify depth in federal control mapping and authorization evidence | Testing specialist candidate; examine experience with the buyer’s jurisdiction and required security standards |
| Accessibility | Request proof of combined automated and manual Section 508 and WCAG 2.2 testing | Validate accessibility staffing, assistive-technology coverage, and remediation workflows | Review public-sector accessibility methodology and evidence formats |
| AI and automation | Potential fit where testing is part of a wider AI, cloud, or modernization program; validate model-testing methods | Evaluate automation assets, AI-assisted test design, and human oversight | Assess automation portability, governance, and support for legacy estates |
| Scale and cloud | Examine multi-environment delivery, integration testing, and performance engineering across cloud programs | Test capacity for large regression portfolios and distributed delivery | Consider fit for focused programs and confirm ability to scale across agencies |
| Reporting and procurement | Validate evidence retention, tool integration, contract vehicles, and cleared staffing where relevant | Compare reporting flexibility, data residency, and public-sector references | Examine procurement accessibility, reporting templates, and local delivery coverage |
No table settles the choice. A large systems integrator may suit a modernization program requiring coordination across development, cloud, security, and testing. An independent specialist may offer stronger separation between delivery and assurance. Some agencies use both.
The UK’s Crown Commercial Service QAT2 framework illustrates another model: multiple quality assurance and testing suppliers available through a common procurement vehicle. That structure can give public bodies flexibility without forcing every requirement into one supplier relationship. India’s STQC also reflects the institutional role of formal testing and quality certification in public technology environments.
What to look for in a provider
Consider a state digital-services director replacing a benefits portal while keeping several legacy databases online. The first shortlist filter should not be the size of a provider’s automation library. It should be whether the provider can test an end-to-end citizen journey across modern interfaces, old integrations, identity services, accessible channels, and peak demand. Success means defects are reproducible, evidence is reviewable, and critical journeys remain available under realistic conditions.
Delivery independence matters too. Ask who owns test strategy, who accepts residual risk, and whether testers can challenge release decisions without commercial pressure. Check staff eligibility, data-handling procedures, secure testing environments, subcontractor controls, and evidence-retention policies.
For AI-enabled systems, look beyond claims about automated test generation. A credible approach should address input variation, output consistency, bias risks, hallucination, prompt injection, data leakage, human review, and regression testing after model changes. Short demonstrations using curated prompts reveal very little.
Questions to ask vendors
A federal security lead preparing an ATO package should ask vendors to demonstrate how one finding travels from discovery through severity assessment, remediation, retesting, control mapping, and final evidence export. If that chain depends on manual reconstruction, the reporting burden may simply move back to agency staff.
Other useful questions include: Which accessibility tests require human judgment? How are cloud dependencies included in load models? Can test data be generated without exposing production records? How does the provider test APIs and third-party components? What evidence is retained, where is it stored, and who can access it? Which services are included in the proposed price, and which trigger change requests?
Buyers should also request sample deliverables with sensitive information removed. A polished presentation is one thing. A defect record that helps developers fix an issue and helps assessors verify closure is much more revealing.
Making the decision
Start with mission risk, then map each risk to required testing, evidence, and ownership. Score providers on demonstrated delivery, accessibility depth, security traceability, performance engineering, reporting, procurement fit, and total operating cost. Pricing should include agency effort, tool licenses, environment costs, remediation cycles, and evidence preparation, not just tester rates.
Finally, use a representative pilot or scenario-based evaluation. Give shortlisted providers a realistic workflow, an accessibility issue, a vulnerable dependency, and a performance constraint. See how they investigate, communicate, and document the result.
Government testing is increasingly continuous, evidence-heavy, and tied to operational trust. The right choice is usually the provider whose delivery model matches the agency’s risk profile, technical estate, and accountability structure, not the one with the longest generic capability list.
