Preparing For The Future Of QA: A Lesson In History

When I first started in QA almost 25 years ago, I was working for Epson America. At the time, there weren’t any documented processes to keep track of what you were testing, let alone any way to automate it. The ability to have repeatable and quickly executed tests was almost impossible, which meant that testing was unpredictable and had many gaps. Now, though, speed and effectiveness are key—especially when customers are expecting fixes and upgrades immediately and having a defect while using a particular browser could mean a total lack of trust in your company.

Back then Epson made desktop computers and I was testing the pre-installed Windows installations that were shipped with each system. My assigned team was responsible for developing and testing these installations that were designated for South America, for Brazil specifically, and it was a challenging time because we were testing windows and software that we couldn’t even understand since everything was written in Portuguese! 

We’d see a message pop up, and we wouldn’t know if it was a disaster or if it was just saying hello. Plus, we didn’t have Google, so we had no way to figure out what it meant other than our feeble attempts at translation from a book on Portuguese. It was more like a feeling—thumbs up, thumbs down, how does it look? That’s really all it was at the time—conversations with other engineers, sitting in a meeting, and saying, “That looks good to me.”  

Since then, though, QA has become a lot more formal. There are a lot more processes now than when I first started, because people want to be able to see what they’ve already done so that they can repeat their testing. That was always difficult back in the day—no one could remember what they’d done exactly, so if a developer asked you for more information, you couldn't always show them what happened. You’d chalk it up to user error and move on if you couldn't repeat the issue. 

Documentation is much better these days, which means that defect tracking and the whole software development lifecycle is a lot better. But back in the early 2000s, we were documenting in Word docs—not even in a spreadsheet—which was better than nothing, but still quite cumbersome. 

Now, the industry is moving away, and has been for some time, from an outdated waterfall method—which kept groups in silos, slowed down the process and forced each group to wait on the other to proceed—to a much more agile system working side-by-side with all groups. There’s a more openness in QA now, a flexibility. All groups, whether it's QA, development or project management, are now working together, where that was not the case years ago. 

The Beginnings of Automation

I have always enjoyed the programming side of software. It reminds me of being back in high school and trying to develop my own video games—it’s just like a puzzle. So, over the years as QA has gotten more and more sophisticated, it made sense to me to move into a role where testing would be less manual and become more automated—and more like solving a puzzle. 

Currently, I’m focusing on mobile automation testing at my company, but have worked on development and execution of automated testing on our web product, as well.  When I first came on board, it was difficult to spin up test environments to handle the varied configurations that we needed to test. We had a lot of different operating systems we needed to cover, with a lot of different browser types, and each configuration combination had to be manually created and maintained, which took a great deal of time. 

However, the amount of time it took was very inefficient and took away from the testing. Trying to get virtual machines in place for all the different versions of Windows, the different versions of Mac, plus all the different browsers, was an enormous amount of work. We’re looking at many different combinations that needed to be tested on a regular basis. 

Plus, having all those virtual machines with different OS/browser combinations means you can never really be sure if they’re clean or not—and you don’t want to be spending too much time on maintenance when you’re supposed to be automating.

So, instead of spending all of my time building virtual machines and making sure they're maintained properly, we began looking into third-party solutions. After all, they’re paying me to write automation tests, not spend my time on test environment maintenance.

I was familiar with Sauce Labs, but I wanted to see what else was out there, so I tried another popular choice: BrowserStack. But after going through the free trial and spending some time with the product, it just didn’t feel intuitive to me. It didn’t feel as smooth as Sauce Labs, which I had used at a previous company, and it came with a hefty price tag. Harder to use and more expensive—not a smart decision. 

The choice was clear and we went with Sauce Labs, which I was already familiar with and trusted. I already knew how intuitive and easy to use it was—the UI was so well set up that it was easy for me to figure out—so, to be honest, it was a rather easy decision to make.

Broadening The Scope

It’s hard for me to describe how much time I’m saving by using Sauce Labs, because there are so many instances where it’s helped me out. I get tired just thinking about all the work I would have had to do otherwise! It honestly wouldn’t be possible for me to do it all manually—we just don’t have the resources to do that kind of testing ourselves. 

By using Sauce Labs we can broaden our test coverage and even go in directions that wouldn’t have been possible otherwise—and the ability to cover a great deal of combinations is so critical in today's market. It's make or break for a company, to be honest. If you show a flaw in your system, you show some doubt in your stability and you lose credibility—especially for a company that deals in web and system security. 

For example, if one of our customers pulls up a supported browser and there's a problem, all our credibility starts falling apart. How much faith can someone have in our security, in what's underneath the hood, if they can't even use our product properly?

That’s why it's so vital for companies to be able to cover a great deal of combinations quickly. You need to get your product to market quickly, and you need to be able to update quickly if anything goes wrong. Being able to automate lets you do that. 

The Future of QA

In the time I’ve been doing QA, it has changed a great deal—the rise of automation, the formation of repeatable processes. These days, I’m noticing another shift, a splitting of roles in QA.

On one hand, there are subject matter experts—people who may have come from customer support or customer success roles, who understand the apps and their domain really well and then moved into testing. However, more and more companies are hunting for QA folks with a developer background. They want people who can write automation scripts and have a working knowledge of tools like Sauce Labs.

Although manual QA probably won’t go away entirely, it’s definitely going to be greatly reduced. Having developer knowledge and the ability to write scripts is going to be key—and tools that can help you do that will be more useful than ever. So, if you’re thinking about getting into the field, or just want to make yourself more marketable in the future, try your hand at automation and tools like Sauce Labs. You’ll be better prepared for the future, and whatever company is lucky enough to snag you will be more efficient because of it.