Analista de Pruebas

El Testing son las “pruebas de software” se aplican como una etapa más del proceso de desarrollo de
software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar
los posibles defectos que este pudiera tener. En un principio la mayoría de empresas de desarrollo
contaban con una etapa de pruebas demasiado informal, en la actualidad el software testing se ha
convertido en una de las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado
el origen de diversas metodologías.

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la etapa de pruebas, en esta
etapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambiente
de desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes
que existen en producción para asegurar su correcto funcionamiento en esa futura etapa, se debe
considerar adquirir un equipo de pruebas especializado “software tester” o analista de pruebas, con
experiencia, estas personas tienen una formación que les permite detectar una gran cantidad de errores
en tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de manera
correcta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testers
situación que puede traer una serie de problemas debido a la poca experiencia que pueden tener los
usuarios en la detección de errores, además se obvian pruebas importantes como las pruebas de Esfuerzo
o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las que deberían
asegurar que cada módulo del sistema trabaje correctamente de manera independiente, otro error muy
conocido en empresas de software es el uso de los mismos desarrolladores como analistas de pruebas,
es muy difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un técnico o
analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la perfección
e inconscientemente evitara realizar pruebas más exhaustivas considerando que las mismas podrían ser
absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedando descartadas y se van
alineando conceptos hacia un software testing profesional.

Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más
fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se
cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo
la gestión del proceso de software testing, la administración y seguimiento de errores, la administración de
los casos de prueba, automatización de pruebas etc.
 Capacitación Software And Tech

Contenido
1.- Analista de prueba ............................................................................................................................... 4
1.1 Conceptos básicos. ........................................................................................................................ 4
1.2 Funciones de un analista de pruebas............................................................................................ 4
1.3 Identificación de Casos de Uso ..................................................................................................... 5
1.4 Identificación de Insumos ............................................................................................................. 6
1.5 Identificación de Casos de prueba ................................................................................................ 7
2.-Matriz y creación de matrices .............................................................................................................. 8
1.6 Tipos de matrices .......................................................................................................................... 8
1.7 Subir Casos de prueba a ALM....................................................................................................... 9
3.-ALM test plan, test lab ....................................................................................................................... 18
1.8 Funciones en ALM ....................................................................................................................... 18
1.9 Test Plan ...................................................................................................................................... 19
1.10 Test Lab ....................................................................................................................................... 19
1.11 Creación de defectos .................................................................................................................. 20
4.-Ejecución ............................................................................................................................................. 22
1.12 Documento de Evidencias........................................................................................................... 22
1.13 Documento de Defectos ............................................................................................................ 22
5.-Cierre .................................................................................................................................................. 23
1.14 • Documento de Cierre ............................................................................................................... 23
 Analistas de Pruebas (TESTER)

1.- Analista de prueba

1.1 Conceptos básicos.

Una vez hecho un repaso, que no está de más, de la importancia del testing y con el ánimo de tenerle un
poco más de estima es necesario que tengamos presente algunos de sus términos básicos para hablar
claro y con propiedad.

Entre sus diversas funciones se encuentran:

• Identificar y definir las pruebas necesarias.

• Seguimiento detallado de las pruebas.
• Recopilación y gestión de los datos de prueba en cada ciclo de pruebas.
• Evaluación de la calidad global como resultado de las actividades de prueba.

Empecemos por diferenciar los distintos tipos de errores:

Fallo: no funcionamiento, o funcionamiento erróneo del sistema según el diseño del mismo.

Error de usuario: es un uso del software no correcto, o no siguiendo lo especificado.

Defecto: es un error cometido en el software durante su diseño o construcción.

Como vemos, aunque entra dentro todo del sentido común, las sutiles diferencias entre uno y otro sitúan
su responsabilidad en una u otra persona o en una u otra fase. Es mejor no asumir el sobre entendimiento
de estos conceptos y emplearlos con propiedad para no caer en el error (en este caso sería “error” al ser
producido por el “usuario”, es decir, quien los usa) de mezclarlos y mal emplearlos.

1.2 Funciones de un analista de pruebas

Por otro lado si ya sabemos los tipos de errores sería conveniente conocer los procesos en la fase de
testing donde pueden estar presentes. Estos dos conceptos son clave y es vital saber distinguirlos:

Verificación: comprobar que el software hace bien aquello para lo que está diseñado.

Validación: comprobar que el software hace lo que el usuario final quiere que haga.

