Software Release Flow : Stages of Development Sprint Cycle
By Jash Unadkat, Technical Content Writer at BrowserStack - June 16, 2020
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. This significantly improves the What is Code Coverage.
What is Version Control?
A Version Control system allows a programmer to keep track of modifications in software projects. It also allows multiple programmers to collaborate on those projects. Using this, the developers can work together on a specific codebase. They can also split their tasks through branches.
There are many Version Control systems available in the market. The most popular ones are listed below:
- Apache Subversion
- AWS Codecommit
- Microsoft Team Foundation Server
- CVS Version Control
IDE (Integrated Development Environment)
IDE is a software tool that provides comprehensive facilities to programmers for software development. Normally, an IDE has at least a source code editor, build automation tools, and a debugger.
Depending on the application being developed and the programming language, developers may prefer to use a specific IDE. Most often, all developers use the same IDE throughout an organization. Some popular IDEs are listed below:
- Microsoft Visual Studio
- Net Beans
- Code:: Blocks
- Code Lite
- Android Studio
- Sublime Text
Unit Testing Tools
Unit Testing is a type of software testing where individual units or components of the software are tested. The main purpose here is to verify whether each unit performs as expected. A unit is the smallest part of any software to be tested. It usually has only a few lines of code.
Listed below are a few popular Unit Testing tools:
- Quilt HTTP
- HTML Unit
- Simple Test
- ABAP Unit
- Type Mock
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. Listed below are some of the top tools:
- Team City
- GitLab CI
It’s highly recommended for teams to leverage a cloud-based platform like BrowserStack that allows developers and QAs to incorporate popular CI/CD tools like Jenkins, Travis, CircleCI in their test process. Such integrations help in better-streamlining the test cycles.
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.
Metrics and KPIs
Teams or Organizations generally pay attention to the following metrics:
- Faster Build Times (engineering / QA leadership)
- Increased Innovation (product & CEO)
- Developer Minutes Saved (Engg and QA)
- Faster Release Cycles (product & Engg leadership)
- Increased Coverage (engineering & product leadership)
- Reduction of lost revenue AND better engagement/reviews/NPS (product & CEO)
- Higher quality with speed (Engg & prod leadership)
- Saving Money going from in-house to cloud vendor (CTO/CIO or Eng)
In the absence of an on-premise device lab, a cloud-based platform can be an effective alternative for test infrastructure. Additionally, the platform should be capable enough to support the efforts and activities of teams of any size without compromising speed or accuracy of results.
Here’s where BrowserStack’s Live for Large Teams enables the QA team to add multiple members to a plan as required. In fact, teams can add unlimited members to their planks. Each QA can run uninterrupted concurrent tests on 2000+ real browsers and the latest devices(Android, iOS, Windows, Mac). Live for Large Teams also makes team management effortless with in-built facilities to create sub-teams, allocate licenses, and enforce access control across teams.
With the rapid advancements in technologies and evolving requirements for a software product, an agile approach proves to be the most effective methodology for faster release. The agile approach helps teams to adapt to rapidly changing environments which makes them more flexible to work.
The stages explained above form the basic structure of the agile sprint cycle. Incorporating this helps teams to streamline their test cycles more efficiently.