In the 1990s, I recall (perhaps wrongly) one of the Microsoft books talking about one tester for every two developers.
At the tail end of the 1990s, I worked as a developer in a group with a QA team, and they caught bugs, including ones where it took me a while to even see there was a bug. Which means that I couldn't have written the tests for them.
Nowadays, I do consulting/contract programming, and my clients always do manual testing of what I shipped them, before signing off on the payment. That's in addition to the unit tests I write. And they find bugs.
So, what does it mean "if you have a good process in place for automated testing you can do just fine"? Does it mean that it's okay to let your users be your QA group, since there's a process for handling that?
Or is it something else I don't know about, given that I'm a one-person developer?
When I have been on teams that are doing a whole vertical as part of a product that includes UI work, it has generally been nicer to have real dedicated testers on the team.
So because I think you can't really generally say what is going to be enough, I think you just need to ask people about their process and decide based on what the project is.
Unit tests: certainly good, but on one team I recall there being the phrase that a good integration test was worth 1000 unit tests: if the individual parts work but they don't work together correctly as a whole system then what practical value was our unit test?
Managers complain about spending so much money that's not in the budget but how much does turnover cost you in terms of lost productivity and recruiting fees?
(And speaking of recruiting fees: why are companies willing to pay $20k or more to recruiters but only a $500 for a referral from current employees? Recruiters in the midwest pay $1000 or more for referrals who get hired -- companies are telling their employees that it's in their interest to tell their qualified friend/lead to contact the recruiter instead of doing an internal referral.)
