1. Calidad en la Prueba de
Software
M.C. Juan Carlos Olivares Rojas
Diciembre 2009
http://antares.itmorelia.edu.mx/~jcolivar/documents/qualitytest.ppt

2. Competencia
• Genéricas: Análisis, Diseño de soluciones, Creatividad,
Trabajo en equipo, Aprender a Aprender
• Específicas: Diseñar planes de pruebas e implementarlos
utilizando alguna herramienta automatizada de pruebas.

3. ¿Qué tiene mayor calidad?
Los dos tienen la
misma calidad
siempre y cuando
cumplan con sus
requerimientos
Para ello
debemos probar
sus
especificaciones

4. Pruebas
• La fase de pruebas se realiza de distintas formas tratando
de encontrar la mayoría de los errores que se encuentran de
manera inherente en el software.
• Pruebas: verificación y validación
• Depuración: es la detección, corrección y eliminación de
errores de software.

5. Pruebas
• Los errores del software le salen muy caros a Estados
Unidos: 59 500 millones de dólares al año.
• 50% de los fallos corresponde a los usuarios el resto a los
programadores y vendedores.
• Las pruebas al inicio del ciclo reducirían los costos por
fallos en 22 200 millones de dólares.

6. Pruebas
• Pruebas: mecanismo de control para asegurar la calidad
de un software.
• ¿Por qué tenemos que probar?
• Toda actividad de construcción (codificación) es
susceptible de cometer errores dado que se trata de una
actividad humana.
• Al realizar la depuración de un programa existe la
posibilidad de un 50% de cometer otro error.

7. Pruebas
• En el pasado se hacían pruebas previas antes de codificar
dado que no se tenían sistemas on-line como ahora.

8. Pruebas
• En el presente el software es más complejo y dinámico por
lo que en muchas ocasiones se empieza a construir software
sin probarlo de manera adecuada.

9. Pruebas
• El tener un plan de pruebas ayuda a clarificar el proceso de
depuración.
• El plan de pruebas debe de estar mucho antes de la
construcción del software.
• Existen muchos tipos de prueba dependiendo de la forma
en como se llevan acabo y dependiendo del autor. Nosotros
tomaremos el siguiente criterio.

10. Tipos de Prueba

11. Tipos de Prueba

12. Tipos de Prueba

13. Ejercicio
• Habilidades de inspección

14. Ejercicio 1
• Llenar los siguientes formatos para figuras chicas,
medianas e indistintas
Rojo Azul Amarillo Color
Indistinto
Triángulo
Cuadrado
Círculo
Forma
Indistinta
Tamaño:______

15. Solución Ejercicio 1
Rojo Azul Amarillo Color
Indistinto
Triángulo 0 0 2 2
Cuadrado 1 1 2 4
Círculo 0 0 0 0
Forma
Indistinta
1 1 4 6
COLOR
FORMA
Tamaño: Chico

16. Solución Ejercicio 1
Rojo Azul Amarillo Color
Indistinto
Triángulo 1 1 2 4
Cuadrado 1 0 1 2
Círculo 0 2 1 3
Forma
Indistinta
2 3 4 9
COLOR
FORMA
Tamaño: Grande

17. Solución Ejercicio 1
Rojo Azul Amarillo Color
Indistinto
Triángulo 1 1 4 6
Cuadrado 2 1 3 6
Círculo 0 2 1 3
Forma
Indistinta
3 4 8 15
COLOR
FORMA
Tamaño: Indistinto

18. Importancia de las Pruebas

19. Pruebas “Lean”
• Mito: trabajo del tester es encontrar defectos
• Inspección para prevenir o para detectar defectos (función del
SQA).
• Pruebas automatizadas antes que el código
– De aceptación
– Unitarias
• Eliminar el desperdicio: Lista de bugs.

20. Pruebas: Mejores Prácticas
• Diseñar un caso de prueba para cada funcionalidad del
software.
• Establecer como mínimo un caso de prueba de datos
correcto.
• Establecer como mínimo un caso de prueba de datos
incorrecto.

21. Pruebas
• Se recomienda probar lo antes posible cualquier fragmento
de código.
• Las pruebas ayudan al aseguramiento de calidad pero no
garantizan que un software esté 100% libre de errores.
• No se pueden tener pruebas que abarquen el 100% de los
casos de uso. Se deben realizar pruebas de segmentos

22. Mejores Prácticas
• Se necesita especificar las salidas o resultados esperados.
• Un programador debe de evitar probar sus propios
programas.
• Una organización no debe de probar sus propios
programas.
• Inspeccionar los resultados obtenidos de cada prueba.

23. Plan de Pruebas
• Se recomienda utilizar la metodología y formatos del
estándar IEEE 829 para documentación de pruebas de
software.
• Se simplificará el plan de pruebas con el siguiente formato.

24. Formato Plan de Pruebas
ID: 1 Nombre: Enviar artículo
Probado por: Fulanito
Descripción: Se introducen los datos del
artículo y de los autores.
Condiciones de Entrada:
nombreArticulo=“Calidad del Sw” …
emailAutor=“jcolivar@itmorelia.edu.mx”
Resultado Esperado: El sistema confirma la
correcta recepción del artículo enviando
un e-mail al autor de contacto con un
userid y password para que el autor pueda
posteriormente acceder al artículo.

25. Plan de Pruebas
• Nos orientan hacia mejores resultados.

26. Práctica de Laboratorio
• Realizar un programa que permita calcular el área de un
triángulo conociendo tres lados utilizando la fórmula de
herón.
• Realizar el plan de pruebas que garantice que el programa
está libre de errores

27. Arquitectura

28. Casos de Pruebas
• ¿Con cuantos casos de prueba valido que el software está
correcto?
• Para cada caso de prueba sólo indicar las posibles
entradas.
• Por ejemplo:
• Caso de Prueba 1: A=3 B=4 C=5, el resultado
esperado debe de ser 6.
• ¿Es diferente el caso A=4 B=3 C=5?

29. Casos de Prueba
• Tipos de Triángulo en Base a sus lados:
• Se deben tener al menos un caso de cada uno de ellos y al
menos un caso no válido: A=0 B=-1 C=“Hola”.

30. Caso de Prueba
• ¿Cuál es el resultado esperado para el caso de prueba
A=1 B=2 C=3?
• Area=0
• ¿Qué pasó?
• !Exento este parcial quien pueda dibujar un triangulo de
dimensiones 1, 2 y 3 cm para cada lado!

31. Pruebas Unitarias con JUnit
• JUnit es la herramienta de pruebas unitarias
automatizadas más popular del mundo. Está enfocada en
Java aunque se ha migrado a varios lenguajes
denominándose XUnit.
• La mayoría de los IDEs actuales como NetBeans la
tienen integrada de forma automatizada.
•DEMO DE JUNIT

32. Conclusiones
• Las pruebas son el mecanismo de aseguramiento de la
calidad más importante que existe.
• El diseño de planes de pruebas es una de las actividades
más importantes del desarrollo de software.
• “Si se como probar un software, se lo que debe de hacer”.

33. Referencias
• Myers, et al. (2004), “The Art of Software Testing”,
Wiley, Estados Unidos, 2004, ISBN: 0-471-46912-2
• Roger S. Pressman, Ingeniería de software un enfoque
práctico.Ed. McGraw Hill.
• Piattini M.G. y F.O, Calidad en el desarrollo y
mantenimiento del software. Ed. RAMA.

34. ¿Preguntas?