CONTROL DE CALIDAD DE SOFTWARE Test Cases RESUMEN

CONTROL DE CALIDAD DE SOFTWARE Test Cases

RESUMEN • Profesionalismo • Ingeniería de calidad • Diseño de Test Cases ▫ ▫ Test Case Core Estándares Prioridad Test Suits • Herramientas • Best practices • Ejercicios

PROFESIONALISMO • Profesionalismo: Se refiere a todas aquellas prácticas, comportamientos y actitudes que se rigen por las normas preestablecidas del respeto, la mesura, la objetividad y la efectividad en la actividad que se desempeñe. . via Definicion ABC http: //www. definicionabc. com/negocios/profesionalismo. php

Ingeniería de Calidad Según CMMI La Calidad contempla dos fases: • Control de calidad, basado en técnicas de inspección aplicadas a producción. • Aseguramiento de la calidad, que persigue garantizar un nivel continúo de la calidad del Producto o Servicio proporcionado. Ingeniería de Calidad (Quality Engineering) Aseguramiento de Calidad (Quality Assurance) Pruebas (Testing) (Unhelkar, 2002)

Test Case Core • Es el modelo de Test Case que adopta una empresa o proyecto. • Se debe considerar el Test Case Core que mejor se adapte a las tipo de trabajo del proyecto.

Que es un Test Case • IEEE Standard 610 (1990) define un test case como: ▫ “(1) Un conjunto de entradas , condiciones de ejecución, salidas esperadas para un objetivo particular , como revisar el curso de un programa o verificar cumplimiento con un requerimiento específico. ▫ “(2) (IEEE Std 829 -1983) Documentación que especifica entradas, resultados predichos, y un conjunto de condiciones de ejecución para un determinado elemento. ”

Que es un Test Case • De acuerdo con Ron Patton (2001, p. 65), ▫ “Los Test cases son entradas específicas que se prueban y los procedimientos que se siguen cuando se prueba un software. ” • Un test case aprobado es una medida de completitud de una Historia de Usuario. ▫ Una historia de usuario está completa cuando todos los test cases de aceptación relacionados han pasado satisfactoriamente.

Como Escribir Test Cases Título: Requisitos • El título debe ser claro de alrededor de 80 caracteres de preferencia. • Una acción y el elemento a ser verificado. • Requisitos de ejecución claros considerando el ambiente de prueba (usar criterio profesional). • Contiene la herramientas, scripts, condiciones de ejecución y de preparación de ambiente.

Como Escribir Test Cases Descripción: • Descripción debe complementar el titulo. Pasos • Pasos que describan solo una acción. • Cada paso siempre debe comenzar con un Verbo Resultado Esperado: Información adicional: • Resultado esperado simple y concreto. • Adjuntar gráficos o videos en lo posible. • Adjuntar Logs, scripts y todo lo necesario para ejecutar el Test Case.

Low-Level Test cases • Son test cases completos que contienen detalles del ambiente y los pasos detallados para ejecutar la prueba. • Presenta las siguientes secciones mínimamente: ▫ ▫ ▫ Titulo Prioridad Descripción Requisitos Pasos Resultado Esperado

Low-Level Test Case (Ejemplo) • Titulo: ▫ Verificar que se puede crear un “Acceso Directo” a la unidad C en el escritorio de Windows • Descripción: ▫ El presente Test Case permite verificar si es posible crear un “Acceso Directo” a la unidad de Disco Duro “C: ”.

Low-Level Test Case (Ejemplo) • Requisitos ▫ Un ordenador con Windows 10 instalado ▫ Una unidad C de disco duro configurada en el ordenador. ▫ Un usuario de pruebas. • Pasos: 1. Ingresar al Sistema Operativo Windows 10 con el usuario de pruebas 2. Dar click derecho en el fondo de escritorio. 3. Elegir “Nuevo” del menú emergente.

Low-Level Test Case (Ejemplo) Pasos: 4. 5. 6. 7. Elegir “Acceso Directo” del menu desplegado. Ingresar el texto “C: ” en campo “Ruta”. Presionar “Siguiente”. Presionar “Finalizar”. Resultado Esperado Un ícono con el acceso directo a la unidad “C: ” debería haber sido creado.

Pruebas (Test cases) Proceso de Pruebas

Low-Level Test Case (Ejemplo) Posibles Resultados Actuales: • En el paso 6 se muestra un error de “ruta no encontrada” • El ícono no se crea.

High Level Test Cases (HLTC) Son aquellos que contienen información resumida, por ejemplo solo Título y Resultado Esperado, por lo que el ambos suelen ser más extensos y descriptivos. Pueden ser elaborados para pruebas muy simples.

High Level Test Cases (HLTC) Son frecuentes en proyectos grandes donde los cambios caen en áreas dispersas y los Test Cases no son repetidos con frecuencia. Adicionalmente pueden contener el Tipo y Prioridad y otros detalles descriptivos útiles para el proyecto.

High Level Test Cases (HLTC) Título: • El usuario debe ser capaz de crear una tarea nueva en el Inbox. Título y Resultado Esperado: • Título: • Verificar que un usuario no autorizado recibe un error tratar de crear un archivo en una carpeta protegida. • Resultado Esperado: • El usuario debería recibir un error con el mensaje de: “Usted no tiene permisos. ”

Pruebas (Test cases) en Continuous Integration Revisar Cambios de Código Escribir & Ejecutar HLTC Reportar Progreso Desarrollo de Funcionalidad

