Imagine that the door to your house is broken, and you need to call to a handyman to fix it. When the handyman arrives, he investigates what’s wrong with the door and gets to work. When he’s finished, he leaves your house without checking if the door opens or closes ok, if the handle works, if the hinges are aligned correctly, and so on. This sounds ridiculous, doesn’t it?
Almost all professionals who build or repair things check the quality of their work before signing it off. It’s a matter of professional pride and taking care in their work. Without this focus on quality, they would not stay in business for very long.
Now think of a software developer working on a bug fix or a new feature. The software development industry has made it possible for the developer to produce work without having to check its quality. What’s more, there are people whose job it is to check the developer’s work for them. This too sounds ridiculous, doesn’t it?
Let’s consider the impact this has on how developers think about quality. Imagine working in an environment where it’s someone else’s responsibility to constantly check your work. How would this make you feel? Would you feel like you are not trusted to produce quality work? In the example of the handyman fixing a door, we would never expect them to check for things that might break the door, such as the structural integrity of the door frame, how much load can be placed on the locking mechanism before it fails, how much force is required to break down the door, and so on.
The same applies to software development. It is reasonable to expect a developer to consider boundary scenarios that would cause an application to fail or crash outside normal usage, or what we call the happy path. However, a developer might not think of all the exceptional conditions, and this is where QA can really help out. Testers are experts at exploring and investigating the non-happy path and coming up with ‘what if’ scenarios. This is where they shine and do their best work. Using testers for happy-path testing is not a good use of their time or skills, and it also lowers the quality bar for developers.
At King, all teams are responsible for the quality of the product that they are developing. There is no team to assure quality or to relieve development teams of their responsibility to deliver high-quality products. Whether it’s with unit tests, integration tests, UI automated tests, or manual tests, product teams are responsible for making sure their product meets the quality standards that our players have come to expect.
So what does QA stand for at King? It stands for Quality Assistance. During the last two years, we’ve been busy building a team of testing specialists that help product teams own the quality of the product they are building. Our people don’t just test our products; they have a much broader mission to influence all team members to take responsibility for quality.
For a lot of teams, the change from assuring to assisting quality is challenging and requires support. We start by shifting the focus of testing from defect detection to to defect prevention. Our specialist testers help product owners concentrate on quality right from the start by focusing on requirements. They then work with developers to make sure they understand how to check that their implementation matches the acceptance criteria. This is achieved through close collaboration between developers and testers throughout the development lifecycle. Some teams have also started investing in Behaviour-Driven Development to assist with this, and the results show an improvement in team productivity, quality, and communication.
When each team member strives to deliver quality in their part of the process, the result is a better quality product overall and the whole team feels proud of what they have achieved. If the ownership of quality is left to testers in a waterfall mode, then it is easier for potential bugs to creep in and even get missed.
For us, Quality Assistance means more than embedding specialist testers in product teams though. It’s also about building tools that help our product teams better understand their quality challenges, identifying ways to track quality improvements, and increasing the number of different types of testing available. We believe that manual testing is not scalable for mobile apps, as there are too many devices and operating systems to test on (>40 combinations just for iOS), as well as too many user conditions. Not to mention that manual testing often leads to missed bugs and delayed releases.
One of the tools we’re building is a device cloud with around 500 devices for automated testing.This will allow any developer to send a test and replicate that test on as many devices as needed. They will then receive a report with detailed information on any bugs that were found, as well as any relevant logs and screenshots to speed up bug fixing.
When testing can confidently be shared with developers and other team members and everyone can rely on test automation, those who are experts in testing can focus on finding the root causes of quality problems in addition to discovering their symptoms, as well as spend their time on other, more complex areas that surround mobile development.