Create QA issue template and link to template in QA docs

[pjhill]

Per Andrew, it is advisable to create a template for issue creation and link to it from the QA documentation.

[pjhill]

I'm not quite sure where to create a QA bug report template. VFS teams creating a product that exists entirely in the front end might find it most relevant to create the bug report in the vets-website repo; whereas, teams creating new components in the back end might find the vets-api repo to be the most relevant.

Should we avoid creating the bug reports in the repository where the related code is stored entirely? If that is the path that we choose to take then perhaps the va.gov-team repo is the best place for the template.

[pjhill]

Regardless of which repository in which we elect to create bug reports, it will require administrator privileges to create the template in the repo. I'm referencing this guide from GitHub -- GitHub Help Page.

[pjhill]

@andreahewitt-odd Do you have any thoughts about where we might best create and address bug reports from the wide variety of VFS teams?

[tlei123]

@peterhill-oddball, just wanted to put this on your radar for developing whatever checklist(s) you’re planning for the QA Request template (unless this template here is exclusively for VSP)...

For front-end, manual, UI testing of va.gov on Staging, I think it's important to determine in advance the specific test-accounts for all user-flows/-scenarios.

The main challenge for me so far when prepping for manual UI testing on Staging has been finding the test-accounts that have actual test-data behind API endpoints to support QA'ing all user-flows/-scenarios. Unlike local environments where developers use mostly local mocked-data, Staging actually retrieves test-data from the actual API-endpoints. The same test-accounts that work on local for developers often don't work on Staging due to this difference in data-sources.

Having a Staging Test Accounts checklist in our template would give up-front (hopefully advance) visibility to VSA teams to ensure actual Staging test-data are properly set up for QA testing. FYI, I've emailed the VSA teams to give at least 1 sprint’s notice to me when requesting front-end manual UI-testing on Staging (and add a “vsa-qa” label).

Feel free to ping me on Slack as desired, or continue this convo here in the ticket.

Thanks much! :)

[pjhill]

@tlei123 , that's great feedback / input. However, the intention for the template described in this ticket is to create a unified way for VFS teams to track issues encountered as a result of QA activities such as defects, enhancement requests, usability issues, security vulnerabilities, etc.

That said, everything that you've described in as a challenge is important, and it is something that I want to address as well. There's definitely an opportunity for tracking and expanding the description of test user accounts. Mapping test accounts to the data that they have available allows QA personnel to create more thoroughly defined test plans. For example, if I know that User1's location is Kentucky and that User1 has a medical history that includes treatments for cardiac arrest then I can create more precise expected outcomes. I will know that when User1 accesses the Facility Locator's new "smart facility selector" I should expect to have VA facilities in Kentucky that specialize in cardiopulmonary services highlighted.

I think the expansion of those capabilities certainly warrants its own ticket. And, it is something that I would like to work on soon!

[pjhill]

We need to rethink the function and scope of QA related tickets / templates on VSP. It seems like we need at least two function --

1. Test incident
2. QA Review Request