TALLER DE TESTING
Y CALIDAD DE SOFTWARE
U2. Desarrollo y ejecución de casos de prueba.
Semana 6
ESCUELA DE CONSTRUCCIÓN E INGENIERIA
Director: Marcelo Lucero
ELABORACIÓN
Experto disciplinar: Aída Villamar Gallardo.
Diseño instruccional: Carla Silva Alvarado.
VALIDACIÓN
Experto disciplinar: Andrés del Alcázar
Jefa de Diseño Instruccional: Alejandra San Juan Reyes.
EQUIPO DE DESARROLLO
AIEP
AÑO
2021
Taller de Testing y Calidad de Software 2
Tabla de contenidos
Aprendizaje esperado de la semana .............................................................................. 4
Introducción ....................................................................................................................... 4
1. Plan de pruebas de sistema, según estándares de la industria. ............................... 5
1.1.- Concepto de plan de pruebas de sistema ......................................................... 5
1.2.- Objetivos ................................................................................................................. 5
1.3.- Estructura ................................................................................................................ 6
1.4.- Estándares de la industria ..................................................................................... 7
2. Relación de función de plan de pruebas con proceso de desarrollo de software,
considerando análisis de planes de pruebas de proyectos en el mercado. ............ 11
2.1.- Análisis de planes de pruebas ............................................................................ 11
3. Diseño de plan de pruebas de sistema para proyecto de software, según
requerimientos del cliente. ............................................................................................. 12
3.1.-Diseño de planes de prueba ............................................................................... 12
3.2.-Requerimientos de clientes .................................................................................. 13
4. Implementación de plan de pruebas para proyecto de desarrollo de software,
según estándares de la industria. ............................................................................... 14
4.1.- -Implementación de planes de pruebas ........................................................... 14
Conclusiones .................................................................................................................... 19
Referencias bibliográficas .............................................................................................. 20
Taller de Testing y Calidad de Software 3
Aprendizaje esperado de la semana
Implementan plan de pruebas de sistema para proyecto de desarrollo de
software, considerando función y diseño, según estándares de la industria.
Introducción
• ¿Qué es un plan de pruebas?
• ¿Qué puedo obtener al considerar un plan de pruebas en mi proyecto
de desarrollo?
• ¿Cuáles son los estándares asociados a las pruebas de software?
Hasta ahora, hemos ido conociendo las distintas pruebas que podemos
aplicar a nuestros proyectos para obtener información acerca de la calidad
del sistema.
Esta semana veremos, qué podemos definir en un plan de pruebas. Por
medio del cual abarcaremos funcionalidades completas, planificando y
detallando las pruebas que se utilizaran, incorporando además estándares
que nos entregaran los lineamientos que debemos seguir tanto en los
conceptos, definiciones, procesos de prueba, documentación, técnicas de
prueba y en lo que son los modelos de evaluación de procesos para
pruebas de software.
Taller de Testing y Calidad de Software 4
1. Plan de pruebas de sistema, según estándares de la industria.
1.1.- Concepto de plan de pruebas de sistema
El concepto de plan de pruebas de sistema está asociado a la definición y
planificación de un plan de trabajo que considera todos los pasos en
cuanto a las actividades de prueba se trata, pudiendo por medio de este
plan de pruebas dar a conocer el alcance de estas.
Dentro del plan de pruebas la planificación se considera como uno de los
ítems con mayor relevancia al momento de probar un proyecto, es
necesario tener bajo control la totalidad de los aspectos que comprende,
como son: la manera en la que se va a probar, cuáles son los recursos que
se tendrán disponibles, considerar las pruebas de regresión, la
documentación asociada al proyecto y todo aquello que se encuentre
relacionado.
Un punto importante es el relativo al presupuesto ya que si bien es cierto se
debe destinar parte de él, la omisión de las pruebas puede generar que los
problemas se arrastren hasta el entorno de producción, y en ese caso será
más caro y lento solucionarlo.
La planificación de las pruebas es uno de los principales puntos a la
hora de probar el software con éxito. En ausencia de un buen test
plan es muy poco probable que las pruebas se ejecuten en un plazo
estipulado e incluso se incrementara el costo del proyecto al consumir
más tiempo y recursos. Esta planificación tiene que estar incluida
dentro de la planificación general de un proyecto de software.
Fuente: (Montecinos, 2020)
1.2.- Objetivos
Durante el proceso de desarrollo de un sistema es posible que existan errores
que no hayan sido detectados, por ejemplo, en los requerimientos, o bien,
en el diseño o en la funcionalidad. Por medio de la definición del plan de
pruebas encontramos que los objetivos están enfocados a la detección
antes de que el sistema sea entregado al cliente, apuntando siempre a la
calidad del sistema y teniendo en consideración que entre más nos
demoremos en la detección desde que se producen los defectos, el costo y
el tiempo en solucionarlo van creciendo.
Taller de Testing y Calidad de Software 5
Según (Montecinos, 2020), los objetivos principales al realizar pruebas
serán los siguientes:
o Detectar un error específico.
o Descubrir errores no descubiertos anteriormente.
o Tener un buen caso de prueba.
Además, los atributos que debería tener una buena prueba son:
o Intentar obtener la más alta probabilidad de encontrar un error.
o No debe ser redundante.
o No debe ser ni demasiado sencilla ni demasiado compleja.
1.3.- Estructura
Un plan de prueba es un documento por medio del cual se definen y
consideran todos los elementos que están asociados con las actividades
para asegurar la calidad, debemos considerar en la preparación un
ambiente de pruebas que sea lo más parecido posible a lo que se tendrá al
pasar a producción.
Si consideramos lo relacionado a la estructura del plan de prueba, debemos
partir por señalar que el enfoque siempre debe ir direccionado por los
requisitos que se han definido al comenzar el proceso de desarrollo de
nuestro proyecto. Una vez que hemos definido lo anterior, pasamos a
trabajar en cada uno de los puntos que serán incluidos dentro de la
estructura del plan de pruebas.
Según (Montecinos, 2020) se indica que hay varias maneras de realizar un
plan de pruebas. Una de ellas es aplicar la norma ―ISO/IEC 29119 Software
testing que sustituye a la norma ―IEEE 829. En esta norma se indican los
puntos que debe considerar un plan de prueba:
o Identificador del plan de pruebas.
o Introducción.
o Elementos de la prueba.
o Características que probar y no probar.
o Método/enfoque de prueba (implementación de la estrategia de
prueba).
o Criterios de paso/fallo de la prueba.
Taller de Testing y Calidad de Software 6
o Criterios de entrada, salida, suspensión y reanudación de las
pruebas.
o Entregables de las pruebas.
o Tareas/hitos clave de las pruebas.
o Cronograma.
o Necesidades del entorno.
o Responsabilidades.
o Dotación de personal y necesidades de capacitación.
o Riesgos.
o Aprobaciones.
1.4.- Estándares de la industria
En la actualidad, podemos encontrar estándares que se encuentran
regulados por diversos órganos internacionales, ellos han documentado
dentro de lo que son sus normas, estándares o lineamientos para las pruebas
que realizamos dentro del ámbito del software, entre estas organizaciones
tenemos:
o ISO (Internacional Organization for Standardization) es la Organización
Internacional de Normalización
o IEEE (Institute of Electrical and Electronics Engineers) Instituto de
Ingenieros Eléctricos y Electrónicos
Además de las organizaciones mencionadas podemos encontrar aquellas
que se han dedicado a crear el ámbito de las pruebas y divulgar sus
beneficios:
o ISTQB (International Software Testing Qualifications Board) Comité
Internacional de Certificaciones de Pruebas de Software
o ISST (International Society for Software Testing) Sociedad Internacional
para Pruebas de Software
o TMMI (Test Maturity Model Integration) Modelo de Madurez de
Pruebas
Dentro de las principales certificaciones están: ISO, ISTQB ISST, TMMI.
Dentro de las publicaciones de estandarización ISO podemos encontrar las
siguientes normas asociadas:
ISO / IEC / IEEE 29119-1: 2013 Fuente: (Standardization, 2013)
Taller de Testing y Calidad de Software 7
Ingeniería de software y sistemas. Pruebas de software. Parte 1:
Conceptos y definiciones.
ABSTRACTO
El propósito de la serie ISO / IEC / IEEE 29119 de estándares de prueba
de software es definir un conjunto de estándares acordados
internacionalmente para las pruebas de software que puede ser
utilizado por cualquier organización al realizar cualquier forma de
prueba de software. ISO / IEC / IEEE 29119-1: 2013 facilita el uso de los
demás estándares ISO / IEC / IEEE 29119 al introducir los conceptos y el
vocabulario sobre los que se basan estos estándares, además de
proporcionar ejemplos de su aplicación en la práctica. ISO / IEC / IEEE
29119-1: 2013 es informativo y proporciona un punto de partida,
contexto y orientación para las otras partes.
ISO / IEC / IEEE 29119-2: 2013 Fuente: (Standardization, ISO
International Organization for Standardization, 2013)
Ingeniería de software y sistemas. Pruebas de software. Parte 2:
Procesos de prueba.
ABSTRACTO
El propósito de la serie ISO / IEC / IEEE 29119 de estándares de prueba
de software es definir un conjunto de estándares acordados
internacionalmente para las pruebas de software que puede ser
utilizado por cualquier organización al realizar cualquier forma de
prueba de software. ISO / IEC / IEEE 29119-2: 2013 comprende
descripciones de procesos de prueba que definen los procesos de
prueba de software a nivel organizacional, nivel de gestión de prueba
y niveles de prueba dinámica. Admite pruebas dinámicas, pruebas
funcionales y no funcionales, pruebas manuales y automatizadas, y
pruebas con y sin script. Los procesos definidos en ISO / IEC / IEEE
29119-2: 2013 se pueden utilizar junto con cualquier modelo de ciclo
de vida de desarrollo de software.
Dado que las pruebas son un enfoque clave para la mitigación de
riesgos en el desarrollo de software, ISO / IEC / IEEE 29119-2: 2013 sigue
un enfoque de pruebas basado en riesgos. Las pruebas basadas en
riesgos son un enfoque común de la industria para la elaboración de
estrategias y la gestión de pruebas. Las pruebas basadas en riesgos
permiten priorizar las pruebas y centrarlas en las características y
funciones más importantes.
ISO / IEC / IEEE 29119-3: 2013 Fuente: (Standardization I. O., 2013)
Taller de Testing y Calidad de Software 8
Ingeniería de software y sistemas. Prueba de software. Parte 3:
Documentación de prueba.
ABSTRACTO
El propósito de la serie ISO / IEC / IEEE 29119 de estándares de prueba
de software es definir un conjunto de estándares acordados
internacionalmente para las pruebas de software que puede ser
utilizado por cualquier organización al realizar cualquier forma de
prueba de software.
ISO / IEC / IEEE 29119-3: 2013 incluye plantillas y ejemplos de
documentación de prueba. Las plantillas están organizadas en
cláusulas que reflejan la estructura general de descripción del
proceso de prueba en ISO / IEC / IEEE 29119-2, es decir, por el proceso
de prueba en el que se están produciendo. El anexo A contiene
esquemas del contenido de cada documento. El anexo B contiene
asignaciones de ISO / IEC / IEEE 29119-2. El anexo C contiene una
descripción general de los ejemplos. Los anexos D a S contienen
ejemplos de la aplicación de las plantillas. El anexo T proporciona
asignaciones a los estándares existentes. La bibliografía para ISO / IEC
/ IEEE 29119-3: 2013 se encuentra al final del documento. ISO / IEC /
IEEE 29119-3: 2013 admite pruebas dinámicas, pruebas funcionales y
no funcionales, pruebas manuales y automatizadas y pruebas con
secuencias de comandos y sin secuencias de comandos. Las plantillas
de documentación definidas en ISO / IEC / IEEE 29119-3:
ISO / IEC / IEEE 29119-4: 2015 Fuente: (Standardization I. O.,
International Organization for Standardization, 2015)
Ingeniería de software y sistemas. Pruebas de software. Parte 4:
Técnicas de prueba.
ABSTRACTO
ISO / IEC / IEEE 29119-4: 2015 define técnicas de diseño de prueba que
se pueden utilizar durante el proceso de diseño e implementación de
prueba que se define en ISO / IEC / IEEE 29119-2.
ISO / IEC / IEEE 29119-4: 2015 está destinado, entre otros, a probadores,
administradores de pruebas y desarrolladores, en particular a los
responsables de la gestión e implementación de pruebas de software.
ISO / IEC 33063: 2015 Fuente: (Standardization I. O., International
Organization for Standardization, 2015)
Taller de Testing y Calidad de Software 9
Tecnología de la información - Evaluación de procesos - Modelo de
evaluación de procesos para pruebas de software.
ABSTRACTO
ISO / IEC 33063: 2015 define un modelo de evaluación de procesos
que cumple con los requisitos de ISO / IEC 33004 y que respalda el
desempeño de una evaluación de la capacidad del proceso
utilizando el marco de medición de procesos definido en ISO / IEC
33020. El modelo de evaluación de procesos proporciona indicadores
para orientación sobre la interpretación de los propósitos y resultados
del proceso como se definen en ISO / IEC / IEEE 29119‑2 y los atributos
del proceso como se definen en ISO / IEC 33020, y proporciona
orientación, por ejemplo, sobre la definición, selección y uso de
indicadores de evaluación.
Un modelo de evaluación de procesos comprende un conjunto de
indicadores del desempeño y la capacidad del proceso. Los
indicadores se utilizan como base para recopilar la evidencia objetiva
que permite a un evaluador asignar calificaciones, siguiendo los
requisitos de ISO / IEC 33002. El conjunto de indicadores incluidos en
esta Norma Internacional no pretende ser un conjunto completo ni es
pretendía ser aplicable en su totalidad. Deben seleccionarse
subconjuntos que sean apropiados para el contexto y el alcance de
la evaluación.
El modelo de evaluación de procesos en esta Norma Internacional
está dirigido a patrocinadores de evaluación y evaluadores
competentes que deseen seleccionar un modelo y método de
proceso documentado asociado para la evaluación (para la
determinación de la capacidad o la mejora del proceso).
Se puede utilizar para la evaluación cualquier modelo de evaluación
de procesos para pruebas de software que cumpla con los requisitos
definidos en ISO / IEC 33004 con respecto a los modelos para
evaluación de procesos. Es posible que se necesiten diferentes
modelos y métodos para abordar las diferentes necesidades
comerciales y de prueba. Este modelo de evaluación se proporciona
como un ejemplo de un modelo que cumple con todos los requisitos
expresados en ISO / IEC 33004.
Taller de Testing y Calidad de Software 10
2. Relación de función de plan de pruebas con proceso de desarrollo de
software, considerando análisis de planes de pruebas de proyectos en el
mercado.
2.1.- Análisis de planes de pruebas
La relación del plan de pruebas con el proceso de desarrollo de software
nos hace ver que podemos encontrar distintos tipos de plan de pruebas, ya
que pueden ser diferentes según la etapa de prueba. Si estamos en el
comienzo del proyecto podemos crear un plan maestro que va a considerar
toda la ejecución del proyecto en el que estamos trabajando.
Adicionalmente a esto, podemos crear planes de pruebas de manera
separada considerando tipos de pruebas de manera específica, como
pueden ser las pruebas de integración, las pruebas de sistema. O, si estamos
cercanos al final pruebas de aceptación o pruebas de usuario.
Está la posibilidad de crear también, un plan para las pruebas funcionales y
de forma separada uno para las pruebas no funcionales. Las pruebas de
rendimiento contarán con un plan de pruebas independiente.
Como vimos anteriormente un plan de pruebas estándar es el que define
IEEE-829
A continuación, revisaremos los objetivos de algunos tipos de planes de
prueba disponibles, considerando distintos enfoques.
Si lo que necesitamos es un plan de pruebas funcionales, podemos basarnos
en la estructura que plantea (ANDALUCÍA, s.f.), en el que señalan con
respecto al modelo propuesto:
El objetivo de este documento es recoger los casos de pruebas que
verifican que el sistema satisface los requisitos especificados. Deberá
contener la definición de los casos de prueba, la matriz de
trazabilidad entre casos de pruebas y requisitos, y la estrategia a
seguir en la ejecución de las pruebas.
Taller de Testing y Calidad de Software 11
Con respecto a las pruebas de integración la estructura que plantea y que
nos entrega una referencia de los contenidos de los planes de prueba
disponibles en el mercado en este contexto(ANDALUCÍA, JUNTA DE
ANDALUCÍA, s.f.) Considera:
El objetivo de este documento es recoger la definición de las pruebas
que se deberán realizar para asegurar la correcta integración entre
todos los componentes/módulos del sistema.
Si lo que se necesita es crear un plan de prueba considerando pruebas
unitarias (ANDALUCÍA, JUNTA DE ANDALUCÍA, s.f.) Propone:
El objetivo de este documento es recoger la definición del conjunto
de pruebas que aseguren el correcto funcionamiento de los
componentes de código de forma aislada.
Para lo que son las pruebas de aceptación o pruebas de usuario
(ANDALUCÍA, JUNTA DE ANDALUCÍA, s.f.) Indica:
El objetivo de este documento es definir el conjunto de pruebas que
deberán ser ejecutadas por los usuarios del sistema para validar si el
sistema cumple con los requisitos de funcionamiento esperado y
proceder así a la aceptación del sistema.
3. Diseño de plan de pruebas de sistema para proyecto de software, según
requerimientos del cliente.
3.1.-Diseño de planes de prueba
Para realizar el diseño del plan de pruebas deberemos considerar al menos
los siguientes puntos que se detallan a continuación:
1. Realizar en base a los requerimientos un análisis para poder
comprender ya sea el proyecto o una parte de él, entendiendo que
serán sometidos a verificación de su calidad. En este punto debemos
saber entre otras cosas, por ejemplo, si es un sistema nuevo o no,
establecer cuáles son las funcionalidades presentes que se están
modificando, determinar los requerimientos no funcionales.
Taller de Testing y Calidad de Software 12
2. Reconocer cuales son todas aquellas funcionalidades nuevas que se
probarán, con la finalidad de incluir todas aquellas características en
el plan de pruebas.
3. Reconocer cuales son todas aquellas funcionalidades que deben ser
probadas dentro de los sistemas existentes, en este caso podemos
dividirlo en aquellas funcionalidades que se modifican y están ante el
usuario (como agregar formularios), o modificar funcionalidades en
sus componentes de forma interna, en este caso el usuario no aprecia
los cambios de manera directa.
4. Es necesario definir cuál será la estrategia de prueba. Es decir, que
tipos de prueba se van a realizar.
5. Se deben establecer cuáles serán los criterios para el inicio o
reanudación, criterios para la suspensión de las pruebas y criterios
para aceptación o rechazo considerando cual será el porcentaje de
tolerancia en cuanto a los casos de prueba sin imprevistos.
6. Reconocer cuáles serán los entornos de prueba necesarios, tanto de
hardware como de software que se van a necesitar para poder
ejecutar las pruebas que se han planificado. En este punto lo que se
recomienda es que esa configuración sea lo más parecida a la que
se tendrá en el ambiente de producción del sistema.
7. Se establecen las necesidades en cuanto a personal y entrenamiento.
8. Se determinan la metodología a utilizar y los procedimientos de
prueba.
9. Elaboración de la planificación de las pruebas que se van a ejecutar.
10. Finalmente se identifican cuáles son los riesgos y se definen los planes
de respuesta ante la ocurrencia de ellos para cada caso específico.
3.2.-Requerimientos de clientes
Sabemos que todo proyecto de desarrollo debe comenzar a partir de la
captura de requerimientos de los clientes, existen diversos tipos de
requerimientos, los que deben ser implementados en el sistema.
Con respecto a las pruebas, encontramos aquellas que están basadas en
requerimientos se indica en (SOMMERVILLE, 2005) que:
• Un principio general de ingeniería de requerimientos es que
estos deberían poder probarse. Es decir, los requerimientos
deberían ser escritos de tal forma que se pueda diseñar una
Taller de Testing y Calidad de Software 13
prueba para que un observador pueda comprobar que los
requerimientos se satisfacen. Las pruebas basadas en
requerimientos, por lo tanto, son una aproximación sistemática
al diseño de casos de prueba en donde el usuario considera
cada requerimiento y deriva un conjunto de pruebas para
cada uno de ellos. Las pruebas basadas en requerimientos son
pruebas de validación en lugar de pruebas de defectos --el
usuario intenta demostrar que el sistema ha implementado sus
requerimientos de forma adecuada.
Pruebas basadas en requerimientos, en donde los casos de prueba se
diseñan para probar los requerimientos del sistema. Esta aproximación
se utiliza principalmente en la etapa de pruebas del sistema. Ya que
los requerimientos del sistema normalmente se implementan por varios
componentes. Para cada requerimiento, se identifica casos de
prueba que puedan demostrar que el sistema satisface ese
requerimiento.
Se puede ver a partir de esto que las pruebas de un requerimiento no
significan escribir sólo una única prueba. Normalmente tienen que
escribirse varias pruebas para asegurar que cubre por completo el
requerimiento.
4. Implementación de plan de pruebas para proyecto de desarrollo de
software, según estándares de la industria.
4.1.- -Implementación de planes de pruebas
Según lo señalado por (Montecinos, 2020), una vez definidos la estructura y
el diseño del plan de pruebas, se procede a la implementación, para lo
cual se deberán tener presente algunas reglas y/o recomendaciones, como
se detalla en el siguiente recuadro:
Taller de Testing y Calidad de Software 14
Taller de Testing y Calidad de Software 15
Taller de Testing y Calidad de Software 16
Taller de Testing y Calidad de Software 17
Tabla 1: Implementación de plan de pruebas Fuente: (Montecinos, 2020)
Taller de Testing y Calidad de Software 18
Conclusiones
En todo desarrollo de software, ya sea que estemos trabajando en un
proyecto completo o una parte él, es necesario considerar la incorporación
de las pruebas. Desarrollando un plan de pruebas, nos permitirá establecer si
se cumple con lo que el cliente requiere y de acuerdo con la calidad que
se ha especificado inicialmente.
El plan de pruebas de software se puede aplicar a todo proyecto de
software, considerando las necesidades específicas de cada caso. Así
como cada empresa puede aplicar un plan que se ajuste a sus
necesidades de mejora continua.
Taller de Testing y Calidad de Software 19
Referencias bibliográficas
1. Mera Paz, J. (2016). Análisis del proceso de pruebas de calidad de
software. Ingeniería Solidaria, 12 (20), 163-176.
2. Pressman, RS y P. (2010). INGENIERÍA DEL SOFTWARE (SADEC V, Ed.).
3. Rodríguez, FT (2014). INTRODUCCIÓN A LAS PRUEBAS DE SISTEMAS DE
INFORMACIÓN. Montevideo, Uruguay: Abstracta.
Taller de Testing y Calidad de Software 20
