4

Doing manual testing for the feature that you have implemented is obviously a bad idea. But what about automated functional tests? It seems to me that automation testing is more related to unit testing and it is ok to create automation test for the feature that you have created (though someone in our team is trying to lobby the practice according to which developers are prohibited to create automation tests for features that they have implemented). Am I right?

Update

From comments

Question itself does not make sense without the context

The reason why I asked this question is because the mentioned person from our team says that it is absolutely prohibited to do automated test for feature that you have implemented if there are other people who can create automation tests in a team. She says that it is a common truth and it is written in every textbook on testing. This seemed to me to be not a common truth and I wanted to debunk this myth. That's why I asked this question.

Opposite arguments were that we had automation tests not to check that developer had implemented everything correctly but to make sure that an old functionality was not broken when we added a new functionality.

Our team consists of 4 developers, 2 manual testers and 1 automation tester. Sometimes automation tester has no time to finish all automation tasks and developers help him to write scripts.

I see why you are saying that my question lacks context but I thought that providing all this details would make my question too localized.

Improve this question
7
  • 1
    It depends on the circumstances. Automated testing is one of many parts of a developer's job. Almost no one excels at and is interested in the entire job. You need to tailor your policy to that reality. If you want a more detailed answer, you need to be specific about how and why you and your co-worker disagree.
    – user246
    Aug 8, 2014 at 18:50
  • 2
    why is testing your own work "obviously a bad idea"?
    – Phil Kirkham
    Aug 8, 2014 at 18:56
  • Let me ask you similar question: What is better car, Prius or Econoline Van E150? If you answered "prius", I will laugh: I need to move 1 bedroom apartment from Virginia to Califormia, including queen bed: how you do it with Prius? If you answered E150, I will laugh again: will you want to use it to commute one hour each way? Question itself does not make sense without the context.
    – Peter M. - stands for Monica
    Aug 11, 2014 at 11:52
  • @PhilKirkham, it is a bad idea when you are the only person who tests the feature that you have created. That's what I meant, sorry for confusion
    – Molecular Man
    Aug 11, 2014 at 13:45
  • 1
    There are no absolutes. Everything depends on what resources and what goals you have - this is also written in every textbook on testing. In your situation, if automated tester does not have time to code all the tests, obviously developers need to help him/her.
    – Peter M. - stands for Monica
    Aug 11, 2014 at 14:47

7 Answers 7

Reset to default
2

In my experience, the answer is both yes, and no.

