Your company is going Agile. Now everyone talks about frequent and iterative deployments. If you’re a tester or QA person, that can scare you about what your world will look like. Will you be expected to test a codebase that changes daily with no breaks or time to breathe? Alternatively, you’ve heard that some teams do away with QA and testers once they go agile. How will you survive? What is QA’s role in agile?
Fear not, we still need QA in our new agile world. However, instead of the old paradigm, where your goal involves finding defects at the end of a lengthy waterfall project, your new goals include continuously preventing defects and helping ship products faster. And with this guiding principle, you’ll be on your way to creating a robust and healthy QA process.
In this post, we’re going to take a look at what going agile means from a QA perspective and how you can change to thrive in this environment.
Where’s the QA Agile Manifesto?
The Agile Manifesto kicked off the agile movement. But it didn’t seem to include our QA team. Let’s review the values.
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Individuals and interactions over processes and tools
How do these values fit with QA?
When reviewing the values and principles of agile, we don’t see testing addressed as clearly as we’d like. In fact, we’re not even sure if traditional QA has a place. So let’s read between the lines and picture what this means for us.
Working Software Over Comprehensive Documentation
For the first value, we learn that working software is prioritized over comprehensive documentation.
First, your goal shouldn’t be to write extensive test documentation or test cases. Writing and executing manual tests consumes a lot of time and results in errors. We’re humans, not machines!
If your goal includes working software, look for ways of rethinking your approach. This is your opportunity to look into test automation tools that will make your testing more efficient, repeatable, and easier to track.
Now, this value doesn’t mean you can’t have any documentation. It means you should create documentation only if it provides value. If you need documentation for something, then write it.
But don’t spend too much time filling out forms, tickets, or any other unnecessary work. Look for streamlined ways you can execute tests and then clearly communicate the defect to the development team without much overhead. Always look for automation opportunities.
And whatever you do, make sure it drives the result of having working software.
Customer Collaboration Over Contract Negotiation
One of the main focuses of agile includes collaboration.
We should always consider the customer of our application. What level of quality do they expect? And what non-functional requirements (NFR) do they require? Understanding the customer will help you automate the correct tests. Those tests may involve system functionality, but they also may involve speed and other expectations.
Overall, your relationship with your customers should look like a partnership, not a criminal case.
Responding to Change Over Following a Plan
One big concern testers have with frequent software delivery involves keeping up with the testing. Agile involves continuous learning and adjustment. So how do we test a moving target?
First, stop trying to build a plan for a future that might not come true. Instead, work to put in automated tests and guardrails so that you’re able to react quickly to changing priorities and functionality.
Sprinkle in as much automation as you can so that when change happens, you’re ready.
Individuals and Interactions Over Process and Tools
In our old waterfall world, the QA team would get a few weeks prior to release to learn and test all the new functionality. And, as waterfall usually went, those few weeks would shrink from four to three to two weeks max as software development deadlines slipped. We still needed to ship our product, and the QA team would feel much of this pain.
In this new agile paradigm, QA should be involved throughout the whole agile process. In fact, testers should be part of the team. Whether it’s pairing on a task or discussing how a story should be tested, they’re integral in discussions around testing and quality.
Another important note: agile teams have frequent ad hoc design discussions, so testers should be co-located and available to jump in on those discussions whenever they happen. So don’t create more paperwork and process to share ideas—instead, involve yourself in the whole software delivery process.
How Should QA Work in Agile?
Now that we’ve covered the agile values, we still might have questions as to how we’re supposed to work when agile. In this section, let’s cover some of the ways that our QA skills can help the team deliver quality software in a continuous way.
We’ll look at these in more detail, but with agile you should:
- Join the agile team
- Focus on the customer
- Automate your test suite
- Test manually for the right reasons
- Continuously improve
Let’s look at these further.
Join the Agile Team
The biggest change involves having QA as a part of the agile development team, and not a separate team. Since we’re part of the team, we’re able to assist in continuous testing, instead of doing it all at the end of a sprint.
Also, when we’re on the team from start to finish, we have the chance to affect the delivery of the product much more. Why is that? In an agile team, roles aren’t as clearly defined. You may be able to write your own story by stepping in as a testing coach or automation SME.
As QA, you have an understanding of good testing practices. Help the team by sharing your experience. Consider how a feature would be easier to test. Perhaps look for ways to make the design more testable.
From a day-to-day standpoint, involve yourself in stand-ups, retros, and demos. Stay on top of the work the team is doing so you’re aware of dependencies between stories and what additional testing will be necessary.
When the team focuses on delivering working software faster to the customer, you’ll have the opportunity to provide flexible support to your teammates.
Focus on the Customer
With Agile, you will continually focus on the customer. And you’ll need to learn a lot about how the customer uses the product. Then you can combine that with the knowledge of the working system to define tests and scenarios that might not be apparent from the outside.
Additionally, keep in mind application design. Understanding your product’s design can help identify interesting edge cases that should be considered.
Understanding the customer can also help with a blind spot the engineers might miss. What are actions that the customer might try to meet their needs? Are we overlooking something from their perspective? The more everyone on the team focuses on the customer, the more perspectives you’ll have. And that will help you uncover assumptions that might leave a gaping quality hole in your end product.
Automate Your Test Suite
Since agile testing is done in parallel to development, automation becomes critical. Without it, you’ll find yourself retesting the same functionality repeatedly and falling behind quickly.
Your developers should write unit and integration tests. However, they don’t always cover all the scenarios or haven’t build up those skills yet. Additionally, they test knowing the internals of the system, using white-box testing methods.
This is where you come in as a QA professional. You’ll be able to test from the outside as if the application were a black box. With developers and QA both tackling automated testing in agile, you’ll get both black-box and white-box testing.
Additionally, with automated testing, you will create tests that engineers can use as well. These tests can be included in the development pipeline and automatically execute with no manual intervention.
Now, you may think that you’ll need to learn to code to automate all these tests. Learning to code—or at least learning some light scripting—definitely has its benefits. But also take advantage of tools like Testim to easily put together automated functional tests for your product. With Testim, you’ll have the option to create tests both automatically and using code. So you can learn the coding side of it over time as you need.
These automated tests can be based on the acceptance criteria in developer stories. Create tests that ensure that your product works correctly. And look for where there may be gaps in understanding, and therefore a need for additional tests.
Test Manually for the Right Reasons
Exploratory testing can identify gaps in automated tests. This shouldn’t involve mindlessly going through the same manual processes over and over.
Instead, this time is for asking those “what if?” questions.
What if the order gets canceled after the shipping paperwork gets printed? What if I lose my internet connection while sending the payment?
Put time into exploratory testing to give your team more confidence that they didn’t miss a critical bug or loss of functionality.
Continuously Improve
Though quality is the whole team’s job, you should be driving continuous improvement of testing practices. Work to become an expert on agile testing methodologies and strategies. Help the devs create integration tests that aren’t flaky but ensure that the system is working. Help build maintainable and healthy test suites.
Summary
In an agile team, everyone is responsible for quality. And this can be your time to shine by sharing your expertise with the team. Work with your team to build quality into the development process. As I mentioned earlier, the goal no longer involves just finding bugs and defects, but preventing them during the development cycle.
But that’s a big change. And with agile, we want to find ways to break that problem down and work towards the final goal iteratively. You need to see the benefits quickly and refine from there.
So how do we get started?
As a first step, start using Testim today for free, and see where the automation can take you. As you improve efficiency and build up an automated test suite, you can iterate, improve, and build onto your fast early wins.
This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.
