Since my first job straight out of college over 20 years ago, I've solely worked at startups. It wasn't something I planned, although it might have to do with beginning my studies at the height of the dot-com boom. The countless companies offering insane salaries, benefits, and offices with ping-pong tables (yes, 18-year-old me thought an office with a ping-pong table was the dream) likely seeped into my subconscious and attracted me to them.

Startups are great places to build up multiple skills, and I have no regrets about the arc I've taken with my career. However, working at a startup is hard. The company is usually strapped for resources (especially after the dot-com bubble burst), meaning that early employees have to wear multiple hats and put in long hours in the hopes of achieving something big. There's also little time to waste in startup land; everyone needs to work as fast as possible to maximize what little exists.

For software-based startups, it usually results in a constant crunch where the company expects the team to churn out new features at breakneck speeds. These tiny teams can't keep up the pace, so corners begin to get cut. When that happens, it usually leads to testing being one of the first things thrown out the window, and it's because startups rarely have decent testing to begin with.

How Small Startups Usually Deal With Testing

It shouldn't be a shock that smaller software startups rarely have any dedicated testers or formal QA processes in place. In my career, the only place that came close was one startup that outsourced their QA processes to the cheapest bidder (unsurprisingly, it was a poorly managed disaster—a story for another day).

Testing is typically an afterthought at a startup, with the work performed by developers or anyone on the team with the tiniest sliver of time to spare just before deploying an update. On rare occasions, I've joined teams where the developers built barely enough automated testing, but those teams were outliers and not the norm. Eventually, these startups either fade into obscurity for different reasons (although typically not because of their lack of testing) or grow rapidly when they bring more employees into the fold.

Testers to the Rescue!

The lack of quality eventually becomes a bottleneck in these companies. Little to no testing creates slower development cycles and preventable defects slipping into production. Sooner or later, the team will realize that testing is necessary to maintain a decent shipping schedule without frequently battling their buggy applications. Clearly, the existing workflow isn't helping with quality, and some expertise needs to come in. That's when the organization finally makes the call—the company will bring in its first QA hire.

Hiring the first team member who focuses mainly on testing feels like it should bring relief, especially when developers are drowning with work. In the minds of the organization struggling to stay afloat, the vision of having dedicated QA feels like someone threw them a life preserver, and they can focus on building the product instead of battling seemingly endless bug reports and customer complaints. But for both the new testing hire and the existing team, it can be anything but a sense of relief.

Now, that person is responsible for implementing QA processes and following them through. Imagine you're the one thrown into this scenario—you're joining an existing team with their existing culture, working on an existing product that's been out for months or years. How does one even start to make a difference?

New Testers, You're Already at a Disadvantage

Unfortunately, testers who arrive on a team with no QA processes in place are at a solid disadvantage before their first day on the job, and it's usually all due to the current working environment that developers are already used to dealing with.

Developers think that testing will drag them down

Developers, especially in startups, are conditioned to ship, ship, ship. Their primary focus is solely on coding the next feature or patching a show-stopping bug quickly so they can move on to the next card on the issue tracker. In environments with no existing testing practices in place, testers will undoubtedly receive pushback when attempting to introduce QA processes into the mix. They'll think the new tester will introduce extra steps to hinder their progress instead of helping.

I had this thinking early in my career when I was young, naive, and thoroughly ignorant of the benefits of testing and believed coding was the only thing that mattered in software. Nowadays, with all the tools and services that help organize QA in a project, I still run into tons of developers who don't believe that having someone focusing on quality is the best way to ship their code fast.

Previous experiences affect existing thinking

One team I joined years ago had a developer fiercely against automated testing. Whenever I brought up the subject, he would instantly dismiss my comments, saying that it was a complete waste of time when we had very little to spare. I soon learned that the tech leads at this person's previous company attempted to establish testing into their definition of "done", which—according to him—caused a massive slowdown in productivity to the point where no one was getting anything done.

When I probed deeper, it seemed like the culprit was a lack of experienced people on the team to guide the process. Whether someone's reasons for thinking that testing is useless are justified or not, everyone on a team carries past experiences, biases, and preconceived notions that will affect how they currently feel about QA. Developers who, in the past, dealt with long test cycles or testers who acted like gatekeepers will likely have an aversion to anything related to formal QA processes.

Ego comes into play

