Running UAT and system testing in parallel

Running UAT and system testing in parallel

Are there any adverse effects to running system testing and user acceptance testing (UAT) phases virtually in parallel? And if so, what would you see as the major issues and/or long term effects this may cause?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

This is largely a question of acceptance tester availability and expectations. Most business acceptance testers are only allocated part-time to testing due to other job responsibilities.

It's often in the interest of the project team to discover their acceptance criteria sooner rather than later.
However since they typically provide sign-off for the production release, it's often in the interest of the project team to discover their acceptance criteria sooner rather than later. Although this sign-off responsibility may seem to imply a high level of business knowledge and testing credibility, that is not always the case. This in turn adds the basic question of quality management. Let's consider each of these factors individually and how they relate to one another:

Availability -- If the business testers are performing testing on a part-time basis, they typically have a higher expectation upon upstream QA system testing activities. In this case they are essentially expecting a "golden" system release to UAT. If a decision is made to run UAT in parallel to QA system testing without also adjusting expectations (in a downward direction) things could get ugly very fast.

Expectations -- Even if the business testers do happen to be available to participate in QA system testing, there is still a need to actively set expectations that things may be a bit "bumpy." There needs to be a distinction drawn between this type of collaborative testing versus the formal user acceptance test process that would follow. Furthermore, business and IT management must recognize that this collaborative testing is not UAT and that defects are to be expected. This type of testing partnership arrangement can be very effective, but can be difficult to negotiate with all the related parties.

Signoff -- The responsibility for production signoff typically rests with a business sponsor who receives input from individual user acceptance testers. In the best case scenario the user acceptance testers are business experts who are have high testing credibility. In the worst case the user acceptance testers are a necessary step in getting to production. In either case you have to get their sign-off, which means early testing collaboration is bound to yield a smoother UAT and will likely result in some useful business-IT cross training.

Software testing help:
User acceptance testing that satisfies users and requirements

User acceptance testing and test cases

Software testing deliverables: From test plans to status reports

The ideal situation is one of testing collaboration and partnership that serves to front-load defect discovery and resolution by embedding business knowledge within system testing process. With the right partnerships and teaming strategy, a parallel UAT process can be successfully managed.

This was first published in September 2008