sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
MalDesarrollo

¿Qué?

Validar Verificar

permite detectar y corregir los defectos que nos desvían de los requisitos y necesidades reales del usuario.

permite detectar y corregir los defectos que nos desvían de resultado esperado dados los requisitos especificados.

  • Trata de buenos productos, eficaces:

    • ¿estamos construyendo el sistema correcto?

    • orientado a la corrección de la disciplina de requisitos

  • Trata de buenos procesos, eficientes:

    • ¿estamos construyendo el sistema correctamente?

    • orientado a la corrección de las disciplinas de análisis, diseño y programación

Caso de Prueba

  • Caracrerística (Feature): unidad de funcionalidad o no funcionalidad comprobable que puede ser construida en la evolución de un programa informatico.

  • Sujeto bajo Prueba (Subject under Test, SUT): bloque de código que implementa la caracteristica que estemos probando. El SUT se define siempre desde la perspectiva de la prueba.

  • Componente del que se depende (Depended-on-Component, DOC): partes de la aplicación que no estamos verificando en una prueba en particular de las que depende el SUT (por ejemplo, objetos de otra clase al que el SUT envia mensajes).
general

  • Prueba o Caso de Prueba (Test Case): procedimiento para validar/verificar el SUT (por ejemplo: guión de entradas/salidas, clases y métodos (guión automatizado) que ejercitan el SUT)

  • Ejecución de Prueba es la ejecución de un método o clase de prueba o un conjunto de pruebas. En cada ejecución puede haber dos resultados (inspirándose en los colores de los semáforos)

Resultado de Pruebas

exitoVerde

falloRojo

menosVerde

sano

menosVerde

enfermo

masRojo

enfermo

masRojo

sano
Verde, pasa! Falso Negativo Rojo, no pases! Falso Positivo

  • Exito de Prueba donde los resultados esperados son los resultados arrojados por el SUT en la ejecución del caso de prueba

  • Aparecerán en producción, si aparecen.

    • Peligro donde se produce un éxito de pruebas incluso sin el SUT esté funcionando apropiadamente,o sea con fallos y/o errores que se escapan!

  • Fallo en la Prueba donde los resultados esperados no son los resultados arrojados en la ejecución del SUT en la ejecución del caso de prueba.

  • Error en la Prueba donde se produce un error (excepción) en la ejecución de la prueba que se ejecuta sobre el SUT. Por tanto, puede ser producido por ambas partes.

  • Peligro donde se produce un fallo o error incluso con el SUT funcionando apropiadamente, o sea fallos o errores en las pruebas.

  • No continúes con el desarrollo! ni modificar ni añadir comportamiento al SUT

    • porque es muy importante mantener el software inestable el menor tiempo posible

    • o en un breve espacio de tiempo, Sindrome de los Cristales Rotos,

    • se produciría un bola de nieve/barro de otros errores

  • Entonces la recomendación es localizar el error extendiendo la cobertura de la red de pruebas con aquellas que detectan el error que se escapó.

  • Fáciles de detectar porque las causas de los problemas suelen ser muy locales y por Triangulación

  • Habrá que arreglar las pruebas quizás ajustando los accesorios del SUT y/o las aserciones.

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseño

arbolMantenible
BuenDesarrollo

  • El Coste de No Conformidad es el coste que se paga cuando no se invierte en calidad

    • Son los costes de corrección e indemnización de errores

    • Por la depuración de errores y sanciones por incumplimiento de requisitos

  • construir un edificio sin construcción de andamios

  • El Coste de Conformidad es el coste que se paga para lograr calidad

    • Son los costes de prevención y detección de errores

    • Por la planificación, diseño, desarrollo y ejecución de las pruebas

  • construir un edificio con construcción de andamios

  • Pruebas inefectivas efectivas

  • Pruebas efectivas inefectivas

  • Por lo general, el Coste de Conformidad es menor que el Coste de No Conformidad.

    • reducir el Coste Total con Calidad tiene un retorno positivo de la inversión

  • El conjunto de Casos de Prueba conforman una Red de Seguridad que permite la retroalimentación inmediata a cada pequeño cambio, código añadido o modificado, es muy importante porque permite

  • aumentar la eficacia porque se facilita la localización y corrección y documentación de errores lo cual permite

    • reducir drásticamente errores en producción, evitando el Sindrome de los Cristales Rotos dentro del ámbito de los requisitos

    • evaluar las suposiciones hechas en las especificaciones de requisitos y diseño a través de la demostración concreta de alternativas de más calidad

  • aumentar la eficiencia porque se reducen tiempo/costes gracias a la Integración Continua de pequeños incrementos de funcionalidad, frente a la Integración Diferida, lo cual permite

    • acelerar el incremento de funcionalidad

    • aumentar el ámbito del producto

  • reducir los riesgos, por encima de todo, lo cual permite

    • asesorar a la dirección de la calidad del software percibida

    • formar un equipo de desarrollo cohesivo más rapidamente

