The life cycle of a ticket is full of adventures, led by our developers, Project Managers and Quality Assurance. Here's our work flow told in the story of a ticket.
The word “ticket” is on everyone’s lips at Netguru. Why? In Pivotal Tracker, a ticket lets us follow the workflow in every project we do! The life cycle of a ticket is full of adventures, led by our developers, Project Managers and Quality Assurance.
Let me tell you a story of a brave and mighty ticket, and its journey from creation to the final phase—deployment.
As you might have discovered in our earlier posts on project management, Pivotal Tracker (aka Pivotal) is our beloved tool of choice when it comes to work coordination. The ticket starts its journey at team members’ fingers. Anyone (i.e. project managers, developers, QA) can start one, either on the client or Netguru side.
Let’s follow the journey of a ticket creation. What happens next?
Apparently, everybody has their own version of events.
Before I start working on my tasks, I need to estimate the ticket workflow: include all features, predicted timing per task, possible bugs, etc. For this stage, it’s crucial to plan automatic test writing and keep in mind that it might take a significant amount of my working time.
There’s one more thing I need to do before clicking Start in Pivotal; I check whether all the ticket information is clear. If anything seems vague and makes me feel lost in space, I can ask the ticket owner to add any necessary tips to the very same ticket. Keeping everyone up-to-date with ticket specifics lets us avoid a huge load of chaos!
After the estimation, I click Start and the ticket begins its journey!
Once I complete my task, the job is not over yet. I need to write tests for each task. We must be make 100% sure everything is working fine. Only afterwards can I click Finish in Pivotal.
Next chapter - Finish and code review
It’s time to push the edits to staging. I can click Deliver only when the staging is built and my changes are visible there. At this point, my delivered tickets need to be checked by QA or another developer (for technical tasks impossible to test on staging, I mark them with no_qa label).
In the meantime, all my commits go through code review, which means that we trade tickets to other developers for a fresh pair of objective eyes. My fellow developers check whether anything could have been done better—we’re all just humans and we make mistakes.
There are three types of feedback I can receive: accept (great job!), pass (it’s OK, but it needs a little polishing, work on it for 2 more days) and reject (sorry dude, do it again). I apply fixes to the code where necessary, according to the feedback I received.
Task delivered. Now it’s up to you, QA!
[to be continued...]
As a QA team member, I test all tickets marked as Delivered. Depending on the result, I can accept or reject them. If I have to reject a ticket (with a tear in my eye, of course), I always leave a comment for the developer to let him or her know what went wrong. Otherwise, I can expect zombie developers hunting me in my dreams, and I certainly don’t want that.
Red or green?
Before I start my work on a ticket, I have a pattern to follow: it’s either me or the client who gives final acceptance to tickets. If the client must accept, and I finished the ticket test with positive results, I leave a note that the ticket was tested and can be accepted (e.g. by adding a
qa_acc label - see the pic below), but I don’t accept the ticket myself! The thing with rejections works in a slightly different pattern - I can reject a ticket anytime I find something to be fixed. Rejections stay just between me and the developer!
Some tickets are left with a
no_qa label, which means I don’t test them. It’s a sign for me that the developer asked a colleague for final acceptance or rejection. When I don’t see any test attached to the bug, or there is no explanation for why the tests weren’t submitted, I reject it by principle. Nothing gets away under the sharp QA eye!
As a developer, I await good news from QA, but it’s not always the case. If the ticket was rejected, I need to restart and follow the regular schedule I mentioned before—do the task, test it after finish, put it through code review and let QA check it one more time. Being a developer requires the modesty and humility of a Tibetan monk sometimes.
Let’s do another round, ticket!
When I finally see the
accepted tag next to my task, I move on to another task in the iteration (hello, tickets, did you miss me?). After collecting a good number of tickets, we get ready to update the Production site. 3, 2, 1… Blast off! Or, should I say: deployment!
Farewell, ticket! See you on prod!
We got to the point where our brave ticket ends its race towards success. Don’t worry, the story continues; you could even say it’s neverending. Dozens of tickets for different clients are awaiting care at any moment.
And this is how we do tickets at Netguru!
Credits (in alphabetical order):
Mobile Developers Team
Project Management Team
Quality Assurance Team
Web Developers Team
Now that you know the ticket's role in our work flow, meet our QA team - one of the members, Marta Męczekalska, shared her views on how to make QA happy and efficient. Also - thank you for the concept of this post, Marta! You rock :)