“Quality is the whole team’s responsibility” these are the words you hear on the lips of all those involved in agile development. Unfortunately this sentiment, although vital in a technologically saturated world, often starts and ends on the lips of the development team. Yes, Software Quality Assurance has gained precedence these last five years or so, and there are a number of companies that are really doing this well, but there are also a number of companies who have adopted some flavour of agile that still involves keeping Quality Engineers locked under the stairs in the basement.
Obviously I use the basement analogy very loosely, let us qualify this in more relevant terms. The first, and most obvious is whether your QA resource is co-located with your team (if you are back at the office of course)? If they aren’t, are they even on the same floor as your team? (Did you check the basement?) The fourth industrial revolution is well on its way and requires an incredibly mature quality-process adoption, so for those of us who haven’t yet mastered the inclusion of quality assurance resources in our teams, we’re going to need a fairy godmother to make a success of this revolution.
Growth and Maturity
Does your company experience the “scramble for evidence” as very stressed-out QAs collate all of their many, many records documenting their testing process- this usually comes on the heels of a “How was this Tested??” or a “did you even test this?” after something goes wrong in production? If everyone is responsible for quality then it stands to reason that the “blame game” needs to become a thing of the past. In our experience, a fair amount of the defects found in production can be traced back to configuration differences between test and production environments, buuut “testing” is inevitably the place we go to first when we experience a major production outage. QAs will always be there to help determine a root cause because we largely feel responsible for defects making it in to production- obviously because quality is everything to us, but also because of the years of being held responsible for the slightest whisper of a defect in production. Its time that teams TEAM and collectively work on resolving issues rather than looking to blame someone for there being an issue.
Does your entire development team have access to every agile tool in the book, but your Quality Engineers still only have access to Jira (or some such other project management tool) in order to manage their testing process? Jira or Azure Devops are predominantly project management tools and aren’t made to create and execute test cases from, or to store the thousands of testcases that become our regression pack, for this we require a plug-in, or alternatively a full application lifecycle management tool like SpiraTeam. However, budget for testing tools is often overlooked and not deemed as important as tools for other phases of the development lifecycle.
If, as you read this, you answered yes to any of these questions, then it’s high time you sit back, evaluate your current process and look for ways to make it more inclusive. Quality and testing should not be an afterthought; in this day and age, quality is of utmost importance. Quality assurance should involve everyone in the team, from developers to non-technical stakeholders and should be included in day-to-day conversations. Everyone should understand their role and be proactive in ensuring quality is maintained. The key to Quality software is active collaboration. Quality must not remain the responsibility of a select few in order for it to be successful; having an effective, collaborative quality process will provide peace of mind for all involved. By involving the whole team in quality assurance, it allows for testing, feedback and communication to occur more frequently and on better terms.
If you look closely, you’ll see that there are a pair of glass slippers on your QA’s feet, we have a bigger part to play in this story and we want out from under the stairs.