← Enterprise admin

QA Testing Process

Slack Rooms

#team-webdev-qa for any communication about the QA testing process

QA Testing Specific Fields (inside the ENT/WEB project task ticket sidebar)

  • Ready For Test - Set by the developer of the specific project when the specific task is ready to start testing
  • Testing - Set by QA when they start testing
  • Testing is Blocked - Set by QA when testing is blocked

Step-by-step Process

  • [Optional] Any projects that need the QA team, can be marked with a [QA] indicator at the beginning of the title if needed
  • The project will get resourced to a developer on the respective team
    • Enough information should be present by this time, that the dev and the QA member can start communicating as needed for the next items
  • [Optional] The developer creates a project plan doc for the Epic
    • This might vary depending on the developer and how valuable they find a document like this. This would contain the same milestones that you see as task tickets in the Epic
  • The developer creates Task tickets within the projects Epic while the QA team creates their checklist
    • Developer code branches should reference these tickets for the QA team to be able to see the branches name on the ticket
    • Task tickets should encapsulate a chunk of work that can be developed, reviewed, merged and deployed behind a UI feature flag without the rest of the project (if possible). This way, the QA team can review the project as the project is being developed, rather than all at once at the end of the project’s initial lifecycle
    • UI feature flags can encapsulate a whole project or pieces of a project. Whatever the decision is, the UI feature flag and what it enables/disables should be detailed within the project plan if applicable
  • The developer should put up a PR for every milestone in the project plan
  • At any point in the process of developing these tasks, the developer can mark the task ticket as Ready for Test
    • This is done in the testing status section in the Jira task ticket sidebar
    • This automatically indicicates to the QA team that the ticket is now ready for their attention (they have a filter to search for these)
    • The QA person assigned to the Task ticket will be assigned in the Tester field
  • The QA team should do a full review of the Staging deployment log that gets automatically created before the dev team deploys to production
    • They should review any QA projects at this time in their entirety
  • Any bugs found while in staging should have Bug tickets created, by the QA team, within the ENT projects Epic on Jira

Feature Flag Removal

  • Every so often, the respective dev team will need to remove the feature flags. When this happens, the QA team should do a feature flag regression look to ensure we didn’t break anything before going to production.

Special Case Projects (large projects)

There will be special case projects in which we can’t use a feature flag, generally because the project is considered too large. For those cases, a feature branch should be made as the Feature Main for that project OR the respective dev team can consider using multiple feature flags for one project.

  • Each milestone branch off of a feature main branch will still get looked at by QA
  • There should be one final QA review of the main branch before it goes to Master