¿Cómo?

¿Quién? ¿Dónde? ¿Cuándo? ¿Cuánto?

Actores de Pruebas

Tipos de Pruebas

Metodologías de Pruebas

Cobertura de Pruebas

Actores de Pruebas

  • Una buena practica que ayuda a mitigar el riesgo de que el usuario final no este satisfecho con el producto, es involucrarlo desde instancias tempranas del proceso y tener en cuenta sus apreciaciones,para generar una retroalimentación a tiempo
actores

Tipos de Pruebas

Según el SUT Según la Ejecución Según la Característica

Según el SUT

segunTipo
Tipo Autor SUT Objetivo

Aceptación

Usuario

  • El sistema completo, desde la interfaz de usuario hasta la persistencia (application under test, AUT)

  • Una rodaja funcional de arriba a abajo del sistema de acuerdo a los documentos de especificación de requisitos

Validar los requerimientos iniciales, casos de uso, historias de usuario, manuales de usuario,…​

Sistema

Probador con Usuario

Verificar los requerimientos iniciales, casos de uso, historias de usuario, manuales de usuario,…​, independiente de las decisiones de diseño de la arquitectura de software

Integración

Probador

  • Varios componentes/subsistemas que proporcionan colectivamente un cierto servicio

Verificar las colaboraciones entre los componentes de un mismo sistema, comunicación entre subsistemas (por ejemplo: DLL, jar, servicio web,…​) o entre hardware y software

Componente

  • Varias clases de un componente que proporcionan colectivamente un cierto servicio

Verificar el funcionamiento correcto, independientemente de otros componentes

Unitaria

Desarrollador

  • Una sola clase (class unit test, CUT)

  • Un solo objeto (object Unit test-, OUT)

  • Un solo metodo (method unit test, MUT)

Verificar el funcionamiento correcto

Según la Ejecución

Pruebas Estáticas

  • Pruebas Estáticas: prueban el sistema sin ejecutar el sistema

  • Para identificar errores antes y durante de la construcción, previo a la explotación

  • Basandose en revisiones o inspecciones, reviews de los artefactos de la especificación de requisitos, del análisis, diseño e implmentación y ante cualquier cambio de su definición.

  • Realizadas por parte de todos los actores: probadores de calidad en colaboración con los usuarios y los desarrolladores
Pruebas Manuales Pruebas Semiautomáticas

  • inspeccionando el SUT, siguiendo algun guion ad hoc o con pruebas exploratorias.

    • En éstas, el probador "explora" el sistema, con las hipótesis acerca de cómo debe comportarse en base a lo que en la aplicación ya se ha hecho y luego prueba esas hipotesis para ver si se sostienen. Si bien no existe un plan rígido, las pruebas exploratorias son una actividad disciplinada con la que es más probable encontrar errores reales que con las pruebas de forma rigida con un guión.

  • inspeccionando métricas del SUT, resultado de un análisis automático de aspectos objetivos, formales, Métricas del Software.

Análisis subjetivo de:

Análisis subjetivo del resultado objetivo de:

  • los requisitos en algún lenguaje natural (español, …​)

    • Ejemplos: omisiones, ambigüedades, colisiones, …​

  • el diseño en algún lenguaje modelado (UML, …​)

    • Ejemplos: Despomposición Funcional, Principio de Separación de Interfaces, Jerarquías Paralelas, …​

  • el diseño en algún lenguaje modelado (UML, …​)

    • Ejemplos: ciclos entre clases y paquetes, estabilidad, abstracción y distancia de un paquete, …​

  • el código en algún lenguaje de programación (Java, …​)

    • Ejemplos: Nombrado, Principio de Única Responsabilidad, KISS, …​

  • el código en algún lenguaje de programación (Java, …​)

    • Ejemplos: acoplamiento de paquetes y clases, cohesión de clases, tamaño de métodos, clases y paquetes, código repetido, …​
