diff --git a/.github/ISSUE_TEMPLATE/QA_Test_Plan.md b/.github/ISSUE_TEMPLATE/QA_Test_Plan.md
index ebf208888df..4a8b7c13762 100644
--- a/.github/ISSUE_TEMPLATE/QA_Test_Plan.md
+++ b/.github/ISSUE_TEMPLATE/QA_Test_Plan.md
@@ -6,7 +6,7 @@ labels: qa
 assignees: ''
 ---
 
-
+<!-- Ticket creator to fill out: -->  
 ## Objective 
 
 The purpose of this ticket is to document the test plan for <!-- List the desired outcome(s) for this ticket -->  
@@ -17,11 +17,24 @@ The purpose of this ticket is to document the test plan for <!-- List the desire
 
 - 
 
+## Known test data:
+<!-- Include information about known test data for QA to use, including staging test users, known variances that will be important to cover, etc) -->  
+
+- 
+
 **Epic(s)**
 <!-- Add link to the feature Epic -->  
 
-## Acceptance Criteria
+## Ticket Checklist
 
+- [ ] Acceptance criteria defined
+- [ ] Labels added (front-end, back-end, feature)
+- [ ] Linked to an Epic
+
+
+<!-- QA to fill out: -->  
+
+## Acceptance Criteria
 <!-- Add a checkbox for each item required to fulfill the user story/issue. -->  
 
 1. - [ ]  Create test plan
@@ -33,9 +46,5 @@ The purpose of this ticket is to document the test plan for <!-- List the desire
 Notes: 
 
 
-## Ticket Checklist
 
-- [ ] Acceptance criteria defined
-- [ ] Labels added (front-end, back-end, feature)
-- [ ] Linked to an Epic
 
diff --git a/VAMobile/documentation/docs/QA/how-we-work.md b/VAMobile/documentation/docs/QA/how-we-work.md
new file mode 100644
index 00000000000..721fd595ed5
--- /dev/null
+++ b/VAMobile/documentation/docs/QA/how-we-work.md
@@ -0,0 +1,26 @@
+---
+title: How we work
+---
+# How we work
+
+The role of QA within a software delivery team is to provide enough details about the software we're delivering, so that stakeholders can make informed decisions (about whether to release, how to prioritize a given bug, etc). 
+
+We typically provide that information by signing off that we've tested the software in question to our satisfaction. Saying "QA approves merging to develop" or "QA approves release" means we believe we've tested the software well.
+
+## When is our testing "good enough"?
+
+Good software testing happens with the keen awareness that it is impossible to "find all the bugs" (limitations in time, resources, tooling, and knowledge; not to mention inevitable changes in data, processes, software, and systems our software integrates with). Therefore, a highly-functional QA team knows when to stop vs continue working on a given task. On our team:
+
+We stop preparing for testing activities when:
+* we are sufficiently aware of how our software and interacting systems can break and what kinds of problems are the most important to find, and
+* we have what we need (tools, data prep, etc) to be able to look for those problems.
+
+We stop testing when:
+* we've examined the product commensurate to the risk it contains,
+* we've met our testing standards, and
+* we've expressed our testing plan and results, along with quality assessments, clearly.
+
+## Common misconception: QA makes the final decision
+QA is one of the last roles, if not the last role, involved in a given ticket; on some teams they are given gatekeeping authority over what software is released.
+
+Within the VA mobile app space, PMs (in conjunction with stakeholders) make the final decision for what goes out the door. That is often explicit (such as new releases or new features) and, on a high-trust team, sometimes implicit (ex: QA stating a ticket meets the PM-set ACs does not need further review before merging into develop)
diff --git a/VAMobile/documentation/docs/QA/working-with-others.md b/VAMobile/documentation/docs/QA/working-with-others.md
new file mode 100644
index 00000000000..794af8d9c81
--- /dev/null
+++ b/VAMobile/documentation/docs/QA/working-with-others.md
@@ -0,0 +1,31 @@
+---
+title: Working with others
+---
+# Working with others
+
+While QA does a lot of our work towards the end of a ticket's lifecycle (testing!), we're involved early and often to help point out problems *before* they're designed or coded problematically, saving cycles and getting us closer to a shippable product as early as possible. Here's where we fit in and what you can expect from us.
+
+## Planning and Design (PM, UX, Content)
+
+| **Involvement** | **How to pull us in** | **Artifacts QA delivers** |
+| --- | --- | --- |
+| High-level design review or feature planning | Included on meeting requests, tagged in Slack/invited to relevant channels | n/a |
+
+## Implementation & PR review (Eng)
+
+| **Involvement** | **How to pull us in** | **Artifacts QA delivers** |
+| --- | --- | --- |
+| High-level review or feature planning | Included on meeting requests, tagged in Slack/invited to relevant channels | n/a |
+| Creation of test plan (features only**) | Ticket created (using [this template](https://github.com/department-of-veterans-affairs/va-mobile-app/blob/develop/.github/ISSUE_TEMPLATE/QA_Test_Plan.md)) and assigned to appropriate QA Engineer | Completed ticket will include: link to TestRail for peer-reviewed test plan and information about any further testing data prep needed from feature team |
+
+**For new feature implementation or other large changes, parallelizing test planning with engineering implementation is the most efficient way to work, to give advance notice if the planned test data is not sufficient for QA needs, and to make sure that QA is ready to jump into testing as soon as Engineering finishes PR review. For bug fixes or other small changes, QA typically will wait until PR review is complete to create a test plan. If unsure if a test plan creation ticket should be created for a particular need, please ask your assigned QA Engineer.
+
+## Testing (QA)
+
+| **Involvement** | **How to pull us in** | **Artifacts QA delivers** |
+| --- | --- | --- |
+| High-level review or feature planning | Included on meeting requests, tagged in Slack/invited to relevant channels | n/a |
+| Manual testing | Engineering implentation tickets assigned to appropriate QA Engineer, after passing PR review | Per-ticket: Completed ticket will include planned & completed testing (comment, or TestRail link, as appropriate). Per-feature: QA Testing Summary. |
+| Automated testing | Engineering detox script addition/updates assigned to appropriate QA Engineer, after passing PR review | PRs or tickets will include QA review |
+
+NB: During testing, towards the end of QA review, the UX team does UX review (visual, interaction, and content review). For details, reference [the UX team documentation on the UX QA process](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/UX/How-We-Work/designing-ui#qa).
\ No newline at end of file