Stages of Development Sprint Cycle
Before getting into the details of the test ecosystem, and stages involved in an agile sprint cycle, let’s understand — What is Agile development?
In layman’s terms, Agile is a set of values and principles incorporated as an approach towards iterative development of software. Following this approach helps cross-functional teams to collaborate and come up with solutions for evolving requirements. It also encourages customer feedback at regular intervals so as to verify the alignment of requirements.
Organizations following Agile development methodology for developing software in sprints. Generally, each development sprint is two weeks long, and in a single sprint, the team develops a shippable feature/product.
Now let’s have a closer look at the different stages in the development life cycle carried out in a sprint.
Stages in Development Sprint Cycle
Stage 1: Planning and Development
Before the sprint begins, developers plan and identify the tasks to work on. Then, they set up their Version Control System (if it hasn’t already been set up) and begin the development of one or more features. If a feature requires designing, then it’s task can be considered as a part of the sprint. In most cases, it is considered prior to the sprint.
In this stage, developers use a Version Control system to manage the code and an IDE (Integrated Development Environment) to write the code. Most matured organizations tend to write Unit Tests along with feature development using popular Unit Testing Tools.
Stage 2: Verification and Commit
Once a functionality within the feature is complete, the developer performs a verification of the functionality. Below are two ways they perform this verification. In most cases, they use both methods, though sometimes only one is used.
- Manual verification of the functionality locally using a local browser or handheld device
- Executing a unit test locally
Once their test passes as per specifications, developers commit the code and push them to their repository (feature branch). Generally, feature commits are made once the functionality is complete. Developers may also choose to commit every night, and pull from the repository every morning before beginning to code. If multiple developers are working on the same branch, the latter method is very helpful.
Generally, more mature organizations also tend to run functional tests at every commit. In this case, they trigger a build using CI/CD, which executes unit tests as well as functional tests.
Stage 3: CI Server
If feature development is complete, developers raise a PR (Pull Request) in the feature branch. Once the PR is raised, the CI Server kicks in and performs the following activities:
- Creates a build
- Runs unit test on the feature branch
- Runs a functional test on the feature branch
- Performs Linting (this is mostly performed by matured organizations) to determine whether the code is written in line with their coding standards
PR’s can be raised daily, or it could be a weekly PR depending on the development frequency. If it’s daily, then overnight builds will be executed.
There are various CI Servers available in the market, with Jenkins being the most popular one
Stage 4: Master Merge, Test and Deploy
If the build passes on the feature branch, the code is merged in the master branch. The CI Server again kicks in and performs the following activities:
- Creates a build
- Runs a unit test on the master
- Runs a functional test on the master
Development teams may then choose to perform different tests depending on the type of software. These can include: Regression Testing, UAT (User Acceptance Testing), Compatibility Testing, Performance Testing, Security and Compliance Testing, Interrupt Testing, Load Testing, System tests
Note: Master Merge generally takes place at the end of feature development. This can happen at the end of every sprint when the team is ready to deploy a feature.
Once the build passes all the testing criteria, its deployed in production at the end of the agile sprint lifecycle. Once in the production stage, a sanity test is performed again to validate the system in production.
The stages explained above form the basic structure of the agile sprint cycle. Incorporating this helps teams to streamline their test cycles more efficiently.
