Startup Testing Strategy: How to Approach Testing When Resources Are Limited
Testing is an often overlooked but critical part of development. Don’t skip it — even when the engineering team needs to move fast like when working at a small startup. Testing doesn’t move the needle but if things break, nothing is moving.
I’ve had experiences where the priority was pumping out features as quickly as possible with minimal review and testing. The bugs stacked up fast. Everyone was so frustrated and most chose to look for a new job than to continue fighting with the codebase. I know it can be tough to strive for both speed and quality, especially when the team is small and resources are limited.
Prioritize and plan project before starting
First, the company has to have a vision of what it wants to accomplish. As cool as some projects are, if they’re low in priority they’re going to be sidelined. Second, for projects I work on, I also break down the work and prioritize each task. Before starting anything I take time to plan out what I want to deliver and how to make the best use of my time.
For example, if I’m building an internal app to manage users, the breakdown might look roughly like:
- Plan out project - 15%
- Write code and tests - 60%
- Test new features before deploy - 15%
- Follow up on any additional work - 10%
Dedicate time for testing features before deployment
As I’m developing I’m also testing locally. I consider that part of development time. I’m dedicating 15% of the project time testing on a staging environment. Depending on the scope of the project, 15% for testing can be anywhere from an hour to a few days.
Before testing I make a checklist of all the changes. When testing websites, I always start with the most popular browser: Chrome. At least half of mobile and desktop usage is on Chrome. Check out browser usage data on Wikipedia. Since a few years ago there have also been more users on mobile than desktop so be sure to spend enough time testing on mobile unless you know most of your users are on desktop.
Chrome is my default browser for work. When the feature is on a staging environment, I run through my testing checklist first on Chrome. I use Chrome Developer Tools to try out the site on mobile as well. Then I move onto testing on actual devices. It’s not uncommon for very small startups to support only Chrome in the beginning. When the team has fewer than ten members supporting all browsers isn’t feasible.
I recommend starting with Chrome for both mobile and desktop. I spend the most time testing on Chrome and do a quick check on Safari and Firefox. The breakdown of my testing is roughly:
- Chrome - 80% (I test the new features and click through the rest of the site to make sure everything works)
- Safari - 10% (I test if the site loads and the new feature works)
- Firefox - 10% (I test if the site loads and the new feature works)
As the company grows, so will its testing needs. There might even be a dedicated quality assurance (QA) team. Even though the QA team’s purpose is to test thoroughly, it still wouldn’t test on every browser and device. Otherwise it can become a bottleneck, preventing new features from getting deployed. It’s common to test on a few browsers, but more than five might be too many.
Test on both desktop and mobile devices
It’s more complicated picking which devices to test on. If the company has a QA team, it most likely has analytics to see usage data, such as devices and popular browsers. The analytics can give an idea of where to start. If there are no analytics available, here’s a starter list of types of devices to test:
- At least one iPhone
- At least one Android phone
- One device with a very small screen
- One device with a very large screen
- One tablet (optional)
- Any other irregular screens, such as those with a curved bezel, notch, etc. (optional)
Bugs happen and it’s OK
Whether it’s writing code or testing, aim for great but not perfect. Otherwise you risk projects falling (far) behind schedule. You might even be wary of trying anything new for fear of ruining the perfect streak.
Bugs happen. If there’s a stable codebase and regular testing, they can also be quickly resolved. It’s far better to be able to diagnose and fix issues quickly than to never have them in the first place. Aim for great but not perfect.