Test Case Guide

Fecha: 30 de Octubre de 2019

 LEAF 1 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

Content

1. Objective from the document.......2

2. Scope 2
3. Formats test cases.......6
3.1. Prerequisite checklist format.......6
3.2. Format of functional test cases..........7
3.3. Checklist of functional test cases.........8
3.4. User acceptance test format....................................................................................9
3.5. Format for technical test cases.........13
3.6. Matrix format of use cases VS functional test cases......14
3.7. Matrix format of non-functional requirements VS technical test cases........................15
3.8. Checklist format......16
3.9. Release notes format......16
 LEAF 2 OF 18
University logo and community Name component
VERSION 1.0
FECHA October 2019

1. Objective of the document

This document aims to establish the techniques, tools, and activities

relacionadas con la ejecución y validación del plan de pruebas; incluye responsabilidades
of each of the tasks, the resources and the prerequisites that must be considered
in the effort of each of the tests, allowing to ensure compliance with the
proposed requirements.

2. Scope
The following are examples of the levels, types, and methods of testing that can be
to be used to shape the service or project attention strategy.

The unlisted testing levels, such as unit tests and tests of

integration of components, is considered the responsibility of the team of
development and are generally outside the scope of services.

Niveles, tipos y métodos de prueba

Levels,
Methods or Name Description
Types
Level of Smoke tests consist of reviewing the software to be tested before starting.
tests the formal testing cycle, its objective is to evaluate whether the
The software is ready to be tested. It is executed in these.
generally the main flow of functionalities in order to
observe installation and configuration problems, in case of
If they are not successful, the formal testing cycle does not begin.
They generally focus on evaluating the basic aspects.
necessary, among them:
Basic functionality
Environments
Data
Security
Configuraciones

Tests of Conducted in a testing or pre-production environment by a

