How important is QA testing in software development?

I think it's a warning sign. Developers make lousy QA testers. We're optimists-- we think the code is going to work; and testing is boring. So they are either wasting developers' time or undertesting.

As a QA guy, I've found very few developers who can write tests. It's just a different skill-set and more importantly, a different mindset. Most developers see test development and testing as wasted time then they could be writing new product code. Thirty developers writing code without any formal QA team and/or process seems like a very bad sign. Maybe some of them are good at testing but I'm sure not all of them. And even if they do test their own code, who's testing the integrated builds? Every single unit test can pass and you integrate, build and fire it up and the whole thing crashes and burns because of conflicting assumptions between components. And who's testing different platforms? Or doing upgrade testing? Or stress testing? Or scalability testing? Or fault tolerance testing? Or power fail testing? If you don't have a dedicated QA team, the answer to those questions is usually, the customers.

It's #10 on http://www.joelonsoftware.com/articles/fog0000000043.html. I'd find it concerning. As Joel says, they're either shipping buggy code or using $100/hour programmers when they could use $30/hour testers. Also, the programmers will get bored and go somewhere that they get to program 100% of the time, instead of 66% If it's otherwise perfect, I might be tempted, but if it seems to have other issues, you might want to keep looking.

It would worry me. I worked for a company that laid off all QA in my division. The devs were expected to test each other's code. It was a nightmare and if I recall correctly it was less than a year later that they started hiring QA again.

It's worrisome. I'd find out what exactly they mean by "engineers are responsible for QA" but I can't think of any answers that would make me feel more comfortable. I would expect a company of 30 developers to have at least 3 dedicated QA people, depending on the type of software they're developing. Unit testing has its place but it's not a magic bullet; if you're at the scale of 30+ developers why aren't you doing anything more than unit and acceptance testing? Dedicated QA personnel can't really just be replaced by "make the engineers spend part of their time doing QA" unless you want crappy QA.

This is the situation at my current company and it is not ideal in any way. We have test plans written by developers, but it is very easy to write a test plan that you know will pass, especially if you must have the rest run by a third party, usually an unfortunately marketing person who would rather be doing something else. It's way cheaper in the short term to farm out QA to your customers, but I don't make any claims for its long-term prospects.

Depends on the kind of software. It's not uncommon for companies to not have QA departments (or to have very small ones) if they're making, e.g., consumer-facing web-based stuff that can be rolled out gradually and patched quickly and isn't likely to have disastrous consequences for anyone if it fails. I'm not saying that it's an optimal methodology, but I know it's the methodology of a number of successful companies and I don't hear the developers complaining too much over it.

I could take a job at a place that had no QA department per se, but not one that had no QA people whatsoever. I have worked on a project where I developers were made responsible for their own QA, and quit, partially for that reason. If I wanted to install four different versions of windows in half a dozen languages each and verify that UIs looked correct in each, I would have gone into QA in the first place. But that is not what I (nor probably you) want to be working on. One of my favorite thing about my current position is how thorough our QA is and how many bugs they actually catch. I would spend half of my time doing work that I don't want to be doing (and therefore hating my job) if it weren't for them.

It's not a good thing, but it's not at all uncommon, even in much larger companies. Even good ones.