John Wooden once said ‘Failure isn’t fatal, but failure to change might be.’

Embracing failures isn’t about the blame game. It’s about identifying what’s not working and improving on it. It’s a learning process, with the goal of creating stable releases rigorously tested for security and performance.

This is the philosophy we’ve adopted at Success Software. And it’s resulted in a unique QA/QC approach that delivers better products.

Here we’re looking at a few of the most distinct parts of our QA/QC approach and how their strength was born out of learning from failure.

Defining roles and responsibilities in QA/QC

At Success Software Services, we don’t follow the prototypical role definitions in QA/QC. Most people see QA analysts as entry level testers and QA engineers as the more experienced, next step up in seniority. Here, the two roles have entirely distinct skill sets and remits.

Our analysts are more like business analysts who specialize in test planning. They’re experienced and they’ve seen success and failure in many different contexts. They have the creative mindset that allows them to develop comprehensive, prioritized test coverage plans. (In other words, all the imaginative ways your software could break in the real world.) They develop the plans that the QA/QC engineers then execute.

While there may be overlap in skills in each individual team member, the distinction and separation of each role within a project is crucial. It separates scope and analysis from thorough, detailed execution. Two very different mindsets.

In the past, we’ve worked on smaller projects where these roles are combined and found it to be less effective. The outcomes simply weren’t as good. Failure taught us that industry standard sometimes only produces standard products. We chose to stand out and be different so that our clients’ products would too.

Embedding QA/QC in the team

In product development we aim for perfection but appreciate that failure is an ever-present reality. Our embedded approach to QA/QC is about containing that failure so that course-correction is faster.

An embedded approach isn’t simply a question of geography. You might have QA/QC resources in Vietnam who are embedded in a team that’s distributed around the world. The key is embedding people in the process.

Often you have developers working during sprints and then handing off that work to a separate QA/QC team, which works in its own sprint. While that works in some scenarios, we find it inefficient for a few reasons:

  • You lose time waiting for testing to come back in bulk, when a few bug fixes might only take an hour or so. In Steve Maguire’s words, ‘Don’t fix bugs later; fix them now.’
  • It can negatively affect your ability to collaborate. Testers become distanced from the development process. Their testing cycles turn into passive checklists rather than active quality assurance.
  • It doesn’t prioritize well. A small bug fix has the potential to remove a lot of blockers for your development team. Waiting around to handoff testing slows down the rate at which you identify these high-priority problems.

Our embedded QA/QC team get their testing handed off to them as soon as it’s ready within a development sprint. The QA/QC engineers are embedded in the same processes that the developers follow. They’re involved in the same agile ceremonies and observe the process that developers consume.

If something turns out to be harder than the developers anticipated, the QC resource is aware of it before it becomes a problem. And when something inevitably needs improving, they’ve already factored it into their timings.

Continuous process improvement

‘The biggest room in the world is the room for improvement.’ – Helmut Schmidt, German politician

Continuous improvement is the philosophy behind our learning-from-failure mindset. Like a sea captain caught in a storm, continuous improvement keeps you course-correcting throughout a project. The result is not just quality processes, it’s quality products.

Continuous improvement happens at every level at Success Software. In the first two weeks of a project, we fully expect things won’t work as they should. Implementing a standard template to a specific project takes adjustment and flexibility.

This used to take us longer to get right, adjusting to client requirements and ensuring process compliance. We learned from that to monitor progress on a micro level, sprint by sprint, watching for repeated defects and taking an iterative and agile approach to course correction.

This approach then feeds up to the standards we develop. We implement CMMi Level 3, ISO 9001 and ISO 27001. But compliance was only the first step. Process improvement means spotting common gaps and defects across projects. We then trickle those learnings back up and update our process documentation. Every sprint and every project is a learning opportunity. We grab those opportunities and crucially, act on them consistently.

To prevent failure, expect it to happen, and be ready

In the words of the author Eloise Ristad, ‘When we give ourselves permission to fail, we, at the same time, give ourselves permission to excel.’

Failure isn’t the end of the line. It’s an opportunity. If a project is struggling and you’re feeling dejected, take a moment to evaluate your processes and work on your approach. You’ll quickly find that leveraging failure makes you a stronger, more flexible team.

For more guidance and advice in the software testing space, have a read of our other articles.