Here's an interesting observation: Fortune 500 companies prefer Agile! Agile methodologies are 50% more effective than traditional Waterfall and Iterative approaches. The agile approach has helped 60% of businesses boost their revenue and profits. If it isn’t agile, next-gen businesses aren’t paying attention and can you blame them? In Part 1 of this blog on “The Ultimate Guide to Agile Testing for Modern Software Teams”, we will explore why agile methodologies are soon becoming a primary approach for next-gen businesses and everything you need to know about Agile Testing for Modern Software Teams!
What to Know About Agile Testing?
Agile development takes a test-first approach, rather than the test-at-the-end approach of traditional development.
- Agile testing and coding are done incrementally and interactively, building up each feature until it provides enough value to release to production.
- The main reasons to do agile testing are to save money and time.
- Agile testing relies on regular feedback from the end user.
- It also addresses a common problem many software teams have, which is building the wrong solution because the team misinterprets a feature and aligns what they're seeing with their development expertise, rather than what the requirement says or what the end user wants.
Let’s look at some agile testing strategies for modern software teams
The Agile Testing Life Cycle
What is an agile life cycle? Unlike the Waterfall methodology, Agile Testing is not sequential--or done after a coding phase--but continuous. Continuous Testing is one of several continuous activities that take place simultaneously on most agile projects, including:
- Continuous Build;
- Continuous Integration (CI);
- Continuous Delivery (CD); and
- Continuous Deployment.
Continuous Build or build automation is the first stage in implementing an agile software delivery pipeline. If your developers are practicing test-driven development (TDD), they'll write unit tests for each piece of code they write, even before the code itself is written. An important part of the agile methodology in testing, TDD helps developers think through the desired behavior of each unit of software they're building, including inputs, outputs, and error conditions. New features implemented by developers are then checked into a central code base before the software build, which compiles the source code into binary code.
The role of continuous integration in agile testing is a practice where members of a software development team use a version control system and integrate their work frequently to the same location, such as a master branch. Each change is built and verified using tests and other verifications to detect any integration errors as quickly as possible. With build automation, the software build happens automatically, using tools such as Makefiles or Ant, rather than when a developer manually invokes the compiler.
(Agile Testing Lifecycle)
In the last stage of a CI/CD pipeline, once an application passes all the required tests, it's then released into production. For all intents and purposes, this means releasing every good build to users.
Agile Testing Quadrants
Because Agile is an iterative development methodology, testing and coding are done incrementally and interactively, where features can evolve in response to changing customer requirements. Agile testing covers all types of testing, including unit, functional, load, and performance tests. The following Agile Testing Quadrants diagram is a useful model for cross-functional agile development teams to use to plan and execute testing activities.
Agile expert Lisa Crispin developed these four Agile testing quadrants as a guide for managers and development teams to use to create test strategies. It's important to realize that the Agile Testing Quadrants diagram is simply a model or taxonomy to help teams plan their testing and that there are no hard and fast rules about which tests belong in which quadrant and in which order the different tests need to be done. (For example, it's not necessary to work through the quadrants from Q1 to Q4 in a Waterfall style.)
Let’s look at the comprehensive guide to agile testing quadrants for QA teams mentioned below:
Quadrant Q1
- These are technology-facing tests that guide development, such as Unit tests, API tests, Web Services testing, and Component Tests that improve product design.
- Tests in Q1 are often associated with automated testing and continuous integration.
Quadrant Q2
- These are business-facing tests that guide development, such as those used for Functional Testing, Story Tests, Prototypes, and Simulations that make sure your software products are properly aligned with the business.
- Tests in Q2 are often associated with both automated and manual testing.
Quadrant Q3
- These are business-facing tests used to evaluate or critique the product.
- Q3 covers tests such as exploratory testing, scenario-based testing, usability testing, user acceptance testing, and alpha/beta testing and can involve product demos designed to get feedback from actual users.
- Tests in Q3 are often associated with manual testing.
Quadrant Q4
- These are technology-facing tests used to evaluate or critique the product.
- Q4 covers test such as performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data migration, infrastructure, and recovery testing.
- These tests are often automated.
The clouds at the quadrant corners signify whether tests in that quadrant generally require automation, manual testing, or specialized tools. The division of tests into quadrants allows teams to strategize whether they have the right skills to accomplish each of the different types of testing, or if they have the necessary hardware, software, data, and test environments. It also makes it easier to customize your agile testing process on a project-by-project or skill-by-skill basis. So, for example, if you don't have a tester on your QA team with appropriate load or performance testing skills, it helps you to see the need to bring in a contractor or outsource that particular test. A testing strategy based on the Agile Testing Quadrants requires effective workgroup communication, which is made easier by a test management solution that allows the team to work collaboratively in real-time.
Agile Methodology in Testing
Let’s look at some of the best practices for continuous delivery in agile frameworks. But first, in traditional waterfall testing and development, software developers typically concern themselves with three types of requirements, often addressed at different stages in a software project:
- Business requirements: These describe why the product is being built and identify the benefits both customers and the business will reap
- User requirements: These describe what tasks or business processes a user will be able to perform with the product
- Functional requirements: These describe the specific system behaviors that must be implemented.
In traditional waterfall development, functional requirements often reside in a software requirements specification (SRS) document, which is used by analysts to communicate detailed requirements information to developers, testers, and other project stakeholders.
User stories
- User stories, a less formal approach, are used in agile development to help shift the focus on software projects from writing about software requirements to talking about them.
- User stories are short, simple descriptions of a feature told from the perspective of the person who wants the new capability, usually a user or customer of the system.
- On agile projects, user stories are the smallest units of work done by a development team and usually follow this standard user-story template:
Example:
As a {type of user}, I want {goal} so that I {receive benefit}.
Here's a simple example from a banking website application that illustrates a user story:
“As a bank customer, I want to be able to check my bank account balance in real-time so that I can see if any purchases I'm about to make will result in overdraft charges.”
DevOps continuous delivery
Agile is all about short, flexible development cycles that respond quickly to customer demand.
Since you are effectively building a continuous, two-way DevOps software pipeline between you and your customers with proactive DevOps continuous monitoring, you should have the ideals of Continuous Integration (CI) and Continuous Delivery (CD) in mind from the start as the destination for your digital transformation journey.
- DevOps continuous delivery is a software development strategy that optimizes your delivery process to get high-quality software into the hands of your customers as quickly as possible.
- Scrum and Kanban are currently the two main types of agile process frameworks for doing that.
- For organizations just getting their feet wet with the agile methodology in testing, here are a few differences between the two frameworks.
- Scrum takes a time-boxed, incremental approach to software development and project management by advocating frequent interaction with the business during what is known as Sprints (which are called iterations in other agile frameworks).
- The simplest Scrum project team (as shown in the figure below) is made up of a customer/ business unit stakeholder (known as a Product Owner), the team facilitator (called a ScrumMaster) and the rest of the agile development team.
- Team members interact frequently with business users, write software based on requirements that they pull from a product backlog (a prioritized list of user stories maintained by the Product Owner) that they then integrate frequently with software written by other team members.
(Overview of the Scrum Agile Process Framework)
Scrum projects employ fixed-length sprints, each of which usually lasts from one to four weeks, after which potentially shippable code should be ready to be demonstrated. The notion of releasing a prototype, or minimum viable product (MVP), is also an important best practice in Scrum for getting early feedback from your customers. Once the MVP is released, you're then able to get feedback by tracking usage patterns, which is a way to test a product hypothesis with minimal resources right away. Every release going forward can then be measured for how well it converts into the user behaviors you want the release to achieve. The concept of a baseline MVP product that contains just enough features to solve a specific business problem also reduces wasted engineering hours and a tendency for feature creep or 'gold plating' on agile software teams.
Another Scrum best practice for the ScrumMaster is to organize a workshop with the customer/end-user and the Scrum team so they can create the Product Backlog together. This exercise will allow the Development Team to estimate the implementation effort and the customer to determine the business value (possibly by assigning business value ‘points’), which helps prioritize the Product Backlog without delegating the responsibility entirely to the Product Owner.
Traditional software teams estimate their work effort in a time format such as days, weeks, or months. Many agile teams, however, have transitioned to story points, which are numbers used to measure the relative complexity of a story in terms of risk or effort involved. The Scrum best practice described in the paragraph above can be further refined by an exercise called “planning poker” in which the Development Team will take an item from the backlog, discuss it briefly, and then everyone holds up a card with the number that reflects their estimate. The goal is to help team members reach an agreement on the relative difficulty of different user stories on the Product Backlog.
The Kanban agile process management framework is designed to aid decision-making about what software to produce when to produce it, and how much to produce. Unlike the time-boxed approach that Scrum takes, Kanban is designed around a continuous queue of work, which goes through several stages of development until it's done. Kanban teams usually write their user stories on index cards or sticky notes that are arranged on walls, such as the Kanban Board shown below, to visualize workflow in a left-to-right manner. When work is completed in a stage, it moves into the next-stage column to its right. When someone needs new work to do, they pull it from a left-hand column.
(Kanban Board)
While Scrum relies on fixed time-boxes for estimating and planning, Kanban puts more emphasis on the concept of cadence, or continuous flow, that an agile team establishes by working together and reliably delivering software at a set pace. Kanban emphasize two main best practices. One involves visualizing the flow of work, which requires you to map your team's workflow stages and configure the lanes on your Kanban board to match. Visualizing workflow enables teams to analyze the amount of work on their Kanban board, better understand how they process it, and then ultimately optimize their process by introducing incremental improvements. The second best practice is to constrain the amount of work in progress, which requires you to set work-in-progress (WIP) limits, such as only allowing five items in the In Progress lane on the Kanban board above.
Scrum versus Kanban
Every organization is unique and you should choose an agile methodology in testing that works best within your culture and the skill sets of your development and testing teams, which can be a mix of the best features of both Scrum and Kanban. Introducing Scrum is quite a change for teams not used to agile software development: they have to start working in iterations, build cross-functional teams, appoint a product owner and a Scrum master, as well as introduce regular meetings for iteration planning, daily status updates, and sprint reviews. On the other hand, Kanban is much less structured and has a looser, more free-flowing style. Kanban may be easier for your organization to adopt since it encourages incremental improvements to your existing software delivery process. You can apply Kanban principles to any process you already have in place, even Scrum. Remember that Scrum and Kanban both have sprints.
So that wraps up Part 1 of the ultimate guide to agile testing for modern software teams. To know more, get in touch with our QA experts!