Herramientas para Pruebas Estáticas
Herramientas CASE Herramientas Analíticas

  • Gestionan y analizan métricas de los requisitos, análisis y diseño expresados en algún lenguaje de modelado (UML, …​)

  • Gestionan y analizan métricas del software expresado en algún lenguaje de programación (Java, …​)

HerramientasCASE

HerramientasCASE2

HerramientasAnalíticas

HerramientasAnalíticas2
Análisis Ecónomico de las Pruebas Estáticas
Con Pruebas Manuales Sin Pruebas Manueles Con experiencia en Pruebas Manueales

  • ¿Cuánto dinero gasta el equipo de desarrollo invertiendo en eliminar errores si asumimos que la media de encontrar y eliminar un error en la fase de requisitos cuesta 1 euro y sucesivamente?

  • ¿Cuánto dinero pierde el equipo de desarrollo sin revisiones como actividad para eliminar errores durante la fases de requisitos, diseño e implementación permitiendo que ciertos errores se "escapen" a posteriores fases de pruebas?

  • ¿Cuánto podría ahorrar al equipo de desarrollo si se analizan los resultados de sus revisiones, de tal forma que mejore los procesos de implementacion de requisitos, diseño y, por lo tanto, reducir en un 50% el número de errores introducidos en cada una de esas fases?

ConPruebasEstaticas

SinPruebasEstáticas

ConMásPruebasEstaticas
No existe ninguna otra actividad de pruebas que produzca una detección y corrección de errores de forma más eficiente (inversión/ahorro de tiempo y coste) que las pruebas estáticas basadas en revisiones
— C. Kaner; J. Falk; H.Q. Nguyen
Testing Computer Software

Pruebas Dinámicas

  • Pruebas Dinámicas: prueban el sistema ejecutando el sistema

  • Para identificar errores en preproducción, previo a la explotación

  • Realizadas por parte delos probadores de calidad y los desarrolladores
Pruebas de Estado o Caja Negra Pruebas de Comportamiento o Caja Blanca

  • Verifican si se obtiene la salida deseada a una entrada dada.

  • Verifican cómo el sistema se ejecuta internamente, cómo es construido y sus soluciones estructurales garantizando que todos los caminos independientes dentro de un componente se han ejercitado al menos una vez

  • Realizadas predominantemente para pruebas funcionales y no funcionales de unidad, componentes, integración y sistema.

  • Realizadas predominantemente para pruebas unitarias y componentes

    • Son muy costosas y frágiles dependiendo de la implementación
Pruebas Automáticas Herramientas de Pruebas Automáticas

  • ejecutando Código de Pruebas que ejercita el Código de Producción, escrito especificamente para probar el SUT.

    • Permiten medir con mayor eficacia y eficiencia el comportamiento de la aplicación desarrollada, siendo uno de los avances más grandes en los métodos de desarrollo de las últimas décadas.

    • El hecho que tantos desarrolladores lo estén haciéndolo por su propia voluntad habla de su efectividad

Tipos

  • Análisis objetivo del resultado objetivo:

    • Verde, pasa! vs Rojo, no pasa!
Pruebas de Registro Pruebas de Guión

  • Uso de herramientas para monitorizar las interacciones del usuario que ejercitan el SUT mientras se prueba manualmente y esta información de guarda convertida en un guión (script) para reproducir automática e indifinidamente esta prueba contra el SUT

  • Escritura de código de pruebas manualmente (scripts) que ejerciten el SUT. El lenguaje del código de pruebas es desde el propio lenguaje de programación hasta ficheros batch, macros y lenguaje propietarios de herramientas.

testcomplete