Uno de los errores más comunes es confundir todos estos términos no dando los ni siquiera mucha
importancia porque, claro está, si no se da importancia al testing menos se le da a su vocabulario. Pero
ahora os hago yo una pregunta: ¿Qué es más grave?
 1.3 Identificación de Casos de Uso

Para su identificación y lectura de los requerimientos al analista tendrá que primero definir que es un caso
de uso.

Caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo
algún proceso.

Un caso de uso representa una unidad funcional coherente de un sistema, subsistema o clase. En un caso
de uso uno o más actores interaccionan con el sistema que realiza algunas acciones. Elementos de un
modelo de casos de uso:

 Actores
 Casos de uso
 Relaciones

Descripción de un requerimiento.

Verificar lo que el documento nos señala. Ejemplo:

 Escenario
Verificar el diagrama de caso de uso:

Actor
CU001 Genera archivo tipo Bandera

IPC
<<extend>>
Origen

CU002 Transfiere Bandera

Control M

CU003 Ejecución Planificación de Carga

<<extend>>

CU004 Generación Archivo de Parametros

Destino
<<include>>

CU005 Ejecución de carga tablas <<extend>> CU006 Control de errores

ABInitio

<<include>>

CU007 Cifras Control

<<include>>
Netezza

CU008 Envío de correo

CU009 Cierre de mes

1.4 Identificación de Insumos

Para poder identificar los insumos el analista debe recopilar la información necesaria del
Requerimiento/Proyecto, una vez puesta en escena debe valorar e identificar los posibles roles que
desempeñara. Para concretar un insumo es lo que el analista necesita como herramienta de trabajo para
poder realizar las pruebas por ejemplo: Una ruta específica, Un dominio en particular etc…
 1.5 Identificación de Casos de prueba

Al iniciar uno de los principales objetivos de este documento es para que el presente lector pueda adquirir
los conocimientos para ser un buen analista mediante ejemplos y practicas dinámicas, con la que pueda
desarrollar las habilidades necesarias durante un requerimiento del cliente

Requerimientos:

Una de las principales habilidades de una analista de pruebas necesita el comprender los Requerimientos
del cliente con la que comprenderá el cómo se desarrolló el Aplicativo

Generación de casos de prueba

Para poder crear los casos de prueba se solicita que el analista de pruebas comprenda el requerimiento,
una vez comprendido e identificado los casos de uso
Podrá verificar y señalar por cada caso de prueba crear más casos de prueba para al final el analista pueda
vaciar la información en una matriz

De acuerdo con el especialista al crear sus casos de prueba es necesario crearlos dentro de una matriz
de pruebas. La mayoría de los casos de pruebas son identificados dentro de un flujo señalado en un
Proyecto/Requerimiento donde muestra todo el proceso del aplicativo, mostrando a detalle cualquier
función que tomara dentro de cada actor.

2.-Matriz y creación de matrices

1.6 Tipos de matrices

Matriz de pruebas

Este documento muestra los casos de pruebas identificados por el especialista donde se vaciara la
información y se mostrara los pasos a seguir para así poder hacer una prueba tanto modular o integral,
principalmente los casos de prueba son creados a detalle para la valoración del proyecto así asegurando
que ningún defecto “Grave” tenga el aplicativo.

Este es un ejemplo de cómo llenar tu documento para la creación de tus casos de prueba, lo principal de

este llenado el nombre del caso de prueba, pasos, descripción, resultado esperado, y tipo de ALM

Matriz de ejecución

Esta matriz es el principal documento en donde se llevara todo el control de todos los casos de prueba,
también llevando el control de tus ejecuciones dentro de ALM, principalmente este documento también
funge el seguimiento del cliente-proveedor para así llevar un mejor manejo de casos de pruebas ejecutadas
por día.

Estatus de los casos de prueba: FAIL, PEN, N/A,OK

Nombre del caso de prueba

Ejecuciones por día es una pequeña grafica donde por día se señalara el estatus que el especialista ha
ejecutado
1.7 Subir Casos de prueba a ALM
1.- Ingresar a Excel una vez ya instalado la aplicación.

2.-Una vez abierto el documento electrónico, dar clic en la pestaña donde se

encuentra el <<In>>.

3.- Ahora para iniciar sesión dentro de nuestro aplicativo, dar clic en el icono “Login” para inicio de
sesión.

4.-Para continuar aparecerá una ventana donde ingresaras los datos para poder iniciar sesión.
 *Ruta para el servidor y poder accesar: https://hpalmapp01:8443/qcbin/ (Para poder ingresar
