Is software testing actually done on professional projects?

Question

I have a few questions about software testing in professional development environment on real-client projects. Projects developed by professional software companies that are actually going to be sold.

Over the years of my professional career I've seen very little systematic testing done on real life projects. Especially bespoke projects. Even though projects were very complex, no actual testing was done (beside ad-hoc testing). At least no proper testing as everyone's trying to convince us that should be done.

I estimate that less than 10% of projects are actually methodically tested where there are dedicated testers part of the team and developers write automated tests (unit, integration, regression etc. tests). All others are not somewhere in between, but rather either just ad-hoc tested or not tested at all.

General questions

I would like to ask some questions about your experience:

1. What estimated percentage of projects you've been involved with have been methodically tested?
   • using a dedicated tester
   • writing unit/integration/regression/other automated tests
   • test coverage tracking
   • test result measurement
   • etc.
2. Which type of projects are normally methodically tested?
   • projects for particular clients (bespoke/general public projects)
   • general projects that will be sold afterwards
3. Which industry aimed projects are normally methodically tested?
   • Finance
   • IT
   • etc.
4. What's the minimum project size (in terms of team size) when projects start being methodically tested? My experience is that the larger the team, more testing methods have to be implemented. Unit testing in particular.
5. How thoroughly should a team implement various methods of software testing? How to decide which tests should be implemented that would actually benefit in certain projects (code complexity, team size, etc.)

More questions in a structured manner

There are even more questions in my thesis questionnaire I'd like to ask but don't fit into Stackoverflow. And shouldn't be, while they're not relevant to this particular question. I've collected them in this Google Docs questionaire about Software testing. I'd be very grateful if you'd take the time (3-5 minutes) to complete the questionnaire and help me get sufficient invaluable data for my thesis.

What's valuable in here for others?

[I hopes of reopening this question]
I know that information gathered by answers to these questions is valuable to any project analyst planner at the very beginning of the project. If someone lingers between something should be or shouldn't be addressed this info would be very valuable. Others my find other useful info as well. This one's just from the top of my head.

(Not to mention that management personnel could more easily mitigate TDD evangelists not to overly implement every aspect of their perfectly tested project dream)

Answer 1

IME the amount of testing is directly correlated to the impact of failures.

If a product crashing is only a mere annoyance (such as a web browser), testing seems to be minimal. If its going to cost the company money (i.e financial processing) then it gets a LOT of testing.

YMMV though.

Answer 2

My understanding is - and I am quite willing to be corrected here - is that legally a software product is considered to be a creative work, not a capital good. Therefore it cannot legally be 'faulty' and therefore the vendor is under no obligation to make good if it is found to be flawed.

On topic:

• We only do manual GUI testing according to a human-readable test plan. There are unit tests here and there, but nothing thorough.
• There are usually dedicated testers who were not directly involved in the development work
• The products I work on are largely retail software, but for a very specific niche market (engineering)
• As an aside to the above, everything we produce has a big disclaimer: 'The user of this software for the solution of an engineering problem is in no way relieved of their responsibility for the correctness of the solution'
• Most development teams are three to four people, including the PM