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
Bug Advocacy

2 Un Bug no solo es un error de programacion.
Que es un Bug??? (Bicho) Es cualquier elemento que pueda causar la disminucion de la calidad de un software. Un Bug no solo es un error de programacion. Se pueden presentar en cualquiera etapa del ciclo de vida de un Sistema.

3 Que cosas se pueden reportar como un Bug?
Generen un resultado incorrecto. Problemas de rendimiento. Hagan al producto menos comercial. No concuerden con las especificaciones o requerimientos No sigue estándares de calidad. Defectos Visuales. Generen perdida de tiempo para el usuario.

4 Ciclo de Vida de un Bug. Nuevo Postergado Rechazado Asignación Activo
Evaluacion Verificación Cerrado Re-Abierto

5 Principios Importantes
Las pruebas revelan la presencia de bugs, no la ausencia de ellos Síntomas pequeños sugiere un problema subyacente. Cuanto antes se comience a probar… mejor!

6 Principios importantes
Las aglomeración de defectos. ¡Los bugs siempre van en pandilla! Debemos ajustar continuamente tu plan de pruebas. Las pruebas se deben adaptar a ciertas necesidades específicas. No todos los defectos se solucionan.

7 Trabajo en equipo. Comunicacion QA DEV Confianza Reputación

8 Que necesita un Ingeniero de Calidad?
Conocimiento Intuición Criterio 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.

9 Que necesita un Ingeniero de Calidad?
Conocimiento Diseño. Requerimientos. Funcionalidades. Funcionamiento en general.

10 Que necesita un Ingeniero de Calidad?
Intuicion Prestar atencion a pequeños detalles Probar puntos criticos Ponerse en el lugar del usuario final

11 Que necesita un Ingeniero de Calidad?
Criterio: Clasificar adecuadamente los errores encontrados. Desarrollar informes que comuniquen claramente los errores, reflejando su alcance, la magnitud y sus consecuencias. Describir las instrucciones para reproducir el error de manera clara y adjuntar capturas de pantalla o hasta videos de ser posible. No minimizar consecuencias

12 Puntos Clave El mejor Ingeniero de calidad no es el que mas bugs reporta! El mejor Ingeniero de calidad es el que mas bugs tiene solucionados…

13 Clasificación de Bugs Severidad
Es la medida en que un defecto (Bug) puede afectar al software. Es determinada por el grado en el que puede llegar a afectar la funcionalidad del sistema. El ingeniero QA es el que determina el nivel de gravedad del problema encontrado. Su valor es objetivo y es poco probable que cambie en el tiempo.

14 Clasificación de Bugs Prioridad
Determina el orden en el que los desarrolladores deben resolver los errores (bugs) reportados. El estado de la prioridad se basa en los requisitos del cliente. Su valor es subjetivo y puede cambiar durante un período de tiempo dependiendo del cambio en la situación del proyecto.

15 Clasificación por Severidad
Bloqueador: inhibe la continuidad de desarrollo o pruebas del programa. Crítico: El error afecta a una funcionalidad crítica o a datos críticos del sistema y no hay la posibilidad un de Work Around. Mayor: Pérdida mayor de funcionalidad, datos de salida extremadamente incorrectos, o dificultades que inhiben parcial o totalmente el uso del programa. Media: Una parte menor de un componente no es funcional. Menor: Una pérdida menor de funcionalidad, o un problema al cual se le puede dar la vuelta(Work Around). Trivial: Son problema generalmente cosméticos. .

16 Clasificación por Prioridad
Prioridad Baja: Es un defecto algo trivial y puede ser pospuesto. Prioridad Media: Es un defecto que debe arreglar pronto, antes del lanzamiento del producto. Prioridad Alta: Debe arreglar lo antes posible.

17 QUE CONSIDERAR? El parámetro de Severidad es evaluado por el Tester, El parámetro de Prioridad es evaluado por el Manager del proyecto o por el equipo (Dev, Tester, Manager). Comprender bien el concepto de prioridad y severidad Comprender cómo un escenario o caso de prueba en particular afectaría al usuario final      Necesidad de considerar cuánto tiempo tomaría hallar el defecto basado en su complejidad y tiempo para verificarlo Para priorizar un defecto, es imperativo que el QA elija la severidad correcta y asi para evitar la confusión con el equipo de desarrollo. Asignar siempre el nivel de gravedad basado en el tipo de problema ya que esto afectará a su prioridad

18 Escenarios Alta prioridad y alta gravedad:
Un error que se produce en la funcionalidad básica de la aplicación y no permite al usuario utilizar el sistema. Alta prioridad y baja gravedad: Los errores de ortografía que ocurren en la portada o título o título de una aplicación. Alta Gravedad y Baja Prioridad: Un error de funcionalidad de la aplicación que no permite al usuario utilizar el sistema, pero que rara vez es utilizado por el usuario final. Baja Prioridad y Baja Gravedad: Cualquier problema de estética o ortografía que esté dentro de un párrafo o en algun informe (No en la portada, ni en los título). 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.

19 Estructura Estándar de un Defecto
Título Debería contener alrededor de 80 caracteres, ser claro y directo al grano. Descripción Complementa el título con detalles e información adicional que ayuda a entender y encontrar el problema, también incluye notas y aclaraciones Ambiente / Requerimientos Describe las pre-condiciones necesarias para replicar el problema. Se consideran elementos como Usuario, permisos, variable, ambiente, navegador, etc. Pasos Siempre comienzan con un verbo: Hacer Click, Revisar, Verificar, Escribir, Ejecutar, Confirmar, etc. Resultado Actual Es el resultado al que se llega después de seguir todos los pasos en el estado actual del sistema Resultado Esperado Es el resultado que se obtendría si el sistema funcionase adecuadamente o como se espera que funcione. Acá se pueden colocar datos comparativos o históricos, incluso información de estándares con tal de justificar la necesidad de cambiar el "Resultado Actual".

20 Ejemplo de Reporte de Defecto
Titulo: La lista de resultados no se refresca cuando se limpia la barra de búsquedas Prioridad Menor Descripción: Cuando el usuario filtra las tareas utilizando la barra de búsquedas superior, y luego borra el contenido de la barra y presiona Enter, los resultados de la búsqueda no se refrescan. Nota: Este comportamiento no es el esperado ya que en aplicaciones certificadas el comportamiento es retornar a la lista original antes de que se inicie la búsqueda, por ejemplo, el buscador de Firefox Requisitos: - Un navegador de internet - Una cuenta de pruebas - El usuario debe tener tareas y proyecto creados con la palabra test Pasos 1. Ingresar al sitio utilizando la cuenta de pruebas: Escribir la palabra "test" en el buscador en la parte superior de la página 3. Presionar "Enter" 4. Borrar el contenido del buscador 5. Presionar "Enter" 6. Verificar si la lista de resultados de la búsqueda se actualiza Resultado Actual La lista no se modifica ni se muestra ningún error Resultado Esperado La lista debería retornar al estado anterior de la búsqueda o al menos mostrar un error indicando que se requiere ingresar un texto para realizar la búsqueda

21 Aplicaciones para el Registro de Bugs
MantisBT Bugzilla Jira Team Track

22 Tarea Buscar un defecto (Bug) en la página es.todoist.com y elaborar un informe de este. Buscar, aislar los más posible y reportar un defecto del programa challenge.exe, sino se encuentra alguna elaborar un test case funcional.