For a tester, there is nothing more panic-inducing than your manager asking you how a defect landed in production. After all, as a tester, YOU own quality, right? In my experience, it’s not as clean as that. As a tester, you are accountable for quality but, the TEAM as a whole should own the quality of your software. So how can you, as testers, help champion this concept that everyone owns quality?
A new software feature goes through many stages before it makes it into the hands of a customer. At the most basic layers, multiple people have to conceptualize the feature, design it, write requirements, develop and test it. What if quality was a bigger consideration in each of those layers and not concentrated just at the end? There are several ways testers can engage those around them to ensure that’s happening. Let’s explore some!
Engage Testers in the Design Phase
If there’s one thing I’ve learned throughout my career it’s that processes at organizations are as unique as snowflakes. This sentiment very much applies when defining whether a tester should be involved in the initial design phase, and to what extent. Each organization has unique circumstances they have to consider. The design of an application accounts for that application’s usability. And usability is key in driving customer satisfaction and sales. So why wouldn’t an organization want to ensure testers are involved in this phase to understand the point of a feature as it relates to how customers will interact with it, something that isn’t always documented as a requirement to write a test case from?
There are varying forms of this concept and determining how best to apply it to your organization is key. Executing design-driven testing can have its pros, like finding design flaws earlier in the cycle. In addition, involving testers in this phase can ensure they have better insight to pull from when writing test cases later. Likewise, involving testers during the design phase can have cons to account for as well. The more people and processes a company invests in this phase, the slower the features may travel to the development teams. Finding the sweet spot of involving QA early on, without unintentionally lagging the delivery, is paramount to successfully implementing any form of testing during the design phase.
Write Test Cases Early and Review Them With the Team
In an agile organization, a team will commit to a specific group of work each iteration, typically organized as user stories and defects. It’s not uncommon (actually, on the contrary) that testers write test cases for their stories at the beginning of the iteration before the stories or defects make it to the testing phase. In doing so, the tester is ensuring that when stories or defects flood QA at the end of the sprint (let’s be honest, it typically happens this way), they’re ready to execute and have used their time wisely throughout the iteration to prepare for this moment.
Let’s take this masterful planning one step further. As the tester, you’ve written a set of test cases upfront, and because of this, you fully understand your testing game plan. Now it’s time to share those with the developer who will be coding the work. As you’re walking the developer through your test plan, explain the areas that you’ll be focusing on during your testing. Also, this a great time to receive feedback from the developer to ensure your coverage is exhaustive. This method helps to ensure your testing is thorough and gives the developer the chance to think through the areas you’ll be looking at to ensure the code accounts for it appropriately. Win/Win!
Encourage Stakeholder Alignment with Actionable Data
As a tester, I can remember countless times when I was asked to sign off on testing ASAP because it was important the resolution get to production quickly. The reasoning for the quick delivery was typically not explained very well, but the tone in which my boss delivered the request gave me a sense of urgency. After outlining my test plan, the time required to fully test was longer than I believed management wanted to wait. I’m positive most testers have been in a similar position; do I cut corners to get it out the door or push back and ask for the time I need? It’s this fork in the road that I want to focus on.
In these situations, it’s difficult for testers to always know which way is best to take; and frankly, that decision shouldn’t be only yours to make. The internal desire of wanting to ensure quality in everything we do is strong but the external pressures of getting code to production, especially if the code fixes a major issue, is very real. If your stakeholders aren’t aligned on the priority of speed vs. quality, it can put the tester in an impossible situation. In these scenarios, I’ve always found it best to present the stakeholders with actionable data. For example, I would explain to them, “in order to fully test this fix, I need to test the fix itself and do regression testing around these 3 areas. To complete this it will take me 1 day.”. I’ve taken the decision off of my shoulders and asked others to help me prioritize. If they encourage me to take the time I need to ensure quality, great!. On the contrary, if they listen to my test plan and timeline and counter it with a lesser timeline, they’ve accepted the risk and I can focus on testing what I can, given the time I’ve been given. Either way, providing that actionable data is key to aligning stakeholders.
Provide Input During Agile Ceremonies
Echoing my previous snowflake statement, every “agile” shop does things just a tad bit differently. The comments made here are based on the experiences I’ve had within the agile organizations I’ve worked at. In my experiences, each iteration, teams have a host of agile ceremonies: backlog grooming, iteration planning, feature planning, stand-ups, and retros. There are obvious ceremonies that must include every person of the team, such as iteration planning, stand-ups, and retros. These ceremonies ensure work moves through the iteration and any blockers the team has are quickly removed by the Scrum Master.
The not so obvious ceremonies like feature planning and backlog grooming are ceremonies where QA can sometimes intentionally pass on, in an effort to keep focused on the testing tasks for the current iteration. The thought of skipping a meeting might be enticing, believe me, I know. However, during those grooming and planning meetings, details of features are being hashed out. It’s paramount that QA can voice concerns around testing needs, such as test data, but equally important is the ability to hear and understand the feature’s purpose and technical implementation. These details will help drive more complete test cases and allow QA to voice their questions and concerns earlier in the cycle.
Conclusion
Quality, at the very least, should be a consideration in each step of your development lifecycle. It’s your passion, something you want to champion and involve everyone in, but its also your responsibility. When your back is against the wall and the deadlines are inching closer, that it isn’t going to be the time you want to suddenly champion quality. Use the tools above to start having those conversations early on. Encourage your organization and stakeholders to prioritize quality within your SDLC, where it makes sense.
However, this is all just one gals opinion. Let’s continue this in the comments below.
- Does your organization do a good job with these things already? What are some lessons learned that you can share?
- What are some examples when presenting the data to stakeholders backfired? How did you handle it as a tester?
- What agile ceremonies do you currently attend?
The QA Connection Blog 
Hi Johanna,
Hope you’re doing well. What are your thoughts on Test Driven Development (TDD) to improve the quality of a project/product/feature?
In your extensive experience as a tester, manager and now director have you seen instances where TDD delivers better quality of product/feature?
Thanks,
Debashis
LikeLiked by 1 person
Great question, Debashis! I hope you’re doing well too.
TDD is certainly a good way to stretch quality across roles and should lead to more stable features coming out of development. It shortens the feedback loop for developers and also results in cleaner code, making it easier to maintain moving forward. Where I’ve seen this fail is organizations assuming that TDD is all the testing they need. Scaling TDD across your dev teams is wonderful, however, it doesn’t take the place of traditional testing. In addition, the full adoption of this is required. Having one or two devs following this practice won’t give you the outcome you’re looking for. When I think of TDD I think of code coverage on the testing side. We are always analyzing what has changed and walking the fine line of testing enough to cover those changes.
Have you worked at an organization that is using this concept?
LikeLike