Quality Assurance Process

QA for this project

In order to ensure quality of our product without interrupting agility and speed in the development process, the DOL 14c team (TTS, vendor, WHD, DOL) will implement the following process below. The goal of this process is to perform the right sized amount and type of testing in a quick and agile fashion. The process below describes the following types of tests that may occur throughout the implementation:

1. Unit Testing
2. Automated Functional Testing
3. Regression Testing
4. Accessibility Testing
5. Manual Functional Testing
6. Performance Testing

---

Process Breakdown

1. Accessibility Assessment on Application Baseline
   -- Perform assessment with Pally chrome extension and enter any findings in product backlog as user stories. This assessment will be done after Brendan has finished updating AngularJS pages with 508 fixes which are currently underway. Assessment must note the existence of a 508 test page that provides patterns for developing new pages/components that are 508 compliant. Assessment must include Brendan's input/observations.
2. User Story (Grooming and Planning Sessions to finalize)
   -- QA section in Markdown template
   -- QA section breakdown within User Story
   --- What are the primary steps/actions that should happen to test this story against its AC?
   --- what tests and types of tests are necessary for this Story? --- Boundary Conditions on testing/positive-negative outcomes
   --- How does this Story potentially break existing functionality (business, security, etc.) --- Add markup to address accessibility within QA effort for user story
   ---- Add at a minimum starter: perform keyboard test and screen reader test
3. Dev/Test Session
   -- Done when picking up stories post planning before dev work
   -- Go through dev/test boundaries and think through conditions and possible issues
4. Sprint Testing
   -- Code coverage SLAs for front-end/back-end
   -- Accessibility testing on build w/ pall.y
5. Usability Testing
6. Just-in-Time Functional Testing
   -- PR to TTS from vendor, when code complete
   -- On approval and merge, notifications sent to Slack Channel/email
   -- Notification sent to testing group (WHD testers, vendors testers)
7. Targeted Testing
   -- Regression tests
   -- Automation Tests -- These test requirements will be identified on a per User Story basis based on priority, complexity and context of the story
8. Performance Testing
   -- The 14c Team will identify the performance benchmarks to be achieved for the project.
   -- Refer to 14C technical requirements document for performance benchmarks. These include development guidelines for Single user performance, IIS compression, browser caching, and other requirements. -- These standards will be documented here in this wiki and will be implemented as a base part of continual testing done at a frequency determined by the team.