Ingeniería de Software

Control y aseguramiento de la calidad

Es el proceso general de administración, aseguramiento y control de la calidad.

Incluye todos los aspectos que hacen a la calidad del software final y sus atributos:◦ SRS◦ Diseño◦ Desarrollo◦ Control de cambios◦ Planeamiento◦ Control de calidad

¿Qué es Quality Assurance?

Un conjunto de actividades que se encargan de controlar que se consiga alcanzar los objetivos previstos

Éstas actividades se pueden dividir en dos grupos:◦ Validación◦ Verificación

El planeamiento y alcance de éstas actividades es responsabilidad de QA

¿Qué es control de calidad?

Verificación:◦ “Estamos creando el producto correctamente?”◦ El producto debe conformar a su especificación de

manera correcta Validación:

◦ “Estamos creando el producto correcto?”◦ El producto debe conformar a las necesidades del

cliente En la práctica es difícil ver el límite entre los

dos grupos.

¿Qué es V&V?

Según IEEE-1012:◦ Facilitar la detección de errores en etapas

tempranas◦ Mejorar la visibilidad de la calidad, los riesgos y el

cumplimiento del proceso◦ Asegurar que se cumplan todas las actividades

planificadas de manera eficiente, respetando calendario y recursos

¿Cuál es el objetivo de V&V?

Según IEEE-1012:◦ Es el proceso de chequear que el software:

Responde a los requerimientos de sistema especificados y resuelve el problema especificado correctamente

Es decir, el producto sea tal cual fue especificado

Herramientas:◦ Testing unitario manual/automatizado◦ Testing integral

¿Qué es Validación?

Según IEEE-1012:◦ Es el proceso de chequear que todos los artefactos:

Cumplen con los atributos de calidad esperados en todo el ciclo de vida.

Satisfacen los estándares de calidad y buenas prácticas durante todo el ciclo de vida

Establecen una base para asegurar que el resultado de cada actividad sea el input esperado para la actividad que lo requiera

Es decir, el proceso sea el esperado Herramientas:

◦ Checklists◦ Inspección de código

¿Qué es Verificación?

Especifica acciones durante todo el ciclo de vida

Los procesos de Validación y Verificación funcionan mejor si están hechos en paralelo al desarrollo del producto, y no después.

Las actividades de V&V son complementarias.

Características de V&V

El objetivo es encontrar fallas en el producto:◦ Hacerlo lo mas eficientemente posible◦ Encontrar la mayor cantidad de fallas◦ No detectar fallas que en realidad no lo son◦ Encontrar las mas importantes

Validación

Incidente:◦ Todo evento no esperado durante la ejecución de una prueba de

software.◦ Clasificación

Equivocación: Una acción humana que produce un resultado incorrecto Defecto: Error o mala práctica en el código Falla: Resultado no esperado. Es la manifestación de uno o más

defectos. ◦ No toda incidencia es una falla◦ No todo defecto produce una falla en el momento del testing◦ Una equivocación lleva a uno o más defectos, que están presentes

en el código◦ Un defecto lleva a cero, una o mas fallas◦ La falla es la manifestación del defecto◦ Una falla tiene que ver con uno o más defectos

Definiciones

Test case vs Test condition◦ Los casos de prueba son lotes de datos necesarios para que se dé una

determinada condición de prueba◦ Las condiciones de prueba son descripciones de situaciones ante las que

el sistema debe responder que quieren probarse Economía de la Prueba:

◦ Se puede invertir mucho esfuerzo en probar◦ Probar es el proceso de establecer confianza en que un programa hace

lo que se supone que tiene que hacer Ya que nunca voy a poder demostrar que un programa es correcto... Continuar probando es una decisión económica

Definiciones

Los tipos de prueba varían de acuerdo a la actividad del ciclo de vida.

Tipos de prueba

De acuerdo al conocimiento interno que se tenga, las prubas unitarias, de integración y funcionales se pueden clasificar en:◦ Prueba de caja negra◦ Prueba de caja blanca

Las pruebas de regresión, sistema y aceptación deben ser siempre de caja negra.

