👊🏼 Bust one of the most common myths in Agile Software Development
In this post, I try to bust one of the most common myths in Agile Software Development: “Having a QA (Quality Assurance Tester) in our team is optional. Devs can test on their own, right?” Well, I think it might be possible in some “special” scenarios but that would not be very effective…
In my early years as a dev, I once thought “Why do we need a QA if I, as a dev build & test my own work and a QA just… tests?” ? This was one of the main reasons why this role caught my attention and why I eventually decided to invest and get into that world, a world that has a lot of flavors and what is most important: is more than to “go to break things”. Let me tell you why.
First, an Agile Development team is a group composed by different personality types and roles who work together to create software that must meet customer needs and expectations where everyone is responsible for ensuring the software quality, by constantly communicating, failing fast and thus getting better together.
🔁 Long-story-short in Agile testing
As soon as one iteration starts, the developers start to code and QAs start creating test cases by using the user story acceptance criteria. Once the unit created by the dev gets to the QA hands, they will execute the previously created test scenarios, perform some exploratory testing or a regression test if needed (which can be automated since test cases might be repetitive). Also, some stories may require performance or reliability testing (i.e.: a given test execution can’t exceed a certain limit time or a given number of operations may fail less than a certain number of times).
A QA brings their ✨unique perspective✨ to the team and they can transfer testing and product knowledge to the whole team by closely working with:
- Developers: agreeing together on the best testing strategy about what would be testable or not, providing constant feedback and identifying potential defects before developing a solution (which helps to mitigate risks by removing defects early in the SDLC).
- Business stakeholders, helping them create acceptance tests and giving them guidance when UAT phase starts. Letting them know why their participation is key before product release.
The feedback a team receives in each iteration is vital because it contributes to building a valuable product. So, let’s summarize how all the team members provide insights on testing, because the product quality does not only depend on the QA engineer.
- in XP (Extreme Programming) testing best practices include TDD (Test-Driven Development), ATDD (Acceptance-Test-Driven Development) or BDD (behavior-driven development) which can be very useful to carry out testing across different test levels. The benefit here is that these approaches follow the early test execution before coding and that the user can easily participate too.
- in Scrum, pair testing or pair reviews are a great approach (and one of my favs) where +2 team members just get together to perform a test (tester+dev, 2 testers, tester + product owner, etc) and can catch issues or improvements.
Another approach is mind-mapping which is useful to describe test data, creating intuitive test plans or when onboarding a new QA in the middle of an ongoing project 🤩
Now that we are in the context of a-kind-of-Scrum, let’s dig a little deeper here…
As stated in the Scrum Guide:
“Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person”.
A Scrum Team is a self-organizing team where there would be one or more testers and those testers should “sit together” with devs/designers/scrum master/product owner and constantly communicate the testing progress and findings or impediments so that the team will be able to respond to any risk or adapt to any change, which promotes transparency and courage.
🤔 Why is important to have a QA in a team?
“The best tester isn’t the one that finds the most bugs, but the one that manages to get the most bugs fixed” — Cem Kaner
✅ A QA must be committed to question and evaluate the product’s behavior and characteristics against customer expectations. When applicable, also by using ISO Quality Standards.
✅ A great QA can make a difference. *If you are new in this world and curiosity is one of your top skills, then tap here to read more about the ISTQB self-study*
✅ As a QA, you need to be willing to speak up. Testers participate from day zero and should not be afraid to ask questions like: how would the end-user feel about this? How can we make the user’s experience better?
🚀 Rest assured, we know what we’re doing and why we do it 😎.
⚠️ Testing is more than just running a few tests to ensure that things work. It involves the core and the complete ecosystem of the application, a full understanding about how every feature interacts with the whole to satisfy the business needs.
A QA team can’t be isolated to achieve their goal and the developers are very busy implementing the best solution of the business need, so…then? Easy, both sides synchronize together to ensure quality efficiently, is a challenge but it def pays off.
- A strong development team creates and runs unit tests with a specific test coverage percentage, to ensure that their unit has been built correctly before sending it to QA. Doing this with pair programming, TDD, core reviews, and Continuous Integration by providing faster feedback, isolating, and resolving issues early.
- A QA team ensures that all the isolated units that have been built behave together meeting the business needs and users’ expectations.
🤐 Reasons for not having a QA in your team
As I mentioned at the beginning of this post, there may be some specific cases where a QA might be optional, I personally consider the following ones:
- When incorporating a QA member to your team you should take care of which skills are required for that QA profile. This is because not all projects will need manual or automated testing only. Some of them will prioritize usability testing or strong performance testing. So be careful which QA profile you are looking for. Without having this into consideration, QA and devs could perceive “noise” and face delivery delays given the high learning curve or by not being on the same page.
- I think that Big Data testing in Agile teams is a pretty good challenge because it can be very difficult to fit the testing operations within the short development iterations that typify agile processes, testers and their innovative skills are a critical factor for the business need success. So you must invest in a subject matter expert or let the dev team be happy without a QA.
- Budget constraints can be a strong reason of not including a QA to a project, mostly when the test execution is more specialized as in the -ility tests.
- Even when there are no testers in a team, you’re gonna have the real testers (your customers) when releasing your product so it’s up to you if you want to gather defects and ugly feedback directly from them. I personally prefer catching bugs in-house first 😉.
Concluding Thoughts
Thank you for reading me! I’m gonna share here some additional resources of the testing importance in real life because is not only for software! Your car, your iPhone, and the plane we would like to take right now to travel, are tested by QA specialists 😏 (and of course, QAs as all human beings make mistakes, it just comes with the package).
