Things I wish I knew as a QA engineer leaving a Corporation for a Startup

Intro

My name is Lena and I am a QA Engineer at Brickit, a bricks-scanning app that helps raise kids smart and creative. I also had the opportunity to work in a large bank. In this article, I will cover the differences between a corporation and a startup in terms of testing processes, and provide some practical advice that I failed to find on the internet at the time. My experience may not apply to each and everyone, and I am genuinely curious if there’s something you agree/disagree with.

1. Differences between a corporation and a startup

Onboarding

In a corporation, there’s no time for anything else in the first couple of weeks. At first I was only assigned tasks related to the company’s ecosystem, essentially teaching me how to create tickets in Jira. Many corporations have their own “universities” with mandatory courses for new employees, covering safety, office etiquette, company structure, development guidelines, and more. I also had a buddy for emotional support during the adaptation period. My onboarding was as smooth as possible.

In a startup, during the first week, the team was implementing paid subscriptions, and I was immediately assigned to test them. There were so many unanswered questions, and I had to figure things out on the go. Naturally, I made mistakes and the release had to be hotfixed.

Looking back, I can laugh and advise you to document all the questions and the answers you get. This won’t prevent mistakes but helps set up a more effective onboarding process when there is usually no time for that. When the team starts growing, you can rely on your notes and help new team members face fewer challenges than you did.

Documentation

It’s no secret that startups have less documentation. But what does that mean for a QA Engineer? In a corporation, everything is not only documented but often illustrated: how services interact with one another, or how the front end communicates with the backend with all possible states and exceptions. System analysts have already ensured that there are no questions about how a feature that doesn’t exist yet works. So, if you can read, it’s almost impossible to miss a test case.

However such analysts are a luxury for small startups. So, if there is any documentation in a startup, it is usually written by developers, product managers, or designers. It may be scattered, conflicting, incomplete, or unclear. If you write test cases based on such documentation, you won’t cover half of the real scenarios. Therefore, for effective testing, you will need to identify missing corner cases and inconsistencies in the documentation, essentially taking on the role of a system analyst yourself.

Processes

In a modern IT corporation, you may encounter the interpretation of Agile approaches, internal development and deployment guidelines, and well-established processes in general. For example, at my previous workplace, there was the same release cycle for dozens of teams. Cycle stability took precedence over meeting KPIs, and an uncompromising release team made sure of that, sometimes causing conflicts with the business. Therefore, planning was taken very seriously, and task management systems were developed to show the status, dependencies, and estimated time for everything.

In a startup, there may not be a release cycle as we know it. Processes could be replaced by discussions in Slack. There may be one Kanban board for the entire team. QA may be getting done on production or not getting done at all. Until the startup starts to grow dramatically it’s a reasonable tradeoff in favor of speed and flexibility

Bugs

In a startup, unlike a corporation where a critical bug is a special event, there will be many serious bugs. This follows from the first two paragraphs as bugs are not only attracted to light but also to poor processes with no documentation. To understand the scale, having 50 bugs per test build is a lot, but normal for a startup. To keep up with a load of bugs coming from each iteration you need to report them quickly and eventually lower your standards for a bug report.

But there is one advantage in the sea of bugs. If someone asked me straight after the corporation, “What is the most interesting bug you encountered in your career?”, I would be humbled in silence. But after working in a startup, a dozen such bugs immediately come to mind.

Margin for Error

Keeping in mind that there is little documentation, many bugs, and poor processes, it becomes clear that critical bugs in production are almost inevitable. Sometimes the team sacrifices testing time to quickly release a critical feature for the business. And no matter how good of a tester you are, process gaps are stronger than you. And that’s okay. Startups are about speed and compromises, not stability and certainty. Embracing the startup ideology, we must be able to quickly respond to such bugs, with no panic, without aiming for perfection. Critical issues in production in a corporation are rare events. It ends up with months of special retrospective sessions, penalties, and other horrors. But in a startup, you release a hotfix, add a test case to regression, and move on without blaming QA.

Knowledge and Growth

This one is the most personal. But if you have worked in a product team on a small block of functionality of a large application, you’ll understand me.

In a corporation, I was a strong Middle QA by grade. Still, I wouldn’t be able to answer questions like “What are the differences between Android and iOS,” “How to conduct UI testing” or “What is the difference between alpha testing and beta testing.” Because all these things were outside the scope of our team. Our small front end didn’t come close to any platform-specific features. We used ready-made UI components, and testing them was not our job. Moreover, we knew nothing about the application’s testing groups. So, leaving the corporation, I had a very specific set of knowledge.

In a startup, there’s an opportunity to see everything that has been happening beyond your department. You can explore and come up with ideas everywhere. What you may lack though is a direct mentor. Then all the decisions about what needs to be done become your responsibility. But in such a setup, you won’t have to wait for quarterly assessments to start working with a new stack of automated tests. You won’t have to wait several years to become a manager and start designing processes. You’ll have to do everything from scratch and grow painfully, but much faster, and that is something.

2. What is there to take from a Corporation?

Being able to scale processes is cool. That’s why the opportunity to see “big” processes in corporations is worth it.

Of course, sometimes there isn’t any room for scaling. When your product has, let’s say, one use case, one thousand users, and a team of five people, there is no need to intervene. But if a startup is doing well, sooner or later these numbers will critically increase. The responsibility for product quality will grow. At the same time, you will need to maintain the pace by releasing more features. In such moments, “intuitive” processes based on discussions and testing with just a keen eye will crumble.

I was hired as the first tester in such a transitional period. I was stunned by how unclear it was what the team was doing and how.

This became the trigger for the whole story of developing the release process in Brickit. Spoiler: not all big tech practices will survive in a startup, but some of them definitely can. Trying something like this is one of the most exciting and challenging opportunities for QA.

3. A few more practical tips before I go

• Compensate for the lack of onboarding with ice-breaking 1:1 meetings with team members and regular meetings with your manager/team lead, if there is one
• Don’t try to document things like you did before. Don’t try to create executable test runs like you did in Jira if you are now working in a “Notepad”-like tool such as Notion or Trello. Create a flat list of test cases with “to do” and “to expect.” For bugs, focus on the essentials: title, reproduction steps, expected/actual results, screenshots/logs, and status. That’s it!
• Rely on ad-hoc and monkey testing approaches as much as you rely on test cases based on documentation. Things will regularly break out in most unexpected places.
• If there is no inner documentation available, take advantage of someone else’s (especially if you are testing an integration). For example, for subscription model implementation, you can find all the official docs online from Google Play, iOS Sandbox, and whatever service you integrate (RevenueCat, Adapty, etc.). In a corporation, you may lose the skill of googling since all the relevant information is stored in a closed knowledge database like Confluence. So don’t forget to Google!
• Put your own oxygen mask on first, before attempting to help those around you. Before thinking about improving processes, organize your own documentation: bug tracker, release tracker, test plans, etc. Send a couple of releases to production.

Outro

The combination of corporate and startup experience definitely makes you an interesting candidate. According to my colleagues’ stories, transitioning from a startup to a corporation is much easier. I want to highlight that either way it could be difficult at first, and that’s okay. You’re definitely braver than many!

Toodaloo✌️