QAing in a startup

After 8 years in big companies like Mercury (R.I.P) and Symantec I have started working for Delver, a startup company, in late 2007. After 15 months of starting and running the QA team I am wiser about QAing in a startup company.

1. Testing is Testing is Testing. Good QA is about methodology: be methodic in your risk analysis and in your tests. This principal doesn't correlate to the size of the company. In Delver we won't write a test case to a feature if it's not documented. I don't settle for oral briefing or email overview. No document, no test case. Easy, really. On the same principal, no testing without a test case, even for small features.
2. Speed over quality. In a startup company the emphasis is on fast development with speed being first priority, quality second. This perspective dictates more investment in speeding up the testing process. We used the following methods:
   
-Automation for testing relatively stable components
-Testing new components outside the main build if the build is not ready
-Issuing "non release" build for focusing on delicate features

3. QA freedom/No safety net. Another aspect of speed oriented, developer dominated organization is the freedom for QA. Since the focus is usually on the developers the QA team in Delver enjoys more professional latitude than what I have experienced on larger organizations. The flip side is the lack of testing peers and no organizational testing history. There is no safety net for me in Delver and when I make a methodical mistake usually there will be no one to correct me. This is an exhilarating feeling, but it's also a scary one. Like all good thrills, I guess.
4. Smaller budgets. Big, commercial testing software is expensive. Startups don't like "expensive". Startups like "cheap" or even better: "free". On one hand this seems like a major limitation (oh, who am I fooling. It is a major limitation.) but on the other hand it's also a challenge and a cool one. Finding a 300$ alternative for a 80K$ load testing suite is a personal victory and shows me that I can overcome seemingly seemingly impassable hurdles (financial, for example). In the future I'll dedicate a post to cheap and free tools we use in Delver.
   
5. No bureaucracy. Well, this one is obvious but it's still cool. When I need to ask something I can go to the guy and ask him. No email to another office, no phone calls to another continent. Go to the guy. Ask. End of story. If I want to hire a candidate I can give him a contract a day or two since the first interview. If I need a new license I simply go to the room of the guy who signs the checks and ask for the money. Simple. Fast.
6. More flexibility in reporting bugs. I don't open a bug for every problem we encounter. Since the company is a small one, when I'm not sure I can simply go to the room of the developer who is responsible for the code I found the problem in and verify whether it's a bug or not. This can be done in larger organizations as well but sometimes the relevant developer is not in the same building. Or town. Or continent.