Should the developer be involved in setup of test data in QA and UAT environment?

Question

When QA or UAT comes, should the developer still be involved in setting up data or finding test data for the QA tester or business user? Or will this introduce bias to the developer who coded the system changes that are being tested in the said environments?

Answer 1

While developer bias with creation of the test code is a risk, many times the developer knows how to do it more quickly than the QA resources could. I have set up test data and environments for QA resources before and it tends to work out in one of two ways:

1. The QA team could do it eventually, but they are not as efficient or quick. They also VERY clearly understand the requirements and already have their test cases planned and ready to go regardless of what you help them with. This is when it is okay.

2. The QA team is incapable of even doing the simplest tasks or anything that can be remotely conceived as critical thinking. They depend on the developer to provide them with test data, environments and even a test plan. A better QA team can probably be assembled by driving around behind a Home Depot with an empty-bed truck and yelling out "Trabajo!". This is when it is a bad thing!

In other words, if they NEED you to do this then it is a bad idea, if they WANT you to do this, then it is probably okay.

Answer 2

Depends heavily on what kind of resources/people the organization has access to, and it depends on the people themselves.

Some organizations can't afford not to utilize developers in this area. And some developers are as good or better at QA then the QA people are, while others are lacking in this area. There's no reason to make a blanket statement and say it should be one way or the other.

You want to have a good QA person/team. If your developer has this skill then that's a bonus you shouldn't pass up.

Answer 3

You should weigh the bias against the potentially saved labor. The developer brings a good amount of knowledge about the system and potential test cases, and can certainly help and shorten the process. I would normally put the burden of avoiding bias on the QA or business person - it's part of their job.

However, this depends for a good part on the actually involved persons. With the wrong combination of personalities, group-think becomes a major issue and the developer will taint the testing with too much of a developer's perspective.