Modelos de Desarrollo • Existen muchos modelos de desarrollo • Pero la mayoría tiene en común las siguientes etapas:

Niveles de Pruebas - The Art of Software Testing 2 nd Ed. Glenford J. Myers - Definición ISTQB Pruebas de componentes o Unitarias • Se enfoca en probar cada componente deforma individual como un pieza aislada del sistema. Pruebas de aceptación: • Es el proceso de comparar los requerimientos iniciales del sistema con las necesidades del usuario y confirma si el sistema puede ser entregado. Pruebas de sistema: • Son las pruebas del sistema en general y sus requerimientos. Pruebas de integración: • Busca probar como trabajan dos o más funcionalidades juntas

Tipos de Pruebas más comúnes Unitarias: Algoritmos Funcionales: Funcionalidad De Sistema: Requerimientos De Aceptación: Implementación De Integración: De Regresión: Lógica Relaciones entre componentes Reparación de Defectos Refactorización

Unit Testing • Son test cases elaborados por los desarrolladores una vez terminado el desarrollo una funcionalidad, método o clase. • Se elabora un método que utilice valores de prueba para simular el uso de la funcionalidad, método o clase recién creados generando una bitácora en el proceso (Logs). Clase Usuario Nueva Clase Usuario Instancia. Usuario id. Usuario datos. Usuario nombre. Usuario tipo. Usuario datos. Usuario Clase Usuario_Test

Pruebas de Funcionalidad (Functional Testing) Positivas: • Prueban la funcionalidad utilizando entradas válidas y así comprobar que funciona como espera el usuario. Negativas: • Evalúa la funcionalidad con entradas negativas esperando un error como resultado, que describa la entrada esperada.

Pruebas de Regresión • Son pruebas que buscan comprobar la estabilidad del sistema después de cambios internos que busquen mejorar el código pero sin afectar el funcionamiento actual del sistema. (Refactorización) • También son pruebas orientadas a verificar que el sistema funcione adecuadamente después de la reparación de defectos. (Que no se haya roto nada)

Pruebas de Regresión • Suelen ser las que comprueban las funcionalidades más utilizadas por los usuarios y de mayor valor para el sistema, como Login, creación y edición de elementos importantes.

Pruebas de Integración • Estas pruebas buscan comprobar la estabilidad del sistema en su conjunto enfocándose en cualquier operación que utilice llamadas entre componentes. • La misión es exponer defectos en las interfaces e interacciones entre los componentes o sistemas integrados.

Pruebas de Integración • La integración se puede dar a cualquier nivel, por tanto las pruebas deben hacerse al nivel que sea necesario: ▫ Integración de paquetes de clases. ▫ Integración de viejas funcionalidades con nuevas. ▫ Integración a través de interfaces con organizaciones externas. ▫ Intercambio de datos electrónicos. ▫ Pruebas sobre Internet.

Organización de Pruebas v Conjuntos de pruebas (Test Suit)

Reportes • Tienen que contener la información más relevante en la parte superior. • Es importante mostrar los resultados primero. • Dilo con números.

Aplicaciones para Ingeniería de Calidad • • • Team Track Test Driver QE track TFS Jira Test. Link

Low-Level Test Case (Ejemplo 2) • Titulo: ▫ Verificar que las tareas personales creadas desde Inbox se muestren en el proyecto “Personal” • Descripción: ▫ El presente Test Case permite verificar que cuando se crean Tareas de tipo “Personal” desde la carpeta principal Inbox, estas se muestran también en el proyecto llamado “Personal”.

https: //es. todoist. com

Low-Level Test Case (Ejemplo 2) • Requisitos ▫ Un navegador de internet. ▫ Una cuenta de usuario para pruebas con permisos de creación de tareas. • Pasos: 1. Ingresar a la página siguiente utilizando la cuenta de prueba: https: //es. todoist. com/ 2. Dar click en el ícono Inbox de la parte superior izquierda de la pantalla. 3. Hacer click en el link “Add Task” de la sección media de la página. 4. Escribir un nombre Tarea “Prueba 1” en el campo de texto mostrado. 5. Dar click en el ícono de selección de proyecto “Project” en la parte inferior derecha del campo de texto (Primer Icono).

Low-Level Test Case (Ejemplo) 6. Elegir la opción “Personal” las opciones desplegadas. 7. Comprobar que el texto “#Personal” aparece en el campo de texto. 8. Presionar “Add Task”. 9. Confirmar que un mensaje aparece en la parte inferior de la pantalla describiendo que la tarea se añadió al proyecto “Personal”. 10. Dar click en el proyecto “Personal” de la sección izquierda de la página. 11. Revisar las tareas mostradas dentro del proyecto “Personal” Resultado Esperado: Debería existir una tarea con el nombre utilizado en el paso 4 del presente Test Case (Prueba 1) en el proyecto “Personal”.

Tarea • Considerando que es. todoist. com acaba de implementar la funcionalidad de Filters:

Tarea • Elaborar 3 Low-Level Test Cases para la nueva funcionalidad de filtros versión gratuita. • Deben contemplar Test Cases de Funcionalidad, positivas y negativas • Elaborar 3 High Level Test Cases para regresión del sistema en general. • Elaborar 3 High Level Test Cases para probar la Integración de la funcionalidad de filtros con la funcionalidad de administración de tareas.

¿Preguntas?

¡GRACIAS!