Learning Zone

It’s been well-documented over the years how costly manufacturing defects to production lines spanning across a range of different industries.  According to the Cost of Quality (COQ) from the American Society of Quality (ASQ):

Anyone who has read any of the work we’ve released here on the Global App Testing blog or read our white paper will know that we feel strongly about the future of QA. To add to that, we also feel that the future of QA is deeply rooted in being able to test at the speed that release demands. In the world of ever increasing product releases and development, how do you ensure that your QA is adjusted properly? Can your testing program really keep up with continuous integration or/and agile approaches to development? Unfortunately, for most organisations and approaches to QA from the past, the answer is no. It doesn’t mean that exploratory QA is dead and it also doesn’t mean that automation or machine learning is the only answer.

One of the things that initially attracted me to working at Global App Testing and moving approximately 4,800 miles from Seattle to London was a set of cultural values. It seems trite in today’s business world that someone would decide to join a company based on their values since, based on what most people write, it appears cultural values are simply vapourware buzzwords. And, to be completely honest, it was what I was initially expecting when they were introduced during the interview process. However, I soon learned that these weren’t merely nice things that we say to get people hooked into working here – they are practised every single day.

When you look at Facebook, Amazon, Google and the other big boys in tech, you assume they’ve got it all figured out. “If only we could release with the same kind of quality that XYZ company have” people will say to me. Just recently, for example, I was working with a very large European media company. I met their director of Engineering at an event and we began discussing how they were approaching their QA. This director confided in me that they were outsourcing their QA to a team somewhere and the results were less than lacklustre. The problem was, he explained, that the bigger the app grew the more QA resources they tried to throw at the problem. Resources in terms of money, people and effort. I told him that the problem was not for a lack of resources - this media company is massive and could easily afford it - the problem was a lack of strategy around how to implement the right QA operations to scale without adding more resources in a linear fashion.

Coming from a background in cybersecurity, I am keenly aware of the past few weeks’ activity in the world of information security. From the Google phishing scare to the current disaster of Wanna Decryptor, it has certainly been a fractious week or two for anyone who may have been infected or damaged by those recent events.

There are of course many more smaller hacks, ransomware attacks and phishing incidents that go completely unreported. Having moved into the world of QA testing, I have begun to examine whether or not any of these incidents could have been mitigated (note: not completely avoided) through the use of testing. It’s often hard to get much detail on less publicised hacking and breach incidents so for the purposes of this article I will focus on a few major news breaking pieces over the last few weeks.

When I first started working at Global App Testing I considered myself a fairly technical person. Coming from a background in cybersecurity and web development, I know my way around plenty of systems, development and scripting languages and certainly have a very good understanding of technology. However, like most people, I had not been exposed to the world of QA. In fact, most of the companies I had worked for, except for perhaps the largest ones, did not have QA teams.

With that context in mind, one of the things that we do here in our London office is arranging a time for new employees to be a “tester for a day” and participate in an ongoing exploratory test. We do this for a few reasons, but really it is to get a feel for what it’s like to be a tester. My task was to test a relatively simple ride-tracking, cycling/mileage application*. A relatively easy task for someone with my kind of technical background no? Let’s find out!

You’ve built a cracking mobile app that you can’t wait to show off to the world. Everything is ready from the development side, and your team is pretty darn excited about the features that they’ve work hard to complete. Anticipation in the office is running high as the downloads begin to pour in from the major app stores around the world. Yet, anticipation soon turns to trepidation as a few bug reports come in from a few users. Your immediate reaction is to head over to the QA and development teams and ask them about it.

In 1984 Cem Kaner coined the phrase Exploratory Testing and used an interesting analogy in a 2008 talk to compare the differences between it and automated/scripted testing before fully defining out exactly what it is. Before diving into exactly what exploratory testing is, imagine for a moment that you are a police crime scene investigator who has been assigned a murder to investigate. But for this investigation you are specifically restricted to a predefined set of scripted actions you can take to get to the bottom of the crime. You cannot deviate from this script and thus are severely hamstrung in solving the murder unless the outcomes of the scripted actions and questions lineup. This is exactly what scripted/automated testing does. It hamstrings the test process only looking for a predefined set of designed questions and thus, the need for exploratory testing.

How do you manage clients needs and expectations as a mobile app or website development agency? Your client has hired you to deliver an amazing end product within a set of parameters and QA testing is almost always an afterthought. So how do other agencies and consultancy companies manage this process? Global App Testing has been helping app development and consultancy companies manage their budgets, deliver quality applications and grow their client bases. Using crowdsourced QA testing, agencies are delivering more frequently than ever.

Over the past few years, we’ve run into plenty of companies who wonder why they can’t use in-house QA teams to deliver the same results that crowdsourced testers do. It’s a common occurrence because companies assume that using an external vendor like Global App Testing can’t deliver the same value as someone sitting inside their organisation. Yet, there are three fundamental factors that set crowdsourced testing apart from in-house QA; time, cost and quality. These three factors help crowdsourced testing deliver a punch that in-house QA teams can’t match.