Versions Compared

Old Version 13

changes.mady.by.user Victoria_Smelova

Saved on

compared with

New Version 14

changes.mady.by.user Piotr Kalashuk

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: API Tests notes


Panel
borderColor#B5C6CA
bgColor#EBFAFE

What should I do before I start working on a Story/Bug

  •  Make sure the requirements and acceptance criteria are clearly expressed and there are no unanswered questions
  •  Make sure the estimation in story points is added to a Story/Bug;
    • Note: estimate should be added to a Story/Bug itself and should include the effort of related sub-tasks if any. Estimates should not be added to sub-tasks as they won't be added to Velocity.
  •  Populate Development Team field to indicate the correct team:
    • Stacks
    • EBSCO - FSE
    • Thunderjet
  •  Fill out Tester Assignee field:
  •  Fill out Fix version(s) field:
    • Select Unreleased Fix Version from the dropdown
    • Contact your SM if you are not sure what to select
  •  Make sure the work on a Story/Bug is not blocked/dependent and it conform to the Definition of Ready
  •  Make sure a Story/Bug is added to an active sprint (ACQ Sprint [XX])
  •  Assign a Story/Bug to you
  •  Make sure you have enough time to complete an additional Story/Bug by the end of current sprint before adding it to an active sprint
  •  Move a Story/Bug to In Progress as soon as you start working on it
  •  Ensure that the Story/Bug has links to an appropriate epic, feature, and to any related stories which might provide additional/helpful context.
    • Note: Contact the PO and/or tech lead if you need help choosing an epic/feature
    • Note: It may be acceptable to omit epic/feature links on some bugs, but they should be provided when applicable




Panel
borderColor#B5C6CA
bgColor#EBFAFE

What should I do while working on a Story/Bug

  •  Communicate to the team and PO in case you find out that estimate for the story is not valid any longer and get it updated
    • Note: try to avoid tweaking the original estimate during the sprint as it is considered as scope change
  •  Update the status of a Story/Bug accordingly:
    • In Progress - work in progress
    • Blocked - work is blocked
    • In Code Review - PR is created and code review is in progress
    • In Review - PR is merged and pending deployment
  •  In case a Story/Bug is moved to Blocked status, link corresponding blocker or indicate the reason in comments (if not blocked with some specific story)
  •  @Tag other people in comments if you need some feedback
  •   Add comments in case there was some additional valuable info found out while development or in case there were some important discussions on the appropriate solution - it can help other people to better understand what was done in scope of a Story/Bug.
  •  Make sure PR is available in a Story/Bug and PR description is added
  •  Merge PR when all comments are fixed and there are at least two approves from other developers
  •  Make sure your updates are working as expected on test env



Panel
borderColor#B5C6CA
bgColor#EBFAFE

What should I do before I assign a Story/Bug to PO for review

  •  Make sure the estimation in story points is added to a Story/Bug
  •  Make sure Development Team field is populated
  •  Make sure Tester Assignee field is populated
  •  Make sure Fix version(s) field is filled out
  •  Make sure a Story/Bug is added to an active sprint (ACQ Sprint [XX])
  •  Re-assign a Story/Bug if updates are available for review on test env:




JIRA StatusDescriptionAssignee/Actions
DraftPO is defining the user story. Not ready for the team to review.

Assignee: PO (or Craig for back-end stories)

  • Requirements to be finalized and added to story/bug
  • Story/bug to be updated according to the templates
OpenReady for development team to groom.

Assignee: None

  • Story/bug to be reviewed and discussed on Backlog Grooming
  • Requirements to be clarified
  • Acceptance criteria to be understood
  • Estimation to be added
In ProgressDevelopment is in progress

Assignee: Developer

  • Requirements to be turned into working software
  • Acceptance criteria to be met 
  • Tests to be added/updated to ensure 80% coverage
  • Dev verification to be done
  • Critical defects to be addressed
BlockedDevelopment is blocked

Assignee: Developer

  • Blocker to be linked in JIRA via "is blocked by" (if any)
  • Comment to be added to clarify what the blocker is (in case there is no blocking story)
In Code ReviewPR is done and Code Review is in progress

Assignee: Developer

  • PR to be reviewed by other developers
  • Comments to be addressed
  • At least 2 approves of a PR are required
  • PR to be merged
In ReviewPR is merged and updates are ready for review

Assignee: Developer

Assignee: PO (or Craig for back-end stories)

  • Story/Bug to be checked on http://folio-snapshot-stable.aws.indexdata.com
    • Back-end Story/Bug: the API Tests should be run from master branch or a branch with prepared PR to make sure no regression introduced and new tests meet Acceptance Criteria. If all is okay, the PR is approved and merged to master
  • Story to be closed if requirements are met and it conforms to the definition of done
  • Story to be reassigned back to developer In Progress in case the requirements are not met
  • Additional stories to be created in case additional requirements/updates are identified while review
ClosedStory is accepted by PO and closed

Assignee: PO (or Craig for back-end stories)

  • Updates to be demonstrated on System Demo