To me, your experience sounds an awful lot like not having much experience in a production environment.
Actually on the contrary, it comes from a growing understanding that the 'production environment' is in fact the problem!
In my experience, context-switching between programming and testing gets quite cumbersome with difficult problems, and can lead to overlooking smaller issues.
Whether or not a programmer or a designated tester is actually doing the work has no bearing on over-testing. In fact I'd argue that this is more likely to occur if you use a tester.
* If I'm busy testing every single edge case I can think of, who's doing the development?*
Nobody! That's the crux of the matter right there:
1. Testing sucks, so if someone else is doing it then it's better for you, and, more importantly
2. the pressure to continue to develop new features at speeds that are unsuistainable all but ensure that you'll eventually find yourself with so much technical debt that it will kill you.
What if I'm developing a new product that has a full specification and design document, and is expected to meet customer acceptance goals?
I'd say run away from this waterfall design process as fast as possible, to be frank.
I don't see a deficiency in the development cycle if I need someone else to help test my software in a manner that I simply don't have time for.
I do. I see a development cycle where you haven't been allocated enough time!
Does your assertion mean that any software that contains bugs is caused by lack of programmer skill?
No, because in order for a bug to be a bug it must not only exist in the code but also in the feature set. (i.e. it must be found) The fact of the matter is that nobody - not you, not your testers, and certainly not your customers knows exactly how the software will be used until it is actually being used.
Actually on the contrary, it comes from a growing understanding that the 'production environment' is in fact the problem!
In my experience, context-switching between programming and testing gets quite cumbersome with difficult problems, and can lead to overlooking smaller issues.
Whether or not a programmer or a designated tester is actually doing the work has no bearing on over-testing. In fact I'd argue that this is more likely to occur if you use a tester.
* If I'm busy testing every single edge case I can think of, who's doing the development?*
Nobody! That's the crux of the matter right there:
1. Testing sucks, so if someone else is doing it then it's better for you, and, more importantly
2. the pressure to continue to develop new features at speeds that are unsuistainable all but ensure that you'll eventually find yourself with so much technical debt that it will kill you.
What if I'm developing a new product that has a full specification and design document, and is expected to meet customer acceptance goals?
I'd say run away from this waterfall design process as fast as possible, to be frank.
I don't see a deficiency in the development cycle if I need someone else to help test my software in a manner that I simply don't have time for.
I do. I see a development cycle where you haven't been allocated enough time!
Does your assertion mean that any software that contains bugs is caused by lack of programmer skill?
No, because in order for a bug to be a bug it must not only exist in the code but also in the feature set. (i.e. it must be found) The fact of the matter is that nobody - not you, not your testers, and certainly not your customers knows exactly how the software will be used until it is actually being used.