Set up QA Strategies For Startups

Establish “any” QA process

Heads up! If you are managing the QA efforts in your organization, prepare yourself for coordinating many departments. Keep in mind that each unit in the organization will have its ideas, requirements, limitations, and constraints. It will take time — embrace the process.
You will need to persevere, have a solid vision, and be able to negotiate, articulate your ideas well, and take the lead on most of the things you want to achieve — but these are general qualities you need to have as a leader.

There may be many problems that you will need to resolve (either on your own or with the help of other departments). They may include:

•establish release dates, frequency, steps
•figure out product versioning strategy and implementation
•build continuous integration
•set up a testing environment (servers, builds, etc.)

That’s a lot to tackle. Start simple.

Define QA role, QA goals, and a vision

When I started setting up the QA, we already had some automated e2e tests and a test management system in place. Other than that, we had no QA process at all and didn’t have definite answers.

Once I established the baseline, the first thing I did was putting together a short, mid, and long-term visions. I knew that the long-term vision should be as broad as possible because everything may change before I have a chance to get to it.

Roughly speaking, the short-term (1 month) plan assumed we would cover all existing features with manual test cases. At the same time, we started an on-schedule, monthly release followed by a QA hardening.

The long-term vision was all about Continuous Delivery, and integrating QA in multiple aspects of the software development lifecycle across the organization.
We defined four main QA goals:

•Increase product’s quality, stability & our confidence
•Reduce the QA effort (cost)
•Define QA processes and best practices
•Improve release process

The 3F Technique: Focus, Focus, Focus

Startups have to operate at a high pace with drastically limited resources. Working efficiently in such an environment requires knowing precisely what to do. Otherwise, you are wasting time and potentially risking the company’s failure.
When starting to build a QA process in a startup, identify all “low-hanging fruits” first. Don’t waste time building complex systems. Deal what’s most pressing and can be done fast. Aim at quick, powerful wins. Whenever possible, reduce the number of things you do until you can take care of them.

If, for example, you’re struggling with on-time releases (which puts at risk contracts with your customers) focus on shipping your product on-schedule. Find a way to minimize the effort of assuring the release’s quality that achieves the best outcome possible.

Here is a bunch of ideas for cutting corners in the first month:

•reduce the number of browsers you test (if possible, focus on most used ones)
•focus efforts on automating critical flows or building a manual test plan — not both
•ditch all automation that takes too much time to implement or maintain — focus on the critical ones
•test wide vs. deep — don’t bother testing dozens of corner cases — you will have time for that later
•if you have many products but few people, test only critical products — that will help you build processes and experience to scale to other products later

Humans & Robots

When it comes to testing the application, there are — pretty much — two approaches:

•test manually
•automation

Choosing what works for you will depend on your team structure obviously (if you don’t have people capable of writing code in your crew, automation is not an option). Another aspect to consider is that manual test cases are easy to write but are slow to execute; automation is harder to write but faster to execute. You need to choose between those two parameters.
Focusing on one of the approaches first makes a lot of sense when you begin.

However, you may later want to mix the two.

If I were starting a QA process entirely from scratch, I would recommend writing several automated test cases first. Once you get critical paths covered (logging in, signing up, etc.), I recommend you start using a Test Management System (TMS) to track manual cases additionally.

There are goods reasons to use TMSs. To name the few:

•adding manual test cases to automate when you have the time
•calculating test coverage
•documenting existing features
•designing release test plans
•performing manual (and automated) test runs
•monitoring regressions

Wrapping it all up

Introducing a QA process at a startup is possible, and (at some point) necessary.
Communicating your goals and process across the board, and assuring things work the way you planned is hard. QA is all about teamwork. You cannot do it alone.