debemos de estar conectados a la VPN)
*Ingresar usuario H, Password, dar clic en el botón Autthenticate

5.-Una vez
ingresado los
datos, elegir un
Dominio y
proyecto en la
que subirás los
casos, dar clic en
“login”.
 7.- Verificar donde se encuentra la carpeta para así poder subirlos a los parámetros correctos. (Se valida
dentro del ALM).

8.-Para poder validar los parámetros de la hoja de Excel y subirlos al ALM es necesario mapear, para
eso verificaremos dentro del Excel los nombres de los campos y anotarlos de acuerdo a la letra por

ejemplo:
A B C D E F G H I J K L M N O P Q

Description Proceso Tipo

Test Evidencia Tipo de Step Expected Tipo
Subject Designer de Modulo de Importancia Aplicativo Servicio Estatus Description
Name Requerida Validación Name Result ALM
Negocio Caso
Descripción Tipo
Nombre Step Expected
Proceso de Description
del Evidencia Tipo de Name Result Tipo
Subject Autor de Modulo Caso Importancia Aplicativo Servicio Estatus (Design
Caso de Requerida Validación (Design (Design ALM
Negocio de Steps)
Prueba Steps) Steps)
prueba
9.-Para poder ingresar el mapeo de acuerdo con la identificación en el Excel, ahora en la siguiente
ventana de muestra como ingresarlos valores, dando clic en Mapping.

10.- Ahora se abrirá la ventana para poder realizar el mapeo correcto, donde seleccionaremos en tipo
de entidad del menú y seleccionaremos de acuerdo a lo que se requiere, en este caso será TEST.

11.-En el cuadro derecho de nuestra ventana abierta se ingresara las letras de acuerdo con el punto
Número: 8.

12.-Una vez finalizado así quedara nuestro mapeo, para finalizar dar clic en “OK”.
13-.Para poder concluir es necesario validar los campos, para que pueda subirlos sin algún carácter no
valido o exceso de caracteres (255).

*para poder validarlos dentro del Excel tendremos que seleccionar la(s) fila(s) que se validara(n) y dar
clic en el icono de “Validate” y una vez terminado dar clic en “OK”.
14.-Una vez concluido la validación ahora daremos clic en el icono de “Upload to ALM”.

*Aparecerá esta ventana en donde está subiendo los Casos de prueba.

*Verificaremos dentro del ALM

Como subir casos de prueba manualmente
Una manera más sencilla para poder crear nuestros casos de prueba de manera manualmente,
necesitamos estar conectados a la VPN, Una vez conectado debemos ingresar directamente al ALM en
el explorador

Una vez ingresado necesitamos revisar dentro de la carpeta los casos ya hechos, para crearlos de una
manera eficiente copiamos el caso y pegamos en donde queremos almacenarlo.
Seleccionaremos el caso y podremos editarlo de manera que se crea un nuevo caso de uso.
A continuación las pantallas de como editar el caso.

Editamos del lado derecho de la pantalla de acuerdo al caso de uso.

También podemos ingresar nuevos pasos “De penderá de cada caso” Aquí se muestra el cómo ingresar
nuevos pasos: Una vez ingresado todo los valores damos clic en “OK”, de esta manera ya generamos un
nuevo caso de manera manual y rápida.
 3.-ALM test plan, test lab
1.8 Funciones en ALM
 1.9 Test Plan
Esta Sección se permite crear Casos de prueba manualmente o corregir los casos de prueba ya subidos
desde ALM, en donde se buscara el VoBo del liderl del proyecto.

1.10 Test Lab

Una vez dado el VoBo del líder aquí el analista comenzara a ejecutar sus casos de prueba asignados por
día

Acción en
Módulo ALM Nomenclatura Texto Ejemplo

New Release F703690 - Nueva

Número de Folio en PPM - "Descripción del proyecto en PPM"
Folder Solicitud de TDC

E"Dos dígitos consecutivos e iniciado en 01" seguido por un guion “-“ y “La E01 - Nueva Solicitud de
New Release
descripción del entregable a ejecutar" TDC
Releases
El primero
siempre debe ser
C"Dos dígitos consecutivos e iniciando en 01” seguido por un guion “-“ y “La C01 - Diseño de pruebas
New Cycle "Diseño de
descripción del ciclo de pruebas a ejecutar"
pruebas"
C02 - Pruebas Integrales

