Acceptance testing types and processes
ACCEPTANCE TESTING TYPES AND PROCESSES
SVTH: Trần Thị Mai Hương, Trương Ngọc Quỳnh
GVHD: ThS Đặng Đình Quân
ắ — Nowadays, the software is applied in all aspects in order to gain better quality of life.
It is essential that a problematic programming product must not be released, especially if it is expected
to work in serious work such as medical or transportation. Correspondingly, testing is upgraded
continuously to detects bugs and ensure software quality. Therefore, In this paper, we are going to
discuss forms, processes, participators, and tools of a significant part of testing - Acceptance testing..
ừ kh a— Software testing, Red box Testing, Acceptance Testing
I. INTRODUCTION
In recent decades, the software industry grows rapidly, the number of products rockets
up to meet social needs. Software products become an integral part of life, from electric
games to business applications. Most people suffered disappointed when using a program that
did not work as expected. Releasing a problematic software can lead to many problems,
namely loss of money, time or business fame, and in the worst case, injury or death (ISTQB,
2018). To assess the quality of the software and reduce risk, software testing is engaged in the
software development life cycle as a mandatory phase.
According to Guru99, in order to enhance testing systematic and easily identify all
possible test cases at a particular level, tests are grouped based on where they are added in
SDLC or by the level of detailing they contain. There are mainly four testing level: Unit
Testing, Integration Testing, System Testing and Acceptance Testing.
This research aims at studying acceptance testing- one of 4 test levels, focusing on
types, processes, participators, and tools.
II. OVERVIEW OF TESTING
I. Test level
According to Guru99, in order to enhance testing systematic and easily identify all
possible test case at a particular level, tests are grouped together based on where they are
added in SDLC or the by the level of detailing they contain. There are mainly four testing
level: Component Testing, Integration Testing, System Testing and Acceptance Testing.
1) Component Testing
Component Testing, also known as module or unit testing, aims to test each part of the
software separately, checks whether that component is fulfilling functionalities. Developers
take responsibility for this kind of testing.
2) Integration Testing
Different software units are combined together and test as a whole to ensure the
integrated system‘s readiness for system testing. The purpose of this level is checking the data
92
flow from one module to other modules, and this level is performed by testers.
3) System Testing
On a complete, integrated system, both functional and non-functional requirements are
evaluated to verify that the system meets the specification. This test is performed by testers.
4) Acceptance Testing
Like system testing, acceptance testing typically focuses on the behavior and
capabilities of a whole product or system to assess the system‘s readiness for deployment and
use by end-user, basically done by the user or customer. However, other stockholders can
joint in this process.
J. Testing‘s contribution to success
It is popular in the program industry that delivered software and system cause failures
or under stakeholders‘ needs. However, using testing in the development life cycle in an
appropriate way can reduce the frequency of such problematic deliveries.
1) Requirement
If requirement reviews or user story refinement has testers involved in, defects in these
work products can be detected effectively, helps decrease the risks incorrect or untestable
features being developed (ISTQB, 2018). Therefore, cost and time will not be wasted.
2) Design
If system designers and tester cooperate while design the system can increase each
party‘s understand of the design and how to test it, thus reduce the risks of fundamentals
design fault and enable tests to be identified at an early stage.
3) Development
Having testers support developers while coding can increase each party‘s understanding
of the code and how to test it, reduce the risk of bugs within the code and the tests.
4) Verify and validate
Testers verify and validate the software before releasing can defect missed failures and
support removing the defects. This increases the likelihood that the software satisfies
requirements and meets stakeholder needs.
To sum up, in every phase of development life cycles, the involvement of testers also
leaps the quality of the product and contributes to success. Therefore, despite acceptance
testing basically done by the customer, the testing team should join acceptance testing.
III. ACCEPTANCE TESTING
A. Definition
As assigned in ProfessionalQA, the main goal behind acceptance testing is to check
whether the developed software product passes the acceptance norms defined on the basis of
user and business requirements, so as to declare it acceptable or non-acceptable for its use by
the users. Acceptance testing is one of the last types of software testing performed over
software or application. It is conducted by a pool of targeted users to ensure the readiness and
quality of the system from the user's perspective, which allows the team to meet their needs
and expectations.
Acceptance testing is also referred to as red box testing. Additionally, the acceptance
tests are derived from the user story and are based on the acceptance criteria.
B. Types of acceptance testing
1) Alpha Testing and Beta Testing
Criteria
Alpha Testing
Beta Testing
Clients/ End users
Clients/ End users location
Security Reliability, Security,
Member
Testers
Developer‘s site
Test location
Reliability
and
Testing are not performed
Robustness are checked
Both the white box and black
box
Test techniques
Black Box Testing
Lab environment/ testing
environment
Test environment
Time
Real- time environment
Long execution cycle
Immediately
Only a few weeks of execution
In future versions of the
product
Fix bugs
Beta testing also concentrates
on the quality of the product,
but gathers users‘ input on the
product and ensures that the
product is ready for real- time
users.
Alpha testing is to ensure the
quality of the product before
moving to Beta testing
Objectives
2) User Acceptance Testing (UAT)
User acceptance testing of the system is typically focused on validating the fitness for
use of the system by intended users in a real or simulated operational environment. The main
objective is building confidence that the users can use the system to meet their needs, fulfill
requirements, and perform business processes with minimum difficulty, cost, and risk.
3) Operational Acceptance Testing (OAT)
The acceptance testing of the system by operations or systems administration staff is
usually performed in a (simulated) production environment. The tests focus on operational
94
aspects, and may include:
- Testing of backup and restore
- Installing, uninstalling and upgrading
- Disaster recovery
- User management
- Maintenance tasks
C.Testing in processes
1) Activities
RECORDING &
EVALUATING
RESULTS
TEST
CASEPREPARATION
ACCEPTANCE/
TEST
REJECTION BASED
ON TEST RESULTS
EXECUTION
- Test case preparation: Preparation of test cases, on the basis of combined
requirements of both business and end-users.
- Execution: These test cases are executed on the software product.
- Documentation: Results are recorded and compared with the expected results, in
accordance to specified acceptance criteria, for meeting the requirements.
- Evaluation: The number of pass or fail of these test cases decides the software
suitability for getting accepted or rejected.
2) Acceptance Testing Criteria
There are three criteria:
- Functional Criteria.
- Non- functional Criteria.
- Performance Criteria.
D.Participators
1) The Users
a) Active Users
Active Users are the people who interact directly with the system, so they would have
been key sources not only of functional requirements but also of performance, usability and
other non-functional requirements as well. Much of what is built into the system is intended
to meet these people‘s needs, so some (or many) of them should definitely be testers.
b) Passive Users
Passive users don‘t interact with the system directly but are impacted by the system
none-the-less. For example, they may receive reports (e-mails or notifications from the
system), or their jobs may include using the information the system produces, or they may
supervise Active or Passive Users. The acceptability of the system for these people‘s
purposes is no less important than for the Active Users, so some of these people should be
testers as well.
2) Business Analyst
- BA responsibilities in acceptance testing are:
- Identifying Testers: Users (Active users/ Passive users), stakeholders…
- Planning Tests: Major focus of acceptance testing is to check how the system will
actually be used in practice instead of finding bugs. Because of different purpose, planning for
acceptance testing is significantly different from planning the other types of testing.
- Determining when to do acceptance testing: There is a mindset that acceptance
testing must be performed at the end of the project, but doing this crucial evaluation too late
might land up in significant risks. Issues found in acceptance testing can cause time delays or
forcibly accepted products.
- Delivering business value through acceptance testing: Actively participating in UAT
planning and execution is an important way for the BA to ensure that value is indeed
delivered.
3) Quality analysis
- Review of acceptance criteria: The acceptance criteria must be clear, consistent,
comprehensive, covers non-functional characteristics and provides measurable pass/fail
criteria.
- Review of acceptance test cases: Previously defined acceptance criteria should be
covered in the acceptance test cases.
- Traceability: Traceability between requirements/ user stories, acceptance criteria, test
cases, and defects facilitates acceptance testing as it clarifies dependencies and provides
simple access to related information.
- Coverage analysis based on traceability: If bi-directional traceability is established, it
is possible to perform a systematic coverage analysis.
- Review of test report: Test reports should be clear, consistent and comprehensive.
96
They should contain all information provided by the tester to support decisions about the
release.
E. Tool support
From both software testing domains and the business analysis, these tools for
acceptance testing are derived (ISQTB, 2019).
Tool Type Usage for
Requirements
Acceptance Testing
Description of acceptance criteria
Requirements
Traceability between tests and requirements
management tool
Coverage analysis
Description of acceptance criteria
Agile
management tool
project
Traceability between tests and user stories
Coverage analysis
Model business process and rules
Business
process
management tool
Analyze defect impact on business processes
Manage acceptance tests and test execution campaign
Test management and Manage test execution results
automation tool
Generate test cases from business process
models
Model-based
tool
testing
Manage traceability between business process
models, business rules, requirements and test
cases
Defect
management tool
/
Incident
Manage defect / incident lifecycle
IV. CONCLUSION
In conclusion, there are 4 levels of testing: Component, Integration, System and
Acceptance Testing. Testing involvement in every phase all contributes to success of the
application or system. This paper discusses 3 types of acceptance testing: alpha and beta
testing, user acceptance testing (UAT) and operational acceptance testing (OAT). Testing
process with activities, acceptance testing criteria, and participators also are studied. Finally,
tools are reviewed. This research paper supply understandings that can be learned to upgrade
acceptance testing.
6 trang
22860
Free
Bạn đang xem tài liệu "Acceptance testing types and processes", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- acceptance_testing_types_and_processes.pdf
