CONTROL DE CALIDAD DE SOFTWARE

Presentación del tema: "CONTROL DE CALIDAD DE SOFTWARE"— Transcripción de la presentación:

1 CONTROL DE CALIDAD DE SOFTWARE
Test Cases

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

3 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 El profesionalismo es sumamente importante al momento de elaborar test cases ya que es indispensable seguir las normas pre-establecidas por la empresa o proyecto para el que uno hace su trabajo. La mesura es la cualidad que permite decidir cuando las pruebas son suficientes para un determinado producto considerando la relación costo-beneficio. Nunca se puedes probar todo, siempre se tienen que dejar de lado muchas pruebas que pueden demorar mucho y aportan poco al producto, para esto ayuda el principio de Pareto 80/20 en casos críticos. La objetividad es la clave en la comunicación tanto escrita como oral para hacer entender nuestro punto de vista. La efectividad tiene que ser considerada siempre al momento iniciar todo proyecto, tenemos que ser efectivos, o sea completar nuestro trabajo al 100% incluso dando más de lo esperado, más un pequeño extra en el menor tiempo posible, calcular nuestro tiempo para ello. Lograr los mejores resultados posibles en el tiempo otorgado, siendo que nos permita entender el código encontrar la mayor cantidad de fallas posible. Y en caso de notar en alguna etapa del proyecto que estamos por detrás de lo que hemos estimado, levantar la bandera de inmediato, sin importar en que etapa se encuentre, así se buscan soluciones en equipo, y se asume la responsabilidad en equipo.

4 Ingeniería de Calidad 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) La idea que plantea CMMI es adoptada por una gran mayoría de las empresas de software en el mundo, y otros estándares comparten muchos principios. Quality Assurance se basa en la parte que administra los procesos que controlan la calidad del producto, por ejemplo los administradores de QA se encargan de definir cuantos ambientes de testing se tendrán, cuantas etapas de testing son necesarias para cada sprint y en general el workflow que va de la mano con el desarrollo. (Unhelkar, 2002)

5 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. Se selecciona la cantidad de elementos que se requieren del test case como proyecto, tipo de test case, prioridad, área, ambiente, tipo de automatización, etc.

6 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 ) Documentación que especifica entradas, resultados predichos, y un conjunto de condiciones de ejecución para un determinado elemento.” EL control de calidad gira en torno a los test cases, por eso es necesario manejar un balance entre High Level y Low Level test cases, de modo que ayuden a agilizar el testeo.

7 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.

8 Como Escribir Test Cases
El título debe ser claro de alrededor de 80 caracteres de preferencia. Una acción y el elemento a ser verificado. Título: 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. Requisitos

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

10 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 Para fines didácticos tomaremos lo elementos más comúnmente utilizados en la mayor parte de los proyectos.

11 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:”.

12 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: Ingresar al Sistema Operativo Windows 10 con el usuario de pruebas Dar click derecho en el fondo de escritorio. Elegir “Nuevo” del menú emergente. Si cualquiera de los pasos tiene problemas, o no se puede confirmar, se puede tratar de un Bug.

13 Low-Level Test Case (Ejemplo)
Pasos: 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. Si cualquiera de los pasos tiene problemas, o no se puede confirmar, se puede tratar de un Bug.

14 Pruebas (Test cases) Proceso de Pruebas
Obtener Resultado y Reportes Escribir Pruebas Organizar Pruebas Ejecutar Pruebas

15 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.

16 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.

17 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.

18 High Level Test Cases (HLTC)
El usuario debe ser capaz de crear una tarea nueva en el Inbox. 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.” Título y Resultado Esperado:

19 Pruebas (Test cases) en Continuous Integration
Revisar Cambios de Código Escribir & Ejecutar HLTC Reportar Progreso Requiere mucha experiencia y entrenamiento. Desarrollo de Funcionalidad

20 Modelos de Desarrollo Existen muchos modelos de desarrollo
Pero la mayoría tiene en común las siguientes etapas: Cada tipo de testing se adapta a la estructura particular del proyecto.

21 Niveles de Pruebas Pruebas de componentes o Unitarias
- The Art of Software Testing 2nd 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

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

23 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 InstanciaUsuario idUsuario datosUsuario Nueva Clase Clase Usuario nombreUsuario tipoUsuario datosUsuario Clase Usuario_Test

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

25 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)

26 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.

27 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.

28 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.

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

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

31 Aplicaciones para Ingeniería de Calidad
Team Track Test Driver QE track TFS Jira TestLink

32 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”.

33

34 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: Ingresar a la página siguiente utilizando la cuenta de prueba: Dar click en el ícono Inbox de la parte superior izquierda de la pantalla. Hacer click en el link “Add Task” de la sección media de la página. Escribir un nombre Tarea “Prueba 1” en el campo de texto mostrado. Dar click en el ícono de selección de proyecto “Project” en la parte inferior derecha del campo de texto (Primer Icono). Si cualquiera de los pasos tiene problemas, o no se puede confirmar, se puede tratar de un Bug.

35 Low-Level Test Case (Ejemplo)
Elegir la opción “Personal” las opciones desplegadas. Comprobar que el texto “#Personal” aparece en el campo de texto. Presionar “Add Task”. Confirmar que un mensaje aparece en la parte inferior de la pantalla describiendo que la tarea se añadió al proyecto “Personal”. Dar click en el proyecto “Personal” de la sección izquierda de la página. 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 (Prueba1) en el proyecto “Personal”.

36 Tarea Considerando que es.todoist.com acaba de implementar la funcionalidad de Filters: Los alumnos pueden crear una cuenta en el sitio de forma gratuita.

37 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.

38 ¿Preguntas?

39 ¡GRACIAS!