How to Switch from Web to macOS QA

My background

Hello, my name is Valeriia, and I am a Quality Assurance (QA) engineer at Setapp – a smart way to get apps. I used to translate technical instructions, but now, as a QA engineer, I help machines help you.

Initially, I made a career change from a Technical Translator into QA specialization. In this role, I tested iOS and web applications, and I had never dealt with macOS before. Approximately after 3 years in quality assurance, I went through an interview at MacPaw, and that's where my transition to desktop QA started.

Spoiler: switching is difficult

Switching, or transitioning to a new field of activity, is always a difficult moral challenge. People often associate this transition with a leap into the unknown, because that's what it is. It's hard to feel stable when you're on the cliff of major changes. Instead of reaching new heights, there is a great risk of experiencing a staggering fall.

However, sometimes it's possible to make a successful career switch!

Today, I want to share with you three stories about my transition to desktop QA, and perhaps help someone to prepare for a career change. Nothing special, just three stories from my life, as Steve Jobs said.

#1: Knowing the platform architecture is the basis

Let's start with the first story, probably the most important for switching. You absolutely must know the system or platform’s architecture you intend to work with. In my case, knowing the macOS architecture and the specifics of its file system became the starting point.

It seems logical. But when you're a newbie and start googling what a desktop QA should know, you get a couple of generic articles – no real insights. That's it. By contrast, if you google what you need to know for web testing, you'll be overwhelmed with new knowledge.

Why do we need to know architecture?

Imagine that you're testing a car engine. You have a vehicle ignition switch and know how to turn it on and off. Everything seems okay. So, do you just install the engine in a car? Of course not, you need to do thousands more tests. But for that, it's necessary to understand the finest details of how a car operates.

The same with your application and the operating system. Without knowledge of the architecture, your application might run, but how far, in the right direction, and exactly as you expect?

Expanding knowledge about the operating system will help you better understand the internal processes and the interaction of components. In general, knowledge of architecture helps testers be more efficient and confident in their duties.

#2: Guidelines: the key to understanding UX in your application

The second story is about the importance of UI and UX in application development.

Everyone comes to this understanding in their own way. I realized it during my interview at MacPaw. They asked me if I was familiar with the Human Interface Guidelines (HIG) and why it is important for a tester. There was no point in answering the second question since I didn't know what the HIG was. Then, a PM participating in the interview shared the Apple Guidelines with me, suggesting I study them if I wish to progress in this direction.

As a rite of passage, I’m sharing the HIG with everyone wanting to get into macOS QA.

The importance of guidelines

Guidelines are a set of recommendations, rules, and principles from the platform or operating system creators that make apps from different developers feel/look unified. If all apps created their own unique design and navigation, users would constantly have to figure out how everything works. Guidelines were created with such considerations in mind, and to simplify and speed up app development.

How will this knowledge help us during testing?

Users already have certain experience with the operating system, as well as learned habits like pulling down to refresh the list data or swiping left/right for navigation between pages, etc. From a QA perspective, it's crucial to consider these habits when developing test scenarios and working through requirements. If your app doesn’t match users' habits, you risk losing your customers and not meeting your key results.

Overall, guidelines simplify life during testing. All the rules are already written. Just take and use.

#3: Independence as the main step towards professional growth

The third story is about independence. If you're a Middle QA engineer and work in a company with a standard hierarchical structure, then you 100% know what a Team Lead is, just like me. Simply put, this person directs you on the project. But imagine you no longer have a Team Lead. What would you do?

(In)ability to take responsibility

In a standard hierarchical structure, Middle engineers rarely build the testing process themselves. They expect the Team Lead to delegate tasks and fully manage the process. Later, engineers want to grow into Seniors, and, unsurprisingly, the main difference between these grades is the ability to take responsibility.

From fear to independence

At MacPaw, I was cautioned that, unlike my previous experiences, I would need to become independent. While the company provided all the essential support and opportunities for my development, I had to be fully responsible for the testing process in my team. Thus, the company's structure implies the independence of engineers of any grade, not just Seniors.

Most Middle or Junior engineers might find this intimidating, and it truly is. At the moment of my transition, I didn’t know if I could become so self-reliant. But believe me, the sooner you start developing this quality, the easier it will be for you in the future. Besides, you'll become a very valuable expert in the tech job market.

How can these stories help?

You might think, "Okay, switching from web to macOS QA seems quite specific and narrow. What can I actually learn from this?" The answer is straightforward. Replace 'macOS' with 'iOS', 'Android', or 'Windows', and you'll realize the underlying principles remain consistent.

First, gain a comprehensive understanding of the operating system or platform's structure; lacking this knowledge, you can't be confident that the app will work as expected. Knowing platform-specific architecture significantly enhances the chances of meeting user needs.

Second, acquaint yourself with your platform or operating system's guidelines and employ them to maintain the trust of our users.

Third, view responsibility as an opportunity for professional growth. This universal quality isn’t tied to any specific platform; it doesn’t belong exclusively to iOS, macOS, or Android. Embracing responsibility might be scary, but that's the path to growth.