Release features without burning customers

What it's like having your workflow destroyed

We’ve all been here: it’s Monday morning, you’re excited to start diving into your workload (that’s piled up from some weekend warriors) and you open up one of your favorite tools for getting the job done. You’ve probably spent about an hour, nearing the end of your first major task of the day and then BAM. That one feature you need to finish up this task is broken. To make matters worse, the workaround you’ve been using seems to have disappeared.

Now, this kind of story is the beginning of a nightmare for any startup founder. Imagine now this kind of problem is multiplied by thousands of users, then what? You’re going to have endless support requests coming in, angry customers, and some may even start asking themselves if there’s a competing product they can use. This kind of problem sucks to have, especially since the best startups have products their customers love to gush about during happy hour.

Why keeping your customers happy is hard

Avoiding this kind of situation is challenging because of the conflicting constraints in the startup life. Right? You’ve got a laundry list of features you’d like to have released yesterday and customers just keep wanting more. They’re sending you money, checks are flowing, but disasters like above are not what you want weighing down your company. The last thing on your mind is probably worrying about QA and getting muddied with too much process. On the other hand, you don’t want to be the next CrowdStrike, crashing millions of computers, shutting down flights, and breaking healthcare systems.

How to get started with agile QA in your startup

So what do you do? Well, unfortunately, QA has gotten a bad name for itself because of previous waterfall management styles. It’s 2024 and everyone’s agile, so how do you make QA agile? Here’s a breakdown of how you can get started:

• Adding QA to your ideation and design process: Having someone QA your product designs, or even bouncing your ideas off of before handing it over to your designers or developers can significantly accelerate your product release velocity. This is because having someone with this adversarial mindset of looking for problems before they are implemented is extremely important.
• Make sure you have the right QA person on your team: Now, effective and constructive criticism is a delicate process. You probably want to make sure you are working with someone who’s interested in building up your vision, and is not acting as a drag. It’s easy to find a critic for any solution, but finding the right person who can ask hard questions and inspire you to find their solutions to the most critical workflows is extremely important.
• Understand when it's time to use manual QA and test automation: This is a hard question to answer in general because it's largely dependent on your vertical and what kind of product you’re building. For example, if you’re building a product as a market research aid and haven’t even found product market fit, it’s probably a bad idea to start implementing test automation. An easy way to figure out when it’s time to start testing is when you start noticing your developers spending a lot of time fixing bugs, or if bugs keep reappearing.
• Add QA where it improves velocity: The main point you should be considering is when and where having QA will increase your product release velocity. For any startup velocity impacts how quickly you find product-market fit and how quickly you can fulfill customer requirements. It’s easy to accidentally overlook QA until you’ve hit a significant bump in the road because of being so focused on your initial velocity. The main pitfall is having your velocity slow to a crawl once you’re spending time fighting regressions and squashing bugs. Also, if your customers are angry because new releases keep breaking features they use, they may start looking for another company to work with.

How to structure your test automation workflow

Once you start integrating automated testing into your SDLC, it’s essential to get this process right. Many companies make the mistake of either spending time testing near the end of their feature release, or just offloading that work onto their developers. Both of these strategies are critical errors because you end up losing a ton of time.

For the first case, you can always have your testers working in tandem with your developers. What they need from your team is the requirements developers are implementing, and the ability to collaborate with developers while they implement test code. It's imperative this machine is set up correctly, but once you have this synergy, your developers will be handing off their code with plenty of test coverage. Additionally, any challenging technical conversations between developers and testers will be much easier to have at this point because the knowledge of their current project is in their head. It’s always challenging to dive into the nitty gritty technical details months after implementing them. For all you know, your developers could be working on something different and have already forgotten many decisions and details.

In the other case, having developers implement tests after writing up features can be a serious drag on their productivity. This is because many are under the expectations of releasing features yesterday, so it’s easy to skimp on implementing the correct amount of tests. Also, the context switching can hurt performance as well. Your developers should be laser focused on releasing features, not switching between writing features and then battle testing them. That gets exhausting and slows down product velocity. Instead, you can have explicit QA team members go ahead and write tests while developers are implementing features.

When you’re at the beginning of this part of the release cycle, you’ve already got the designs and the specs, it’s not hard for your QA to give your devs some pointers on what they need. Like the specific metadata the devs should integrate into their React components. There’s not a whole lot preventing testers from doing their job in tandem to developers, so why not let them.

How QAComet helps you get started with agile QA

The other headache then is QA is just another part of the product dev process you have to manage. But that’s why you outsource to someone like QAComet, and let them integrate with your team. They have the expertise in making sure your product is up to snuff. Also, they will know how to properly set up your test automation suite so your developers can release features without getting annoyed by flaky tests. If your developers are tired, and mentally are finished after implementing a feature, how much bandwidth do you think they will have to write a test that doesn’t flake out in your CI system? It’s always a bummer to think you’re finished with a feature, only to find out there’s some nasty bugs sitting inside, frustrating customers. Then you have to go back, fight fires, and deal with any of the fallout.

Instead of dealing with that tedium you can funnel out this work to a service that lets you focus your attention back to what matters the most, building products people love. Having an expert manage this part of the product development process lets you and your team recover some mental bandwidth and invest it in other areas. Also, having a top-tier product release process helps keep morale high. It’s more fun to tell your friends about the new features your team got to release this week than it is to share some of the battle stories about how they spent hours putting out fires.