QA, and life for that matter, might seem more manageable when you apply processes that have worked before. So it’s no surprise that some treat a work breakdown as a step-by-step guide, believing success will ensue as long as they follow it to the letter.
And yet, not every roadmap takes you in the right direction. To reach your destination, sometimes you have to take a detour.
QA Engineers focus on quality, often by performing tests. They identify issues, gaps, and conflicts in software applications, and are involved in discussions around the best way to fix them. This can call for a change in the software’s requirements and the roadmap, which means it’s always better to approach QA flexibly.
But when you have a work breakdown structure organizing your project in minute detail, you might find coloring outside the lines difficult, if not altogether impossible. This begs the question: how can you make something as prescriptive as a work breakdown compatible with the agility that good quality requires? And how can you ensure the outcome is always a win for everyone involved?
Let's look at how you can make your testing both structured and flexible, and explore how to approach a work breakdown structure in QA.
Read the full guide below or fill in the form to get it as a downloadable PDF:
Base your approach on reality
“Face reality as it is, not as it is or as you wish it to be.” - Jack Welch, former Chairman and CEO of General Electric
Sure, best practices often look good on paper. But do they work in reality? To find out, it’s crucial you test and observe your approach first.
There are some factors you need to take into consideration. First of all, where does your testing come in during the software development life cycle? Putting the horse before the cart is counterintuitive. To provide QA that improves the end product, you’ll need to be on hand when your input is most valuable, right at the beginning of the software lifecycle. If you come in too late in the process, the issues you flag might be hard to mitigate.
And even if you have decades of experience, the software development landscape is ever-evolving. As such, you need to be open to changes, and welcome them should they improve your processes. So talk to stakeholders and see if the results match their expectations. If not, what could you do differently (and when)?
Remember, just because you’re used to doing things one way doesn’t mean that it’ll work for every situation. This is especially true when you’re working with a testing team who have new (and exciting) ideas to contribute. This brings us to our next point.
Ensure your processes are win-win
“Win-win is a belief in the Third Alternative. It's not your way or my way; it’s a better way, a higher way.” - Stephen R Covey, educator and author
You might be stuck in your ways, and it could be for good reason. But who knows? If you welcome outside ideas, you could learn a thing or two.
That said, actively encouraging new approaches is easier said than done. Phrases like, “this is how we do it,” might seem harmless as it rolls off your tongue, and yet it could very well alienate your teammates and sabotage your project as a result.
Your goal is to improve the quality of your end product first and foremost, and this means improving your development process. Strong communication and good team dynamics are key to this, and they come with the added value of improving employee satisfaction. Since happy workers are also more productive, this is a win-win for your project.
So, as you approach your work breakdown structure, ask yourself this: where can I assist and what value can I add? Ultimately, whatever you bring to the table should help others in your team. It’s about people over processes, not blindly applying techniques just because they’ve worked before.
Talking to your teammates and understanding their viewpoints will allow you to formulate an approach that will get the best out of all your varying knowledge and experience. And the result could be something truly innovative.
It’s also vital that you communicate clearly with your clients. As the Harvard Business Review says:
“Many organizations have unwittingly designed innovation processes that produce inconsistent and disappointing outcomes. They spend time and money compiling data-rich models that make them masters of description but failures at prediction. But firms don’t have to continue down that path. Innovation can be far more predictable—and far more profitable—if you start by identifying jobs that customers are struggling to get done.” - Harvard Business Review
Together, you and your clients can establish who the end-user is. Understanding their pain points and goals will ensure that the software includes features that resonate with them and that they enjoy the best possible user experience as a result.
Think flexibly and adapt
“Think for yourself and let others enjoy the privilege of doing so too.” - Voltaire
Don’t get us wrong – we love processes when they work. That said, it's better to think of them as useful tools for specific scenarios rather than the answer to every problem within your project.
As much as work breakdowns help you plan a project in advance, they can be prescriptive thanks to their number of processes. While this is useful when everything is going to plan, it can stifle productivity when conditions are less than ideal.
If your team is experiencing a mental block around how to approach a particular QA issue, for example, adhering to a work breakdown too stringently can halt progress altogether. Sometimes it’s necessary to start afresh and trust that the right processes will emerge to complement your renewed efforts.
And we get that you might feel the need to act as if you know it all. Confidence, after all, is essential in steering a project in the right direction. But leaders show true confidence when they’re not afraid to admit they don’t have the answers to everything.
Temper your confidence with a dash of curiosity. As good as your approach has been to date, nothing is perfect. Just read what McKinsey has to say:
“To keep pace with new market entrants, emerging technologies, and changing customer expectations, companies will need to find ways to extend their capabilities in agile software development to all functions and business units. They must be willing to adapt the very fabric of their organizations and give agile methodologies the space and support they need to thrive.” - McKinsey
Some days, that work breakdown will be the step-by-step guide you and your team need. But other days, you’ll need to scrap your plan and find an entirely new angle.
By continually learning, you’ll also be able to adapt and improve your approach. So prepare to sometimes be unprepared—by treating each situation uniquely (and not panicking when things don’t go to plan), you’ll find the tools and approach right for your team and enjoy a successful outcome as a result.
Find your own (On)path
“Those who can't change their minds, can't change anything.” - George Bernard Shaw
A work breakdown is great when everything works. But when things don’t run as smoothly as they should, consider taking a flexible approach.
No two projects are the same. As such, they likely demand different processes. So be open to new, creative ways of QA testing. While a work breakdown will tell you how to start out, it’s not necessarily the answer to where your project will end up.
If your work breakdown structure is too rigid, don’t be afraid to bend it or even discard it. After all, one size rarely fits all, especially in the realm of software development. Taking a flexible approach will enable you to learn, adapt, and implement changes where they are most needed for win-win projects that everyone is happy with.