No developer is perfect, and no matter how good or experienced they are, there's a solid chance that their code has a defect lurking somewhere. It can show up immediately or six months down the road, but it's likely there, and developers should know that bugs are inevitable. Many developers, particularly less experienced ones, take pride in the code they carefully craft. Some will even go as far as to assume that their latest work is flawless because it runs on their machine without any issues.

When QA points out some issue that they found, some developers will take the feedback as intended—a collaborative effort to produce the best work possible. However, others can take that same feedback and feel like you're personally attacking them if you point out the flaws in their work. I've even seen developers say that a defect is the tester's fault because of "how they tested it", whatever that means. Sadly, ego can cause a lot of friction between developers and testers.

How to Best Establish QA Processes on an Existing Team

Even if you're at a disadvantage when establishing quality processes in a team without any, you can surmount these obstacles and improve everyone's work in the long run.

Keep the changes small

The main reason for pushback that I've seen on teams introducing new testing processes into the fold is when QA wants to introduce a dozen things at once. The organization expects developers to write automated regression tests simultaneously, help with exploratory testing, review test cases, implement new bug-tracking tools, and more—all while shipping new features. Imagine if you were a chef at a restaurant and the owners asked you to design the menu, purchase the food, clean the kitchen, and fix the broken oven on top of cooking the food. It's enough to drive anyone mad.

New testers have good intentions in wanting to introduce these changes into the team, but it's not feasible. The ideal way is to make one change at a time, measure, and repeat the cycle with something else. The first action depends on what the team needs the most at the moment. As a developer, I've had success by introducing some automated testing into the project and expanding from there. Your team might need better visibility into new and existing defects or improved metrics on current testing processes. The key is to take one thing at a time and avoid overwhelming everyone.

Show the value of QA quickly

Another good reason for starting small with your changes is that it's the quickest way to demonstrate that your newly adopted processes yield positive results. Another common way that teams deem testing a waste of resources is because they can't see if these processes are doing anything. Usually, that's on the QA team because developers and other stakeholders won't actively seek this information, even if you offer dead-simple ways for them to access it. I can't tell you how many hours I've spent creating reports or other metrics around testing that no one ever looked at.

As a QA leader in an organization, it's your responsibility to show that what the testing team implements is helping everyone ship better software faster. Every company has its preferred way to receive these details. In most organizations, the best way to show this is by how much the work saves them time or money—ideally both. For example, I often try to point out when new automated tests catch something that would have otherwise slipped through to production (both saving time and money). Find what works best for your team and make sure they know about it often.

Become a trustworthy asset

Any new introduction to an existing environment is bound to create wariness among the status quo. Expect the levels of caution in software development-driven organizations without a QA team to go through the roof when throwing a tester into the mix. As mentioned in this article, developers can find a thousand reasons to distrust testing becoming a formal part of their workflow, from horrible past experiences to misunderstanding the role of QA in an organization. Essentially, they'll mark QA as an enemy to their productivity despite their best intentions to help.

Testers joining a team to establish QA processes will need to work hard to gain trust and rapport with the rest of the group. This statement is true for anyone, regardless of their role, but unfortunately, it seems more necessary for testers. In my experience, QA teams often keep themselves separate to avoid stepping on toes, but this only widens the gap between teams and stifles progress. Testers can prevent this issue by joining development meetings, listening to the team's pain points, paying attention to their comments, and trying to fix problems when possible. I understand it's easier said than done to collaborate with a new team. But your efforts will pay off with confidence over time, leading everyone to do their best work.

Wrapping Up

It's no easy feat to introduce new processes to an already-established development team, especially when you're the first tester on board. Developers will almost immediately distrust your intentions at helping because of a bad experience with other testers, thinking you'll slow them down or because they don't think they need any help whatsoever. You're at a disadvantage from the get-go at no fault of your own.

Thankfully, you have ways to avoid being viewed as the enemy. You can help ease the development team into a proper QA flow by introducing smaller changes instead of overwhelming everyone with a ton of processes at once. Keeping these changes at a minimum helps you demonstrate value quickly, which will let others see that you're there to help. Finally, communicate and collaborate frequently instead of staying in your QA bubble to build trust in the system. Once the organization finally understands the power of testing within its software development lifecycle, you'll become the magic ingredient that will help everyone build and ship better software faster than ever before.