Tipos de prueba

Se valida que el resultado de una acción sea el esperado de acuerdo a la especificación.

Requiere, por lo tanto, una especificación verificable

En la teoría, una prueba de caja negra completa es imposible de realizar: se deberían probar todas las combinaciones de todos los valores posibles.

En la práctica, se definen conjuntos de datos de entrada posibles.

Prueba de caja negra

Conjuntos:◦ Clases o particiones de equivalencia

Conjunto de valores equivalentes◦ Condiciones de borde◦ Valores de tipos no esperados o incorrectos◦ Integridad del modelo de datos

Dominio Entidad Relación

Probando los valores específicos de cada conjunto encontrado se cubre toda la prueba

La cantidad de conjuntos y combinaciones utilizadas definen la calidad de la prueba

Prueba de caja negra

Al igual que la prueba de caja negra evalúa el resultado.

A diferencia de este, aprovecha el conocimiento interno del código para dirigir la prueba.

El desarrollador al conocer la estructura interna puede dirigirse directamente a las partes del código más riesgosas.

Prueba de caja blanca

Test coverage:◦ Mide la calidad del test de acuerdo al porcentaje

del código probado.◦ Grados de cobertura:

Sentencia Decisión Condición

◦ A mayor complejidad ciclomática, mayor dificultad en maximizar el test coverage.

Prueba de caja blanca

Prueba componentes en forma independiente o en conjuntos reducidos.

A mayor cohesión, mayor capacidad de probar componentes independientemente.

Generalmente es realizado por el desarrollador, y se ejecuta de manera automatizada.

Se debería hacer para cada componente de código individual.

Se busca encontrar errores lo antes posible Al ser un test de caja blanca, se busca

maximizar el coverage.

Tipos de test – Unit Test

Pruebas orientas a probar que la funcionalidad no modificada en una iteración o luego de un cambio siga funcionando.

Se realiza de manera manual, a partir de un plan de testing que especifique los casos de prueba que se deben ejecutar en casos de regresión.

Se complementa con los test unitarios, en la medida que, estos, se ejecuten automáticamente cada vez que se realice un cambio.

Tipos de test – Prueba de regresión

Se prueba cada requerimiento por separado, probando los resultados esperados contra los actuales.

Es un test de caja negra. Cada caso de prueba es un conjunto corto

de acciones.

Tipos de test – Pruebas funcionales

Se prueba el sistema buscando que las relaciones entre los distintos requerimientos se cumplan y se tienen en cuenta los requerimientos no funcionales.

Tipos de prueba:◦ Pruebas exploratorias◦ Pruebas de camino básico◦ Pruebas de stress◦ Pruebas de rendimiento◦ Pruebas de usabilidad

Tipos de test – Pruebas de sistema

Prueba especificada por el sponsor, basada en la especificación de requerimientos, y ejecutada por él, con el objetivo de definir si el software cumple, o no, la especificación y en qué grado.

Tipos de test – Pruebas de usuario

El objetivo es asegurar que se sigue el proceso

Esto incluye asegurar que los resultados de una actividad sean los esperados

Herramientas:◦ Inspecciones de código manuales◦ Inspecciones de código automatizadas◦ Checklists

Verificación

Actividad realizada por los desarrolladores con el objetivo de descubrir defectos y anomalías.

Las inspecciones no requieren software andando y pueden ser realizadas tanto contra el código, como contra el diseño.

Es una técnica que permite encontrar defectos en etapas tempranas que serían difíciles de encontrar en pruebas en ejecución.

Inspecciones de software manuales

Se espera la presencia de desarrolladores expertos.

Son complementarias al testing, no lo reemplazan.

Una sola inspección puede encontrar muchos defectos

Inspecciones de software manuales

Se debe tener la especificación de requerimientos

Un checklist de errores comunes puede ayudar

Se debe tener la aceptación y conformidad del management, dado que estas tareas implican costos directos, pero reducen costos a futuro.

Las inspecciones de código no son herramientas para evaluar al personal

Pre-condiciones

