Agile Development process
How to define your development process and test strategy to run a SCRUM sprint?
I have been working as a test engineer for some years, being part of agile and self organized teams, adopting the SCRUM methodology. We develop new features for software products in production, running 2 weeks sprints, executing all scrum cerimonies such as planning, daily meetings, sprint review and retrospective.
First, lets to talk a little bit about our agile process adopted in the Oceania cell of CESAR. We start with UX designers defining the UX prototype, which are validated with the product owner and showed for the whole team. Then, the user stories and acceptance criteria are defined by test engineers together with UX design.
What are user stories?
Efficient way of specifying requirements that informs by whom and for whom the feature is being developed, guiding the development and allowing the team to make decisions more in line with customer expectations and needs.
How to write user stories?
There is information that must be contained in an user story. We adopt the following format:
- Who? For whom are we developing
- What? Brief description of the feature.
- Why? Why the user needs this feature (the business value gained by this functionality)
For user stories that describe different parts and processes of the same feature or area, must be grouped into epics.
An epic allows a large user story to be broken down into smaller activities and organize them into running sprints and backlog.
Once the user stories are defined, we need to describe the rules that will determine if that user story was satisfied or not, to validate the stories we use Gherkin. It is a technical language that helps to specify the functionality of the product and allows to validate the described behavior, checking if it attends an acceptance criteria.
- Given — a specific context or condition
- When — an action is fulfilled
- Then — a consequence is obtained
So, an acceptance criteria is directly linked to a user story.
As we can see, agile development has several advantages, making possible to focus on features which add business value to the software product as well as getting fast feedback from product owners and users. However, as any real world software project, it is subject to constraints such as time to market and limited resources. Thus, testing activities are also impacted, demanding an optimised testing strategy once it is not possible cover all test scenarios.
Once user stories have been defined, the team needs to decide what to work on and how to prioritize the activities. These decisions are made in sprint planning.
Sprint Planning
The Sprint Planning is an event always held at the beginning of each sprint where the team determines which backlog items will be worked on in the sprint that will start and plan on how to complete them.
The Product Owner (PO) and the technical team participate in the sprint planning meeting. The PO can be a person from the client or they can be represented by a team member as the UX designer, a technical leader or a test engineer.
The PO decides which backlog items he wants to prioritize by assigning criticality levels to stories. Subsequently, this prioritization helps the team to assess the complexity levels of each story and discuss which of these items they are able to deliver through the estimation process.
So, at the end of the meeting, the whole team evaluates the complexity of the selected valuable user stories, using planning poker technique. It is a gamified technique through which the user stories are estimated based on their complexity, a measure for development. Each individual estimate is considered a vote, set by the team. These estimations are based on the entire group’s input and consensus, engaging the team and making this technique more accurante than others. Rounds of voting are carried out assigning story points to each prioritized user story. In each round, a user story is chosen to be voted on, and the team members involved or impacted by that user story vote. For more details about planning poker estimation method, see the article A brief overview of planning poker. In our projects, we conduct online voting with PlanItPoker.
“A story point is a combination of the amount of effort involved in developing a feature, the complexity of that development and the risk contained in it” (Mike Cohn)
At the end of voting, the team calculates the total size of the sprint, based on the sum of the complexity values assigned to each estimated user story.
Sprint vs. Backlog
After all requirements processes performed and Planning activities, the team will create the scrum board in JIRA tool, to guide the sprint activities.
In Jira it is possible to have the macro view of the entire Backlog of the project and have the sprint view with the estimated stories.
Backlog — It’s the to-do list, where all user stories/epics raised without prioritization are found.
Sprint — It’s the package or piece of product, which will be developed during a defined period of time. A Sprint is made up of a set of stories prioritized by the P.O and estimated by the team to be delivered at the end of this defined period of time, which can range from 1 week to 1 month of development.
About Test Strategy
After delivering a first version in production environment, we continue the project adding new features in predefined milestones following a roadmap. Whereas, as more complex features are developed, the existing ones may be impacted causing side effects.
So, the test strategy and branching scheme are two important subjects that help to assure the quality of system that is running in production and to prevent that stable features break due to side effects, avoiding introduction of bugs in the production environment.
The test strategy may consider a sort of test levels and tools, depending on the software context (web, mobile, service, or whatever), as listed here. These tests can be manual or automated, but this is not the focus of this article. I promise to approach that in another moment.
However, the main point here is the design of test scenarios, that are based on the user experience, once the system functions are provided based on a set of user roles (Personas). So, we define end to end (E2E) tests, addressing different personas in a single test scenario. To make it possible (capture the main user flows), some tester abilities, described in the figure below, are very important.
So, it is important to create test suites which can be used to validate hot-fixes or new features as soon as they are released through a tag, in order to execute assertive test cycles (sanity, feature or regression) that make possible validating the acceptance criteria and catch possible side effects.
What About Tags?
Tags are base on semantic versioning. For every new version generated, a tag with the following structure will also be generated:
vX.Y.Z.-ID<.ID>
X — Major — when it presents modifications that are incompatible with the API, or insertion of a new epic.
Y — Minor — insertion of new stories
Z — Patch — bug fix [Must be reset to ZERO whenever the Minor is updated]
ID — ID that references the version type.
<.ID> — Other IDs can be added separated by dots to better specify the version
So the tags are applied according to the adopted branch schema.
The story branch should only be integrated into development if it is considered tested and approved and it uses the version tag vX.Y.Z-alpha. Code in the story branch is ready for testing and functionality evaluation, but it is not considered stable.
The development branch will always have the stable version that is the release candidate and it uses the version tag vX.Y.Z-beta. Beta represents code in a incomplete stage, that not all stories have been integrated, or are not yet approved by the QA team, is considered stable but not yet a release candidate
The master branch will always have the approved and stable version for submission to the stage environment on the client infrastructure and it uses the version tag: vX.Y.Z-rc. Code in the master branch is code ready for homologation, considered stable. Bugs discovered in master branch are considered escaped defects.
So, triggers can be defined in the test pipeline to execute automated tests, but this is not purpose of this article.
So, the main point here is to show that this tag versioning schema does not require the traditional code freeze with a big test cycle. Small cycles are executed as soon as new tags are released, this way hot-fixes, improvements and new features can be validated earlier in the development process, reducing risks and costs. That's why we call it an agile development process.
Who define and run the Test Strategy?
At the very begging of a new software project, the test engineers assigned for that project are responsible for adapting the test strategy and execute it during the whole project life cycle. Here is the test engineering team of the Oceania cell.
Conclusion
The business value of the test strategy allows to increase the assertiveness of test cases as well as a better coverage of users' scenarios. At the same time, we will reduce the side effects, the size of test execution cycles and consequently the effort of test execution. Let's agile testing!
Review
Credits for Vitor Arrais (project manager) and Urbano Chagas (Oceania cell's manager).
