Las pruebas que comprueban la corrección del código fuente de una aplicación son
Unidad 6: Gestión de las pruebas de sistemas
No sólo los aspectos técnicos de las pruebas son parte de la prueba efectiva. Es fundamental el papel del gerente de pruebas en el lanzamiento de mejoras en las pruebas
Casi todas las actividades de gestión pueden agruparse a lo ancho de tres esferas de influencia.
La esfera del liderazgo involucra encaminar y motivar a los integrantes del equipo en busca de los objetivos comunes.
La esfera del control es la que asegura que la organización está en el camino previsto. Incluye el monitoreo, seguimiento.
La esfera del soporte implica facilitar el desarrollo del equipo. Incluye el entrenamiento, los métodos de trabajo.
Todo lo que el gerente haga puede ser categorizado en una de estas esferas de responsabilidades, y lo que es más importante, todo programa de acción debe ser balanceado entre las tres esferas.
6.1 El rol de la gestión: Las 5 M’s
La actividad de pruebas es importante, porque es el proceso que hace visible y tangible la calidad de producto. El proceso de pruebas es medir la calidad. Como dice (Hetzel, 1988, p. 179) sobre la gestión de la calidad:
Una buena gestión de calidad significa, primero y principal, un reconocimiento de las responsabilidades de la gestión de la calidad.
Por ello es que cada gerente debe ver como una responsabilidad personal, el llevar adelante un efectivo proceso de pruebas.
Partiendo de las tres esferas de gestión vistas: Liderazgo, Control y Soporte se definen las acciones necesarias que son la base del enfoque de gestión sobre las pruebas: las 5 M´s
La esfera de Control es la que describe, a juicio de Hetzel (1988) las áreas de responsabilidades mayores para todos los gerentes.
Una serie de preguntas.
Planteadas las preguntas, se deben responder honestamente. Se cuentan las respuestas por SÍ. Si se alcanza las 10 o más respuestas por SÍ, significa que se está seriamente trabajando en alcanzar la responsabilidad personal. Para cada respuesta por NO, se debe formular una pregunta adicional: ¿Qué estás haciendo al respecto?
Cada una de estas preguntas está dirigida a las responsabilidades personales que requieren acciones para que las actividades de pruebas de la organización se desarrollen bien.
Este cuestionario de las 5 M´s, se puede emplear tanto para medir el nivel de gestión sobre las pruebas, como también como una herramienta orientadora de hacia dónde se debe .
6.2 Especialistas de pruebas: Las 5 C’sr
Los especialistas de pruebas son los encargados de asegurar que la calidad es medida cuidadosamente. Sabiendo que la calidad va a ser medida efectivamente sirve para prevenir muchos errores y actuar como una fuerza positiva para la calidad de trabajo.
Una especialidad es reconocida como especialidad necesaria, si requiere conocimiento técnico especializado
¿Se justifica un especialista de pruebas?
Si el impacto de sistemas de calidad pobre es menor, entonces la organización no puede justificar un recurso especializado dedicado.
Un especialista de pruebas:·
Asegura que las pruebas se realizan· Asegura que las pruebas se documentan· Asegura que las técnicas de pruebas se establecen y se aplican.
Existen responsabilidades a asignar que son cruciales para el éxito de cualquier proyecto:
·Preparación de los planes y diseños de las pruebas· Organización de las actividades de pruebas· Desarrollo de los procedimientos y las especificaciones de las pruebas · Desarrollo de los casos de pruebas· Preparación de la documentación de prueba· Implementación de las herramientas de pruebas· Revisión de los diseños y las especificaciones·
Prueba de sistemas y de programas· Prueba de mantenimiento de los cambios· Supervisión de las pruebas
Habilidades claves necesarias en un especialista de pruebas
hay un cuadro…Celular
de aceptación
6.3 Planificación y estimación
Para llevar adelante cualquier proyecto de pruebas exitosamente, una de las actividades fundamentales a llevar adelante como actividad de gestión, es la Planificación de las pruebas.
Alguien debe establecer, qué va a ser probado, cómo va a ser probado, qué se necesita para probar, desde equipos hasta recursos, es decir, alguien tiene la responsabilidad de confeccionar el Plan de proyecto de pruebas.
Si bien la actividad de Planificación de Pruebas puede y debe tener como producto un Plan de Pruebas, dependiendo de las carácterísticas del proyecto. El plan de Pruebas puede ser un documento con un par de hojas, o bien un documento que lleva 20 o más hojas.
Es el proceso de definir un proyecto de pruebas para que pueda ser correctamente medido y controlado. Incluye los requerimientos, las estrategias y los recursos en un plan de pruebas, y más detalladamente lo que se hace en la Planificación es lo siguiente:
– Determinar el alcance y los riesgos. – Identificar los objetivos de las pruebas y los criterios de salida de pruebas. – Determinar el enfoque: técnicas de pruebas, cobertura de pruebas, equipo de pruebas. – Implementar el método de pruebas / estrategia de pruebas, – Planificación del período de tiempo para el desarrollo de las actividades a seguir. – Adquirir/obtener y programar recursos requeridos por las pruebas: personal, entorno de pruebas, presupuesto de pruebas.
Una estrategia de prueba:
Descripción a alto nivel de los niveles de prueba a llevar a cabo y las pruebas asociadas a ellos para una organización o programa (uno o más proyectos).
Y el enfoque de prueba es:
La implementación de la estrategia de prueba para un proyecto específico. Normalmente incluye las decisiones tomadas con el objeto de lograr los objetivos de prueba del proyecto y el análisis de riesgo, puntos de inicio respecto del proceso de pruebas, técnicas de diseño de pruebas a aplicar, criterios de salida y tipos de prueba a ejecutar.
¿Por qué es necesario definir una estrategia?
Por las carácterísticas del software, no se puede garantizar un producto libre de defectos, es necesario asumir un compromiso razonable con el aseguramiento de la calidad de software.
Una estrategia se compone
Objetivo de calidad: modelos de calidad, estándares, criterio de calidad —-niveles de prueba: componentes, sistema y integración —tipo de pruebas:cargas, estrés, volumen —técnica de pruebas:caja blanca, negra, revisiones.
Una vez definidos cada uno de estos elementos, otro aspecto a considerar es el orden de la Prueba que tiene como propósito definir en qué momento y en qué orden se aplicarán las pruebas.
Tanto la estrategia y el enfoque deben quedar formalizados en el documento de Plan de Proyecto.
Resumiendo, el Plan de Proyecto debe especificar todo lo que se llevará adelante, con qué recursos.
Se pueden citar además:
·Fases, actividades y tareas· Formularios· Procedimientos· Cronograma· Responsables· Productos· Estadísticas· Estándares· Requerimientos· Estrategia
6.3.1.Plan de pruebas de alto nivel
El objetivo de este plan de pruebas maestro es que queden definidos: el alcance, los recursos, el cronograma y los criterios.
Dado el siguiente listado de elementos de un plan como una tabla de contenidos, se agruparán a cada uno de los elementos, según definan o se relacionen con:
Alcance, recursos, cronograma o criterios
1. Identificador del plan de pruebas. 2. Referencias. 3. Introducción: resume los elementos y carácterísticas a probar. 4. Producto a probar: detalla el sistema y/o la documentación a probar, como módulos, programas entre otros. 5. Riesgos en el desarrollo del sistema. 6. Carácterísticas a ser probadas. 7. Carácterísticas que no serán probadas. 8. Estrategia: enfoque general de la prueba, actividades, técnicas, herramientas, entre otros. 9. Criterios de aceptación o falla: se debe definir para cada elemento. 10. Criterios de Suspensión y condiciones para retomar. 11. Entregables: documentos a entregar. 12. Actividades de pruebas: documenta las actividades de preparación y ejecución de pruebas. 13. Ambientes de pruebas: describir las necesidades de ambientes para llevar adelante las actividades. 14. Necesidades de personal, apoyo y entrenamiento. 15. Responsabilidades: describe todas las responsabilidades en la organización y realización de las pruebas. 16. Cronograma. 17. Planeación de riesgos y contingencias. 18. Aprobaciones. 19. Glosario.
Y también se tienen otros elementos que pueden ser necesarios definir o reconocer que es necesario definir durante la actividad de planificación.
Laboratorio de pruebas Red de pruebas Datos de pruebas Números de ciclos Gestión de la configuración Implementación de herramientas de pruebas Motivación e incentivos Requerimientos de oficina
Estimaciones
Existen varios criterios de estimación que el ISTQB (2011) adopta de la administración de proyectos, para pruebas.
Uno de los criterios puede ser el denominado estimación experta.
El método consiste en:
– Empleando en enfoque top down o bottom up, identificar las tareas a ejecutar.
– Para cada tarea hacer las estimaciones, normalmente se recurre a los expertos
. – Calcular la sumar de todos los valores de las tareas.
– Incluir los llamados tiempos amortiguadores para cubrir tareas omitidas o subestimadas
Este método tiene ciertas ventajas, entre las que se destacan que la estimación genera a una información detallada de las actividades que puede ser controlada y ajustada a lo largo del ciclo de vida del proyecto.
Entre las desventajas, se pueden citar que es un método considerado caro, y que requiere una idea clara respecto de la estrategia de pruebas y actividades de pruebas en una fase temprana del proyecto.
Y una desventaja muy importante es que se heredan los errores relativos a la planificación de proyecto.
Otro de los métodos de estimación, es estimación basada en analogías.
En este método se requiere tener en claro las tareas de pruebas que serán necesarias. Basado en un proyecto que se haya desarrollado anteriormente, buscar para cada actividad similar el esfuerzo real para hacer la estimación. A partir de ahí, calcular el valor de la estimación total empleando métricas como líneas de código.
Se trata de un método simple y efectivo, ya que se pueden lograr valores bien exactos o reales para la estimación si se cuenta con suficiente experiencia.
Por último, mencionamos la estimación basada en porcentajes, donde el esfuerzo para las actividades de pruebas se estima sobre la base de la totalidad de las actividades del proyecto.
El valor del porcentaje que se requiere para pruebas se basa en los registros de proyectos pasados, por ejemplo: se podría estimar un 40% de actividades de pruebas respecto de la totalidad de las actividades del proyecto.
No sólo se emplea para estimaciones de tiempos de pruebas, sino que se puede utilizar también para cualquier otra parte del trabajo del proyecto, por ejemplo estimación del tiempo de gestión de proyecto
Como ventaja se encuentra que es una técnica simple y a la vez no requiere mucha información de entrada para realizar la estimación.
Por el contrario, puede resultar poco precisa ya que no considera los hechos particulares que se dan en los proyectos. Se requiere experiencia e intuición de aquellos que realizan la estimación para obtener estimaciones confiables.
“Nunca planificar suponiendo que no habrá defectos”
6.4 Gestión de riesgos asociada
Las pruebas basadas en los riesgos tienen que ver con atacar o dar prioridad a esas áreas de riesgo, logrando:
• Gestionar y reducir el riesgo.
• Priorizar los casos de pruebas para enfocar las áreas principales de riesgo
• Distribuir el tiempo de prueba según el grado de los riesgos involucrados
• Entender el riesgo del negocio.
Dentro de la tarea de Planificación de las pruebas, como en toda tarea de planificación, está parte de la Gestión de Riesgos.
Dentro de una categoría están los riesgos de productos y en la otra categoría los riesgos de proyectos.
Consideraciones generales
Un riesgo es un problema posible que podría afectar el logro de un objetivo
Se deben identificar, sobretodo, detectar los riesgos típicos, los que con frecuencia se han presentado. Entonces resulta útil mantener registros de estas situaciones que nos servirán para bases futuras.
Los riesgos se miden por la probabilidad de presentación y el impacto.
Probabilidad de presentación:
qué probabilidad existe que se presente.
Impacto:
qué produce si se presenta, es decir, cómo afecta si se presenta
Riesgos de producto:
Estos riesgos tienen que ver con los factores relacionados a lo que es producido por ese trabajo o proyecto. Ejemplo: lo que se está probando.
Para identificarlos se deben pensar como la posibilidad que el sistema o programa o software no alcance las expectativas de usuarios o clientes, por ejemplo, riesgos asociados a la calidad.
Un sistema no satisfactorio puede:
• Omitir funciones claves especificadas. • Fallar frecuentemente y alterar el comportamiento normal. • Tener problemas relacionados a una carácterística de calidad particular.
Es importante que se comience lo más tempranamente identificando estos riesgos y, usando el conocimiento de esos riesgos.
Esto es lo que se conoce como Pruebas basadas en el riesgo
Los riesgos de producto no solamente se utilizar para priorizar y enfatizar los casos de pruebas o áreas del sistema a probar durante la ejecución, sino también para tomar acciones que permitan desarrollar el producto de proyecto tal cual se lo planteó
Pasos esenciales en la gestión de riesgos
1. Análisis de los riesgos de producto
• Revisión de documentación • Brainstorming • Sesiones planificadas
2. Para identificarlos, y completar el análisis anterior, se puede:
• Emplear alguna norma de descomposición de software que ayude a recorrer todas las carácterísticas, por ejemplo, analizando las carácterísticas y sub-carácterísticas de la Norma ISO 9126.
• También se puede plantear la pregunta siguiente: ¿De qué tenemos que preocuparnos?
empleando una lista de chequeo de riesgos pasados.
3.
Una vez identificados todos los riesgos, se debe otorgar a cada riesgo dos puntos muy importantes, uno, la probabilidad de presentación y otro el impacto.
4. Con esos dos puntos de impacto y probabilidad de presentación, se calcula la prioridad y se confeccionar una lista priorizadas de riesgos.
5. Finalmente, se define sobre qué riesgos se va a hacer algo y se comienzan a definir las posibles acciones
Riesgos de proyectos:
Tienen que ver con la manera en que los riesgos del proyecto afectan a las pruebas. Entre los ejemplos, se tienen las presiones sobre el equipo por cronogramas ajustados, la alta rotación de personal por falta de incentivos.
se pueden pensarlos como riesgos directos y riesgos indirectos.
Ejemplos de riesgos directos:
• Entrega tardía de los elementos de prueba
• Problemas con el ambiente de pruebas. No se puede montar el ambiente para probar, o no es posible simular el ambiente del cliente.
Ejemplos de riesgos indirectos:
• Demora excesiva en la corrección de defectos reportados, es decir que se había previsto un tiempo
• Problemas con el soporte en la administración de los ambientes de pruebas. Cuando se ha requerido algún elemento para armar el ambiente de pruebas y este no es provisto.
A partir de los ejemplos brindados, se puede ver que los riesgos de proyectos directos son aquellos que dependen de nuestro equipo y sobre los que tenemos inherencia directa, en cambio los indirectos son aquellos que nos afectan pero no tenemos dominio directo.
Para identificar los riesgos, se pueden realizar una serie de preguntas:…….
Una vez identificados los pasos a seguir para su priorización son los mismos que para los riesgos de proyecto.
Se resumen y se definen como:
Mitigar:
definir acciones en pos de reducir la probabilidad de presentación y en lo posible el impacto.
Contingencia:
tener un plan para llevar a cabo cuando el riesgo se presente.
Trasladar:
convencer a otros que reduzcan la probabilidad de presentación, o aceptar el impacto.
Ignorar:
no hacer nada
6.5 Organización para las pruebas
Entre muchas otras cosas establecer el clima para una buena prueba y comunicación. Esto significa establecer una política de pruebas y el nivel de prueba que se espera en todo el trabajo desarrollado.
Comunicar la expectativa de lo que se quiere llevar adelante y asignar las responsabilidades.
¿Qué involucra una política?
Involucra objetivos, metas y guías de trabajo, pueden ser formales e informales, pueden estar escritas o no.
Dentro de la política de pruebas esta la oficina de pruebas.
Bill Hetzel (1988) establece ciertos enfoques alternativos.
Puede ser como:
1. Una organización no formal, es decir, la prueba vista como una parte de cada rol. Todos, diseñadores, programadores, llevarán adelante su propio nivel de pruebas.
2. Una parte componente del aseguramiento de calidad
3. Un comité de revisión de pruebas, es decir un comité permanente que revisa planes de pruebas
4. Especialistas de proyectos de pruebas, donde cada proyecto es asignado a un especialista de pruebas
5. Una función de soporte de pruebas
6.
Una función de aseguramiento de producto, es decir, como una organización independiente que prueba productos del cliente.
Sólo los enfoques
5 y 6 implican unidades funcionales dedicadas solamente a las actividades de pruebas.
¿Por qué es necesaria una oficina de pruebas?
· Porque construir sistemas sin una oficina de pruebas, no funcionará bien. · Porque es esencial medición efectiva para el control de calidad del producto. · Porque coordinar las pruebas implica recursos dedicados.
Gerente de pruebas
Entre las responsabilidades, se pueden citar:
·Conducción estratégica y coordinación.· Facilitador.· Dirección total.· Planeamiento de la prueba.· Adquisición de recursos.· Reportes del proyecto.· Evaluación y seguimiento de la prueba.
Para cumplir con las responsabilidades citadas, requiere:
·Conocimiento profundo del proceso de prueba.· Capacidad de liderazgo.
· Capacidad para el manejo de proyectos. · Compromiso con la calidad.· Familiaridad con las herramientas de prueba.
Ingeniero
Diseño y desarrollo
Es el que diseña los casos de prueba necesarios y establece el orden en el cual se ejecutarán los casos de pruebas.
Tiene las responsabilidades de
· Descomposición de los requerimientos de prueba· Diseño de la prueba· Desarrollo de la prueba
Y requiere:
·Conocimiento de los requerimientos de la aplicación· Conocimiento respecto de especificaciones técnicas cualquiera sea· el método de especificación Familiaridad con la herramientas de prueba· Destreza en programación (opcional)
Ejecución
Es el que ejecuta las pruebas de acuerdo con la especificación de casos de prueba.
Tiene las responsabilidades de
·Ejecución de la prueba· Evaluación de resultados· Recuperación de errores.
Y requiere:
·Conocimiento del sistema de prueba, redes, server, otros.· Familiaridad con las herramientas de prueba· Conocimiento básico de pruebas· Capacidad de diagnóstico· Experiencia en la ejecución de pruebas.
Automatización de pruebas
Es el que evalúa las posibilidades de la automatización de pruebas y las implementa en el caso de contar con un proceso así.
Entre las competencias especiales necesarias, están:
· Experiencia como probador· Conocimiento técnico de diseño y automatización de pruebas· Conocimientos de programación· Amplios conocimientos en el uso de las herramientas· implementadas
Administrador
Es el que prepara y opera el entorno de pruebas.
Entre sus responsabilidades están:
· Administrar el sistema de prueba· Instalar nuevos usuarios· Manejar las necesidades del usuario.
Requiere:·
Experiencia y conocimientos de administración de sistemas· Conocimiento de las herramientas de prueba.
El ISTQB (2011) incorpora el rol de Experto técnico, quien asiste al equipo de pruebas cuando éste lo requiere.
por ejemplo, en administración de bases de datos, en interfaces de usuario, redes, entre otros ejemplos.
Están las competencias para cualquier miembro del equipo de pruebas:
o Instinto político o lo que se llama contar con diplomacia o Disposición a preguntar sobre puntos obvios al parecer o Persistencia o Meticulosidad y creatividad o Personalidad fuerte o Capacidad de resolución de problemas o Capacidad de aprendizaje rápido.
Sistemas involucrados
Además de los roles, como otros recursos pueden estar:
• Sistema para desarrollo de la prueba • Sistema de administración de la prueba • Depósitos de datos de la prueba • Sistema del cliente • Red • Servidor de base de datos, como procedimiento de backups, procedimientos de restauración de la base de datos.
6.6 Gestión de los ambientes de pruebas
Tanto para la creación como para la ejecución de los casos de prueba, es fundamental la implementación de ambientes apropiados para realizar las pruebas.
Los ambientes de pruebas deben estar configurados tal cual el ambiente de producción, debe contar con las herramientas necesarias instaladas de manera que se pueda probar en la versión correspondiente a cada ciclo de prueba.
Otro aspecto importante, es no caer en la tentación de compartir el ambiente de pruebas con desarrollo.
Actualizar la versión, por más pequeño que parezca el cambio introducido, modifica fuertemente el ambiente
¿Qué involucra un ambiente de pruebas?
Involucra partes físicas y partes lógicas.
A saber:
o El equipamiento físico (hardware) en el que corren los programas
. O
Software de sistemas, software de aplicación asociado o Motor de base de datos o Base de datos: se refiere acá puntualmente al contenido de la base de datos, qué datos tiene cargados y qué no. o Sistemas a probar en sus versiones exactas y todo lo que conforma el producto bajo pruebas
. O
Cada parámetro que se establezca para el ambiente es una carácterística a considerar.
6.7 Monitoreo y control
6.7.1 Gestión de incidentes
Se denomina incidente a todo defecto como así también puede llamarse a todo aspecto del software que se desea mejorar y que es sugerido desde la oficina de pruebas o desde quien realiza las pruebas.
La Gestión de Incidentes comienza desde que éste es ingresado al sistema como herramienta de soporte para su gestión.
No es posible realizar una gestión de incidentes a través de listados manuales, o defectos enviados por mail al programador o gerente.
Contar con una herramienta que permita registrar los incidentes y a su vez permita su seguimiento
Workflows
Estos estados van indicando el ciclo de vida del defecto o incidencia, y marcando en qué punto se encuentra. Cada estado tiene un dueño o responsable.
Workflow de incidencias de defectos
El workflow presentado es solo un ejemplo para explicar un ciclo de vida básico de un defecto o incidencia.
Pueden coexistir varios workflows (si la tecnología lo permite): uno para el ciclo de vida de los defectos, otro diferente para las sugerencias de mejora que pueden surgir en el proceso de pruebas y que no tienen que tener el mismo ciclo de vida que los defectos.
Se presenta a continuación un workflow
Cuando un defecto se ingresa al sistema, pasa a estar en un estado NUEVO5.
Este estado le pertenece al sector de pruebas, mientras le asigna los atributos correspondientes.
Recién ahí es cuando mediante la acción de Abrir lo pasa al estado ABIERTO.
Este estado es el que le pertenece a Desarrollo, indicando que lo tiene asignado para su correspondiente tratamiento. Un defecto ABIERTO implica que requiere acciones de tratamiento para poderlo pasar a un estado subsiguiente del ciclo de vida.
Una vez en ese estado, cuando Desarrollo le da tratamiento, mediante la acción Atender lo pasa al estado PENDIENTE.
Puede que un defecto requiera atención y no implica una corrección. También puede suceder que el defecto no esté bien explicado, o se requieran mayores evidencias para poderlo atender, por lo que se lo devuelve al equipo de pruebas mediante la acción Rechazar sobre el estado ABIERTO, para volverlo al estado NUEVO.
Cuando el defecto alcanza el estado PENDIENTE implica que está a la espera de ser validado por el equipo de pruebas. En ese punto, pueden suceder dos cosas:
una, que el defecto pase al estado CERRADO, mediante la acción Validar (cerrar o con el nombre que quiera darle).
O bien, que al hacer el re-testing para comprobar su corrección, se detecte que no está corregido o salvado. Así, mediante la acción Rechazar, deberá volver al estado ABIERTO.
De estado CERRADO, lo único que puede suceder, es que el defecto reaparezca, por lo que existe una acción a tomar denominada en este caso Re-abrir, y vuelve al estado ABIERTO.
Se habrá podido observar que en casi todos los estados existe una acción Re-asignar.
Uno pasa un defecto de un estado a otro, generalmente, se hace una asignación a un responsable.
Estas herramientas lo que permiten es que cada usuario que ingresa al sistema puede ver y sólo ver (o según los permisos) los defectos que tiene asignado y sobre los que tiene que trabajar.
Se insiste en que el workflow que se defina debe responder al proceso que se defina para la función de pruebas. Por ejemplo, en este workflow, sólo de un estado PENDIENTE se puede pasar el defecto al estado CERRADO. Esto está indicando que sólo las personas autorizadas del equipo de pruebas podrán cerrar un defecto y no los programadores. Esto puede ser definido diferente, con permisos para los programadores quienes también pueden cerrar los defectos
6.7.2 Registración
o
Identificación del defecto, es el id (número identificador).
o Sistema o componente afectado.
o Versión y fecha en que se detectó.
o Ambiente: los mismos pueden estar correctamente identificados.
o Tipo de prueba en que se detectó
o Persona que reporta y persona que lo detectó
o Descripción corta y detallada.
o Pasos para reproducirlo.
o Atributos de defectos, como pueden ser la Prioridad, Severidad, y Síntoma.
o Archivos adjuntos: estos pueden ser de distinto tipo, evidencias del defecto, resultado de las consultas
o Resolución (al cierre).
Todos estos atributos de los defectos son sugeridos, pudiendo ser más o menos que los citados acá.
Por ejemplo:
1. Un defecto puede estar asociado a un módulo del sistema que se está probando,
2. Un defecto puede estar asociado al tipo de caso de prueba que lo detecta, es decir, si el caso de prueba es de performance, puede asignarse al defecto el tipo “performance
3. Un defecto puede estar vinculado al o los casos de prueba que lo detectan. Ésta es una trazabilidad requerida
Desde ya es que se vuelve indispensable contar con una herramienta y no con planillas manuales, por más desarrollo o ingeniería que se le incorpore a esas planillas.
Para definir los datos o elementos que describen una incidencia, se puede basar en el estándar de la IEEE Std 829-1983. Los elementos que involucra este estándar son:
o Detalles que puede incluir un informe de incidencia: o Datos de la incidencia § Número único del defecto, que generalmente se genera de§ forma automática en la herramienta. § Objeto de prueba: cómo se denomina y qué versión.
§Entorno de pruebas: los mismos pueden estar identificados, y se§ puede utilizar esa identificación para asociarlo al defecto. Nombre del autor. § Fecha de la primera ocurrencia: también puede ser generado§ automático, si es que en el mismo momento que se detecta se reporta.
o Clasificación de errores. Clase de defecto, que este estándar lo llama Severidad.§ Estado del defecto según el workflow definido.§ Prioridad: que le asigna la urgencia o no de corrección o§ tratamiento.
6.7.3.Clasificación
En el apartado anterior se listaron una serie de datos que pueden ser necesarios a la hora de registrar un defecto. Algunos de ellos son atributos que le dan una clasificación a defecto
Los más importantes a la hora de clasificar a los defectos son: Severidad, Prioridad y Síntoma
Severidad
Especifica la forma en que el defecto afecta a la aplicación bajo testeo.
Las sugeridas pueden ser
: Invalidante, Grave, Común y Leve
A continuación, a modo de ejemplo, se de una tabla de severidades con su significado, de la manera en que deberían quedar definidas en el proceso marco de pruebas
Es el elemento en el cual se basa la generación del defecto. No es la causa del defecto, sino el síntoma, lo que sucede al darse el defecto.
Como ejemplos se pueden citar
• Caída del sistema • Corrupción de datos • Operación incorrecta • Pérdida de datos • Comportamiento inesperado • Comportamiento inamistoso, poco amigable • Bajo rendimiento • Presentación • Problema de entorno
Pueden estar ligados a su vez a la tecnología utilizada o al tipo de sistema del que se trata
Prioridad
Califica el defecto según tiempo y oportunidad de realizar la corrección.
Las mismas pueden ser:
• Inmediata • Urgente • Media • Baja
Resolución
(Síntoma, Severidad y Prioridad)
Deben asignarse al momento del ingreso del defecto al sistema, en cambio, la Resolución es la que acompaña al estado CERRADO.
Es la forma en que se da por terminado un defecto
Se encuentran:
• Duplicado • Corregido • Corregido indirectamente • Funciona según diseño • Limitación de Hardware • Limitación de Software • Necesita más información • Corrección no planificada • Diferido
En función de los ejemplos dados, se habrá notado que no todos los defectos al momento de ser CERRADOS
6.7.4 Reporte de fallos y análisis
Una vez registrados todos los defectos y clasificados los mismos, viene la etapa de la generación de los Informes a partir de los cuáles se harán los análisis correspondientes.
Esta fase de análisis de los reportes de resultado corresponde con la etapa de Evaluación.
Con este análisis se obtiene una indicación de la corrección del producto
El ISTQB (2011) establece lo siguiente:
– Al inicio del proyecto o en las fases de preparación los ciclos de pruebas, los informes son más esporádicos. En cambio durante las fases críticas de la ejecución de pruebas los ciclos de los informes suelen ser más cortos.
No debe faltar un informe al cierre de pruebas.
Evaluación
La cantidad de defectos se puede (se debe) reportar como:
• una función del tiempo • y/o una función de un atributo del defecto como es la gravedad o el estado.
Es necesario contar con:
• Medidas cuantificables del progreso de la prueba. • Informes sobre los defectos • Informes sobre la cobertura de la prueba, es decir, cuánto hemos abarcado con las pruebas.
Por Pressman (2006)
para las definiciones de medidas y métricas, es importante darse cuenta que lo que debemos generar son métricas y no medidas individuales
La métrica está orientada a relacionar de alguna manera, las medidas individuales
En esta fase de Evaluación se debe contar con las siguientes entradas:
• Registros de la prueba • Defectos reportados • Plan de prueba • Especificaciones de procedimientos de pruebas, es decir, los casos de prueba.
Y como salidas :
• Medida de la cobertura de la prueba. • Reporte de análisis de defectos.
Criterios de completitud de la prueba
Se debe establecer un criterio que ayuda a determinar cuándo se termina la prueba. Normalmente se dejan de hacer pruebas cuando se acaban los recursos, principalmente cuando se termina el tiempo.
Dentro de las etapas de Planificación de la prueba deben establecerse cuáles son o es el criterio para determinar si se ha terminado de probar
Algunos criterios pueden ser:
• Cuando se termina el tiempo planificado
• Cuando se terminan los casos de pruebas definidos.
• Cuando no existen defectos dados de alta por corregir.
El ISTQB (2011) plantea los siguientes:
Criterio 1: Por casos de pruebas
Si existen técnicas para la generación de casos de pruebas, la prueba terminará cuando todos los casos de pruebas hayan sido corridos sin problemas. El problema de este criterio es que no se podría aplicar si no existen técnicas definidas.
Criterio 2: Por cantidad de errores estimados
n este criterio se requiere estimar la cantidad de defectos de antemano, en función de estadísticas propias o de terceros. Como el número de defectos estimados en base a estadísticas puede resultar bastante alto, se establece un porcentaje de defectos.
El problema con este criterio es que se requieren datos previos para estimar.
Criterio 3: Por cantidad de errores encontrados por unidad de tiempo
Este criterio se puede aplicar si se mantiene una métrica de cantidad de defectos encontrados por unidad de tiempo. La prueba concluye cuando la cantidad de defectos encontrados por unidad de tiempo disminuye significativamente.
Los problemas con este criterio saltan rápidamente a la luz. La tasa puede disminuir por razones que no son la disminución de defectos sino por ejemplo baja en la eficiencia de las pruebas
Además exige llevar un registro y gráfico de la tasa de defectos.
Cobertura de la prueba
• Cobertura de requerimientos
Empleando una matriz de validación de requerimientos y definiendo para cada requerimiento los casos de pruebas con los que se prueban, se puede tener una medida de cobertura sobre los requerimientos (caja negra o caja blanca)
este tipo de cobertura se puede aplicar
• Cobertura lógica
Se refiere a cuánto del código se ha abarcado. Siendo de esta manera, es claro que cuando se han aplicado técnicas de caja blanca, se puede dar una medida de cobertura lógica. Mide si cada instrucción ha sido ejecutada al menos una vez, cada condición en una decisión toma todos los resultados posibles al menos una vez.
Este tipo de cobertura depende de la técnica de caja blanca aplicada:
Cobertura de sentencia, cobertura de decisión, cobertura de condición
• Cobertura funcional
Si se aplicaron técnicas de prueba asociadas a las funcionalidades a probar, se puede dar una medida de cobertura respecto de las funcionalidades.
Se debe definir, lo que todo líder de proyecto necesita conocer:
• Necesidad de la realización de pruebas adicionales. ¿Cuáles pruebas realizar adicionalmente? • Decisiones de detención del esfuerzo de pruebas. Confección del informe final de terminación.
Ejemplo de reportes
·Reporte de distribución de defectos· Reporte de edad del defecto· Reporte de tendencia de los defectos· Reporte de progreso del testeo· Reporte de cobertura en la ejecución del test
·Número de defectos versus: defectos corregidos, defectos diferidos· y defectos duplicados. Número de defectos versus áreas funcionales del sistema más· importantes: GUI (interfaces de usuario), documentación. Número de defectos abiertos versus plazos de tiempo. Identifica:· defectos abiertos por día, defectos abiertos acumulados. En el mismo diagrama es posible hacer figurar: defectos resueltos, defectos cerrados, a los efectos de comparar las tendencias. Tasa residual de errores
Reporte de distribución de defectos:
Este gráfico muestra la cantidad de defectos en cada estado y quién tiene asignado cada uno de los defectos
Reporte de defectos por edad:
Muestra la edad de cada defecto según la prioridad, por ejemplo, los defectos que tienen asignada la prioridad.
Reporte de tendencia de defectos:
Estos gráficos son muy útiles para poder proyectar la tendencia en función de cómo ha sido nuestro desempeño histórico. Si no se cuenta con suficiente información histórica, los resultados arrojados pueden resultar pocos confiables.
Reporte de progreso
Este gráfico de barras muestra los casos de pruebas que se han corrido, y de ellos aquellos que pasaron y aquellos que fallaron. A, B, C pueden referirse a módulos, sistemas