Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a very interesting situation. Management has strictly asked to do unit testing for the code being developed and divided the task in such a way that few are developing the code and others are writing the test cases for the code. Now developer keeps on refactoring the code and others keep on changing the test cases.

I told them that this is not the best practice(since person who is developing the code need to write test case), but they are not willing to listen me and citing all kind of examples from their past experiences where work is divided like this way.

How should I convince them or deal with this situation.

Edit: I am looking for some argument/proof which could make them think.


Note I asked management about reasons for this and they told me that we are just dividing the workload. I opposed for this and told them that it is not best practice, then they started citing some of their past experiences. Actually, one of team members has accepted the task in past. At that time I tried to convince him to oppose this and now they are saying if he can do why can't you. I have accepted to do as of now but I want to stop this as practice.

To my best I want to demonstrate something that can convince them.

share|improve this question
    
Are you part of the team writing the tests? –  JeffO Mar 26 '13 at 11:55
    
Initially I was not part of team but against this, but now they are planning to make it practice. So I thought it is better to voice my concerns. –  ritesh Mar 26 '13 at 13:19
    
When test cases are written by someone other than the developer, you're not only testing code, you're testing assumptions. –  Gilbert Le Blanc Mar 26 '13 at 13:31
    
did you ask your mgmt about reasons for this? what was their responce? It's a known and often reasonable idea that Functional testing must be done by external party to avoid bias but the way you present how it was done and especially that this has been forced on unit tests, smell dangerously like micro-management –  gnat Mar 27 '13 at 7:23
    
They told me that we are just dividing the workload, I opposed for this and told them that it is not best practice, then they started citing some of their past experiences. Actually, one of team member has accepted the task in past. At that time I tried to convince him to oppose this and now they are saying if he can do why can't you. I have accepted to do as of now but I want to stop this as practice. To my best I want to demonstrate something that can convince them. I think that it is mis-management (or management done by people who have little idea about what they are doing). –  ritesh Mar 27 '13 at 7:50
add comment

5 Answers 5

up vote 4 down vote accepted

How should I convince them or deal with this situation.

You have already tried, and they didn't pay any attention.

I'd just leave the problem alone now.

They have made a judgement that this won't be a problem. If it does turn out to be a serious problem, the impact on team productivity and morale will soon become apparent to them. Either way, it is their responsibility.

share|improve this answer
    
Completely agree with you.I have implemented this solution(as you mentioned) and before asking this question, I have only this answer in my mind.But Is there no way that it can be proved within 10 min for example if I write some class and then cleverly underscore the importance of unit testing by developer only. Can't there be some proof for "best practices" or asking the proof about "best practices" is wrong question in itself. I am more intrigued by the question that how to prove it. I am assuming my self a beginner. Please correct me if you feel that I am making mistake in my argument. –  ritesh Apr 10 '13 at 11:58
1  
1) There is no such a thing as "proof" of best practice. Especially in cases like this. In fact, I'm not even sure there is broadly accepted "best practice" on this issue. 2) The issue is convincing people, not proving something, and in this case it involves changing their opinions. There is no guaranteed way to change peoples' opinions ... no matter how solid your arguments are. 3) IMO, appealing to "best practice" is tantamount to admitting that you can't put forward a convincing argument ... on the merits. –  Stephen C Apr 11 '13 at 0:48
add comment

The approach of a qa team, or technical business users writing unit tests is not necessarily a bad thing.

Crucially - the tests can the be written to test the behaviour of the code being written and the public contracts. If the developers then refactors the code then this shouldn't change the test cases unless the test cases are dependant on the specific implementation which makes them less useful going forward.

Developers writing test cases as well is important but I can definitely see value of someone writing test cases based on the requirements, not on what's been written.

share|improve this answer
    
situation is like this: we don't know the requirement, we have to understand the code and then write test cases. I completely agree that third person writing some test cases will add value but in this situation developer has written the code and then looking for another person to write test cases to please QA is not getting down with me. –  ritesh Mar 26 '13 at 9:24
1  
I sympathise, not knowing the requirement is the crux of your problem but it's hard to solve. However, once you've written the code and the developer level tests then you can still provide the behaviours to qa who can write their own tests on top once the business users have signed off that the implemented behaviours are correct. Not ideal but I don't see what other option you have. –  Michael Mar 26 '13 at 9:33
1  
If this arrangement precludes the developers from writing their own unit tests to make sure their code works before giving it to QA, I'm not in favor of it. That's what it sounds like... abdicating writing of all tests to other people who didn't write the code. That role is more appropriately reserved for integration tests and acceptance tests. –  Robert Harvey Mar 26 '13 at 17:31
    
Correct, developers should absolutely write tests but the business value in tests come from people who didn't write the code and test the behaviour as in integration tests and acceptance tests. I think we agree on this. –  Michael Mar 26 '13 at 17:34
    
@Ritesh: it sounds like the real problem is not that code and tests are being written by different teams, but rather than tests are being written by a team that doesn't know the requirements. I can't see how effective testing can possibly be done in this situation. –  Carson63000 Mar 27 '13 at 1:03
show 2 more comments

When you are talking Unit tests, then yes they should be developed by the developer. Now if you are talking more a set of automated functional tests, i.e. something that tests the code from the outside, rather than the inside, then yes, that is usually a separate team of QA/QE testers.

share|improve this answer
    
+1 for the distinction between Unit_testing and and other tests like Integration_testing and that non-unit-tests could be implemented by a seperate team. @doc brows answer is semantically the same but this one is shorter. –  k3b Mar 27 '13 at 12:17
add comment

It depends on what you and management mean by "unit tests". If you are talking about "TDD style unit tests", then it does not make any sense to let a second dev write the tests.

Those are (or should be) tests where you switch between writing the test code and production code typically in such a high frequency that you cannot work effectively any more when separating that tasks between people. Perhaps this may be possible when combining TDD with pair programming (not that I ever have done pair programming in that kind of way).

On the other hand, people often call different kind of integration or system test also "unit test" (mostly because they use some xUnit tool for driving them). Such kind of tests can often easily split between people, and it makes sense because of the reasons you already got from some commenters. If the requirements are not clear for the test coders on that level of abstraction, this is a sign for a serious lack of documentation.

Ideally, you have both kind of tests - "real" unit tests written by the dev who writes the code, and additional tests written by a second person.

share|improve this answer
    
I would have accepted this answer. Pinpoints the problem perfectly. Unit tests may drive the APIs, so to send them to another coder either slows down the evolution of the API or forces you to have the API ready before you start writing any code, including unit tests. It sounds like an inflexible proposition for me. –  Mihai Danila Jun 16 '13 at 3:07
add comment

nice question, hope you this helps you.

  1. Most of the developers/programmers not wish to do any other options or functions which is user friendly and not mentioned in SRS even though they came to know that feature. they treat like that are additional works.
  2. some times they avoid to overcome an known issue/bug without reported by testing team then only they got extra time for bug fixing.
  3. developers/programmers/coders never check full cross functionality and browser testing as like as a tester.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.