Obviously a developer can write automated tests for a feature he/she implemented. Whether that developer should write those tests is another argument and depends on - among other things - the type of automated test being written, the style of development, whose time is better utilized performing which task, and of course, office politics (which alas can't ever be escaped).

In my experience, a developer should write automated tests for their feature when:

  • they are doing test driven development and writing the unit tests before they write the implementation.
  • they are writing unit tests, period.
  • the automated tests require knowledge of the internal workings of the application code which testers may not be able to access/use.
  • the automated tests will be compiled and run as part of the build process.

Developers may not be the best people to write automated tests for their feature when:

  • the tests are at the functional, API, or GUI level and don't need knowledge of the internal code.
  • time constraints are pushing them to a different feature development (once a developer starts on a new project, the advantage of deep familiarity with the code starts to fade rapidly, and within a month or so is almost completely gone)

No matter who writes the automated tests:

  • they should be reviewed by someone else for code quality.
  • they should be reviewed by someone else for missed scenarios.

The argument that developers "can't" test their own code stems from inattentional blindness, where familiarity with the code through development causes potential problems to be missed. Someone else reviewing their tests will reduce the impact, as will returning to something after a period of time working on a different project.

So, yes, programmers are subject to inattentional blindness when creating automated tests for features they developed, but that doesn't mean that they absolutely should not create those tests. They may still be the best person available to create them (if, for instance, the rest of the dev team is fully occupied and the test team are primarily manual testers, then the best person to write the automation is the developer who wrote the feature).

Improve this answer
2

The highest quality product with the fewest production defects I ever worked on had no QA team. The developers were responsible for end-to-end service and the quality expectations were clear. The problems arise when changes are rushed through without sufficient validation - whether that is by QA or Dev.

Developers are often best placed to automate tests and also can make small changes to the implementation to make testing easier. For these reasons I would suggest best practice would be to have a tester assist in identifying what test cases offer the most value and specify their parameters. The developers can then implement these test cases.

Improve this answer
2

The activity that a developer should not do against their own code is really test design, not test execution or test automation. If the developer is doing their own test design, anything the developer forgot to think of won't be tested, by definition; a separate tester can think of things the developer did not.

If the developer is automating a test case written by someone else, there's no conflict involved.

Improve this answer
1

I would say you are partially right. Unit testing is a good practice for development and ensures your code does what it is supposed to do. That should probably be written by the developer and then executed on continuous integration. Code reviews should provide a good check to ensure that the code is correct as well as the unit test being correct.

True QA testing at any level should involve the following testing functional(works), positive(good user experience-usually includes working), negative(validates user inputs), boundary(weird or malicious stuff that sometimes people do), requirements(is correctly implemented), and regression(avoid introducing new bugs)...possibly more or less depending on the nature of the development.

I have been full time and team leads in both development and QA. From this unique perspective...people think differently in each group. Most QA people would be skeptical of any Dev person developing a complete test. As much as most dev people would be skeptical of any QA person developing a fix and checking in the code.

With the above being said, I would say that automation tests can be created by development and it's probably a good idea if the developer who wrote the code does it since that speeds up time...however, those automation tests should be reviewed, validated, and modified based on a QA review of the test as they bring a different perspective that greatly needed.

In general this is why UI automation is done by QA after the manual testing is complete...but dev delivering code with automation tests written already is a great idea and speeds up the process and communication.

P.S. This is also why you sometimes have an "automation engineer" to bridge the gap between the two...

Improve this answer
1

To answer the question in the title, of course a developer can write their own tests, but the developer likely has some blinders and assumptions, and may not test all the edge cases, only the ones they've considered. The skillset between developers and testers overlaps, but isn't a perfect intersection. Joel Sposky wrote about some of this before.

It sounds like the person advocating that developer's not write tests of their own code is really hoping to push the group towards test driven development.

Improve this answer
1

Remember that the ultimate goal is to create high quality code. Anything you do that gets you closer to that goal is OK. So, yes, it's OK for a developer to write automated acceptance tests if they want.

The more important question to be asking is, is it OK for the developer to be the only person to write automated tests for the feature they are working on? That depends a lot on your organization, your resources, the risk of missing a defect, etc. Generally speaking, some other person should be involved in testing the code besides the developer.

It's all too easy for a developer to think "this one area can't possibly break, so I don't need to test it" or "I already testing this last week and it's solid!". It's also quite likely that if they are the type of person to not consider edge cases when developing code, they likely won't think of those edge cases when writing the test for the code.

Testing is a skill. It's not something just anyone can do. A skilled, professional tester will almost always do a better job testing a piece of software than the developer will do. If you don't have skilled professional testers, or you don't have enough skilled professional testers, it's quite acceptable to have developers write tests.

Again, the goal is to create high quality software. Your team should do whatever it can to get as close to that goal as possible.

Improve this answer
2
  • Is the ultimate goal always high quality s/w?
    – Phil Kirkham
    Aug 11, 2014 at 18:08
  • @PhilKirkham: perhaps the better way to describe might have been to say the goal is to create appropriate quality software. Quality is definitely relative -- a shell script that will be run once has lower quality demands that the software for driverless cars, medical equipment and nuclear reactors. Still, I think we should all strive to produce high quality software no matter what the circumstance.
    – Bryan Oakley
    Aug 11, 2014 at 18:19
1

Depends on structure and skills of your development team and testing team. If your testing team has only manual/exploratory testers with no skills/time/resources/etc to write automated tests, and you want automated test, the only people who can write them are developers, and then it is much more productive if developers writes tests for the new feature s/he is developing. Just common sense.

If your test team has skills and resources to write automated test, is obviously more effective to specialize and developers develop new features, while testers develop the tests. Both groups use different libraries and design patterns, it is just common sense again.

So without the context, your question does not make sense. In context, answer is obvious.

Improve this answer

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