htmlunit

  • Pruebas de Registro de la UI

    • Involucran que el usuario interactúa con el SUT via la UI grabando la sesión con posibilidad de reproducción

    • Aplicable al nivel de sistema o componente con UI.

    • No requieren habilidades especiales pero son complejas, fragiles y dificiles de mantener

  • Pruebas de Guión de la UI

    • Involucran escribir manualmente el código de pruebas que ejercitan el sistema atacando a a UI de SUT

    • Aplicable al nivel de sistema o componente con UI.

    • Requieren la habilidad de programar pero son faciles de mantener pero algo fragiles

mockito

junit

  • Pruebas de Registro de la API

    • Es la familia XUnit con Reproducción que involucran escribir manualmente el código de pruebas donde se registran todas las entradas y respuestas para que el SUT sea ejercitado, incluyendo puntos de observación y cualquer DOC con en el propio lenguaje de programación del SUT y luego,durante la ejecución de la prueba, se inyecta en la API las entradas registradas y se comparan los resultados con los registrados.

    • Aplicable al nivel desistema, integración/ componente y unidad

    • Requieren alguna habilidad de programación pero son robustas aunque dificiles de mantener

  • Pruebas de Guión de la API

    • Involucran escribir manualmente el código de pruebas que ejercita al SUT en el propio lenguaje de programación del SUT.

    • Aplicable al nivel de sistema, integración/ componente y unidad

    • Requieren la habilidad de programar pero son faciles de mantener y robustas

Según la Característica

Pruebas Funcionales Pruebas No Funcionales

Verifican aspectos funcionales del comportamiento del SUT, atendiendo a

Verifican aspectos no funcionales del comportamiento del SUT, escalabilidad, portabilidad, seguridad, …​

Pruebas No Funcionales

Tipo Verifica

Pruebas de Rendimiento

niveles de rendimiento acordados en los requisitos, en las situaciones previstas de interaccion (entradas, transacciones,…​). Los criterios de éxito son la comparación de dichos valores establecidos para el volumen de transacciones (throughput), el tiempo y/o velocidad de respuesta, …​ Obviamente,informan al equipo de producción de las tareas de optimización a acometer.

Prueba de carga o de esfuerzo o escalabilidad

las condiciones de uso del sistema bajo una pesada carga de los datos, la repetición de ciertas acciones de los datos de entrada, los grandes valores numéricos, consultas grandes a una base de datos o para comprobar el nivel de los usuarios concurrentes para la escalabilidad, …​ generando situaciones en un máximo nive. El criterio de éxito es la resistencia a que el tiempo de respuesta no se degrade.

Pruebas de estrés o volumen

los limites del sistema escalando la cantidad de carga con el tiempo con el objetivo de examinar cómo falla y vuelve a su funcionamiento normal. Puede incluir cargas de trabajo extremas, limitaciones de memoria, hardware y servicios disponibles o recursos compartidos limitados. Obviamente, informan de las tareas de recuperabilidad a acometer, que la aplicación continúe funcionando incluso después de que el servidor se haya reiniciado o se haya agotado su espacio en disco, …​

Prueba de estabilidad

anomalias como pérdidas de memoria u otras degradaciones por la continuidad de la ejecución durante más de 24 horas

NoFuncionales1

Tipo Verifica

Pruebas de Usabilidad

aptitud para el uso mediante la confirmación de que los usuarios reales pueden usar la aplicación de software para lograr los objetivos fijados, informando de si se presentan interfaces engorrosos que no siguen los flujos de trabajo normales o esperados

Pruebas de Seguridad

la presencia de virus y gusanos, delincuentes que entran en el sistema, vándalos que causan ataques de denegación de servicio y mucho mas

Pruebas de Manejo y Recuperación de Errores y Desastres

comportamientos con entradas no validas, fallos en conexiones o del sistema operativo, archivos dañados, ets.

Pruebas de Instalación y Desinstalación

cosas que pueden ir mal cuando se instala/desintala una aplicación: la instalación causa daños en el sistema o no se instala, en especial con configuraciones mínima, máxima o inusuales; la desinstalación no elimina completamente los archivos y deshace los cambios, elimina demasiados archivos o "deshace" cosas que la instalación no hizo

Pruebas de Configuración, Compatibilidad o Portabilidad

capicidad de ejecutarse en diferentes versiones o configuraciones de los entornos, hardware y software, como con diversos navegadores o versiones de los mismos.

