What Does “Quality Assurance” Mean in an Agile World?

Have you ever heard this conversation before: “We are totally Agile, we have stand-ups everyday! That isn’t agile. That is trying to be “hip” to all the “new jazz.” #FellowKids

Before writing this, someone asked me “What is the one thing the Quality Engineering team at Appian does that is unique?” I couldn’t answer them, because I don’t feel I am part of the QE team. I feel like I am part of the development team. This is what it means to be agile at Appian. This is why we are Quality Engineering (QE) and not Quality Assurance.

So how does QE fit into Agile development? I often hear QEs at other companies say, “We do all the testing at the end of the sprint” or “We test the previous sprint’s work in the next sprint” — NO! NO! NO!

Agile testing is about continuously testing the product from the beginning (spec document review) to the end (regression and release testing). The earlier you find a bug, the cheaper it is to fix.

Here are my rules for being a good QE in an Agile world:

1. Be part of the team. QEs should be embedded into the development team. Be a member of the team. QE is not a separate team that gets work thrown at them. You should be talking to developers daily. You should be sitting with them. You should be going to all the same meetings as them. This includes planning, retros, and stand-up.
2. Test from the beginning. You are not waiting until the end of the sprint to start testing. If you do little to no work for the first 80% of the sprint, you are doing it wrong. Every day in stand-up, listen to the updates. Ask if there is any part you can start to test. If nothing needs testing yet, you should be thinking about test plans and how things will be tested. Remember your testing can provide valuable feedback. In an Agile world, feedback helps shape the code. If the developers are not ready for you to test until the last day of the sprint, then their increments are too big.
3. Speak up. Your opinion matters. When your team is planning, don’t be afraid to speak up. This may mean saying a feature is more points than others are saying because of the testing required. This may mean telling your product owner something can’t be delivered in the requested time frame because testing can’t be completed. You may even be forced to have a discussion about holding back a release because the quality is not up to par.
4. Be Agile yourself. Maybe you planned on testing a certain feature this release, but now the team will be working on a different feature. That is OK. Just like the developers need to pivot sometimes, so does QE. Be agile. Start learning about the new feature and get ready to test. Learn about multiple testing methodologies, so that you are ready to test any feature when the time comes.
5. Have fun! This goes with any job. If you don’t like what you are doing, you won’t do it well. Being a tester isn’t about “breaking the software.” It is a mindset. Some people say be a “Quality Ambassador;” that’s perfect. If you want good software you have to be an ambassador for good software. “Be the change you wish to see in the world” (Mahatma Gandhi). More and more software companies are trying to do Agile. Start thinking about QE’s role in Agile and start improving your skill set.