What does QA stand for at King?

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?

handymanForKing

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.

devsAtKing

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.

deviceCloudRack

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.

Oriol Marti

About Oriol Marti

As Development Director at King, Oriol helps to build, evolve and support competent, agile development teams . Looks after our technical development organisation in Barcelona, covering the Tech development groups there, including Game Production, Game Platform and Player Comms Tech. Oriol lives in Barcelona, but has also lived and worked in the UK and Scotland; however, he has remained loyal to FC Barcelona, and claims that is the best football team in the world. If Oriol is not in the office, he is probably in the gym or riding a bike in the Pyrenees.

10 thoughts on “What does QA stand for at King?

  1. Uou, another big company following the Assistance trend. Props to Atlassian, which is the first one I heard talking about Assistance. I truly believe this is the swift that the industry needs to meet Agile speed, and that’s why I’ve been working with it lately!

    Wish you the best of luck with the project, Assistance brings loads of new challenges! But thinking that we’re moving the industry forward make it worth 🙂

  2. I find a bit pretentious to take ownership of the practice of Quality Assistance without giving credit to the people that have been doing it for a while already.

    Some reference to the guys at Atlassian would make this article more credible 🙂

    1. Hi Alfredo,

      It is not our intention to take anything away from Atlassian and the awesome work they are doing to drive Quality Assistance both in their company and in the wider software development industry.

      At King, we are interested in sharing our best practises and learning from others and think of ourselves as flag bearers for Quality Assistance and not the originators of the idea.

      We decided to move from Quality Assurance to Quality Assistance back in 2013 when we started looking at the role of a tester on an agile team and, from our own experiences as testers in companies where we had worked previous to King. We were looking for a paradigm shift in the way development teams think about quality ownership.

      About 6 months into our Quality Assistance journey, we did some digging around to see if anybody else was embarking on something similar that we could learn from and found this blog post from Michael Bolton: http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/. This was the first time we had seen the term Quality Assistance mentioned outside of King, and it felt great to know that there are others out there thinking along the same lines as us.

      We didn’t find any articles / blogs from Atlassian talking about Quality Assistance at the time but it’s great to know the Quality Assistance movement is growing and thank you for highlighting this to us 🙂

      Warm Regards,

      Dominic Assirati
      Head of QA @ King

  3. Thanks Oriol for a nice blog. Would not agree more about having a mindset of Assistance for Assurance. That too when you want the Agile team to strive for being truly Agile.
    Feels like so similar with the challenge of getting the team to understand the “Assistance” thing and also the challenge that the current mobile device market poses with such fragmentation across the globe. Just selecting devices to add to your device farm is a challenge in itself.
    Wish you luck with the device cloud and the continue Assisting 🙂

  4. Dominic, thank very much for your explanation! I was just missing some background regarding this recent trend that advocates a paradigm shift in Quality Assurance.

Leave a Reply

Your email address will not be published. Required fields are marked *