4 ms·

To me, your experience sounds an awful lot like not having much experience in a production environment. In my experience, context-switching between programming

To me, your experience sounds an awful lot like not having much experience in a production environment. In my experience, context-switching between programming and testing gets quite cumbersome with difficult problems, and can lead to overlooking smaller issues. If I'm busy testing every single edge case I can think of, who's doing the development? With separate testers, you get the benefit of concurrency (the software can continue being tested while issues from the previous version are fixed), and subsequently more software developed. "The problem is the cycle is too long. Fix that." How so? 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 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. Does your assertion mean that any software that contains bugs is caused by lack of programmer skill? I, too, would like to learn the secret to writing completely issue-free code if you're willing to share it. Now, please don't take what I say to mean programmers shouldn't test their own creations. If you hand something that crashes 100% of the time to a tester, you're being lazy. The purpose of testers goes far beyond simply checking to see if it's "code that works."

run4yourlives 17y ago
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.
nostrademons 17y ago
"If I'm busy testing every single edge case I can think of, who's doing the development?" The edge cases are the development. In my experience, the core functionality takes less than 10% of the time. A good programmer should be able to crank out an algorithm in a couple days; the problem comes when that algorithm meets end users and they request features that are completely insane from an engineering perspective, yet necessary for user acceptance.

run4yourlives 17y ago

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.

nostrademons 17y ago

"If I'm busy testing every single edge case I can think of, who's doing the development?" The edge cases are the development. In my experience, the core functionality takes less than 10% of the time. A good programmer should be able to crank out an algorithm in a couple days; the problem comes when that algorithm meets end users and they request features that are completely insane from an engineering perspective, yet necessary for user acceptance.