What's your experience working in a Startup as the first QA member?

🙋 Questions
, ,
1

I’m interested to find out how the experience is like working in a startup which is established or in it’s early stages.

I feel like it would be a good opportunity to work in a startup as a the first QA but I’m guessing it would have it’s challenges.

Most of my QA experience has been in large companies that have well establish tools, processes for testing.

What would be the pros and cons of a startup company?

2 Likes
2

Yes I have had experience in this area and the skill is being able to start and learn about the products they use, for familiarity.
Don’t over-think it by considering Full documentation, strategies, test plans and test cases.
Simply, whilst familiarising with a product - call out the main areas - what are the key areas that need to “work” for this product
Use that as a guide in creating your own smoke test - High level test that does not take long to run - If you see any issues, take a note of them in relation to what you expect to see happen, what actually happened with steps
Use something like excel to begin with
Over time, everyone will see the value in what you are doing and you can evolve the process by looking at test case management tools etc

The positives is that you can show value quickly - do that by highlighting the first issue - as this is something that would have slipped through the net without you being there. Also it is likely to be a less formal environment so the time between code being deployed into an environment for testing through to being deployed to prod may only be hours (whereas there is loops to jump through with some old school organisations)

The cons is that if you used to full formal process - this would be a culture shock

4 Likes
3

I would consider myself a “startup”. Our team is 2-3 people or so.
Doing QA is super important for us because we produce a desktop app that is cross released on 3 platforms, windows, mac, linux debian.
We also maintain front-end website, APIs, and chrome extensions…that’s a lot and it’s hard to test it all!

Doing QA on the desktop app is really important:

  • We have e2e tests that ensure that the basic user-paths/happy-paths are always working after release.
  • We run these e2e tests automatically before release is merged but also during a pull request (smoke tests and regression tests)
  • We set up monitoring for a lot of other services, occasionally we go and test these things (i.e. API and backend)
  • We store all of our test knowledge (including metadata) in a tool similar to a wiki / Confluence / Notion, including references to code in Github
  • When a test fails, we go investigate it ASAP based on criticality, esp if for some reason it’s after release. Some tests are okay to fail, for example - if a certain page is a 404 from the /doc website, not as bad as if the login on the desktop app hits a problem on the backend…that’s way worse for us specifically!

Some bugs are really hard to catch, i.e. one day we realised we had broken an auto-update feature, leaving all the people using the app in a weird situation because they had to update the app by hand…ouch!

2 Likes
4

From personal experience, depending on skillset, you may end up working on things besides base/true QA. Or be involved in multiple teams and projects.

I worked at an organization where I was originally tasked to help with scale testing their cloud components. I also ended up building some simulation and test tooling there, and also ended up working with project/feature teams I originally wasn’t working with, and moved on to doing software development there.

I wasn’t the first official “QA” member though, but I was the first (and only) of what you could call a (cloud) scale/performance test engineer. And we never did build a test team or dedicated test role for this area, so I still helped out when needed for scale/performance testing, which wasn’t done often due to resource constraints and complexity of performance testing cloud components at scale.

2 Likes