Intro to Insane Startup QA (Part I)

The Asylum is open.


Welcome to my first post on my new blog. A quick introduction is probably in order I suppose. My name is Drew. I've been working in Software QA for over ten years. Sorry, but if you don't know what QA means, you're probably not going to like this blog that much. I've worked at small, medium and big companies at one point or another and by far, the most enjoyable times I've had have been at startups. Why is that? Don't know for sure, maybe it's the energy, the excitement of being part of something brand new or maybe I guess I'm a glutton for punishment...or an idiot...or, well, insane.

Anyways, this blog will be about my trials and tribulations at my current gig, HubSpot, as well as reflections back on past experiences at other companies, and I'll share stories that I've heard from other people. Basically I'll post about things that interest or amuse me and I'll try to share some of the challenges I face and tell you about how we're attempting to overcome them. I'll be merciless on the guilty, make fun of the non-believers and in general, try to be occasionally funny...oh, and maybe we'll both learn something along the way from one another. It's a very helpful trait to have a good sense of humor if you work in QA at a startup.

Ok, for those of you that have never worked at a startup before, here's the 30,000 ft. view (and yes, I will abuse and re-use old & new buzzwords and terms that I've heard over the years, that's the "net-net" of it my friend):

• Startups are companies that don't have a lot of people to do all the work that needs to get done.


• Startups typically don't have a lot of money, but they will give you stock options, free food & sodas,and occasional pillow talk if the project is at risk of missing the date they promised.


• It is a myth that you have to work a lot of hours at one. Wait, no, that's true, never mind.


• Usually they're building their 1.0 product, unless they're a Web 2.0 company, then I'm not too sure what version they start with.


• Usually they're wicked smaht people working there (yes, I live in Bahstan)...they have to be smart in order to get all the work done (see first bullet).


• There is a lot of pressure typically because of some richer-than-they-need-to-be Venture Capitalist who wants to see a return on their investment before Britney Spears returns to re-hab.


• You get to know your co-workers really fast, mainly because they're sitting so close to you that they're practically in your lap or sharing your monitor.

Ok, there ya go, that's a good enough primer on life at a startup...now...how about QA life at a startup you ask?

The unique thing about working in QA at a start-up is that you're typically brought in well after a product has been prototyped, demoed and revisioned about 200 times as they figure out all the whiz-bang features that they're building. There are requirements for this wonder app, they're just in emails that you don't have, whatever open source bug db they installed when they got tired of tracking bugs by email, in the nether-regions of IM-land or they're inside of someone's head. I know what the QA purists are thinking...this is contrary to the mainstream QA battle-cry of "QA should be involved from the very beginning." Well, reality (yes, I said R-E-A-L-I-T-Y) is that if you're starting up your company and you have to "build" something, most QA engineers aren't developers that build applications, so you're going to hire developers instead or you will not be very successful at getting venture funding if you don't have a product...or so I'm told.

Well, by this point they've convinced some VC to throw some money their way and now they can start to hire more people to market and sell the wonder-app and they can actually start to think about things like office space, 401k, better health-care, etc...

So, they're getting closer and closer to wanting to launch this puppy and a few of the sales people they've hired to sell it have said that the wonder-app is really cool, but really hard to demo because of all the issues with it and only one or two people in the whole company actually know how to use the thing end to end.

Uh-oh, it's time to "test some quality into the product" and fast, we need to get some QA in here pronto!

Enter QA.

(to be continued...)