“Número de Folio en PPM” seguido por un guion “-“ y “La descripción del proyecto F703690 - Nueva
Carpeta
en PPM" Solicitud de TDC

CP"Tres dígitos consecutivos e iniciando en 01" seguido por un guion “-“ y “La
New Test Plan CP001 - Solicitud de TDC
descripción del ciclo de pruebas a ejecutar"

Test Plan Caso de prueba donde se

Description Descriptiva valida la generación de
una nueva solicitud

New Test CP"Tres dígitos consecutivos e iniciando en 01” seguido por un guion “-“ y “La CP002 - Solicitud de TDC

Configuration descripción del ciclo de pruebas a ejecutar" ORO

New Test Set “Número de Folio en PPM” seguido por un guion “-“ y “La descripción del proyecto F703690 - Nueva
Folder en PPM" Solicitud de TDC
Según aplique se crea una de las siguientes: Carpeta de
 MU - "Descripción de la Matriz de pruebas unitarias" acuerdo al tipo de
 MM - "Descripción de la Matriz de pruebas modulares" pruebas
New Test Set
 MR - "Descripción de la Matriz de pruebas de regresión" MM - Solicitud TDC
Folder
 MI - "Descripción de la Matriz de pruebas integrales"
 MC - "Descripción de la Matriz de pruebas de certificación"
 MRT- "Descripción de la Matriz de pruebas de Rendimientos"
Test Lab Nomenclatura para nombrar la matriz de pruebas (dependiendo del tipo de
prueba)
 MU - "Matriz de pruebas Unitarias"
 MM - "Matriz de pruebas Modulares"
 MR - "Matriz de pruebas de Regresión"
New Test Set  MI - "Matriz de pruebas Integrales" MM01 - Solicitud TDC
 MC - "Matriz de pruebas de Certificación"
 MRT - "Matriz de pruebas de Rendimiento
Después de la nomenclatura que indica el tipo de prueba deberán incluir “dos
dígitos consecutivos, iniciando en 01" seguido por un guion “-“ y "la descripción de
la matriz de pruebas a ejecutar"
 1.11 Creación de defectos

La gestión de incidencias es una parte implícita de la fase de ejecución, pero que al tener una alta
importancia en las pruebas funcionales, diferenciamos como una etapa independiente. Cuando al realizar
la acción de un step el resultado obtenido no es el esperado, habrá que abrir o reportar una incidencia para
que el equipo de desarrollo tenga constancia del error. La gestión de incidencias es el principal canal de
comunicación con el equipo de desarrollo. Las incidencias han de ser claras y con todo lujo de detalle,
tienen que describir el error para que el equipo de desarrollo pueda comprenderlo perfectamente,
reproducirlo, localizarlo y poder solucionarlo. Se deberá mantener una continua comunicación con el
equipo de desarrollo para conocer el estado de los defectos y poder realizar las repruebas necesarias para
su cierre.
Defectos

 Todos los defectos se deben reportar en ALM, sin importar el folio.

 El Tester debe seguir el flujo definido para los defectos, por lo que se les pide que sigan el orden
correcto de los estatus.
 Actualizar el estatus de cada defecto de acuerdo al procedimiento de seguimiento de defectos y
agregar el comentario adicional cuando se reasigne la incidencia.
 Documentar de manera precisa el defecto. Ser muy claros en la descripción de los datos y adjuntar
archivo de incidencia.
 Las soluciones por parte de desarrollo deberán estar documentadas anexando evidencia de su
prueba unitaria, en ambos casos de ser rechazado o solucionado.
 En caso de necesitar de una prueba asistida, el defecto deberá quedarse en desarrollo, hasta no
tener la solución y la solicitud de esta prueba deberá ser por email.
 Los defectos podrán ser rechazados una vez que ambas áreas (desarrollo y testing) estén de
acuerdo.
 Los Defectos diferidos se aprobarán por desarrollo y el líder de proyecto
 No se cerrarán defectos, sin la evidencia exitosa en el formato designado.

TESTER DEFECT MANAGER LIDER DE DESARROLLADOR

DESARROLLO

Asignad En En
Nuevo
o revisión proceso

Instalad
Resuelto
o

Fallado

Re-ejecución
Re-ejecución

Cerrado
 4.-Ejecución
1.12 Documento de Evidencias
Documento de Casos de prueba exitoso

1.13 Documento de Defectos

Documento de Defectos

Ejemplo Banorte
 5.-Cierre

1.14 • Documento de Cierre