Task Order in Dev Process

Overview

When the dev team takes a user story or a bug and starts working on it, it's being divided into tasks of different subjects, like coding, test plan, design, verification, etc.

It was clear to my team that the order of the tasks is important. It helps us handle the story from all of its aspects and ensure its completeness, quality and no surprises at the end.

Tasks, by Order

Test Plan

• A descriptive documentation of what to test.
• It's preferred to write the test plan in Gherkin (even if you don't use Cucumber to run it). Keep reading to see the benefits. To ignore tests, since they're not yet implemented, use an ignore tag.
• It's preferred that the one who writes the actual code will write the test plan. This will give the coder also an ownership and responsibility on the quality. You can have a QA engineer review it.

Design

• Show how the development will be approached.
• Show what contracts (APIs) should be added.
• Show what is the flow of the system.
• It's advised to use templates.
• Give the reviewers enough time to go over the design before the review session

Automation

• Developing the Gherkin steps to bring them alive, so that frameworks like Cucumber can run them.
• Strive to make all the Gherkin tests alive, but in some cases we can decide to only run them manually.
• Add plain-code tests as needed. Not everything can or should be expressed with Gherkin.
• Automation is code as any other code and should follow proper code methodologies and guidelines.

Coding

Write the actual code of the feature. Use the design, the test plan and the red tests (from the Automation task) - make them green.

Start this phase by removing the ignore from the tests.

Manual Testing

In case there are no automated tests, we should test now manually.

Tests that we've decided not to automate should still be written in Gherkin and the manual test should be performed according to them.

What's More

Every task from the aforementioned tasks should be reviewed.

A user story (or bug) represents a value to the customer. The scrum team's objective is to deliver as many complete user stories as possible.

Each story is measured by story points, and the team should measure itself by how many story points it can deliver in a sprint.

A complete user story that comes out of a sprint means that it's ready to be shipped to the customer ("potentially shippable").

Therefore it means that the story has no bugs, or has bugs we have intelligently decided to ship ("zero bugs policy").

How do we handle user story and bugs during the sprint?

One of Scrum's principles is "Communication over Documentation" - have the people talk instead of having bugs on the board:

Let the team members decide what works best for them - sometimes they'll decide to have a bug on the board, and sometimes the bug will be fixed right away.

When a bug is fixed, a scenario should be added to the test plan (the Gherkin file) or to the automation code. This way we can make sure the bugs found during the sprint will not return, and that's why documenting them as a work item is less important - they're documented in the Gherkin file as a scenario!

By starting the user stories with writing Gherkin as the first task, we can achieve the following:

• Make sure the team understands the requirement.
• Having an early review by the PO and the PM and make it easy for everyone to read and understand, and make sure the scenarios cover everything.
• The Gherkin files can be used as the behavioral documentation of the story/bug fix.
• The tests can be executed manually or automatically (with Cucumber).
• Make it easier for the developers to develop - they already have the tests ready (Behavior-Driven Development, a form of TDD)
• The user story will get to the testing task more stable and robust
• The testers have sprint-related work at the beginning of the sprint (a known issue in scrum)

Writing a good Gherkin isn't easy - it's an art on its own, but that's something for another article.