To find the perfect process, you need to balance structure and flexibility around your unique situation. I can’t express how important it is to be constantly vigilant, however, as some tools and processes may sound great but actually be overkill and counter-productive for smaller teams. Alternatively, overly simple tools can be woefully under-powered for large teams with complex demands. Similarly, formal processes are often necessary for large teams but serve as little more than red tape for smaller more nimble teams.

Everything should be made as simple as possible, but not simpler.Albert Einstein

No matter which situation you’re in, small or large team, it’s always best to start as simply as possible and only expand your tools and processes when it’s clear that you’ve outgrown your existing setup. It’s much easier to add complexity to a process than it is to remove it. But add too much process, and you’re just adding red tape. So how do you know what’s right for your team? It depends, but we’ll touch on some of the factors you’ll want to consider.

Team

Skillsets & Backgrounds

One of the most important considerations when choosing tools and processes is understanding the background of the people that will be using them. While developers tend to be adept at learning new tools and processes, non-technical team members aren’t always so comfortable. One of the biggest challenges that we’ve seen again and again happens when developers choose advanced toolsets based on features, but the non-technical team members end up being overwhelmed by the tools and opt not to use them.

This is particularly common for agencies. Your internal team is likely incredibly technical and adaptable, but agency customers are more likely to be less technical. (That’s why they hired you, right?) So when testing rolls around and you invite your clients or designers to participate, they’re often confused or overwhelmed and decide it’s easier to email issues instead of learning a new system. The result is that some issues slip through the cracks, or someone still has to manually log them.

Team Size

Team size will also play a factor in your decisions. And remember, this isn’t just the number of developers and testers on your team. It also includes clients, stakeholders, project managers, designers, and anyone else that will help with the project. Larger more specialized teams often need different sets of functionality and may need deep reporting or easily configurable views into your team’s issues. Or if you’re a solo developer, a text file might be all you need.

Another consideration is user-based pricing. With issue tracking, you’ll have some team members that use the application regularly while others may only be involved for a single project or short time period. When you have to pay extra or upgrade just to add someone for a week, you may tend to invite fewer people, and ultimately find fewer bugs. Alternatively, as your team grows, your costs may grow drastically as well.

Team Structure

Will everyone on your team be internal or will you have external clients too? Do some need access to some projects but not others? Will you have a dedicated team of testers? Are they part of your organization or an outside company? Having enough flexibility to configure people and projects to control access and participation will likely be important sooner rather than later. Make sure that your tool supports organizing users in a way that works for your projects.

Team Location

With centralized and hosted tools, location is becoming less relevant, but there are times where it can matter. For instance, a team with everyone in the same room can get away with using a whiteboard or sticky notes to track issues, but a remote team needs something centrally accessible.

If you’re lucky enough to have everyone in the same room, it’s often best to start out low-tech with the afore-mentioned whiteboard or sticky notes to get a feel for your team’s process. Then, you can use your real-world behavior to help you choose a tool rather than focus on hypothetical or potential needs.

Technology

Application Domain

The biggest technology impact that we’ve seen over the years is your domain. If you’re building software for space shuttles or pace makers, you’re likely better off with an incredibly tightly controlled development and testing process. However, if you’re building marketing web sites, integrating with off-the-shelf CMS’s, or even simple web or native applications, the tool that enables the most productivity is probably the best. In most cases, the extra complexity of advanced tools will only get in the way.

Platform

Your platform may affect many of the tools and processes that you use. For instance, the release process for a native application is entirely different than that of a web application. Or your product may include components of both. Testing and reporting issues from an iOS or Android phone will be a different experience than reporting issues for a web application.

Releasing updates depends significantly on your application’s platform. For instance, on iOS, you have to upload an update and wait for approval. With web applications, you can release constantly. So for native applications, you may spend more time on focused exhaustive testing periods while a web application may just be constantly testing and releasing updates daily or even hourly.

Technology Stack

Different tools work better with different stacks. While some tools are designed to work regardless of stacks, some of the best tools are great because they specialize on only a few stacks. Your source control, build process, static code analysis tools, and others will integrate deeply with your technology. While you probably won’t be changing your technology stack to use a specific tool, it’s worth keeping in mind if you’re still making decisions on which stack is best for your situation.

Codebase Size

Your codebase size will affect your overall approach to creating or improving your testing strategy. For instance, if you have a gigantic application with no previous testing strategy, implementing automated tools as a first step may be overwhelming and kill morale. Instead, you’d likely see better results adding a manual testing process to each release and then expanding your automated testing after you’ve begun to get everyone on board with the idea of improving quality.

Of course, if you’re starting fresh with a new project, you can set high standards and commit to doing things right from day one. If you have a small application, you might be able to retrofit some automated tools with a day or two of work. Regardless of your situation, the goal is to temper your expectations and just focus on constant improvement.

Audience Platforms

Finally, the platforms used by your customers will have a significant impact on your testing strategy. Android. iOS. Windows. Mac. What about browsers? Internet Explorer, Safari, Chrome, Firefox, Opera, and all of their mobile variants are increasingly on equal footing. If you develop on Mac, but half of your customers are on Windows computers, there could be a significant hole in your testing strategy. While virtualized testing can help, it’s often useful to have a dedicated testing machine to get the most accurate understanding of your customers’ experience.

Mobile devices are another key aspect. With tools like responsive design, it’s often tempting to test exclusively in a desktop browser with a smaller window, but that doesn’t do a great job of simulating the mobile experience. Similarly, while developers are more prone to frequently upgrade their devices, your customers may be less likely to do so. Are you testing on devices that are more than two years old? Do you know how your product performs on those devices?

Browsing on a desktop computer is a completely different experience than browsing on a mobile device. So if you have a lot of mobile customers, even a small device lab can really help with testing the overall quality of your product.

Tools and processes aren’t one-size fits all. It’s often tempting to use the tools used by larger organizations because they’ll have all of the power and be something that your team can grow into, but this can be a case of over-engineering.

Alternatively, if you have a large team with complex processes selecting simple tools with the hope of simplifying your workflow can backfire just as easily if the simple tools don’t support your workflow the way your old tools did. In either case, the tools should support the process to which you’re committed.

So now you’re ready to start thinking about the logistics of setting up your quality assurance strategy.