Estrategias y Proceso de Pruebas de Software

Estrategias y Proceso
de las Pruebas de Software.
INDICE
Contenido
CONCEPTOS GENERALES ......................................................................................................................................................... 3
MODELOS DE CICLO DE VIDA DE DESARROLLO DE SOFTWARE .............................................................................................. 6
CMMI 1.3 – VALIDACION Y VERIFICACION .............................................................................................................................. 8
EL MODELO DE MADUREZ DE PRUEBAS (TMMSM).................................................................................................................. 9
TIPOS DE PRUEBAS ................................................................................................................................................................ 11
TIPOS DE PRUEBAS – CAJA NEGRA........................................................................................................................................ 11
TIPOS DE PRUEBAS – CAJA BLANCA ...................................................................................................................................... 13
METRICAS .............................................................................................................................................................................. 16
PRUEBAS DE LA DOCUMENTACION ...................................................................................................................................... 16
PRUEBAS DE USABILIDAD ..................................................................................................................................................... 17
PRUEBAS DEL WEBSITE ......................................................................................................................................................... 17
OTROS TIPOS DE PRUEBA ..................................................................................................................................................... 18
HERRAMIENTAS DE PRUEBA ................................................................................................................................................. 21
EL PROCESO DE PRUEBAS ..................................................................................................................................................... 22
ETAPAS DEL PROCESO DE PRUEBAS...................................................................................................................................... 24
COMPONENTES DEL PROCESO DE PRUEBAS ........................................................................................................................ 25
PLAN DE PRUEBAS................................................................................................................................................................. 26
DISEÑO DE PRUEBAS ............................................................................................................................................................. 27
CASOS DE PRUEBA ................................................................................................................................................................ 28
PROCEDIMIENTO DE PRUEBA ............................................................................................................................................... 29
REPORTE DE ERRORES........................................................................................................................................................... 29
BIBLIOGRAFIA ........................................................................................................................................................................ 30
SITIOS WEB............................................................................................................................................................................ 30
CONCEPTOS GENERALES
Objetivos de Curso:
•
•
•
•
Proporcionar los conceptos fundamentales del proceso de pruebas.
Ubicar los artefactos generados en el modelo CMMI v1.2 para Validación y Verificación.
Exponer las técnicas y las herramientas orientadas a la generación de pruebas de aplicaciones de la TI.
Contar con formatos para la instrumentación y documentación del proceso de pruebas.
¿Por qué Probar?
•
•
La mayoría de las organizaciones minimizan la importancia de las pruebas.
Si analizamos que existen de 1 a 2 defectos por cada 100 líneas de código, entonces tendremos 10 a 20
defectos en cada 1,000 líneas de código y ya dejaron de ser son solo un par de bugs.
¿Qué es probar?
“Probar es la búsqueda sistemática de defectos en todos los entregables de un proyecto”
Probar no es … …
•
•
•
•
•
Solo medir.
Fase post-desarrollo.
Barato.
Liberar o Aceptar.
Capacitar en el uso o control de los sistemas de operación.
¿Por qué ocurren los defectos?
•
•
•
•
Somos humanos.
Presupuestos limitados.
Programa de trabajo intenso.
Conflictos de intereses o prioridades.
¿Qué probar?
❖ Criterios de Prioridad
• Crítico para el negocio.
• Complejidad Técnica.
• Dificultad para Probar.
• Costo de Prueba.
• Severidad.
•
•
•
•
Probabilidad
Visibilidad.
Prioridad de Negocio.
Extensión de Pruebas.
❖ Las pruebas pueden incluir
• Requerimientos.
• Diseño.
• Código del Sistema.
•
•
Documentación.
Procedimientos de Operación.
Precisión y Exactitud
•
•
Precisión: Es la capacidad de realizar medidas similares, es decir, cuantas veces se pruebe un
programa, este debe de mostrar los mismos resultados.
Exactitud: Es la capacidad para acercarse a la magnitud real.
Verificación y Validación
Validación
¿Estoy construyendo el producto correcto?
Determina si el sistema cumple con los
requerimientos y realiza las funciones para las cuales
es construido y cumplir las metas de la organización y
las necesidades del usuario. Es tradicional y se realiza
al final del proyecto.
Verificación
¿Estoy construyendo el producto de la forma
correcta?
La revisión de los pasos de trabajo y entregables
interinos durante un proyecto para asegurar que son
aceptables. Para determinar si el sistema es
consistente, se adhiere a los estándares, usa técnicas
confiables y practicas prudentes y realiza las
funciones seleccionadas de la manera correcta.
¿Estoy accesando los datos correctos? (En el lugar
correcto; en la forma correcta)
¿Estoy accesando los datos correctos? (En términos
de los datos requeridos para satisfacer el
requerimiento)
Actividad de alto nivel
Actividad de bajo nivel
Realizada después de que se produce un producto de Realizada durante el desarrollo de los artefactos clave
trabajo contra el criterio establecido asegurando que como walkthroughs, revisiones e inspecciones,
el producto se integra correctamente en el ambiente retroalimentación del guía, capacitación, checklists y
estándares
Determinación de la correctez del producto de
Demostración de la consistencia, completez y
software final por un proyecto de desarrollo con
correctez del software en cada etapa y entre cada
respecto a las necesidades y requerimientos del
etapa del ciclo de vida de desarrollo
usuario
Calidad y Confiabilidad
•
•
•
Un software es de alta calidad cuando este satisface las necesidades del cliente. El cliente es el que le
asocia el grado de excelencia que considera conveniente.
La confiabilidad del software se refiere a la precisión con la que una aplicación proporciona los
servicios que se establecieron en las especificaciones originales.
Para que un tester se asegure que un software es de calidad y confiable, debe de verificarlo y
validarlo.
Tester y Aseguramiento de la calidad
•
•
El tester que prueba el software tiene como principal función encontrar bugs, lo más temprano
posible, y asegurarse de que sean arreglados.
La persona encargada del aseguramiento de la calidad del software tiene como responsabilidad
principal crear y hacer cumplir los estándares y los métodos para mejorar el proceso de desarrollo y
prevenir que los bugs aparezcan.
Actividades del tester
Un tester de software tiene como meta principal:
• Encontrar bugs lo antes posible.
• Asegurarse que estos se corrijan.
• Metafóricamente, el tester es “los ojos del cliente”.
• Es el primero en ver el software.
• El habla por el cliente, debe buscar la perfección.
Habilidades del tester
Un tester se caracteriza por los siguientes rasgos:
• Explorador.
• Implacable.
• Creativo.
• Perfeccionista.
• Buen nivel de conocimiento técnico.
•
•
•
•
Buen juicio.
Discreto y diplomático.
Persuasivo.
Contar con el respeto de sus compañeros.
Perlas del conocimiento
“Nunca pongas a probar funciones criticas o con alta criticidad a un inexperto, para probar pon al mejor y más
experimentado elemento” – Dan Roy
Probar lo más temprano posible.
•
•
•
•
Permite encontrar y resolver defectos tan pronto como sea posible.
Ayuda a reducir el riesgo de fracaso del proyecto.
Ayuda a reducir los costos globales de desarrollo.
Provee datos valiosos en la evaluación de viabilidad del proyecto.
Importancia de las pruebas – Fases de desarrollo
•
•
57% - Especificación.
24% - Diseño.
•
•
13% - Código.
06% - Otras.
Definición de bug
Es la falla en un componente o sistema que puede causar que el componente o sistema deje de operar en la
función requerida.
Términos para las fallas de software
Se emplean varios términos sinónimos cuando el software falla:
• Defecto, Inconsistencia, Variación.
• Avería, Anomalía, Hallazgo.
• Error, Bug, Falta.
MODELOS DE CICLO DE VIDA DE DESARROLLO DE SOFTWARE
Proceso de pruebas y ciclo de vida
En las diferentes Metodologías de desarrollo, existen muchas variantes del ciclo de vida de los proyectos de
sistemas y, por lo tanto, es válida una flexibilidad razonable en la determinación del ciclo de vida particular de
cada proyecto.
Modelos de ciclo de vida de desarrollo de software
Los modelos de ciclo de vida de desarrollo de software principales son:
• Cascada.
• Prototipo Rápido.
• Espiral.
• Modelo V.
Modelo de Cascada
•
•
•
•
•
Desde el inicio, se especifican todos los requerimientos por completo.
La fase de codificación se hace en un solo bloque.
No hay traslapes entre las fases del modelo.
Es necesario terminar todas las actividades de una fase para pasar a la siguiente. No es posible
regresarse a fases anteriores.
Como todo es cuidadosamente especificado, las pruebas se efectúan a un plan y a un calendario.
Modelo Espiral.
Este modelo involucra seis pasos principales:
• Determinar objetivos, alternativas y restricciones.
• Identificar y resolver riesgos.
• Evaluar alternativas.
• Desarrollar y probar el nivel actual.
• Planear el próximo nivel.
• Decidir el enfoque del próximo nivel.
Es un modelo mucho más flexible, se puede encontrar
problemas tempranamente.
El tester tiene la posibilidad de influenciar en el producto
desde la etapa de diseño.
Modelo Prototipo Rápido
•
•
•
•
•
•
•
Ideal cuando el sistema no se ha comprendido del todo por el usuario y/o desarrollador.
Reduce el ciclo especificación-retroalimentación del usuario.
Prototipo “quick and dirty” usado para obtener retroalimentación del usuario.
Varios ciclos de prototipeo pueden realizarse. El prototipo representa el sistema deseado, el
desarrollador y construye la aplicación correcta.
Utiliza el prototipeo para obtener información y después produce la especificación de requerimientos.
Define los escenarios importantes para el usuario y los utiliza para los casos de prueba del sistema.
Trae el punto de vista operacional (o de comportamiento) a la fase de especificación de los
requerimientos.
Modelo V
•
•
•
Es un modelo mucho más flexible.
Se trabaja paralelamente en la especificación de los requerimientos, diseño y código con la
especificación de las pruebas de aceptación, integración y unitarias.
Optimiza el tiempo de desarrollo, al trabajar paralelamente el equipo de especificación y desarrollo y el
equipo de pruebas.
CMMI 1.3 – VALIDACION Y VERIFICACION
Evolución del proceso de pruebas
❖ Antes
• Las pruebas, como etapa del ciclo de vida del software, constituían la determinación cualitativa
de la eficiencia del producto elaborado.
❖ Ahora
• Se llevan a cabo desde etapas iniciales y durante todo el ciclo, además del aseguramiento de la
calidad.
• El aseguramiento no solo se hará al final del proceso de producción sino también durante todo
el ciclo de vida.
CMMI 1.3 Verificación
•
•
•
Asegurar que los productos de trabajo seleccionados cumplan sus requerimientos especificados.
Los métodos de verificación se aplican a los productos de trabajo desde sus etapas iniciales con la
verificación de los requerimientos hasta la verificación del producto completo.
Las revisiones entre colegas es un mecanismo importante para verificar los productos de trabajo.
❖ SG1 Preparar la verificación
• SP 1.1 – Seleccionar los productos para verificación.
• SP 1.2 – Establecer el ambiente de verificación.
• SP 1.3 – Establecer los procedimientos y el criterio de verificación.
❖ SG2 Ejecutar revisión entre colegas.
• SP 2.1 – Preparar la revisión entre colegas.
• SP 2.2 – Conducir las revisiones.
• SP 2.3 – Analizar los datos de las revisiones.
❖ SG3 Verificar el producto y sus componentes.
• SP 3.1 – Realizar la verificación.
• SP 3.2 – Analizar los resultados de la verificación.
CMMI 1.3 Validación
❖ SG1 Preparar la validación.
• SP 1.1 – Seleccionar los productos para validación.
• SP 1.2 – Establecer el ambiente de validación.
• SP 1.3 – Establecer los procedimientos y el criterio de validación.
❖ SG2 Validar el producto y sus componentes.
• SP 2.1 – Realizar la validación.
• SP 2.2 – Analizar los resultados de la validación.
EL MODELO DE MADUREZ DE PRUEBAS (TMMSM)
Ventajas:
•
•
•
Los niveles de madurez corresponden con SW-CMM.
TMMSM puede ser utilizado fácilmente en conjunto con SW-CMM, CMMI, ISO-9001, e ISO/IEC 12207.
Simplifica la planeación, implementación y monitoreo de la mejora de los procesos.
Desventajas:
•
Existen pocos libros publicados al respecto (Un libro, Practical Software Testing: A Process-Oriented
Approach, por Dr. Ilene Burnstein está en fase de edición final).
Niveles de Madurez:
➢
➢
➢
➢
➢
Nivel 1 – Inicial.
Nivel 2 – Fase de Desarrollo.
Nivel 3 – Integración.
Nivel 4 – Administración y Métricas.
Nivel 5 – Optimización, prevención de defectos y control de calidad.
•
•
•
Cada nivel, excepto el nivel 1, contiene Metas de Madurez.
Las metas de madurez, son soportadas por sub-metas de madurez.
El logro de las sub-metas son alcanzadas por la satisfacción de las
Actividades-Tareas-Responsabilidades (ATRs).
ATRs son acciones específicas identificadas que deberán ser optimizadas.
•
Cada acción es asignada:
➢ Administradores.
➢ Desarrolladores / Testers.
➢ Usuarios / Clientes.
Nivel 1 – Inicial
•
•
•
•
•
El proceso de pruebas es caótico.
Es definido, pero no se distingue del eliminado de errores (debugging).
Las pruebas desarrolladas son adecuadas después de que la codificación esta completada.
Se carece del personal adecuado, personal capacitado o herramientas.
El software se entrega comúnmente sin aseguramiento de la calidad.
Nivel 2 – Fase de Desarrollo
•
•
•
•
Las pruebas están separadas del debugging.
Fase después de la codificación.
La meta primaria de las pruebas es mostrar las especificaciones del software conocidas.
Técnicas basadas de pruebas y los métodos están en un lugar.
Nivel 3 – Integración
•
•
•
•
Integración de pruebas dentro del ciclo de vida entero.
Pruebas objetivas basadas en los requerimientos.
Existen pruebas en la organización.
Reconocimiento de pruebas como una actividad profesional.
Nivel 4 – Administracion y Metricas.
•
•
•
•
•
Pruebas es un proceso medido y cuantificado.
Se llevan a cabo revisiones en todas las fases de desarrollo y son reconocidas como pruebas.
Los productos son probados por atributos de calidad, tales como, confiabilidad, uso y mantenimiento.
Los casos de pruebas son recolectados y guardados en una base de datos de pruebas para reutilización
y regresión de pruebas.
Los defectos son registrados y alcanzan niveles severos.
Nivel 5 – Optimización, prevención de defectos y control de calidad.
•
•
•
•
•
•
•
•
Pruebas está definido y administrado.
Los costos de pruebas y la efectividad pueden ser monitoreadas.
Pruebas pueden ser finamente y continuamente mejoradas.
La prevención de defectos y el control de calidad son practicados.
Las herramientas automatizadas son una parte primaria del proceso de pruebas.
Las herramientas proveen soporte para el diseño del os casos de prueba y el análisis de la colección de
defectos.
Las métricas relacionadas con pruebas también tienen herramienta de soporte.
La reutilización del proceso es practicada.
TIPOS DE PRUEBAS
Objetivos primarios del proceso de pruebas
•
•
•
•
Demostrar que el desarrollo de un producto será útil al usuario final.
Verificar que el sistema cumple con los requerimientos del cliente para el cual fue creado.
Identificar defectos antes de la puesta en producción.
Aceptar o rechazar el producto, en función de parámetros definidos previamente.
Alcance del proceso de pruebas
• Se debe realizar para cada nuevo desarrollo, cambio o mantenimiento a implementar en producción.
TIPOS DE PRUEBAS – CAJA NEGRA
Características de las pruebas de caja negra
•
•
•
Las pruebas de caja negra se conocen por data-driven o input-output driven.
Se concentra en encontrar las circunstancias en las que el programa no se comporta de acuerdo a sus
especificaciones.
Los casos de prueba se basan en probar todas las condiciones de entradas posibles. Es necesario
reducir el número de casos de prueba.
Pruebas de caja negra estática
Estas pruebas se aplican a los documentos de especificación del producto de software. Por ejemplo:
• La documentación de la arquitectura.
• La documentación del diseño.
• La documentación de las interfases.
• Otros documentos que sean de especificación.
Un checklist que verifique los atributos siguientes:
• Completo.
• Exacto.
• Preciso, no ambiguo, claro.
• Consistente.
•
•
•
•
Relevante.
Factible.
Libre de código.
Verificable.
Características de las pruebas de caja negra dinámicas
•
•
•
•
Las pruebas de aja negra dinámicas también se conocen por behavioral testing.
Son dinámicas porque verifican los casos de prueba cuando el programa se está ejecutando.
Son de caja negra porque se introducen datos de entrada, se reciben datos de salida y se evalúan los
resultados sin saber exactamente cómo funciona el programa.
Para generar los casos de prueba se requiere forzosamente el o los documentos de especificación del
producto.
Pruebas de caja negra dinámicas
❖ Prueba de Datos:
• Condiciones de limite y sub-limites.
• Default, vacío, blanco, nulo, cero y ninguno.
• Datos incorrectos, erróneos, inválidos, basura.
❖ Pruebas de Estado:
• Flujo lógico del software.
• Estados de falla.
¿Qué es una partición de equivalencia?
•
•
•
•
Conjunto de casos de prueba que prueba la misma cosa o revela el mismo error.
Se utiliza para reducir considerablemente el número de casos de prueba posible a uno más pequeño
pero igualmente efectivo y manejable.
Cuidado al seleccionar la partición, se está escogiendo no probar todo.
Puede ser subjetiva su selección.
Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices:
1. Si una condición de entrada especifica un rango, se define una clase de equivalencia valida y dos no
válidas.
• (Valida) 1 <= Numero <= 49;
• (No Valida) Numero < 1, Numero > 49
2. Si la condición de entrada es un valor especifico, se define una clase de equivalencia valida y dos no
válidas.
• (Valida) Num. propietarios = 3;
• (No Valida) Num. Propietarios < 3, num propietarios > 3.
3. Si la condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia
valida y otra no valida.
• (Valida) “El primer carácter es una letra”;
• (No Valida) “(…) no es una letra”.
4. Si la condición de entrada es lógica, se define una clase de equivalencia valida y otra no valida.
• Tres tipos de inmuebles: (Valida) “Pisos”, ”Chalets”, ”Locales comerciales”.
• (No valida): “Jkllñ”.
Análisis de Valores Limite (AVL)
Los casos de prueba que exploran las condiciones limite producen mejores resultados.
• “Los defectos del software se acumulan en situaciones límite”.
Diferencias de AVL con particiones de equivalencia:
• No se elige “cualquier elemento” de la clase de equivalencia, sino uno o más de manera que los
márgenes se sometan a prueba.
• Los casos de prueba se generan considerando también el espacio de salida.
Reglas para identificar casos:
1. Si una condición de entrada especifica un rango delimitado por los valores a y b, se debe generar casos
para a y b y casos no validos justo por debajo y justo por encima de a y b, respectivamente.
• Rango de entrada: [-1.0,1.0]
• Caso de Prueba para: -1.0, +1.0, -1.001, +1.001
2. Si una condición de entrada especifica un numero de valores, se deben desarrollar casos de prueba
que ejerciten los valores máximo y mínimo, uno más el máximo y uno menos el mínimo
• “El fichero de entrada tendrá de 1 a 255 registros”.
• Caso de Prueba para 0,2,254,256.
3. Aplicar las directrices 1 y 2 a las condiciones de salida.
• “El programa podrá mostrar de 1 a 4 listados”.
• Caso de Prueba para intentar generar 0,1,4 y 5 listados.
4. Si las estructuras de datos internas tienen límites preestablecidos, hay que asegurarse de diseñar un
caso de prueba que ejercite la estructura de datos en sus límites.
TIPOS DE PRUEBAS – CAJA BLANCA
Características de las pruebas de caja blanca.
•
•
•
•
•
•
•
Se conocen también por logic-driven.
Examinan la estructura lógica del programa.
Los casos de prueba se basan en probar todas las trayectorias posibles de flujo de control.
Esta prueba exhaustiva de todas las trayectorias, no garantiza que el programa carezca de errores.
No es garantía de que el programa cumple con la especificación.
No detecta la ausencia de trayectorias necesarias.
No evidencia los errores sensibles a los datos.
Pruebas de caja blanca estáticas.
Estas pruebas se realizan sobre el diseño y el código.
❖ Revisiones Formales:
• Revisiones entre colegas.
• Walkthroughs.
• Inspecciones.
❖ Estándares de codificación y guías:
• Estándares y guías de programación.
• Checklists de revisión de código.
Revisiones entre colegas
•
•
•
•
•
Son las más informales.
Participan el programador que escribió el código y otro programador que actúa como tester.
El pequeño grupo revisa el código juntos y buscan problemas o equivocaciones.
Al revisor se le solicita sus comentarios generales y que sugiera mejoras al código.
Si se desea se puede utilizar un cheklist para la revisión.
Walkthroughs
•
•
•
•
•
Son más formales que las revisiones entre colegas.
Requiere de una examinación del código previa a la revisión.
La persona que presenta el código es la misma que lo escribió.
Después de la revisión, el presentador escribe un reporte con los errores encontrados y como planea
resolverlos.
Entre los revisores debe haber uno con mayor experiencia.
Inspecciones
•
•
•
•
•
Son las más formales de todas las revisiones
Son altamente estructuradas.
Cada participante requiere de capacitación especifica.
La persona que presenta el código no es la misma que el programador original.
Cada participante toma una perspectiva diferente de revisión: Usuario, tester, soporte.
Estándares y guías de programación.
❖ Estándares:
• Reglas establecidas, fijas que se tienen que seguir. Son los do’s y los don’ts.
• Los estándares no tienen excepciones.
❖ Guías:
• Las mejores prácticas sugeridas, recomendaciones, forma preferida de hacer las cosas.
• Las guías son un poco mas relajadas.
Importancia de adherirse a un estándar/guía:
• Confiabilidad: Es más seguro un código que se apega a un estándar o a una guía que el que no lo hace.
• Legibilidad/Mantenibilidad: El código que se apega a esto es más fácil de leer, entender y mantener.
• Portabilidad: El código que se apega a estos es mucho más fácil de mover entre plataformas
diferentes.
Checklists de revisión de código.
•
En cualquiera de las revisiones formales se puede utilizar un checklist de revisión de código genérico.
•
Sin importar el lenguaje de programación, los principales aspectos que un checklist cubre son:
➢ Errores de referencia de datos.
➢ Errores de declaración de datos.
➢ Errores de computación.
➢ Errores de flujo de control.
➢ Errores de parámetros de subrutina,
➢ Errores de entrada/salida.
➢ Otros.
Pruebas de caja blanca dinámicas.
❖ Cobertura de Datos:
• Flujo de Datos.
• Sublimites.
• Formulas y Ecuaciones.
• Forzar el Error.
❖ Cobertura de Código:
• Cobertura de Línea.
• Cobertura de Rama.
• Cobertura de Condición.
Prueba del camino básico.
Los objetivos de estas pruebas son:
1. Obtener una medida de la complejidad lógica de un diseño procedural.
2. Usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.
•
•
Los casos de prueba obtenidos del conjunto básico garantizan que durante la prueba se ejecuta al
menos una vez cada sentencia del programa.
Se puede automatizar.
❖ Complejidad Ciclomatica:
• Métrica del Software que proporciona una medición cuantitativa de la complejidad
lógica de un programa.
• Define el Numero de caminos independientes del conjunto básico de un programa.
• Determina el número de casos de prueba que se deben realizar para asegurar que se
ejecuta cada sentencia al menos una vez.
METRICAS
•
•
Una base de datos de rastreo de errores es un medio importante para medir el estado del proyecto.
El termino de Métrica de software se usa para describir la medición de un atributo particular de un
proyecto de software.
Ejemplo de métricas:
• El promedio de errores por tester por día.
• El número de errores encontrados por área de software.
• El porcentaje de errores por severidad.
Un tester utiliza métricas todo el tiempo, algunas comunes y de uso individual son:
• ¿Cuáles son los identificadores de los errores que tengo asignados para cierre?
• ¿Cuántos errores de los que he encontrado, se resolvieron como “no se arreglaran”?
• ¿Cuántos errores he introducido en este proyecto?
• ¿Cuántos de mis errores fueron de severidad 1 o 2?
• ¿De todos los errores que he encontrado, cuantos se corrigieron?
Métricas comunes a nivel proyecto:
• Errores encontrados en cada área funcional del software.
• Errores encontrados en el tiempo.
• Errores acumulados en el tiempo.
• Errores acumulados resueltos y errores acumulados cerrados en el tiempo.
PRUEBAS DE LA DOCUMENTACION
¿Qué documentos se prueban?
•
•
•
Garantía.
Etiquetas.
Setup.
•
•
•
Manual de usuario.
Ayuda en línea.
Tutoriales, Wizards.
•
Mensajes de Error.
Importancia de probar la documentación
Una buena documentación del software contribuye a la calidad del producto de tres maneras:
• Mejora la usabilidad.
• Mejora la confiabilidad.
• Reduce los costos de soporte.
Aspectos a considerar en las pruebas.
•
•
•
General: Audiencia.
General: Terminología.
General: Contenido.
•
•
•
Correctez: Figuras e Imágenes Capturadas.
Correctez: Muestras y Ejemplos.
Correctez: Ortografía y Gramática.
PRUEBAS DE USABILIDAD
¿Qué es la usabilidad?
•
•
Usabilidad es cuan apropiada, funcional y efectiva es la interacción del software.
El principal medio que se utiliza para interactuar con un programa es la interfaz de usuario o user
interface (UI).
Características de UI
Una adecuada interfaz de usuario posee:
• Cumplimiento con estándares y
lineamientos.
• Intuitiva.
• Consistente.
•
•
•
•
Flexible.
Cómoda.
Correcta.
Útil.
Se recomienda la página web de Jakob Nielsen para ahondar en aspectos de usabilidad
• http://www.useit.com/
PRUEBAS DEL WEBSITE
Características de las páginas web
En cada página web deben verificarse:
• Tamaño, Tipografía y color de texto.
• Texto y gráficos de hyper-enlace.
• Anuncios Rotatorios.
• Textos de las cajas de selección drop-down.
• Campos para introducir información.
• Posicionamiento y contenido personalizable.
• Compatibilidad entre browsers, versiones y plataformas de software y hardware.
Web – Prueba de Caja Negra
•
•
•
Cada página se ve como una caja negra.
Se verifican los detalles funcionales a nivel general.
Aspectos a considerar:
➢ Texto.
➢ Hyperligas.
➢ Gráficos.
➢ Formas.
➢ Objetos.
Web – Prueba de Caja Gris
•
•
Es una mezcla de las pruebas de caja negra y de caja blanca.
Consiste principalmente en observar el código HTML de la página web para encontrar errores.
Web – Prueba de Caja Blanca
•
Se verifica el código para generar las páginas web utilizando las técnicas de caja blanca.
Algunos aspectos a considerar son:
• Contenido dinámico.
• Paginas manejadas por base de datos.
• Paginas creadas por programación.
• Rendimiento y carga del servidor.
• Seguridad.
Web – Prueba de Configuración y Compatibilidad.
Aspectos a probar en un sitio web:
• Plataformas de hardware.
• Exploradores web y versiones.
• Plug-Ings de los exploradores.
• Opciones del explorador.
• Resolución de video y profundidad de color.
• Velocidades del modem.
OTROS TIPOS DE PRUEBA
Estrategias
❖ Análisis Dinámico: Requiere la ejecución del código.
• Pruebas de Aceptación.
• Pruebas de Instalación.
• Pruebas de Rendimiento.
• Pruebas de Funcionalidad.
• Pruebas de Integración.
• Pruebas de Unidad.
❖ Análisis Estético: No código en ejecución.
• Revisiones entre colegas.
• Seguimiento.
• Demostración del programa.
Tipos de prueba
Prueba de
Unidad
Prueba de
Unidad
Prueba de
Integración
Prueba de
Unidad
Prueba de
Funcional
Módulos
Integrados
Prueba de
Rendimiento
Sistema
Funcionando
Prueba de
Aceptación
Software
verificado y
validado
Prueba de
Instalación
Sistema
Aceptado
¡SISTEMA EN
USO!
Pruebas de Regresión
•
•
Las pruebas de regresión se aplican a una nueva versión o liberación, para verificar que la aplicación
ejecuta las mismas funciones todavía de la misma manera como en una versión o liberación anterior.
Especificar y crear una batería de pruebas completa es importante para realizar las pruebas.
Pruebas de Aceptación
•
•
•
•
Una serie de pruebas que el cliente ejecuta cuando el desarrollo está terminado.
El propósito es facilitar al cliente y a los usuarios que determinen si el sistema verdaderamente
satisface sus necesidades y expectativas.
Las pruebas de aceptación deberían definirse junto con el cliente.
El cliente debe estar de acuerdo en que, si el sistema pasa las pruebas, el contrato se ha cumplido y
que cualquier otro cambio o problema se pagara por separado.
Tipos de pruebas de aceptación.
❖ Prueba Piloto
• Instala el sistema en una base experimental.
• Las pruebas corresponden al trabajo diario en el sistema para probar todas las funciones.
• Es menos formal y estructurado que una prueba de benchmark.
• Pruebas Alpha: Se pone a prueba en las instalaciones del desarrollador.
• Pruebas Beta: Se pone a prueba en las instalaciones del cliente.
❖ Prueba en Paralelo
• El sistema nuevo funciona, en paralelo, con la versión anterior.
• La transición gradual ayuda a los usuarios a comparar y contrastar el sistema nuevo con el
anterior.
• Permite a los usuarios tener confianza en el sistema nuevo.
Pruebas de Instalación
•
•
•
•
Instalar el sistema en la sede del usuario.
Si las pruebas de aceptación se han realizado en las instalaciones, las pruebas de instalación pueden no
ser necesarias.
Requiere trabajar con el cliente para determinar las pruebas que no son necesarias.
Las pruebas se centran en la integridad del sistema instalado.
Pruebas de Rendimiento
Los tipos de pruebas de rendimiento se determinan por los tipos de requerimientos no funcionales:
• Pruebas de Strees: Evalúan al sistema cuando se le presiona hasta tus limites por un corto periodo de
tiempo.
• Pruebas de Volumen: Abordan el manejo de grandes cantidades de información en el sistema.
• Pruebas de Configuración: Analizan las diversas configuraciones de software y hardware especificadas
en los requerimientos.
• Pruebas de Compatibilidad: Se utilizan para probar las interfaces del sistema con otros sistemas.
• Pruebas de Regresión: Se realizan cuando el sistema probado reemplaza a uno existente.
• Pruebas de Seguridad: Garantizan que los requerimientos de seguridad se cumplan.
• Pruebas de Sincronización: Evalúan los requerimientos relacionados al tiempo de respuesta a un
usuario y el tiempo de ejecutar una función.
• Pruebas Ambientales: Valoran la habilidad del sistema para desempeñarse en el sitio de instalación.
• Pruebas de Calidad: Evalúan la confiabilidad, mantenibilidad y disponibilidad del sistema.
• Pruebas de Recuperación: Se ocupan de la presencia de fallas o de la perdida de información.
• Pruebas de Mantenimiento: Cubren la necesidad de herramientas de diagnóstico y procedimientos
para ayudar a localizar el origen de los problemas.
• Pruebas de Documentación: Verifican que los documentos necesarios se hayan redactado.
• Factores Humanos: Investigan los requerimientos relacionados con la interfaz del usuario del sistema.
Arquitectura C/S con Múltiples Capas
Ventajas y Desventajas
•
•
Ningún método o herramienta para pruebas garantiza que un programa va a estar libre de defectos, sin
embargo, algunos son mejores que otros.
Por lo anterior es importante hacer la elección correcta, para lo cual es necesario tomar en cuenta
depende de la fase en la que se encuentre el sistema, por ejemplo: Las pruebas unitarias y entre pares
son muy rápidas y efectivas para encontrar errores de código, así como problemas simples de diseño,
sin embargo, no son recomendables para pruebas de rendimiento complejo (perfomance) o problemas
de usabilidad.
HERRAMIENTAS DE PRUEBA
Herramientas de Código Abierto
Existen una gran variedad de herramientas, entre ellas se mencionan:
HERRAMIENTA
JFunc: JUnit Functional Testing Extension
Avignon
Doit: Simple Web Application Testing
Eclipse TPTP
ITP
Ivalidator
jWebUnit
Marathon
Toster
J2ME Unit Testing Toolkit
TIPO DE PRUEBA
Pruebas de Integración
Pruebas de Aceptación
Aplicaciones Web y Formularios
Pruebas de Rendimiento de Unidad y Manuales
Pruebas de Regresión
Pruebas de Integración y Regresión
Pruebas de Aceptación para Aplicaciones Web
Pruebas de Aceptación y Regresión
Pruebas de Sistema
Prueba de Aplicaciones Web y de Servicios
Recomendaciones
Algunas recomendaciones de las herramientas y de la automatización de pruebas:
• Como el software cambia, no es recomendable generar muchas macros.
• Jamás serán un sustituto del ojo humano y de la intuición del tester.
• La verificación es difícil de realizar.
• Utiliza los mismos estándares y guías de tus programadores.
• Evita las herramientas que son invasivas, los que modifican el código cuando encuentran un error.
• Cualquier herramienta automatizada puede ser de utilidad, sin embargo, se debe ser cuidadoso con su
uso ya que muchos programadores asumen que las herramientas que utilizan son poderosas por que
encuentran todos sus errores simples de código o incluso sintaxis incorrecta, sin embargo, no debemos
olvidar que es posible que se pueda generar una sintaxis correcta y aun así el programa tenga una
lógica incorrecta.
• Algunos datos arrojados al utilizas PSP muestran que cuando se utilizan lenguajes tradicionales, las
herramientas que utilizan los programadores no detectan el 10% de errores simples en la tipografía o
de codificación. Esta es la razón por la cual la mayoría de ellos caen en la trampa y creen que están
generando un código 100% libre de este tipo de errores, y dejan de tratar de detectar algunos más.
EL PROCESO DE PRUEBAS
El Proceso de Pruebas
- Crear el contexto de pruebas.
- Comprender el contexto más ampliamente.
- Evaluar y priorizar los riesgos de calidad.
- Estimar el esfuerzo de pruebas.
- Conjuntar el equipo de pruebas.
- Construir el ambiente de pruebas.
- Refinar el proceso de prueba.
- Ajustar el proceso de prueba actual.
- Institucionalizar las mejoras a largo plazo.
- Evaluar la calidad de un sistema bajo prueba.
- Obtener una liberación de pruebas.
- Ejecutar las pruebas.
- Documentar los resultados de las pruebas.
Evaluar
Calidad
Crear
Contexto
El Proceso de
Prueba
Refinar
Prueba
Comunicar
- Comunicar los resultados de las pruebas.
- Identificar las necesidades de los involucrados.
- Definir el tablero de pruebas.
❖ Criterios de Finalización
• Costos.
• Tiempo.
• Defectos Encontrados.
Estos son útiles, pero siempre será mejor los criterios de cobertura.
•
•
•
•
•
•
•
Si asumimos que las pruebas son necesarias, debemos diseñar un proceso que proporcione el máximo
valor posible, ejecutando actividades que reduzcan los riesgos.
Comprobar que las especificaciones son diseñadas y codificadas como fueron documentadas.
Considerar que las necesidades del negocio, el software y los procedimientos manuales asociados con
su desarrollo, proporcionen la suficiente seguridad.
El proceso de pruebas arranca desde el inicio del proyecto, una vez entendidos los requerimientos.
La actividad más importante que se debe realiza, es la revisión de la documentación de requerimientos
(Pruebas Estáticas).
Muchos problemas y defectos detectados en la ejecución de las pruebas de aceptación son provocados
por los malos entendidos desde la documentación de los requerimientos originales.
La simple comprobación de que todos entendemos lo mismo de los requerimientos documentados,
eliminara los defectos de diseño.
Principio del Proceso de Pruebas
Algunas de las dificultades importantes para realizar adecuadamente el proceso de pruebas son:
• Tener un proceso de pruebas completo NO ES POSIBLE.
• Limitaciones Practicas: Es importante alcanzar confianza total con cualquier tipo de pruebas. Los
procesos de pruebas son tediosos y exhaustivos.
• Limitaciones Teóricas: No podemos estar seguros de que las especificaciones son correctas. La prueba
de sistemas no puede identificar que todo programa es correcto.
• Los sistemas no son simples, por lo tanto, no es simple entenderlos. Para realizar un buen proceso de
pruebas es necesario entender completamente el sistema. De aquí, que el proceso de pruebas no es
simple.
• Una importante razón para realizar el proceso de pruebas es prevenir la ocurrencia de defectos.
Barrera del Proceso de Pruebas
Alguna de las dificultades importantes para realizar adecuadamente el proceso de pruebas son:
• El proceso de pruebas pone en duda la efectividad del desarrollo del sistema que ha sido realizado.
• Se carece de una metodología que proporcione el aseguramiento necesario de que el sistema se
encuentra libre de defectos.
• Resistencia.
Objetivos Primarios del Proceso de Pruebas
•
•
•
•
Demostrar que el desarrollo de un producto será útil al usuario final.
Verificar que el sistema cumple con los requerimientos del cliente para el cual fue creado.
Identificar defectos antes de la puesta de producción.
Aceptar o rechazar el producto, en función de parámetros definidos previamente.
Alcance del Proceso de Pruebas
•
Se debe realizar para cada nuevo desarrollo, cambio o mantenimiento a implementar en producción.
Verificación del Alcance
Alcanzar los objetivos asegura:
• El riesgo asociado de no entregar un producto aceptable es minimizado.
• La calidad del producto a entregar.
• La capacidad de entregar productos de alta calidad se incrementa.
Enfoque del Proceso de Pruebas
En lo que todas las organizaciones coinciden, es en que es una prueba desde la perspectiva del negocio.
• ¿Cubre el software mis necesidades?
• ¿Hasta dónde responde a mis requerimientos?
• ¿Cómo funcionara en mi ambiente de trabajo?
ETAPAS DEL PROCESO DE PRUEBAS
Estrategia del Proceso de Pruebas
El diseño de las pruebas se puede llevar a cabo en tres etapas:
• Requerimientos y Especificaciones.
• Diseño del Software.
• Código (la lógica y las estructuras de datos).
Etapa de Requerimientos
Funciones y/o requerimientos que serán probados:
• ¿Cómo van a ser probados?
• ¿Qué necesitamos para comprobarlos?
• ¿Cuáles son los criterios de validación de las pruebas?
Etapa de Especificaciones
Componentes del sistema que serán probados:
• ¿Cómo se propone probarlos?
• ¿Cómo voy a validar las pruebas?
• ¿Cómo se probaran los programas?
• ¿Cuánto tiempo se llevaran las pruebas?
Etapa de Codificación
•
•
•
•
¿Cómo vamos a crear el ambiente de pruebas?
¿Qué se necesita para crear el ambiente de pruebas?
¿Cómo se van a ejecutar las pruebas?
¿Cuánto tiempo se llevaran las pruebas?
COMPONENTES DEL PROCESO DE PRUEBAS
Planeación
•
•
•
•
•
•
•
Se inicia en etapas tempranas, no hasta la codificación.
El plan de pruebas evoluciona conjuntamente con el proyecto de desarrollo o mantenimiento del
sistema, documentarlo y desarrollarlo en todo el proyecto.
Definiendo un plan de pruebas.
Identificar los objetivos del negocio.
Resumen del plan:
o Descripción de funciones.
o Atributos no funcionales asociados.
Detalles de las pruebas:
o Casos de pruebas.
o Scripts de pruebas.
Desarrollar un plan de ejecución de pruebas:
o Establecer las especificaciones del ambiente de pruebas.
o Especificar los criterios de entrada y salida de datos.
o Características que no se probaran.
o Criterios de terminación (exitoso/rechazo/suspensión).
o Políticas para atención de fallas encontradas.
o Riesgos de plan y medidas contingentes.
Ejecución
•
•
Desempeño de las pruebas estáticas a toda la documentación desarrollada en todas las fases
anteriores a la programación.
Ejecución de las pruebas dinámicas.
Documentación
•
•
Todos los elementos de los planes y sus resultados deben ser documentados para su formalización y
que las pruebas futuras se beneficien de las anteriores.
Los registros generan métricas.
PLAN DE PRUEBAS
Plan Maestro de Pruebas
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Es el documento más importante para el área de pruebas.
Debe de comunicarse a todos los miembros del equipo de desarrollo.
El plan de pruebas comprende de los siguientes aspectos:
o Expectativas de alto nivel.
o Personal, ambiente, otros.
o Responsabilidades inter-grupales.
o Que si y que no será probado.
o Fases de las pruebas.
o Estrategia de prueba.
o Recursos.
o Testers, calendario.
o Casos de prueba.
o Reporte de bugs.
o Métricas y estadísticas.
o Riesgos e issues.
Expectativas de alto nivel: Definir el propósito del proceso y del plan de pruebas.
Personal, ambiente, otros: Identificar a la gente que trabaja en el proyecto.
Responsabilidades inter-grupales: Identificar las actividades y los entregables que afectan el trabajo
de las pruebas.
Que si y que no será probado: Delimitar que componentes si se probaran y cuáles no, ya que no todo
lo incluido en el producto de software se prueba, sobretodo el software de terceros.
Fases de las pruebas: Identificar las etapas de prueba de acuerdo al modelo proyecto.
Estrategia de prueba: Identificar las técnicas de prueba que se emplearan en cada fase.
Recursos: Estimar todo lo necesario que se utilizara en las pruebas durante el proyecto.
Testers, calendario: Generar el calendario de las actividades de prueba e incluirlas en el calendario del
proyecto global.
Casos de Prueba: Definir los casos de prueba de acuerdo a la estrategia definida.
Reporte de bugs: Definir el reporte de bugs para cada error que se detecte.
Métricas y Estadísticas: Identificar las métricas a través de las cuales se medirá el éxito del proyecto y
del proceso de pruebas.
Riesgos e Issues: Identificar los riesgos del proyecto que puedan impactar el proceso de pruebas.
Se pueden encontrar los formatos oficiales de la IEEE 829 en http://www.standards.ieee.org, o bien, en
la web haciendo una búsqueda con el termino “Test Plan Template”.
El Plan maestro de pruebas es uno de los principales work products relacionados con la SP 1.3 de la PA
de Validación.
Ambiente de Pruebas
•
•
Definición de requerimientos que se necesitan para efectuar las pruebas tales como: área de trabajo,
hardware, software, soporte técnico, seguridad, etc.
Definición de las aplicaciones o módulos que deberán ser probados.
Técnicas y Herramientas de Prueba
•
Identificar las técnicas y herramientas que se utilizan para planear y ejecutar las pruebas.
Documentación de Pruebas
Plan de
Pruebas
Especificación del Diseño de
Pruebas.
Especificación del
Diseño de Pruebas.
Incrementar el
énfasis en el proceso
de creación del plan.
Incrementar el
énfasis en el plan
escrito.
Especificación de los
casos de pruebas.
Especificación del
Procedimiento de Prueba
DISEÑO DE PRUEBAS
Importancia del Diseño de la Prueba
•
•
•
•
En un documento que refina el detalle del Plan de Pruebas.
Describe la prueba que es necesaria realizar a una característica específica, sin detallar los casos o los
pasos para ejecutar la prueba.
Identificar los casos y los procedimientos de prueba.
Especificar el criterio de pase/fallo del proceso de prueba.
Diseño de la Prueba
•
Los puntos importantes de un diseño de pruebas son:
o Identificadores: Es un identificador único que se usa para referenciar y localizar la
especificación del diseño de prueba.
o Características a Probarse: Una descripción de la característica del software cubierta por la
especificación del diseño de prueba.
o Enfoque: Describe la técnica que se utilizara.
o Identificación del Caso de Prueba: Una descripción de alto nivel y referencias a los casos y
procedimientos de prueba específicos que se usaran para comprobar la característica.
o Criterio de Pase/Fallo: Describe exactamente que constituye un pase y un fallo de la
característica probada.
CASOS DE PRUEBA
Importancia de los Casos de Prueba
•
Una adecuada planeación de los casos de prueba es importante por:
o Organización: Los casos de prueba se tienen organizados para que se usen en otros proyectos.
o Repetibilidad: Los casos de prueba deben poder ejecutar cuantas veces sea necesario para
verificar la ausencia de errores anteriores.
o Rastreo: Es importante obtener diversas estadísticas de las pruebas realizadas.
o Evidencia de la Prueba: Para aplicaciones de alto riesgo, los casos de prueba son evidencia de
haberlas probado.
Casos de Prueba
•
•
•
Un caso de prueba contiene los siguientes puntos:
o Identificador: Formado por letras y números. Lo importante es que sea único.
o Aspecto a probar: Describe la característica a probar, el módulo de código y todo lo demás que
será probado.
o Entrada: Lista todos los datos de entrada o condiciones del software para que se ejecute el caso
de prueba.
o Salida: Describe los resultados que se esperan de la ejecución del caso de uso.
o Necesidades Ambientales: Todo lo necesario para ejecutar el caso de prueba: Software,
Herramientas de Prueba, Instalaciones, Personal.
o Requerimientos de Procedimiento Especiales: Describe todo lo inusual que deba hacerse para
realizar la prueba.
o Dependencia entre Casos: Si un caso de prueba depende de otro caso o puede verse afectado
por uno, debe especificarse también.
Se pueden encontrar formatos en la web haciendo una búsqueda con el termino “Test Case
Template”.
Los Casos de Prueba son uno de los principales work products relacionados con la SP 1.3 de la PA de
Validación.
¿Dónde almacenar los casos de prueba?
•
Dependiendo del tamaño del proyecto y de los recursos financieros que se quiera invertir, se pueden
almacenar en 4 medios posibles:
o Cabeza: Para proyectos muy pequeños.
o Papel/Documentos: Para proyectos pequeños. Se utiliza tablas y cuadros de checklists.
o Hoja de Cálculo: La hoja de calculo Excel es la mas ampliamente utilizable. Permite de una
ojeada tener un panorama general del estado de las pruebas.
o Base de Datos Personalizada: Es el método ideal. Permite crear la base de datos de acuerdo a la
IEEE 829.
PROCEDIMIENTO DE PRUEBA
Procedimiento de Prueba
•
•
•
•
•
Define, paso a paso, los detalles de exactamente como realizar los casos de prueba.
Los aspectos que incluye un procedimiento de prueba son:
o Identificador: Un identificador único que liga al procedimiento de prueba con los casos y el
diseño de prueba.
o Propósito: Describe el propósito del procedimiento y las referencias a los casos de prueba que
deban ejecutarse.
o Requerimientos Especiales: Otros procedimientos, habilidades de prueba o equipo especial
necesario para ejecutar el procedimiento.
La descripción detallada de como las pruebas se ejecutan. Algunos puntos que puede contener:
o Bitácora.
o Setup.
o Inicio.
o Procedimiento.
o Medición.
o Cierre.
o Reinicio.
o Terminación.
o Wrap up.
o Contingencias.
Se pueden encontrar los formatos oficiales de la IEEE 829 en http://www.standards.ieee.org, o bien, en
la web haciendo una búsqueda con el término “Test Procedure Template”.
El Procedimiento de prueba es uno de los principales work products relacionados con la SP 1.3 de la
PA de Validación.
REPORTE DE ERRORES
Reporte de Errores
•
•
•
Algunos principios fundamentales para reportar errores:
o Reportar los errores tan pronto como sea posible.
o Describe los errores efectivamente
▪ Minimo.
▪ Singular.
▪ Obvio y general.
▪ Reproducible.
o Se no critico al reportar los errores.
o Reitera tus reportes de errores.
Severidad indica que tan malo es el error; la probabilidad y el grado de impacto cuando el usuario
encuentre el error.
Prioridad indica cuanto énfasis debería de ponerse en corregir el error y la urgencia de hacerlo
corregir.
BIBLIOGRAFIA
•
•
•
•
Ron Patton. Software Testing. Second Edition. Sams. 2006.
William E. Perry y Randall W. Rice. Surviving the top ten challenges of software testing:
Apeople-oriented approach. Dorset House. 1997.
Glendford J. Myers. The art of software testing. Second Edition. John Wiley & Sons. 2004.
Paul C. Jorgensen. Software Testing. A craftsman’s approach. CRC Press. 1995.
SITIOS WEB
•
•
•
Estándares de la IEEE 829: http://www.standards.ieee.org
International Institute for Software Testing: http://www.iist.org
Quality Assurance Institute: http://www.qaiworldwide.org
Diversas Herramientas de Prueba:
• www.mercury.com/us/products/quality-center/functional-testing/quicktest-professional
• www.seapine.com/ttpro
• www.compuware.com
• www.qadownloads.com
• www.operativesoft.com
• www.infobeagle.com
• www.logigear.com
• www.newmerix.com
• www.tethyssolutions.com
• www.operativesoft.com
• www.pctest.com
• www.techexcel.com
• www.vectorcast.com
• www.eSkill.com
• www.adminitrack.com
• www.autoitscript.com/autoit3
• www.ranorex.com
• www.marathontesting.com