In 2001, at a ski resort in Utah, seventeen leading figures in the software industry met to talk, ski, unwind and try to find common ground. What emerged was the agile ‘Software Development’ Manifesto. What is the agile methodology exactly and what is so remarkable about it?
Agile is a project management methodology used within software to encourage rapid development and flexible requirements that can change. It promotes in particular:
- Adaptive planning
- Early delivery
- Continuous improvement
Agile’s goal is to go hand in hand with the ever-changing world of the digital realm. The software team works at a very fast pace on product development, taking into account changing requirements throughout the product lifecycle, to avoid the increasing the risk of becoming irrelevant.
Agile minimizes risks of becoming irrelevant by helping teams focus on what they need in order to be successful. How so? For instance, by encouraging to present your work and gather feedback regularly in an infinite loop of feedback cycles.
As a result, 88% of respondents in VersionOne’s 2017 State of Agile Report rated “ability to adapt to change” as the number one benefit of embracing the agile methodology.
While agile is flexible and adaptive, it also requires testers to participate and deliver shippable code faster. Agile operates best on fast pace work, which means there is hardly any time to test everything. All tasks are prioritized and testing automation is used whenever it is possible to ship faster.
To this extent, adaptability is key. Features and requirements can change significantly from one development step to the other. And the final goal is to create code that actually works. This new pace has forced testers to change the way they do testing, how they collaborate with developers and even what tests they conduct. All of this while maintaining high-quality standards.
Every organization is unique and, as such, faces different internal and external factors. To help meet the variety of challenges, several agile methodologies exist. The one you will choose depends on your internal and external factors, needs and goals.
So let’s take a look at what are the most used agile methodologies and its testing methods are!
Scrum
Scrum is one of the most popular agile development methodologies. It is used by 58% of organizations that have embraced agile according to VersionOne. People say that it’s the easiest methodology to transition from the classic waterfall approach.
Waterfall approach is a sequential design process. This means that as each of the eight stages (conception, initiation, analysis, design, construction, testing, implementation, and maintenance) are completed, the developers move on to the next step. As this process is sequential, once a step is completed, developers can’t go back to the previous step. With the waterfall approach, there’s no room for change in requirements. Therefore, in the beginning, you set a project outcome with an extensive plan and then follow it carefully.
Scrum is a requirements-driven approach, but it involves shorter repetitions with a lot of collaboration between team members.
- The product owner creates a prioritized wish list called “a product backlog”.
- During the sprint planning, the team pulls a small chunk of tasks from the top of that wish list, which is called “a sprint backlog”. Then the team decides on how to implement those pieces.
- The team has a certain amount of time — a sprint (usually, 2-4 weeks) — to complete the assigned work, but everyone meets each day to assess its progress (daily Scrum).
- Along the way, the Scrum Master keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
Because of its fast repetitions, Scrum is the best fit for teams whose customers and stakeholders are actively involved in the project management. With Scrum they can regularly observe working products at showcase meetings. This collaboration allows the team to make fast and consistent changes required by the customer.
Kanban
Kanban, as a method, solves production visible and helps to identify bottlenecks. The reason is that it tracks each phase of the process. This visibility enables you to identify which steps in your process are hurting efficiency and provides the tools to drive greater agility and output.
Unlike Scrum, Kanban is not based on time but on priorities. Once a developer is ready for the next task, he or she pulls it from the to-do list. Since there are fewer planning meetings, the team members need to work together closely. For example, if the developer works much faster than the tester, bottlenecks will appear. Therefore, other members have to join the team and help out.
Kanban is incredibly simple but incredibly powerful at the same time. In its simplest incarnation, the Kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top. Cards represent work items as they flow through the development process. While columns represent the development process itself, numbers on the top of each column show the limit of cards allowed.
The limits are the critical difference between a Kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP) prevents overproduction and reveals bottlenecks. Allowing you to address them before they get out of hand.
Example of Kanban
The board below shows a situation where developers and analysts cannot take on more tasks until the testers free up a slot and pull in the next work item. At this point, developers and analysts should be looking at ways they can help each other in order to relieve the burden.
Notice that we’ve split some of the columns in two. This is to indicate items worked on and those finished ready to be pulled by the downstream process. There are several ways you can structure the board. The limits at the top of the split columns cover both the “doing” and “done” tasks. Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.
Now the empty slot in the “Test” column is available for one of the cards in the development “done” column. That frees up a slot under “Development” and the next card you can pull from the “Analysis” column and so on.
Testing Methods
Test Driven Development (TDD)
Test Driven Development is a software development process that relies on the repetition of a very short development cycle. First, the developer writes an (initially failing) automated test case that defines a desired improvement or new function. Later, the product team produces the minimum amount of code to pass that test. Finally, refactors the new code to acceptable standards.
Although there are many potential benefits of aligning with TDD, it’s not for everyone. It is a great fit for flexible firms — the hard-wired agility built into a TDD approach is often too attractive to ignore.
Behavior Driven Development (BDD)
As a subset to Test Driven Development (TDD), Behavior Driven Development (BDD) uses an initial requirement that’s driven by the end-user behavior, rather than a technical test.
As with most development processes, BDD starts with a functional specification. With this process, consolidated specification functions are acting as a guide for the developer, tester, and product owner; based on the behaviours.
The BDD methodology is ideal for teams that put the user experience first and work on feature-focused software.
Acceptance Test Driven Development (ATDD)
Similar to Test Driven Development (TDD), ATDD is an agile approach where tests are designed in advance and code is written to comply with the test, but these tests are more customer-facing acceptance tests than technical unit tests.
If you want customers to purchase your product, the functionality and the end user perception is as important as the features themselves. Empowering customer perception to drive product performance is the thinking behind Acceptance Test Driven Development (ATDD), eliminating the requirements-driven process waterfall. Instead, select customer input up front and concentrate on Acceptance Criteria, which are translated into manual or automated Acceptance Tests.
ATDD suits teams that have goals surrounding high rates of adoption. Teams that are focused on the user experience, and want to minimize the number of feature changes in future releases.
Conclusion
Agile has already made significant inroads into the software development lifecycle. There has never been such sophistication and innovation in the tools available to software teams than there is today. If you can set up your team to use one of the agile methodologies, move with great speed, and improve your software quality at the same time, you’ll be an unstoppable force.
