Why would it be wrong, Darrell? The developers know much more about the code coverage than the testers. In order to get the maximum coverage on the partial test, the developers could simply "point" the testers in the right direction.

For example, the type of company selected by the tester may cause all sorts of decisions to be made in code. The developers, in this case, could inform the testers of the important company types to select when testing.

If you're in a time crunch, what better way is there?

Mark - that kind of removes the benefits of having a separate group do the testing. As a developer, I can easily say do this and this and this and it should cover the majority of the code (in my opinion). The testers should be the ones going in and determining which of the code paths are the most in need of testing based on the requirements.

The whole point of Hacknot's reasoning is that the testers aren't developers and cannot delve into the "code path" to determine what should be tested; so in a time crunch, important tests may be missed.

I would agree, normally, that this is not desirable. Hopefully, being in a time crunch is not a normal condition <g>.

As a developer, your opinion has more weight than anyone elses when it comes to what tests would cover more code.

On the contrary, I think the testers should poke around in the code. At Microsoft, SDE/T's (testers) do just as much coding as the SDE's.

The point of having a separate QA or testing group is because they have no knowledge or attachment to the code. If you allow developers to tell them what to test, then that whole benefit is nullified.

JC, Darrell, you're going way off point. In what world, other than Microsoft, do the testers write just as much code as the developers? Doesn't that make them developers? We don't want developers testing the code, do we? If the testers are developing and testing, then "that whole benefit [detachment from code] is nullified" is it not?

The point - a time crunch - is what Hacknot was talking about.

Alright Bonafe, way to come close to cursing! Shall I expect more reasoned discussion from you?

No, I'm not going way off point. My position is that if a developer tells a tester how to test his code, the benefits of having a separate QA group are LOST. The whole point of having a separate group is that the developers CANNOT tell them how to test. By allowing Developers to do this in a time crunch, the whole benefit is compromised. Let's just have the developers test the code paths they choose why don't we? Because that is exactly what's happening.

On my current project we're in a time crunch, but I'm not going to tell the testers what they should be testing. Testing is driven by the business requirements, NOT the developers.

And your attempt to say that testers that write code are really developers and turn that around against what I said was weak. ALL of my comments point to the benefit of having a SEPARATE group do the testing. Just because they write some code does not mean they have the same attachment to the code they are testing as the original developer. In fact, their challenge is to break it by writing other code. And good testers write code all the time. How do you think tests get automated in the first place?

Well, uh, there you go again! (nice imitation of Reagan, huh?) Automated tests? Time crunch? The two just don't make sense in the same paragraph. Most companies do not have anything even remotely resembling automated tests. Maybe thats how they got in a time crunch in the first place. Most companies also do not have the resources to have competent developers/consultants writing/performing tests. The competent developers are too busy developing the application.

I think the article was commenting on past experience. Maybe that needs to change, but convincing companies to spend more money on testers is very difficult. Yes, it should be done exactly as you say. However, management has a long way to go in realizing the benefits of such an operation.

I absolutely agree on all your points. The problem is getting clients to put more resources ($$$) in the right place. My current client has been shown studies, white papers, books, you name it - all stating that competent testing is a major key in successful software projects. Their answer is to either ignore the advice, put key stakeholders in testing roles (which isn't bad, but the stakeholders are busy doing their "real" job), or... well, I'm sure you get the point.

All we can do is keep trying. And now for my obligatory slam - you must be bucking for management because staying on topic seems to be a weakness. ;)

Pardon me. It's not that you didn't stay on topic, you did. It's the context of the topic. My bad.

Context is relative, is it not? :)

I disagree that my context was off-topic, but oh well. We'll just agree to disagree.