Se debe especificar quiénes participan en la inspección y con qué responsabilidad.

Los participantes deben saber qué código se va a verificar y se debe estudiar con antemano

Se realiza la inspección del código o documentos seleccionados, y se anotan los defectos encontrados

Se arreglan los defectos encontrados Se evalúa si se debe volver a hacer la

inspección

Procedimiento

Autor:◦ El responsable del código o documento a evaluar◦ Se debe entender que lo que se evalúa es el código o

documento, NO al autor Inspector:

◦ Una o más personas que se encargan de encontrar errores Lector:

◦ Encargado de dirigir la lectura Moderador:

◦ Maneja el proceso y se encarga que no haya conflictos.◦ Reporta al responsable de la inspección.

Responsable de inspección:◦ Se encarga de planear y administrar las inspecciones y definir los

roles de cada integrante

Roles

Se utilizan herramientas de software que procesan el código

Encuentran errores comunes, a partir de patrones definidos.

No reemplazan a las inspecciones manuales, pero ayudan a encontrar errores comunes más fácilmente, por ejemplo:◦ Manejo de excepciones◦ Chequeo de tipos de datos◦ Chequeo de inicialización de variables

Inspecciones de código automatizadas

Herramienta de verificación manual, utilizada para saber si un artefacto cumple, o no, con ciertas condiciones.

Las condiciones incluyen condiciones de formalidad y contenido, condiciones impuestas por estándares de calidad, condiciones impuestas por la organización.

Se utiliza tanto para código como para documentación.

Checklist

Se utiliza como ayuda para las inspecciones de código

Enumera defectos comunes, dependientes del lenguaje, que es probable encontrar

Cuanto más levemente tipado es un lenguaje, más chequeos se necesitan

Ejemplos:◦ Inicialización◦ Nombres de variables◦ Manejo de excepciones

Ejemplo - Checklist de código

Inspecciones y Reusabilidad se pueden apoyar en:◦ Métodos ponderados por clase◦ Profundidad del árbol de herencia ◦ Falta de cohesión de métodos◦ Acoplamiento entre objetos◦ …

Pruebas unitarias y verificabilidad / mantenibilidad se pueden apoyar en:◦ Test coverage◦ Complejidad ciclomática◦ Comentarios/Documentación◦ Cohesión / Acoplamiento◦ …

Métricas y su relación con V&V

Planeamiento de pruebas

Planeamiento de pruebas

El proceso de prueba: Una descripción de las fases principales del proceso de prueba

Seguimiento de requerimientos: Se debe saber que requerimientos individuales se están probando

Elementos probados Calendarización, incluyendo asignación de recursos Procedimiento de registro de las pruebas: No

alcanza con ejecutarlas, hay que registrar el resultado

Requerimientos de HW y SW: No todas las pruebas requieren del mismo HW o SW para ser ejecutadas

Planeamiento de pruebas

Referencia: identificador, creador, versión, nombre, …, requerimientos que prueba, dependencias (con otros subsistemas por ej)

Ambiente: Configuración de HW y SW a utilizar Inicialización: Prepara el escenario Acciones: Acciones para ejecutar y completar la prueba Finalización: “Resetea” el ambiente a un estado inicial no

relacionado con el test case Datos de entrada: Se especifican las diferentes particiones de los

datos de entrada Resultados

◦ Resultado: Ok/Fallido◦ Salida esperada◦ Salida obtenida◦ Severidad: Impacto de la falla◦ Adjuntos: Screenshots, archivos log, …

Estructura de un test case

Intervalo (que largo que fue, no?)

CASE: Computer Aided Software Engineering Ingeniería de Software Asistida por Computadora

Desde “simples” modeladores para realizar análisis, hasta herramientas capaces de generar código fuente.

Herramientas CASE

CASE: DB

CASE: Análisis

CASE: Desarrollo

Building continuo Inspección automatizada (Sonar, find bugs,

etc…) Test coverage Test automatizados Formateo automático, control de inclusión

de documentación

CASE

Preguntas

Sugerencias

Aplausos