In development, I would normally have my own test scripts that would document the data, scenarios and execution steps that I plan to test; this is my dev test plan. When the functionality has been deployed to Test, testers test it using their own test script that they wrote. In UAT, the business user then tests using their own test plan.

In retrospect, it looks like this provides a better coverage, with dev tests having a mix of black and white box testing, while testers and business users focus on black box testing. But on the other hand, this brings up distinct test cases that only are executed per stage (ie. some cases which testers thought of are only executed on Test stage) and it would like the dev missed it, which makes it a finding/bug.

Is it worth consolidating the test scripts from the start? Thus using one unified test script, or is it abit difficult to do this upfront?

6 Answers 6


Firstly QA is not Test. If your QA department are not involved in the entire development process, they are Test, not QA. QA when doing it's job, provides quality assurance, at best Test shows the lack of quality, but cannot prove quality exists - i.e. Test shows QA has failed, but cannot show they have succeeded, so Test and QA should not be the same department.

I believe the best way is to have each group manage their own tests, as it does provide better coverage. However, each team should start testing as soon as possible. This means that UAT starts as soon as there is something that Users might be able to use, Test starts as soon as a part that they have a test for is ready etc. This prevents the late find of distinct test cases. This may mean some rejigging of your work models, as often UAT and Test expect to be working on complete product and need trainning in testing partially complete outputs. It can be more expensive unless workflow is disiplined and a developers "Complete" means Complete.

QA should oversee this, along with other quality measures, to ensure the process not only delivers the desired quality output, but also at an approriate efficency level.

Edit: Original question reference to QA has been removed, hence this answer now appears OT.

  • 2
    +1 - superb answer. The activities that occur during the different types of testing are different enough that one unified script doesn't really make sense. Also, developers will usually want a test script that's completely automated, so that they can run it quickly, both in their sandboxes and on a CI server; this doesn't really fit well with what QA and UAT people will want to do. Mar 19, 2012 at 5:45
  • "QA is not Test". I cannot up-vote this enough. Feb 7, 2017 at 9:58

We use UATs from the start.

It acts as a universal reference and I think it works well. While there might be test scripts that are used only by the Devs or Testers for smaller components, the direction of the testing is always pointed towards one unified target. At the end of the day, the UAT is the only one that counts so you might as well make it the focus at the start.

Doing UATs from the start also has an added benefit. It really clears up any ambiguity between the customer expectations and your own.

  • When you say you use UAT test script from the start, does that mean it should come from the business user? I mean to say, the user has already created a test plan early at this stage and that this plan is accessible to the developer to use as part of his dev testing? Mar 19, 2012 at 7:22
  • @CarlosJaimeC.DeLeon, yep, it comes from the business user. We find that it works well because most customers tend to have a fuzzy idea of what they want and this helps to flesh it out as well as providing a guide for the devs and testers. Also, when we as in the UAT they stated, they are more understanding when we ask for time if they want changes :P
    – Permas
    Mar 19, 2012 at 7:29

They don't need a unifed test script as the things they test and the way they perform tests are often supposed to be differnt, what they need is a unified requirement that all parties are working off of. If UAT and QA are testing things the developer never thought of, then it is time to be looking at the requirements.


I agree, that having a unified test script for devs, testers and business users would be nice to have but i belive it is not possible without a lot of effort where the cost outrageas the benefit.

The reason for the difficulty is that the database content in every system is different and tests usually heavily depend on database content. our approach to "unified tests" was that every system also gets an additional test-database and there are scripts to create that db from the scratch. the test scripts run against the testdb where the content is standartised.


In perfect world devs must have unit tests(xUnit), testers - automated integration tests(Selenium) and business users - acceptance tests(FIT). They can have access to each other tests.


It really depends on the project. In some cases a unified Test, QA and UAT team that meets to discuss findings can be highly beneficial. It saves duplication of testing effort, and ensures that all parties have a clearer understanding of the business needs via UAT scripts. On the other hand, depending on the complexity of the project, it might make more sense to have thoroughly QA'd the inputs and outputs prior to testing business examples. For home-grown system development, initial QA would be a must prior to user acceptance. For out-of-the-box implementations, a unified testing team would make the most sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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