I know a Lead Tester who holds a view I quite like, which is that QA shouldn't be seen as existing as a team or a step, because everything is QA.
- You do peer code reviews, because that's QA.
- You do continuous integration, because that's QA.
- You do test driven development, because that's QA.
- You do manual testing of work before it's handed off to someone else to manually test, because that's QA.
- You do pair programming, because that's QA.
- You provide customer support, because that's QA.
- You regularly meet with with your client to establish you are fulfilling their requirements with each iteration, because that's QA.
All of these things are Quality Assurance. QA Isn't a step or a team, it's a core tenant of professionalism and craftsmanship.
This is effectively what we do, aside from the building toward test driven development. We have only 3 main developers, so we often work together and review each others' work. It definitely helps weed out some design flaws or bugs. We also usually contact customers directly related to requirements and deployment of code, and this also usually helps a lot in weeding out problems.
Unfortunately, our typical development process tends to miss a lot of rather obvious bugs. Things like uploading a .xls file where a system expects and only works with .csv files. Maybe those are things we should just catch when we stop, step back and think about the interface and other components.
Test driven development is something that I've wanted to push our company toward for years now though. I don't know how much it would help in cases like this, but stopping to think of test cases to write probably would help identify obvious things like, "Okay, what does the code do if someone uploads a Word document instead of a .csv file? Oh, wait... or anything but a .csv file for that matter?"