So your company is going Agile. If you’re a tester or QA person, that can bring about frightening thoughts about what your world will look like. For example, will you now be expected to test a codebase that changes daily, with no breaks or developer deadlines? Alternatively, you’ve heard that some teams do away with QA and testers completely once they go agile. How will you survive in this scenario?
Fear not, for there’s still a need for QA in our new agile world. However, instead of the old paradigm, where your goal involves finding defects, your new goals include preventing defects and helping ship products faster. And with this guide, 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.
What Does Going Agile Mean for 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. But we need to read between the lines and picture what this means for us. Here are the four values that came from the Agile Manifesto:
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Individuals and interactions over processes and tools
Now let’s look at how these values fit together with QA.
Working Software Over Comprehensive Documentation
For the first value, we learn that working software comes before comprehensive documentation. Now, this doesn’t mean you can’t have any documentation, no matter what your development team tells you.
It means you should create documentation only if it provides value. In the testing world, we should spend less time writing out manual test plan documentation and more time automating the tests.
And we do have some things that will always need documentation. For example, putting together documentation for the customer can be a big part of QA’s job, as they’re most familiar with how to use the system.
As another example, you’ll need to document how to recreate a defect within the application. But don’t spend too much time filling out forms, tickets, or any other unnecessary work. Look for streamlined ways you can clearly communicate the defect to the development team without much overhead.
Whatever you do, make sure it drives the result of having working software.
Customer Collaboration Over Contract Negotiation
In the previous section, we mentioned putting together documentation for customers. That should be one of the last steps. Before the documentation, we should be working closely with our customers to understand how they use the system and why they might run into defects or bugs. Learn what their pain points are so you can share what you’ve learned with the development team.
Overall, your relationship with the customer should look like a partnership, not a criminal case.
Responding to Change Over Following a Plan
One big concern testers have when it comes to delivering software frequently involves keeping up with the testing. Everything changes in agile, and fairly quickly. 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 process. In fact, testers should interact daily with 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.
What Should QA Do Now?
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.
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.
What else should you do?
Join the Team
The biggest change involves not having a separate QA team. Instead, QA should be part of the development 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 the 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.
When the team focuses on delivering working software faster to the customer, you’ll have the opportunity to provide flexible support to your teammates.
Understand the Big Picture
While the developers dive into specific details of the task they’re working on, you have the responsibility of understanding the big picture. You’ll need deep knowledge of the working system to define tests and scenarios that might not be apparent from the outside. And with that whole-system view, you’ll be able to write the documentation that’s necessary for your customers.
Additionally, keep in mind application design. Understanding your product’s design can help identify interesting edge cases that should be considered.
Understanding the big picture can also help with a blind spot the engineers might miss. The big picture will help you uncover assumptions the team has made about the system. And those assumptions could leave a gaping quality hole in your end product. Therefore, you’ll always want to have a keen understanding of the system as a whole.
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 three or more times in a sprint or iteration.
Your developers will write unit and integration tests. However, they write those tests to a spec and typically can’t cover the use case from end to end. This is where you come in as a QA professional.
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.
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 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.
Enable Faster Delivery
As mentioned before, because it’s so critical, we need to enable faster delivery of software. As the QA person on the team, this can mean a lot of different things. For example, help your team define what a completed story looks like. Assist with story creation. Help the team identify what’s missing or out of scope for a particular story. Guide them to ensure that you deliver your product with quality.
But most importantly, don’t be a bottleneck or a block. Enable the team to go faster.
Share Testing Practices
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.
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.
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 finding bugs and defects, but preventing them.
Find ways to use agile practices and values to make that happen in collaboration with the team and the customers. You’ll be able to find comfort in your new agile workplace without fear or apprehension.
Author bio: 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.