system specialized and independent team from the construction team of
the solution. It includes functional and non-functional tests and
they start from the analysis stage (static tests within the
software development life cycle.
Tests of It refers to the assessment of the correct integration between
interoperability of different applications, systems, services, or processes that
of systems, they form a platform or technological solution.
applications Very commonly used in ERP systems quality assurance,
services or and in service-oriented architectures (BPM, SOA).
processes They usually include the verification and validation of the
following elements:
Business integration scenarios using
 SHEET 3 OF 18
University logo and community Name component
VERSION 1.0
DATE Oct-2019

Levels, types, and methods of testing

Levels,
Methods or Name Description
Types
multiple message schemes and large payloads
messages between the different services, applications or
processes.
Information flows within and through the
applications using simple message schemes
with high volumes of messages, including
security of those messages and the correct
identification of emitters, receivers, and pathways of
the same.
Evaluation of the correct standardization of
data structures and messages for efficient
usage and distribution of the same in a manner
transversal among the different applications, services or
processes that integrate the platform or solution
technological.
Use of technologies dedicated to services,
including business solutions and made to the
measure, mainly:

ESB
SOA
BMP
XML Parsing
Service Binding Interfaces and Encoding
Styles
Message Queues (JMS) and Synchronous
(HTTP) Requests
BPEL, JBI, and Proprietary Business
Integration
Transformation using XSLT and
XQuery
Adaptors to mock service objects

Tests of Primarily applied in maintenance tests of

Regression software, consist of evaluating the introduced changes
they have not caused failures regarding the functionality that already exists
delivered correctly, to evaluate that
functionalities must be tested must apply analysis of
impacts and risks. This type of testing is also applied.
during the regression testing cycle at the end of the
stabilization.
Tests of It refers to the evaluation of software quality from the
acceptance of user perspective, in order to review if it meets their
user (UAT) needs and meets their expectations.
Methods of Box tests They consist of evaluating functionality using
Test black specifically the Front of the application, just like it would do
end user. It is not necessary to know the internal structure of the
system to carry out this type of tests.
 LEAF 4 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

Levels, types, and methods of testing

Levels,
Methods or Name Description
Types
Box tests It is necessary to know the internal structure of the system, in this
white type of tests evaluates the software from the inside, it is not
relevant only if the functionality is delivered otherwise as it is
processed the information within the system to offer
this functionality.
Gray box testing Consistent in the evaluation of functionality, similar to
black box, the difference is that in gray box testing is performed
reviews also on the internal structure of the system for
verify the functionality, for example when registering a record
It is checked, in addition to the Front, that it has been inserted.
effectively in the database through queries
direct

Types of Tests Execution of previously designed test scripts,

Tests automated built or configured in machining tool.
Functional Tests Execution of test scripts to determine if it satisfies
manuals the required attributes and capabilities as well as the requirements
functional.
Tests of Adherence to current or required regulations and standards
compliance by the client.
regulatory and
normative
Data quality The state of integrity, suitability, coherence, timeliness and
precision that makes the data suitable for use
specific (requirements and standards)
Types of tests Static tests consist of the evaluation of the Software (requirements,
non-functional or programs, data, documentation) without executing the
techniques same

Tests of Design and preparation of environments and scripts for execution

performance or of performance tests in a dynamic or static manner.
evaluation of the Among the most common dynamic tests are the
performance following:
Capacity
Durability
Elasticity
Response time
Bottlenecks
Volume
Stress

Among the most common static tests are the

following:
Efficiency.
Maintainability.
Portability.
Reliability.
 LEAF 5 OF 18
University logo and community Name component
VERSION 1.0
DATE Oct-2019

Levels, types, and methods of testing

Levels,
Methods or Name Description
Types
Security.

Tests of It is about the assessment of the security of an application, in

security all or some of its layers, looking for vulnerabilities and
bad coding or configuration practices that can
derive into intrusion risks.
The most common services include:

Vulnerability Review.
Penetration Testing.

Automation Design It refers to the construction of frameworks for

of Tests construction and test automation to cover the
implementation of specific needs of a client, project or
frameworks service, facilitating the design and subsequent execution of
automated tests.
There are different types of frameworks, with levels of
different maturity, the most common are:
Recording and playback of evidence.
Guided by data.
Guided by keywords.
Hybrids.
 leaf 6 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

3. Test case formats

[Link] checklist format.

1.

Reviewed
Documents Available Observations
Approved
Master Work Plan Yes No Yes No
of the Procedure

Project Schedule Yes No If No

Use Cases Yes No Yes No

Requirements no
Functional Yes No Yes No

Design Specification Yes No If No

Source Code (Tests Yes No Yes No

White Box
Control Plan of the
Configuration. (Environment If No Yes No
of Tests)

Prototype (Software) Yes No Yes No

Migration plan Yes No Yes No

QA Plan

Production plan Yes No Yes No

[Link] of functional test cases

 LEAF 7 OF 18
University logo and community Name component
VERSION 1.0
DATE Oct-2019

GLOBAL INFORMATION OF THE TEST CASE

Test case number Completed version
constituted [case number of by the analyst of
use]-[Case number of tests in the
VERSION OF
test moment of
EXECUTION
execute it. This
TEST CASE
number is
No.
increase by 1 in
1>
<Fecha de ejecución
EXECUTION DATE filled out by the
test analyst
Use case identification <Nombre del modulo
object of the test MODULE OF to whom it corresponds the
USE CASE:
SYSTEM object use case
from the test>
Case description Description of what is intended to be tested in the test case
of test:
TEST CASE
a. Preconditions

List of preconditions that must be met to carry out the test.

b. Test steps

Sequential steps that must be executed by the test analyst or user in front of the system to
run the test

COINCIDE
INPUT DATA ANSWER
E RESPONSE OF
EXPECTED OF THE
TYPE SYSTEM
FIELD VALUE APPLICATION YES NO
SCENARIO
<Description Value Type of Response that is
of the data from what should scenario that
wait for the
entry to be pretends
Response obtained
supply to try on application from the application in the
done in the Correct/Incorrect
moment of the execution of
test rrecto>
the test
for the
date of
entry
 SHEET 8 OF 18
University logo and community Name component
VERSION 1.0
DATE Oct-2019

c. Post conditions

List of postconditions that must be met after performing the test

2. TEST RESULTS
Defects and deviations Verdict

<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la

test Step

Failed

Observations Tester

General observations of the analyst or user about the

execution of the test
Company:
Nombre:
Date:

[Link] of functional test cases

In order to ensure that the test cases cover 100% of the scenarios to
test for each use case; in its construction, the following must be taken into account
checklist.

Each set of test cases for each use case must include:

USE CASE ELEMENT TEST CASE

Input data Verify that the input data complies
pro:
Obligation
Data type
Length
Structure
Reglas de Negocio Validate business rules that affect the
input data (Data dependency).
Validate business rules that affect the
flows.
Alternate Flows Verify the execution of all flows
 LEAF 9 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

alternates.
Exception Flows Verify the execution of all flows
Exception.
Basic Flow Verify the execution of the basic flow.
Generalities: The test cases must specify
exactly routes, file names,
values for the input data.
To ensure that the routes and names of
files are fulfilled; it must be installed
a predefined folder tree in the
station where the test will be conducted.

[Link] Acceptance Test Format

QUESTION EVALUATION CRITERIA

Are there terms in different languages mixed? 1 = They are found everywhere in the
system

It is found in some
parts of the system.

3 = Not found in
no part of the system.
Is the vocabulary used simple? The vocabulary is too much
technical.

The vocabulary presents

some difficulties of
comprehension.

The vocabulary is
completely understandable.
3. Is enough time provided to make the entries? 1 = Time is very limited.
by keyboard?
Time is limited for
some functionalities.

The weather is completely

sufficient.
4. Is there any type of assistance for users who make There is no help.
Is this the first time using the system?
Help can be found in
some parts.

There are aids throughout the

 LEAF 10 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

system.
3. Is the system easy to operate for someone who did not receive The system is difficult
training in its operation? understanding.

The system is easy to operate.

in some of its
features.

3 = The system is
completely easy to operate.
6. Do you understand the interface and its content? 1 = Its interface is not clear.

The interface is understood in

some parts.

3 = The interface is
completely understandable.
Is it easy to identify an object or an action? It is difficult to identify the
objects or actions.

2 = The can be identified

objects and actions in some
parts of the system.

3 = All objects and

actions are easily
identifiable.
8. Is it easy to understand the result of an action? 1 = The results of the
actions are not understandable.

The results of the

actions are understandable in
some parts or most of it
of the system.

All the results of the

actions are understandable.
9. Is the interface designed to facilitate the completion The interface is difficult to use.
efficiently carry out tasks in the best possible way?
The interface is difficult to use.
in some parts of the system.

The interface is
completely easy to use.
10. Are the messages presented by the system appropriate? 1 = The messages are not
appropriate.
 SHEET 11 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

The messages are

appropriate in some parts
of the system.

3 = All messages are

appropriate and easy to
understand.
11. Does the system act in the prevention of errors? The system does not prevent
user errors.

The system prevents some

or most of the errors of the
user.

3 = The system prevents

any error that may
commit the user.
12. Does the system clearly report errors? 1 = The system does not inform of
presented? proper way on the
committed errors.

The system informs about

proper way some or the
majority of the mistakes
committed by the user.

3 = The system reports in a way

appropriate all the mistakes
committed by the user.
13. Are descriptive messages and texts used? 1 = Text messages do not
they are descriptive.

The majority of the texts are

descriptive or easy to
interpret

3 = All texts are

descriptive or easy to
interpret
14. Does it allow for comfortable navigation within the product and 1 = Navigation is not
an easy way out of this? simple.

2 = Navigation presents
some difficulties.

The navigation is simple,

requires few links to
 SHEET 12 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

access to the functionalities

of the system.
13. Is the user allowed to customize the interface? 1 = The interface is not
personalizable.

The interface is customizable

with some restrictions.

The interface is
completamente personalizable.
16. Is visual information provided about where it is? 1 = None is presented
user, what is he doing and what can he do next? visual information or any other type of
help.

2 = Presents aids in some

parts of the system.

The aids are appropriate

and are distributed along
of the system.
17. Are there well-made keyboard shortcuts? 1 = There are no shortcuts for
keyboard.

There are some shortcuts for

keyboard.

3 = All options
keyboard shortcuts are presented.
18. Is the user presented with only the information they need? 1 = The information presented
is more than what is needed and
tends to be confusing.

In some parts there

presents more information to the
necessary.

The information is
strictly the necessary
according to the profile.

[Link] Test Case Format

 SHEET 13 OF 18
Logo of the university and the community Name component
VERSION 1.0
DATE October 2019

Format to be used for documenting technical tests; these tests will be

documented as the development of the solution progresses and versions are available
released on which these tests will be applied.

GLOBAL INFORMATION OF THE TEST CASE

Description of the type of Code
test: Load, Volume, of the <Test Coding>
Tipo de Prueba:
Stress, Smoke, ETC> test

Description of the
<Description of the test objective>
test

Version or iteration of Execution date in format

Version of Date of
execution of the test AAAA/MM/DD filled out by
Execution Execution
the test analyst at
moment of its execution
1. Test prerequisites

List of prerequisites to consider before executing the test

2. Test inputs

List of Supplies needed to carry out the test

3. Test checklist
Test
Steps to Follow satisfactory Observations
NO
Numbered steps in logical order for the
execution of the test

4. Test Results
Defects and deviations Verdict

<Lista de defectos o desviaciones encontrados por el analista

the user when running the test Step

Failed

Observations Tester

General observations of the analyst or user about the

execution of the test
 leaf 14 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

Company:
Name:
Date:

[Link] of the use case matrix vs functional test cases

Traceability matrix format that will be used to ensure that everything is tested
the aspects defined within the use cases.

Use Case Aspect to Evaluate Test Case

1. Input Data
Obligation Case Identification of
test that evaluates
Obligation
Length Case Identification of
test that evaluates Length >
Data Type Case identification of
test that evaluates Type of
data>
2. Business Rules
Related to data from
entry
<List of test cases> Case Identification of
test that evaluates the rule of
Case Identification of business
use 3. Business Rules
<List of test cases> Case Identification of
test that evaluates the rule of
business
4. Exception Flows
List of exception flows Case Identification
test that evaluates the flows of
exception
5. Alternate Flows
List of flow cases Case Identification of
alternates test that evaluates flows
alternos.
6. Basic Flow Case Identification of
test that evaluates the flows
basic.

[Link] of non-functional requirements matrix VS cases of

technical tests
 SHEET 15 OF 18
Logo of the university and community Name component
VERSION 1.0
DATE Oct-2019

Traceability matrix format that will be used to ensure that all are tested
the technical aspects of the solution; each test case will be recorded in this matrix
technical and non-functional requirement that will be verified.

TEST CODE REQUIREMENT NO

OBSERVATIONS
TECHNIQUE FUNCTIONAL VERIFIED

[Link] format

Format to be used for the checklist of the tests executed.

TYPE OF Version Date of EXECUTED FULFILL NO Observations

TEST of Execution A E COMPLIES
Execution n
n

[Link] notes format

Format that will be used as release notes, which should accompany each of
the versions delivered for testing.

1. Presentation
a. Identificador de la versión: <Numero de versión>
b. Product description:
2. Hardware, Operating System and Base Software Requirements.
The hardware requirements, operating system and must be specified
Software Base that the testing environment must have installed and configured
before starting the system installation process.

COMPONENT REQUIREMENT
HARDWARE
 LEAF 16 OF 18
University logo and community Name component
VERSION 1.0
DATE October 2019

OPERATING SYSTEM

SOFTWARE BASE

3. System Requirements.
Here are the installation and configuration requirements of the system.
4. New Features (optional).
The new features of the delivered version are described.
5. Obsolete Features (optional).
The obsolete characteristics are described in relation to a previous version.
6. Removed Features (optional).
The removed features are described in relation to a previous version.