Skip to content

please-test label: how and when to use it #46

@iteles

Description

@iteles

I couldn't figure out whether to put this here or in our https://github.com/dwyl/ateam-master-reference repo, but either way, reference will need to be made to it from https://github.com/dwyl/contributing

There seems to be some confusion at dwyl around how and when to use the please-test label, as well as what it means.

The over-arching process is, once PR is merged:

  • Developer ➡️ Deploy to staging area of project (if not already done automatically)
  • Developer ➡️ Quick manual test to ensure functionality has been deployed correctly as is in fact ready for review by product owner (PO) as nothing is more annoying than being asked to test something that is obviously not working
  • Developer ➡️ If ready to be tested by PO, add please-test label and assign to PO
  • PO ➡️ Test feature
    • If working as expected, close issue
    • If not working as expected:
      • Write description of steps taken to test feature
      • Write description of results, preferably accompanied by screenshot where relevant
      • Remove please-test label
      • Assign back to developer

Process starts again as if a new, high priority issue.

Other points:

  • Only user stories should be moved to please-test and assigned to PO, technical tasks are closed by the developers who opened them.

Metadata

Metadata

Assignees

No one assigned

    Labels

    please-testPlease test the feature in Staging Environment and confirm it's working as expected.priority-2Second highest priority, should be worked on as soon as the Priority-1 issues are finished

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions