For most of the organisations, if IT stops, the business stops, no upgrade viewing the future, business loss.
Whenever an organisation plans for the rapid growth or extend the service,
there is invariably a new or modified IT system behind it. A problem-free IT
system is the “acid test” of significant investment of time, effort, resources
and finance.
Whilst the technical testing of IT systems is a highly
professional and exhaustive process, testing of business functionality is an
entirely different proposition.
Does the system deliver the business functions – does it follow
the company’s business rules – does it support a government regulations - does
it cope with exceptions – is it secured?
The people who have to make these decisions – to accept or reject
the new system – are the business users. It is therefore critical to get the
business user involved in testing and not rely only on the technicians.
Both robust quality system which serves the business to scale in
the future. Quality is never an accident; it
is always the result of intelligent effort.
PROBLEM
How often do we see project teams making compromises to meet an
immoveable deadline? Deadlines can be imposed by business objectives and by regulatory
compliance requirements. Whatever the reason, to meet a deadline usually
requires a compromise.
All projects share three common parameters:
·
Time
·
Resources (people, funding,
tools, hardware, workspace)
·
Deliverables (functionality,
quality, assessment, reports)
We can’t control time so we’re left with resources and deliverables.
The amount of resources we commit to a project will determine the functionality
and quality of deliverables. Functionality by a certain date is what an
immovable deadline usually means so we are left with quality. The quality of a
deliverable is directly proportional to the thoroughness of testing - but
testing takes time.
When do
you stop testing?
a) When all the planned tests are finished
b) When you run out of time
c) When you run out of budget
In an ideal world, all projects would allow adequate time for
testing. Project teams would plan exhaustive testing for each piece of system
functionality and if they ran out of time then they would drop functionality
from a release rather than compromise on quality.
With business systems, it’s virtually impossible to test for every
possible eventuality. We must therefore ask ourselves what is the most important
functionality that must be tested within the available timeframe. The obvious answer is –
the business critical functions that the system will deliver and on which the
project justification is based.
User acceptance testing should be performed by business users to
prove that a new system delivers what they are paying for. Business users have
the knowledge and understanding of business requirements that IT testers do not
have. They are uniquely placed to accept or reject the new system – after all
they have to live with the consequences.
BUSINESS USER
In these examples, we see systems failing at great cost for many
different reasons. The systems all went through many types of testing by
programmers, analysts and designers. Why focus on UAT?
The key is in the word User. Quite simply all other forms of testing are carried out by
technicians to ensure that the system works technically, according to their
understanding of the business requirements.
UAT alone is carried out by the users and business managers to
satisfy themselves that the system will meet their business requirements. Business
users know whether a new system will not only work technically, but also actually
allow the company to make money out of it or meet their regulatory compliance.
USER ACCEPTANCE TESTING (UAT)
The allocation of resources by the business to determine the expected
business outcome of a new or changed IT system or other asset.
UAT is in essence part of risk management. We cannot allocate time
and resources to test everything the system will do. With UAT we must allocate
limited resources where they will be
most effective.
One of the most commonly accepted models for software testing –
regardless of the development methodology – is the V Model. This maps each
development phase of a project to a particular testing phase of a project. UNIT
– INTEGRATION – SYSTEM - ACCEPTANCE.
Acceptance testing is the final checkpoint before the system goes
live – and before the client pays. Whilst business requirements start the
development project, it is acceptance testing that completes it. When
specifying requirements our goal should be: This
is what the system must do and this is how we will test it.
User Acceptance Testing: proves to
the users that the system works according to their understanding of their own
business requirements. They test the primary business functions they asked for
and look at the business results to make sure they are correct.
Note: UAT is the final chance for the users to test the end system to
their satisfaction before they committing to use it in production.
RESPONSIBILITY
·
The business unit which owns the
system is responsible for testing business functionality
·
IT is responsible for supporting
UAT with resources, infrastructure and personnel to correct errors
·
The testing team is responsible
for managing the deployment of resources to provide the best recommendation to
management
·
Management is responsible for
allocating sufficient resources, skilled personnel, infrastructure, time and
budget
·
At the end of the day, management
must also make the final decision - to release or delay the system - based upon
the testing evidence provided and any identified risks.
·
Often a system will be released
with known risks but an informed decision is always better than an uninformed
one.
RULES
·
Define testing criteria when
defining business requirements
·
UAT testers should have their own
reporting line - not be part of the project team
·
Detachment- during development
testers can “look but not touch” (review only)
·
Not everyone does testing well
·
We are not good at finding errors
in our own work
·
Teamwork is essential
·
It’s almost never right first
time
·
A successful test is one that
finds errors
·
User acceptance testing is a
business, not a technical, activity.
·
UAT is partly a risk management
process, a balance of risk against available resources
·
UAT is the business users
checkpoint, it tests the business outcomes
·
Resource planning and
prioritisation are required, not everything can be tested
·
Testers need experience and
knowledge of business operations and business rules
·
UAT needs people working together
– business users, IT, suppliers and even customers
·
To re-emphasise the final point,
the system supplier (in-house or external company) must work with the business
users to develop a testing strategy, valid acceptance criteria of the business functionality
and a test plan that maximises the potential for a successful system rollout.
The business depends on it.
Keep a positive attitude; testing is not about assigning blame.
Quality standards (Criteria, process and procedures) should ensure that risks
are identified and mitigated at source.
I have not failed. I've just found 10,000 ways that won't work. - Thomas
Edison
