🎫

JIRA Ticket Processes

Within Engineering Team
1. Tickets created by Engineering team whenever bugs, tasks, new features etc
decided need to work on.
2. Rules when creating tickets:
• Epics
◦ A big task that requires a lot of efforts that might involved multiple
projects and sprints.
◦ Ticket title/summary : [Epic] - description
◦ Must include the following details:
▪ Clear context or objectives
▪ Clear timeline of items deadline either by sprint or release
• Stories
◦ Smaller tickets that is part of an EPIC.
◦ Ticket title/summary : [Story] - description
◦ Must Include the following whichever applies*:
▪ Clear descriptions of what need to be done.
▪ Product design*
▪ Related EPIC*
• Note : Refer : +3 - Requirements Engineering
• Tasks
◦ Similar to stories but this changes only affect internal team and do not
involve user
◦ Ticket title/summary : [Task] - description
◦ Must Include the following whichever applies*:
▪ Clear descriptions of what need to be done.
▪ Related EPIC*
▪ Product design*
• Bugs
◦ Tickets that specify anything broken within the system or not up to the
requirement.
◦ Title should be negative to show it is not working correctly. e.g. User
unable to log in.
◦ Add label production-bug for bugs found in production environment
1. Example of JIRA ticket creation : [Epic Sample] Fave User Authentication

Jira Ticket Process

skip_tip Process
skip_tip label :

How does a ticket classified as skip_tip :

• tickets that is deem not testable in staging environment.
• tickets that only require updating any field of the item (deals, outlets,
partner)
• tickets that do not change the behaviour of the system e.g. adding specs
//remove
Dev role:
• Code reviewer - responsible to know the scope of the changes
• Code reviewer - identify whether the changes affect the system behaviour (If
yes, dev needs to provide context on testing that they've covered)
 • JIRA ticket must have :
◦ A clear description. (e.g add column, refactor, add gems)
◦ Areas of testing that have been covered (unit or integration level)
◦ Specs link(s)
◦ PR link
QA role:
• Understand the context of the changes/additions needed.
• QA will review the ticket if the ticket provided has a clear context and will
comment the ticket.
• If the ticket is not clear, it is not a blocker to merge it to master. But it is a must
for the reporter/reviewer/developer to update the ticket accordingly for future
reference

Self Test Process

self-test label :
• Ticket example : https://kfit-asia.atlassian.net/browse/FAVE-11708 ,
https://kfit-asia.atlassian.net/browse/FAVE-12844
Guidelines to be followed :
• Product Managers, Developers, Product Designers need to inform QA any
tickets that they want to self-test
• Include information such as test environment, test build and test cases
• Specs must be included in the ticket especially if the ticket is a back end ticket
• Clever tap tickets that is straight forward. Dev to attach screenshot of Clever
tap Page result.
• QA will review the test cases
• Side note : It is important for QA to review and approve by commenting in the
ticket
How do the team navigate BE tickets (no
dependencies to native tickets?)
How do the team navigate FE/native tickets