Should a developer write their own test plan for Q/A?

Question

Who writes the test plans in your shop? Who should write them?

I realize developers (like me) regularly do their own unit testing whilst developing and in some cases even their own Q/A depending on the size of the shop and the nature of the business, but in a big software shop with a full development team and Q/A team, who should be writing those official "my changes are done now" test plans?

Soon, we'll be bringing on another Q/A member to our development team. My question is, going forward, is it a good practice to get your developers to write their own test plans?

Something tells me that part of that might make sense but another part might not...

What I like about that:

• Developer is very familiar with the changes made, thus it's easy to produce a document...

What I don't like about that:

• Developer knows how it's supposed to work and might write a test plan that caters to this without knowing it.

So, with the above in mind, what is the general stance on this topic? I'm of course already reading books like the Mythical Man-Month, Code Complete and a few others which really do help, but I'd like to get some input from the group as well.

Answer 1

In our shop, the dev gives QA details on what the change(s) may affect and what he's worried about. QA writes the test plan, and the dev reviews it to see if they missed anything he thought of. QA uses a test plan template that helps them avoid missing anything. It also helps that QA generally knows the platform better than devs, and knows all the weird ways to get from Point A to Point B that we forget/didn't know about.

Answer 2

Personally, as a developer I like to test my own code. It gives me satisfaction when I see it passing each test case. However, in larger organisations where there is scope for a separate testing team, I believe this option should be taken. As you stated yourself, a developer might bias the tests because of their familiarity / understanding of the way the solution has been implemented.

I this this article (They Write the Right Stuff) shows a good approach to software quality assurance: http://www.fastcompany.com/magazine/06/writestuff.html

Basically the approach taken here is to have 2 competing teams: the developers writing the code, and the testers trying to break / find flaws in it. This competition drives the entire process and helps to assure a higher level of quality. It is similar to the competition between crytographers and cryptanalysts.

The quality of this code is something I think we should all aspire to, even in smaller organisations.

Answer 3

In my opinion, absolutely not. There is too great of a possibility that the developer will unknowling write the test plan to make sure it passes. Should they test their own code? Absolutely, but QA needs to indendently verify the system works. If not, things will ulitmately be missed, and bugs will slip into production.

Programmers really do think differently than most people. Their approach to solving a problem (or using a piece of software) can be radically different than end users and is why they shouldn't have the final say as to what test scripts are executed to verify the system is functional.

From a software security perspective you shouldn't ever have the same person write the code and build the test plan. The reason being is that it allows that developer to slip in untested without anyone knowing it. All anyone would have to do in that case is just not add a test plan for updated code.

Answer 4

Having developers test their own code is necessary, but not for QA. As other answers here point out, having the developer write the QA tests is akin to a self-fulfilling prophecy in that the developer will be biased to write cases such that the code passes.

The tester needs to be someone who does not understand the code, but does understand the application. Developers may know a segment of the application fairly well, but where I work, the QA is done by users of the application, as they are the ones who know how the application is typically used, and are better at performing QA than a developer who knows how a particular segment of the application is supposed to be used.

That's not to say that developers CAN'T do QA, just that they should not be doing QA on their own code, and should only be doing it on applications that they understand thoroughly from a user's perspective.

Answer 5

There are more dangers to it than the advantages if any. Both developers and QA get the requirements from business analyst at the same time. So both the teams are involved with the software and any changes coming with that in the beginning of the process. QA not only design the test plan based on business requirement but also refers to the design document for the database and workflow testing. So at the end everybody is on the same page eliminating any possibility of missed requirement. Also it will be time consuming for developer to write a test plan which I believe not every developer will prefer.

Answer 6

Testing and development are two different skills, and approach software from opposite angles. Developers are creative and look to get things working, while testers are creative and look to stop things working. Testers spend all their time planning test cases and hunting for bugs, while for developers, this will only ever be a secondary task.

As a developer, I know I'm not a very good tester. Sure, I write unit tests, but watching a real tester in action shows how far removed I am from being one.

Answer 7

There are obvious pros and cons to a developer writing their own tests for features that they are writing. But their can be happy mediums for this. In Test Driven Development you write the test cases first, so that can mean writing Unit Tests first. So the developer writes Unit Tests first, and then we can have the business side approve any features that are tested here. Following the creation of the approved Unit Tests, then the developer codes the feature to pass these tests. Whomever is responsible for Q/A then can run the Unit Test to verify that it passes, AND also run through the feature or application to make sure that it functions as it was designed, and not just to pass a Unit Test. Coding in this order can prevent a lot of errors from arising. Writing Unit Tests first locks a developer into a certain design from the get-go, and might eliminate someone from writing tests that their code already passes, but might not test the feature as it was SUPPOSED to be defined.

Answer 8

Both.

The test plan should be influenced by the specification, which (with any luck) has input from both the development and QA teams. But the test plan isn't carved in stone and evolves along with the spec.

Developers add/change test cases based on implementation details, surprises, etc.

QA adds/changes test cases based on requirement changes, interactions with the rest of the system, etc.

Answer 9

As a QA person, I always welcome developers giving testing suggestions. It's a quick sanity check, where if what the developer says works winds up failing, I can immediately kick it back as probably just an integration issue. I'll still develop my own plan, and work through my own tests, but any assistance by the developer is great. It'll help speed up testing.

Developers don't always have access to the same data set as QA. If they weren't able to unit test something, as QA I'd like to know about it. For example, if the developer says a SQL query works, but is concerned about performance, I'll put the "1 million row data set" test higher on the priority list. If it's slow, I can kick it back sooner than going through a full regression test and then doing performance.

The other thing that's handy is when developers say how to test something. I had a case where the developer modified code that checked for ISDN interface status. The developer was able to tell me the four different states the interfaces could be in.

Answer 10

ideally, your QA person should write the test plan. if you work at a small company, you probably wont have a dedicated person for that

next on the list is the business analyst or project manager

last on the rung is the programmer

its a matter of whoever has the best written documentation skills. if no one else is there to write it, than i guess you have to

if you want a simple template for writing test plans, try this article: Writing a System Test Plan

-- LM