I'd say it depends on the sort of application you're developing.
In the next couple of weeks I'm due to release a boxing game (shameless plug: leatherthegame.com), and other than myself my only tester has been my cousin.
Having worked on the project for over 3 years I'm aware that there are areas where I "can't see the wood for the trees", but I am confident in my own knowledge, and only wanted an external viewpoint to see how a noob would see things from afresh (both in terms of not having used the app before and also him being only a lite-casual boxing fan, so he wasn't up-to-speed with some terminology).
I know full well that once its released the proper boxing fans will get in touch, and I'll change things post-release from that feedback, so my strategy is very much a post-launch end user feedback one. In an ideal world I would have had more friends who could help me test it, but there's only so many opinions I can factor in pre-launch, and managing their experiences and feedback would have been a mini-project to manage purely by itself. When already time-constrained with launch schedules, app store listings and last minute bug hunts and device optimisation I couldn't spare the time to manage a phalanx of testers.
This has been a passion project/scratch-my-own-itch project, which is why I feel more secure not having many outside opinions. If you're building something more strategic, to fill a target niche in a specific market say, then my approach will DEFINITELY NOT WORK. In this case you'd be best off firing out a message on LinkedIn or something like that, asking for would-be best testers.
I used to work at a place with an ostensibly open-plan office, but with lots of wall panels on wheels that could be moved to form little work areas. These also doubled as white boards.
In short: I like modular, configurable workspaces, with lots of whiteboards.
In the better places I've worked "getting things done" was the priority. The places that valued code quality always overshot deadlines by enormous degrees (over a year late on an 8 month project, for instance).
Typically I find that code quality isn't too vital, as the majority of big-co systems tend to get re-written from the ground up every few years, rather than modifying and evolving the existing system.
Seems that way at most large orgs. A friend of mine was talking about how some random support desk person will just log in, kill a specific logging process and manually type the path to run it in at a root shell, which inevitably borks things, and due to it happening multiple times a day he has written a unit file so systemd will actually kill the process, fix the now wrecked permissions, and start the logging daemon's unit file properly.
But, the real question is why does a support person have global root access to every server in a large enterprise?
Well, because it "used to be like that" and nothing is as persistent as a stopgap solution. Fun story: Used to work at a 8 year old, heavily growing ad network in customer support and hadn't even officially progressed to engineering yet, but people heard stories about my PHP hacking skills.
So one of the old-timers came by (really fun and totally random guy) and was like... "ah, there's this one thing I thing you could help me, I'm trying to find a solution for these tracking error reports. wait, I'm giving you access"
A few minutes later came my email together with password over MS Lync, and nothing else. And I waited for him to come by with some requirements.
Which of course didn't happen. But what happened instead was that the newly minted Head of IT came by who was tasked of cleaning up the mess after the acquisition and introduce a proper process.
He looked at me very earnestly and just when I tried to think hard what I did wrong he blurted out "WTF ARE YOU DOING WITH YOUR LIVE DB PRODUCTION CREDENTIALS!?"
In the moment I realized what that guy gave me, it was gone already unfortunately.
So long story short, as time goes by and companies grow, there are very different approaches at "getting things done" ;-)
I'm afraid I have to agree; the ones I've worked with have all been characterised by terrible code quality.
Perhaps the key thing is a tighter attitude to specialisation: most Indian (and, for that matter, far east Asian) development teams tend to have a "we can do everything across a billion platforms and techs" approach, where it might be better off concentrating your offering down to a few key techs, and really doubling down on the quality of those.
