User acceptance testing

In my experience, most of the people building the website (programmers, testers, product owners) should be considered as “Power Users".

In my experience they are competent in using computers, they posses domain knowledge, they are project stakeholders and they typically have insights in to the project and product.

They are often computer savvy and hold significant insight in to the product being built. This would essentially mean they aren't "greenfield" users. They may be biased in many ways towards what the product should do and why they are building it. After all, they are the ones building, testing, marketing and supporting the product.

Greenfield users are users who are coming to your site for the very first time, with little or no prior knowledge of the technology and the design. They want to complete certain objectives (i.e. solve a problem or complete an action.)

Sometimes, as Testers, we ignore the end users of our products and assume they possess similar levels of experience when interacting with websites. This is a potentially dangerous assumption.

How to test like a user
The easiest way to get feedback from people outside of the development team is to perform a regular user acceptance program. These can be as large or as small as you see fit, but the more frequent they are in the development process the better. Agile development partly takes care of user acceptance testing assuming that you have a customer available and are releasing regularly.

Long term projects running waterfall, V or other longer releasing methodologies would certainly benefit from more frequent user acceptance testing.

User Acceptance, as stated in that ever-so-contentious ISTQB certification is:

“Acceptance testing is often the responsibility of the customers or users of a system; other stakeholders may be involved as well.
The goal in acceptance testing is to establish confidence in the system, parts of the system or specific non-functional characteristics of the system. Finding defects is not the main focus in acceptance testing."

There is much to argue with in this statement, but I’ll save that for another time. I think we should look differently at this. I think User Acceptance testing can be done at any point in the project.

I think it should be the responsibility of the Development Team (as it aids you in delivering the right product) and I think we should encourage bug finding (depending on what you classify a bug as; enhancement, defect, fault, missing compliance, usability, performance). It is feedback on whether the product you are building is on point, working as expected and relevant to your users.

Why would you wait until near completion to get that feedback?

Getting feedback from your end users is critical to your success. Try to get that feedback as early as possible.

Useful Hint
A UAT phase every few weeks, or months is a great strategy. Get your product in front of the end users as quickly and as often as possible. That way you get feedback early and can include this feedback in your product.

Useful Links
ISTQB online - http://istqb.org/display/ISTQB/Home



If you’re interested in a career in Software Testing then check out my book Remaining Relevant And Employable (Tester’s Edition) - it’s packed full of ideas about writing good CVs, communicating your value to employers and doing well in an interview.