©Truefit. All rights reserved.
©Truefit. All rights reserved.
In the past, the software development process progressed more like a version of the Telephone Game – the summer camp pastime. Sales would close a deal and developers would build with little-to-no client interaction. This left QA to test the product with sparse information on what the client was expecting or how the builder meant it to function. This troublesome building style was known as the Waterfall Approach.
Thankfully, an ambitious few saw the potential in having each discipline working alongside each other from start to finish, a process referred to as agile. There’s an extensive list of notable benefits for working with cross-functional teams, but this time, we’ll investigate how QA’s involvement in the sprint fosters team trust, client satisfaction, and increased project speed.
There’s never been much appreciation for the Middleman, has there? And we think deservedly so. With every degree of separation between the doer and the tester, the risk of miscommunication increases, just think back to the Telephone Game. With every hand off of information, vitals slip through the cracks, whether it be because of changing scope, personal opinions or mere forgetfulness. QA working alongside design and development in agile mitigates confusion. They can help identify gaps in preplanning and bring insights from past experiences to the new project.
Writing clear scenarios that explicitly define requirements before starting your build is not only a surefire way to avoid headaches, but critical to running an efficient project. Picture this: a pile of wood, a bag of hardware and a box full of tools. Now build something. What did you envision? A trunk? Bunk beds? A large deck? How are the builder and the quality assurer supposed to test against expectations if we didn't set any? Unfortunately, in the past, it wasn’t uncommon for QA to receive sparse or totally empty story cards. Thorough user stories should be written upfront by Product Owners. That way, they can use them to confirm client approval; engineers and designers can reference them for product insight and guidelines; and QA can search for holes in the workflow and functionality.
What did you have for breakfast last Tuesday? Can't remember? Can you explain a line of complex code you created the Tuesday before that? Consider how much more effective these questions would be if they were posed only days, or hours, after the activity took place. Revisiting your work and identifying a bug is exponentially easier when you’ve just written the code. Switching tools, languages, or even client industries requires a shift in thinking that can substantially slow down an experienced developer. You can avoid bottlenecks by having QA test a recently completed section of the program while another is being written. This strategic progress makes sure you don’t get so far ahead of the project, that it’s difficult to jump back in should a problem arise.
As a practitioner gains experience in a specific discipline, it molds a unique perspective. Including experts from each team allows for individuals to raise concerns the others may not have been trained to see. Quality Assurance can work with Development to identify whether an additional feature will work autonomously or if it’ll effect several parts of the code. Regression architecture, or changes to the product’s foundation, is a red flag for the QA process and requires retesting several touch points – knowing early on helps in building out an appropriate testing plan. When Design, Dev, QA, and Product Owners work together to shake out potential problems upfront, it makes for a smoother running product.
Have you experienced the phenomena of desperately looking for something, only to realize it was in plain sight the whole time? When you’re buried in details, missing the obvious is common. Clearly defining the purpose of each product feature ensures QA has a definition to test against, so they can confirm it’s working properly. Functions are weighed by carefully considering the client’s needs, it’s vital to ensure each one works, they likely had to prioritize this one over a long list of others.
It may seem counterintuitive to encourage more hands in the pot and it’s true that without a well-oiled process to lean into, including more opinions can lead to bureaucracy. However, the fast-paced nature of agile processes and the inclusion of problem solvers from the get-go, allows you to bulldoze obstacles and keep projects on course. These five reasons only begin to assert the value of utilizing QA as an active partner in the building process, but we wager you’d learn more from joining us in the approach.
