Przemek Furtak

Przemek Furtak is a software QA lead at Headforwards. His quality assurance experience includes design development and implementation, test plans, test cases and processes. Before QA he spent eight years in roles including scrum master and project manager. Outside of software he enjoys beach BBQs with his wife and daughter and has a penchant for cheese and onion pasties.


True quality is hard to define – and therefore difficult to achieve.

In fact, even the word itself is difficult to define in a way that’s satisfactory for everyone. In its simplest form, Google says that quality is “the standard of something as measured against other things of a similar kind”. More advanced users might look to standards like ISO 9001:2000 and find it defined as “the degree to which a set of inherent characteristics of an object fulfils requirements”.

But for those of us working in software, it all comes down to this: a drive to ensure every change or addition we make is in line with requirements and brings measurable value. It’s when software does everything our client asks for and works seamlessly for their end users. And that can be difficult to balance.

True quality is invisible

Quality is something that exists in the background of user experience. When tools and applications work as they should – and as expected – users won’t think too hard about whether they’re using a high-quality piece of software.

But when they click a button and nothing happens, or an accidental double-click sends them to a completely different page, they take notice.

Maintaining quality is crucial for keeping your end users happy and making sure your software, whatever its purpose, is delivering value for everyone. But simply ticking off every feature on a requirements list doesn’t necessarily mean a piece of software will be high quality. So how do you ensure you’re building high-quality software?

Everything breaks with enough effort

The short answer is testing, testing, and testing again.

Let’s revisit that button example. Say a single click should make a pink cartoon elephant appear on the screen. The end user clicks, the elephant appears – perfect. But what does it take to break that button? What happens if the user drags? Or if they click on something else while the image of the elephant is loading? These are the questions that testers are asking when they approach software for the first time.

You can’t always predict how a user will interact with the software, so testers need to try as many eventualities as possible. (Few pieces of software survive contact with the public intact.)

Many developers used dedicated testers and quality assurance teams to test out their software, find the bugs and breaking points, and report back to the developers. But this might slow development down, and means software is often passed back and forth between teams until it’s ready to launch.

At Headforwards, with one of our long-term telecoms clients, we approach it differently. We don’t separate out our development and QA teams; every person has testing skills that they exercise within their role as they work on software.

We’re all testers

High-quality software comes from developers who are engaged, curious, and accountable. One of the biggest advantages of Agile development is the ‘whole team’ approach; there are no individual departments, just a group that has the skillset required to build the right product. Everyone is responsible for the quality of the product they deliver, so there’s no passing on a hot potato of buggy software for a QA team to deal with.

Approaches like mob programming and automated quality checks within the continuous delivery pipeline mean cleaner code that’s easier to test and less likely to include bugs. And what we can’t automate effectively, we check manually.

As a team, we sit down and work through challenges together, discussing the best approach to ensure code is only as complex as it needs to be. (That makes changes and additions easier further down the continuous improvement journey.)

These approaches not only let our developers build the software in line with our clients’ requirements, but also to implement the bug-avoiding solutions and usability fixes that are usually suggested after a testing phase. We embed those directly into development, which means even the smallest piece of code doesn’t go anywhere without being properly designed, and unit- and integration-tested first.

All this means that every person on the team is dedicated to producing high-quality software, that answers clients’ needs and delivers seamless end-user experiences. So, if you’ve got a project that needs that quality-focused CI/CD approach, you know where to find us.

Want to know more about how we use mobbing to deliver quality software? Get in touch