Measure Twice, Accept Once (Part 3)

Acceptance Testing Is Often Considered As a Validation Process

Considered often as a validation process, the Acceptance Testing does three things:

Measure how compliant the system is with business requirements;
Expose business logic problems that unit and system testing have missed out since unit and system testing do not focus that much on business logic;
Provide a means of determining how “done” the system is;

The very basic steps to organize an acceptance testing, where Managers shall start are:

Define criteria by which the software shall be considered “working”;
Create a set of acceptance testing test cases;
Run the tests;
Record and evaluate;

Basic Steps to Organize a Well – done Acceptance Phase

Having seen what the primary approach and being ignorant of it, let’s say, you are about to take the basic steps to organize a well – done Acceptance phase. Even before taking them, you must make sure that you have in your pocket all the prerequisites needed to start, such as:

Business requirements are available and they are not incomplete or ambiguous;
The application code is fully developed;
All other types of testing such as unit, integration and system testing are completed;
There are no show stoppers or high or medium defects in the system integration testing phase;
You must have only the so called “cosmetic” errors before the Acceptance testing;
Regression testing should be completed with no major defects;
All reported defects are supposed to be fixed and retested;
The Acceptance testing environment must be ready;
Sign off mail or communication must be evident;

Approaches to Create Acceptance Test Cases

After you have made sure that your requirements are present, clear and complete, the next step is to start writing the acceptance test cases. There are several approaches to do so, and what is advisable is to you a mix of them. The approaches that you should definitely take into account are the test cases that are requirements – based (traditional approach), business process/ workflow and data – driven approach.

Why We Advise You to Use More Than Just One Approach?

Because if you use only the traditional requirements – based approach, then the test cases you create may also carry over the defects of the requirements. In addition to that when incomplete and incorrect requirements are present, then your test cases are incomplete and incorrect. The downside of the business process/ workflow test cases is that the data related testing is out of its scope. And, then the data – driven ones focus heavily on the data and miss out the process and the business side.

Never also forget that writing the acceptance test cases is not the last step of the system development. Writing them shall start right after the completion and approval of the requirements, data models and application models. And before the development is completed.

The Tips We Can Give You When You Start Planning the Acceptance Testing Phase Are:

Identify and involve the key users – they have a deep understanding of the user requirements;
Provide not only demo but also a hands – in training of the system to the users;
Have the users write their own test – cases as well;
Ensure that the users will also execute the tests;

More specifically, it is very important to clearly identify and set SMART boundaries of the roles, the type of testing to be executed – in person or self – paced, the time frames (as you are aware time is never enough to perform a thorough testing), to set the documentation standards and determine the change control process.

Roles & Responsibilities

The roles are similar to the one in the Scrum team – you should have an Owner/ PM who will manage the process and take the final decisions within the team. The Owner will also update the project sponsor on the status. Then, the Project sponsor or Business Owner comes. S/ he will take care of the requirements and will assist the Owner/ PM when testing them. That person will also be solely responsible for the Change Control process. The team resources will actually do the acceptance testing.

Having learned what the primary approach includes and how to organize a well – done Acceptance phase, in our last article devoted on this topic you will get some tips about:

What is to avoid when the Acceptance Testing is performed?
Involving the end – users: challenges;
Acceptance Testing performed by the internal QA team;
What are the main reasons that the Acceptance testing phase often fails?
What is the best option to do the acceptance testing phase successful and, at the same time avoid all the obstacles set before you?
To outsource Acceptance Testing or not?

More about the mentioned tips above, you will find in the last part IV.

Quality House Team