Aseguramiento de la calidad y pruebas de software

6- Clasificación de defectosEstándar IEEE-1044

Blanca A. Vargas Govea vargasgovea@itesm.mx

Abril 26, 2013

2

Objetivo

● Conocer y aplicar la clasificación de anomalías de software de acuerdo al estándar IEEE-1044

3

Proporciona una clasificación de anomalías de software independientemente de la fase del proceso en la que se hayan encontrado.

¿Qué aporta el estándar?

4

Usos

Análisis causal dedefectos Administración de

proyectos

Reduce la inserciónde defectos en el

software

5

Anomalía

Anormalidad

Irregularidad

Inconsistencia

Variación conlas expectativas

6

AlcanceMi auto salió defectuoso, ¿puedo aplicar el estándar para analizar las causas?

● No, solamente aplica a software.

● Puede estar en cualquier fase del proyecto.

7

¿Cuál es la diferencia entre una falla y un defecto?

8

Definiciones● Defecto una →

imperfección o deficiencia que hace que el producto no cumpla con los requerimientos.

Ejemplo:

Defecto de codificación en el módulo de login.

● Falla evento en el →cual un sistema o componente no realiza una función requerida.

Ejemplo:

No se despliega el campo para password.

9

Proceso de clasificación

La organización debe definir un proceso de clasificación que siga los siguientes pasos

10

Proceso de clasificación

1. Metas a lograr por la clasificación de defectos y fallas.

2.El estándar de referencia (contenido en la especificación o plan) usado para determinar qué comportamientos del software constituyen una falla.

3.Cómo resolver los conflictos o desacuerdos relacionados con decisiones de clasificación.

4.En qué parte del ciclo de vida del software empieza y termina la clasificación.

11

Proceso de clasificación

5.Proyecto/producto a los que se asignarán los atributos de clasificación.

6.Quién asignará los valores a los atributos de clasificación a cada defecto y falla descubierta.

7.Cómo y dónde los datos de clasificación se mantendrán.

12

Clases de defecto

Requerimientos1

Diseño2

Codificación3

Pruebas4

Reflejan su punto de origen en el ciclo de vida del software

13

Requerimientos1

● Descripción funcional La descripción de lo que →el producto hace y cómo debe comportarse es incorrecta, ambigua, y/o incompleta.

Clases de defectos

Aspectos funcionales, performance

● Atributo características de un componente de →SW o sistema.

14

Requerimientos1

● Atributo de interacción Incorrecta descripción de →cómo los atributos deben interactuar. Ejemplo: el sistema agrega a un nuevo cliente en la BD de clientes. Este atributo interactúa con otro que categoriza al cliente.

Clases de defectos

● Descripción de interface Incorrecta descripción →de cómo el SW se comunica con SW externo, HW y usuarios.

Caja negra

15

Diseño2

● Algorítmico y procesamiento →ocurren cuando el pseudo-código es incorrecto. Ejemplos:– Falta o sobra un paso.– No se verifica división

por cero.

Clases de defectos

● Control flujo incorrecto→

– Anidamiento inadecuado.– Funciones invocadas

equivocadas.

● Secuencia uso →incorrecto de operadores lógicos.

16

Diseño2

● Datos diseño →incorrecto de estructuras de datos.– Un arreglo con un

número incorrecto de elementos asignados.

● Descripción funcional diseño poco claro, →

incorrecto o faltante.

Clases de defectos

17

Codificación3Clases de defectos

● Algorítmico y procesamiento.

● Lógico.● Secuencia.● Tipográfico.

● Inicialización →omitida o incorrecta.

● Documentación de código.

● Hardware/Software externo.

18

Pruebas4Clases de defectos

● Código de pruebas →errores en el código de prueba.

● Diseño de casos →

– incompletos– inadecuados– faltantes.

19

Requerimientos1

Diseño2

Codificación3

Pruebas4

Repositorio de defectos

20

Posibles valores de las fallas

● Estatus abierto, cerrado.→

● Severidad crítica, mayor, menor, →inconsecuente.

● Carácter causa desconocida, duplicada, →resuelta.

21

Ejemplo

● La persona 1 reporta que no puede entrar al sistema porque el campo del password no aparece en la pantalla de entrada.– Falla: no aparece el campo del password.

● Estatus: abierto (no se ha resuelto)● Severidad: crítica.● Carácter: duplicada (ya se había reportado otra falla).

– Clase de defecto: codificación en el módulo de login. Si una persona 2 reporta la falla, entonces seconsideran dos fallas originadas por un mismo defecto.

22

Actividad 22 - equipo

23

Actividad 22

Para su proyecto, elabora una tabla de clasificación de defectos que incluya lo siguiente:

IDCasodePrueba,Sistema/sub-sistema, Falla, Defecto

Las fallas y los defectos corresponderán a fallas y defectos potenciales a ocurrir en los módulos de tu sistema.

24

Referencia● Estándar IEEE-1044● Taza-café Photo Credit: <a href="http://www.flickr.com/photos/86318165@N00/3772118924/">James Nash (aka

Cirrus)</a> via <a href="http://compfight.com">Compfight</a> <a href="http://creativecommons.org/licenses/by-sa/2.0/">cc</a>

● Kitty Photo Credit: <a href="http://www.flickr.com/photos/45940879@N04/6401502073/">Kalexanderson</a> via <a href="http://compfight.com">Compfight</a> <a href="http://creativecommons.org/licenses/by-nc-sa/2.0/">cc</a>

● Photo Credit: <a href="http://www.flickr.com/photos/45940879@N04/5491910420/">Kalexanderson</a> via <a href="http://compfight.com">Compfight</a> <a href="http://creativecommons.org/licenses/by-nc-sa/2.0/">cc</a>