Pruebas de Internacionalización y Localización

soportar configuraciones locales, normales o leyes, como si el sistema no soporta los conjuntos de caracteres para el lenguaje local, si el sistema no contempla los efectos locales de distintos calendario de distintos usuarios, …​

Pruebas de Manejo de Fecha y Hora

tratamientos de expiración de fechas, zonas horarios o eventos basados en fechas u horas

Pruebas de Mantenibilidad

la fluidez, flexibilidad, reusabilidad y robustez del código de producción
Herramientoas para pruebas No Funcionales

  • Especificas de una "-ilidad" a probar:

    • Pruebas de Rendimiento, Carga y Estres: JMeter

    • Pruebas de Seguiridad: Blog

    • …​

jmeter

Resumen de Tipos de Pruebas

Disciplina Caracteristica SUT Táctica Ejecución Herramienta Objetivo Cuándo Rol

Requisitos

Funcionales y No Funcionales

Sistema

Estatica

Manual

Inspección

Validación de Requisitos

Inicio Iteración

Analista de Sistemas

Diseño

Sistema, Integración, Componente y Unidad

Manual

Inspección

Verificación de Diseño (subjetiva)

Final Iteración

Arquitecto, Desarrollador Senior

Automática / Manual

CASE + Inspección

Verificación de Métricas de Diseño (subjetiva)

Automática

CASE

Verificación de Mérticas de Diseño (objetiva)

Implemen- tación

Manual

Inspección

Verificación de Diseño (subjetiva)

Automatica / Manual

SonarQube + Inspección

Verificación de Métricas de Diseño (subjetiva)

Automática

SonarQube

Verificación de Métricas de Diseño (objetiva)

Funcionales

Unidad

Caja Blanca y Caja Negra

Automática

xUnit, xUnit Reproducción

Verificación de la Funcionales de la Implementación

Continua- mente

Desarrollador

Integración y Componente

Final Iteración

Probador

Sistema

Caja Negra

Robot, xUnit Moderno, xUnit*

Verificación de la Funcionales de la Implementación

No Funcionales

Sistema, Integración, Componente y Unidad

Jmeter, xUnit

Verificación de Umbrales No Funcionales de la Implementación

Funcionales y No Funcionales

Aceptación

Caja Negra

Manual

Inspección

Validación de Requisitos

Fin Iteración

Usuario

Proceso de Desarrollo Software con Pruebas

Desarrollo con Pruebas al Final Desarrollo con Pruebas Primero Desarrollo dirigido por Pruebas Desarrollo dirigido por el Comportamiento

Test Last Development (TLD)

Test First Development (TFD)

test-driven development (TDD)

Behaviour-driven development (BDD)
tld
tfd
tdd

BDD

  • El desarrollo de las pruebas se realiza después de la implementación del SUT

  • El desarrollo de las pruebas se realiza después del análisis/diseño pero antes del comienzo de la implantación de SUT.

    • Esto asegura que las responsabilidades de cada unidad de software son bien entendidas antes de que la unidad está codificada

  • El desarrollo de las pruebas se realiza antes del comienzo del diseño e implantación de SUT.

  • El énfasis está en que las pruebas son como documentación en lugar de la mera utilización de pruebas para la verificación, enfocando en describir claramente el comportamiento esperado del SUT

  • Metodología:

    • Cascada

  • Metodología:

    • Proceso Unificado de Desarrollo

  • Metodología:

    • Programacion Extrema

      • Escuela Clásica(inside-out): bottom/Up

      • Escuela Londinense(Outside-in): top/Down

    • Proceso Unificado de Desarrollo
Las actividades, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera más eficiente según contexto del proyecto
— Meszaros
xUnit Test Patterns: Refactoring Test Code

Integración Continua

  • Para evítar el tradicional problema de la integración diferida, sin retroalimentación, proceso largo e impredecible de la metodología en cascada

  • Práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente

    • Generalmente cada persona integra cada pocas horas o al menos diariamente dando lugar a múltiples integraciones por dia en el equipo

    • Cada integración es verificada por una construcción automatizada

      • En caso de fallos y/o errores, séra una prioridad del equipo volver a disponer de una construcción sin fallos y/o errores, solo se admitirán cambios en el código enfocados a obtener una nueva construcción sin fallos.
