SoT: Testing - Historic Stress Testing of E2E

[jadudm]

Problem

Assuming we have two APIs (API 1.1.0 and API 2.0) that use the SAC and SoT data (respectively), how can we stress-test this?

Initial thinking was that we could use the Census migration tooling to run hundreds or thousands (but not hundreds of thousands) of submissions and make sure that the SAC/SoT pathways are "the same."

How did we discover this problem?

Job Story(s)

When I [situation], I want to [motivation] so I can [outcome/benefit].

What are we planning to do about it?

What are we not planning to do about it?

How will we measure success?

Security Considerations

Required per CM-4.

---

Process checklist

• Has a clear story statement
• Can reasonably be done in a few days (otherwise, split this up!)
• Shepherds have been identified
• UX youexes all the things
• Design designs all the things
• Engineering engineers all the things
• Meets acceptance criteria
• Meets QASP conditions
• Presented in a review
• Includes screenshots or references to artifacts
• Tagged with the sprint where it was finished
• Archived

If there's UI...

• Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order
• Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works.
• Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.