Pruebas de Regresión Pruebas de Humo

  • Incluye las pruebas que no se ejecutaban antes del checkin, ya que llevan tiempo sin ejecutarse y al cambiar o añadir nuevo código a un programa fácilmente puede introducir errores en el código que no se ha cambiado

  • ¡¡¡Para optimizar el proceso, cuando las pruebas de regresión consumen mucho tiempo!!!

    • Es un subconjunto de pruebas rapidas (un subconjunto de pruebas especifico, TestSuite) que se realizan sobre aspectos funcionales no tanto para encontrar errores sino para asegurarse de que la funcionalidad básica de SUT se encuentra estable y respondan al comportamiento esperado.

  • Mantener un único repositorio de código con un sistema de control de versiones (CVS, GitHub,…​)

  • Automatizar la Construcción, con la inmediata ejecución de pruebas en el Entorno de Integración

    • Todo check-in se construye en la rama de desarrollo en el Entorno de Integracción

    • Arreglar los fallos inmediatamente

  • Automatizar el Despliegue, con la inmediata ejecución de pruebas en el Entorno de Pre-Producción

    • Facilitar la obtención del ultimo ejecutable

    • Todo el equipo puede ver qué está pasando con Radiadores de Información (pantalla dedicada)

Jenkins

Entornos de Ejecución

Entorno de Producción: en el que se ejecutan las aplicaciones para su explotación

Código de Producción: el que está escrito para el despliegue en el entorno de producción

Entorno de Pre-Producción: de las mismas características que el Entorno de Producción pero cuyo objetivo no es explorar la aplicación si no realizan pruebas de la aplicación antes de llevarlo al Entorno de Producción para evitar "catástrofes"

Código de Pre-Producción: el que está sometido a pruebas en el Entorno de Pre-Producción para ,en caso de éxito,llevarlo a código de producción

Entorno de Integración Continua: donde se gestionan todas las ramas del código de un proyecto con sus versiones

Codigo de Integración Continua: master, develop, feature, release# y hotfix#

Entorno local: el del desarrollador

Código local: el del entorno de desarrollo enfocado a una rama

Ejecución de Pruebas

consturcciones

  • Constucción en el entorno local

    • para incrementar funcionalidad bajo demanda del desarrollo

construccionLocalFuncionalidad

  • Construcción para arreglar un error en el entorno local

    • detectado en integración, pre-producción o producción

construccionError

  • Construcción para el entorno de integración

    • automatizado por herramienta

construccionIntegracion

  • Construcción para el entorno pre-producción

    • automatizado por herramienta

construccionPreProduccion

  • Construcción para el entorno producción

    • bajo demanda de la planificación

construccionProduccion
Pruebas Alfa Pruebas Beta

  • realizadas por un cliente,

  • en el lugar de desarrollo en un entorno controlado.

  • se usa el software de forma natural

  • con el desarrollador como observador del usuario y registrando los errores y problemas de uso

  • realizadas por los usuarios finales

  • en los lugares de trabajo de los clientes en un entorno que no puede ser controlado por el desarrollador

  • se usa como una aplicación en vivo del software

  • el cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador

Cobertura de Pruebas

  • La Cobertura es la medida porcentual del grado en que el código fuente de una aplicaciòn ha sido ejercítado durante las pruebas determinando indirecta y supuestamente la calidad de las pruebas que se lleven a cabo.

  • ¡¡¡La medida de la cobertura es peligrosa!!!

  • Las técnicas de análisis de la cobertura miden sólo una dimensión de un concepto multidimencional.

  • El número suficiente de cobertura de pruebas es mucho más complicado

  • La sentencia "no se puede entrar en producción con una cobertura inferior al X%" puede provocar que se escriban pruebas para hacer felices a los números o gestores y, cuando menos, es sospechoso.
"Un hombre sabio dijo una vez: me esperaba un alto nivel de cobertura (80%-90%)! A veces los gerentes requieren una. Hay una diferencia sutil"
— Brian Marick
Defecto Exceso

"Lo barato al final sale caro!"

"Pagame ahora y ya no me pagas luego!"

  • Los valores de baja cobertura inferiores al 50%,son una señal de problemas.

    • La deuda de pruebas surge cuando no escribimos todas las pruebas necesarias dando como resultado que se tiene código sin protección en el que podria romper sin causar que ninguna prueba falle

    • El concepto de deuda es una metáfora de "no hacer lo suficiente" de algo.

    • Para salir de la deuda, hay que poner un esfuerzo extra en él, algo que no estábamos haciendo suficiente.

  • Solución ineficaz porque solo se dispone de una Red de Seguridad con agujeros grandes, que no filtra errores si se cambia el código de producción para aumentar funcionalidad, mejorar calidad, optimizar, …​ evolucionar

  • La cobertura al 100% no significa que el 100% esté probado.

    • Dos casos de prueba diferentes pueden alcanzar exactamente la misma cobertura pero los datos de entrada de uno pueden encontrar un error que los entrada de la otra no.

  • Una señal que se está probando demasiado es si las pruebas se están desacelerando o si un simple cambio de producción hace que los cambios excesivamente largos en las pruebas.

    • Esto puede no ser tanto que se estén probando muchas cosas sino que hay duplicación en el test

  • Solución ineficiente porque se dispone de una Red de Seguridad con agujeros finisimos y/o grandes, dependiendo de los datos de prueba, que no filtra errores si se cambia el código de producción para aumentar funcionalidad, mejorar calidad, optimizar, …​ evolucionar

introduccion3
Equilibrio

"Mas vale prevenir que currar!"

  • Efectividad, es crucial para mantener una alta productividad de pruebas, lograr los máximos resultados con el mínimo esfuerzo.

    • Eficacia, que produce un resultado deseado

      • Un buen caso de prueba es cuando es probable que detecte un error que no se ha visto todavia

    • Efeciencia, que produce sin despifarro

      • Debe tratarse de ejecutar las pruebas correctas para encontrar los errores más importantes antes de que los errores de menor importancia.

      • Debe tratarse de descubrir los errores tan tempranamente como sea pocible

  • El equipo de desarollo rara vez:

    • tiene errores que se escapan a producción,

    • es reacio a cambiar algo de código por miedo a los errores que se causarán en producción,

    • precisa el depurador

Sintesis

sintesis

diagramaSintesis

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • xUnit Test Patterns: Refactoring Test Code

    • Gerard Meszaros

    • Addison-Wesley Educational Publishers Inc; Edición: 01 (21 de mayo de 2007)

xUnitTestPatternsRefactoringTestCode

  • Effective Unit Testing

    • Lasse Koskela

    • Manning Publications Company; Edición: 1 (16 de febrero de 2013)

EffectiveUnitTesting

  • The Art of Software Testing

    • Glenford J. Myers

    • John Wiley & Sons Inc; Edición: 3. Auflage (16 de diciembre de 2011)

TheArtofSoftwareTesting

  • Pragmatic Unit Testing in Java with JUnit

    • Andy Hunt, Dave Thomas

    • The Pragmatic Programmers (1674)
PragmaticUnitTestinginJavawithJUnit

  • Testing Computer Software

    • Cem Kaner,Jack Falk,Hung Q. Nguyen

    • Wiley John + Sons; Edición: 2nd (12 de abril de 1999)

TestingComputerSoftware

  • Diseno Agil con TDD

    • Ble Jurado, Carlos

    • Lulu.com (18 de enero de 2010)

DisenoAgilconTDD

  • Test Driven Development

    • Kent Beck

    • Addison Wesley; Edición: 01 (8 de noviembre de 2002)

TestDrivenDevelopment

  • Growing Object-Oriented Software, Guided by Tests

    • Steve Freeman

    • Addison-Wesley Professional (12 de octubre de 2009)

GrowingObjectOrientedSoftware,GuidedbyTests

  • How Google Tests Software

    • James A. Whittaker,Jason Arbon,Jeff Carollo

    • Addison-Wesley Educational Publishers Inc; Edición: 01 (2 de abril de 2012)

HowGoogleTestsSoftware

  • Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps

    • Mike Clark

    • The Pragmatic Programmers (1900)

PragmaticProjectAutomation

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM