Testing QA

El ciclo de desarrollo tradicional siempre se ha compuesto de las fases de analisis, diseño, programación y pruebas, dejando para el final el testeo de la aplicación. Sin embargo, hoy en día, esta demostrado que este planteamiento es erróneo, ya que, cuanto más tarde es detectado un error dentro del ciclo de desarrollo más alto será el coste de solucionarlo.

Para definir y organizar como diseñar software de calidad, se creo en el año 2002 la ISTQB (International Software Testing Qualifications Board), una organización de certificación de la calidad del software. Esta organización define un esquema de certificación internacional para los probadores de software. Suministra el plan de estudios y el glosario sobre los que se definen los que se establecen las guías para la acreditación y evaluación de los profesionales del testing a cargo de los comités de cada país.

Fundamentos ISTQB

Principios Propios sobre testing

En mi opinión, el testing, es una de las herramientas más poderosas que existen para crear y ofrecer software de calidad, robusto y mucho más fácil de mantener, a lo largo de los años, he aprendido una serie de principios que siempre tengo presente a la hora de crear nuestro software y transmitirlo al equipo de desarrollo.

  • Un software es tan bueno o malo como lo son la calidad de sus pruebas.
  • El testing puede probar la presencia de BUGs pero no la ausencia de ellos.
  • El testing requiere de mucha EXPERIENCIA por parte de los probadores.
  • El testing siempre usa HERRAMIENTAS para llevarlo a cabo en los proyectos.
  • El testing requiere de APRENDIZAJE y DISCIPLINA que es dificil, duro y complejo.
  • El testing NO GARANTIZA el éxito de un proyecto ni asegura su calidad al 100%

Voy a incluir el temario completo del ISTQB, para tener un visión de todo lo que engloba el mundo del testing y las pruebas, porque a priori parece algo simple pero la realidad es que es mucho más que eso.

TEMA-1: LOS 7 PRINCIPIOS BASICOS DE LAS PRUEBAS

  1. LAS PRUEBAS MUESTRAN LA PRESENCIA DE ERRORES PERO NO LA AUSENCIA DE ELLOS
    • Identificar y evitar la aparición de defectos en el software.
    • Reducir la probabilidad de encontrar defectos ocultos en el software.
  2. LAS PRUEBAS EXHAUSTIVAS NO EXISTEN PROBARLO TODO ES IMPOSIBLE
    • Elegir que pruebas hacer según riesgo, prioridades, presupuesto, tiempo, recursos.
    • Falicilitar información para tomar decisiones hasta donde cubrimos con las pruebas.
  3. LAS PRUEBAS TEMPRANAS SE DEBEN EMPEZAR LO ANTES POSIBLE EN EL PROYECTO
    • Aumentar la calidad del sistema que estamos construyendo.
    • Aumentar la confianza de todos los implicados en el proyecto.
    • Ahorro costes, tiempo, recursos, menos errores, más calidad,etc.
  4. AGRUPACION DE DEFECTOS EN AREAS MAS DENSAS O CON MAS FALLOS
    • Mayor probabilidad de encontrar +defectos si ya existen.
  5. NO REALIZAR SIEMPRE LAS MISMAS PRUEBAS (PARADOJA DEL PESTICIDA)
    • Si repetimos siempre las mismas pruebas tienden a perder su efectividad.
  6. LAS PRUEBAS DEPENDEN DEL CONTEXTO
    • Cada tipo de aplicación y sistema tendrán sus pruebas especificas, no hay dos iguales.
  7. LA FALACIA DE AUSENCIA DE ERRORES
    • Detectar y reparar defectos no garantiza que el sistema pueda volver a fallar.
    • Un sistema no garantiza que satisface o cumple todas las necesidades de los usuarios.

TEMA-1: LAS 5 FASES DEL PROYECTO DE PRUEBAS

  1. PLANIFICACION Y CONTROL DE LAS PRUEBAS
    • Definir objetivos del cliente y alcance de las pruebas a realizar.
    • Estimación de la infraestructura y recursos necesarios para las pruebas.
    • Definir las politicas y estrategia de las pruebas a realizar.
    • Definir pruebas en todo el ALM del software si es posible.
  2. ANALISIS Y DISEÑO DE LAS PRUEBAS
    • Definir condiciones y casos de prueba tangibles.
    • Identificar las fuentes de datos para las pruebas.
    • Diseñar configuración del entorno y herramientas necesarias.
  3. IMPLEMENTACION Y EJECUCION DE LAS PRUEBAS
    • Implementar y priorizar los casos de pruebas.
    • Crear datos de prueba del sistema a testear.
    • Verificar entorno de pruebas correcto y disponible.
  4. EVALUACION CRITERIOS DE SALIDA E INFORMES
    • Comprobar registros de prueba con criterios de salida.
    • Elaborar informes resumidos para las partes interesadas.
  5. ACTIVIDADES DE CIERRE DE LAS PRUEBAS
    • Una vez finalizado proyecto o versión del software
    • Finalizar los productos de pruebas para entregar.
    • Guardar entorno y infraestructura para su uso posterior.

TEMA-2: PRUEBAS EN TODO ALM DEL SOFTWARE

Importante: Para cada actividad del desarrollo existe su correspondiente actividad de pruebas, no solo para la parte de programación sino también en fases de requisitos, funcional, tecnico, en resumen, durante todo el ALM del proyecto se deben realizar pruebas.

Nota: El objetivo es garantizar la calidad y robustez del sistema a todos los niveles.

2.1.Modelos de Desarrollo de Software

  • Modelo en V o Cascada: Requisitos, D.Funcional, D.Técnico, Especificaciones, etc.
  • Especificaciones para cada módulo o componente, (ver apuntes)
  • Modelo Iterativo-Incremental: Agile (incremental), RUP, RAD, etc

2.2. Niveles de Pruebas

  • Pruebas Componentes: pruebas unitarias, p.positivas, p.negativas, p.excepciones
  • Pruebas Integración: ensamblar componentes, modulos, aplicativos, b.datos
  • Pruebas Sistema: requisitos, funcionales y no funcionales
  • Pruebas Aceptación: alfa, beta, caso-uso, contractuales,  user, admin, cliente

2.3. Tipos de Pruebas

  • Funcionales: Las que v&v que el sistema cumple lo que tiene que hacer, basadas en los requisitos y procesos de negocio definidos, son pruebas de caja negra.
  • No Funcionales: Las que v&v los atributos de comportamiento del sistema, capturar la QoS, revisar el rendimiento y disponiblidad del sistema, etc.
  • Estructurales: Las que v&v la estructura del sistema como la arquitectura, son pruebas de caja blanca y cobertura para saber hasta donde cubren las pruebas.
  • Mantenimiento: Las que estan asociadas a los cambios que v&v que no se ha roto nada. Una vez desplegado un sistema de software, estará en funcionamiento durante años o decadas. Son frecuentes y necesarias las modificaciones, configuraciones y ampliaciones durante ese tiempo, hay dos tipos a realizar las pruebas de regresión y las pruebas de confirmación (pruebas que los cambios funcionan).

2.4. Tipos de Herramientas de Pruebas (uso en todo el ALM)

  • Herramientas Gestión Pruebas (requisitos, configuración, incidencias)
  • Herramientas Pruebas Estáticas (h.revisión, h.análisis estático, h.modelado)
  • Herramientas Especificación Pruebas (h.diseño, pruebas y datos de prueba)
  • Herramientas Ejecucion de Pruebas (xunit, scripts, registro salida, arnes, stubs)
  • Herramientas Mediciones de Cobertura (sentencias, ramas, condiciones)
  • Herramientas Pruebas Seguridad (confiable, integridad, autorizacion, no repudio,etc)
  • Herramientas Monitorizacion y Rendimiento (status, cpu, ram, red, carga, stress,etc)
  • Herramientas de Conversión y Migracion de Datos (…)

TEMA-3: TECNICAS DE DISEÑO DE PRUEBAS ESTATICAS

  1. EXAMEN MANUAL Y REVISIONES DE TODO TIPO DOCS
    • Requerimientos, docs de diseño, planes, manuales usuario, etc.
    • Defectos de analisis, defectos requisitos, defectos diseños, etc
    • Defectos de normativas, standares, ISO, LOPD, LSSI, cond.contractuales
  2. ANALISIS ESTATICO DEL CODIGO DE LA APLICACION
    • Herramientas de revisión de código, sistaxis, métricas
    • Detectar anomalias en los flujos de control y datos
    • Otras herramientas de codigo sin ejecutar la aplicación
  3. PROCESOS DE REVISIONES FORMAL & INFORMAL
    • Revisión informal (colega de trabajo, poco esfuerzo)
    • Tutoriales o revisiones guiada (pequeños equipos, poco esfuerzo)
    • Revisiones técnicas (expertos, técnicos)
    • Autorias y inspecciones (auditores, experto cualificado)
  4. PASOS DE REVISIONES FORMALES
    • Planificación
    • Inicio de la revisión
    • Preparación individual
    • Reunión de la revisión
    • Adaptar y documentar el trabajo
    • Seguimiento
  5. ACTORES Y ROLES
    • Selección de técnicos de pruebas del sistema
    • Jefe, Autor, Moderador, Tipos de Revisores, Escriba
    • Incluyen pruebas funcionales y no funcionales
    • Misión de identificar casos, condiciones y datos de pruebas
    • Objetivo de revisar normativas, cond.contractuales, riesgos, etc

TEMA-4: TECNICAS DE DISEÑO DE PRUEBAS DINAMICAS

  1. BASADAS EN LA INSPECCION (caja negra)
    • Técnicas partición de equivalencia (rangos, clases equiv.)
    • Técnicas análisis de valores limite (limites inicio-fin)
    • Técnicas tablas de decisión (condiciones y acciones)
    • Técnicas pruebas de casos de uso (uml)
    • Técnicas transición de estados (diagrams y maquina estados finitos)
  2. BASADAS EN LA ESTRUCTURA (caja blanca)
    • Pruebas de sentencias y cobertura (sentencias -> nodos)
    • Pruebas de decisión y cobertura (ramas si/no)
    • Pruebas de condición simple (if (condicion) then …)
    • Pruebas de condición múltiples (and, or, not, case)
  3. BASADAS EN LA EXPERIENCIA (intuitivas)
    • Pruebas Exploratorias, sin documentacion (pruebas de ataque, intuitivas)
    • Predicción de Errores, cazador de errores (habilidades del probador)
  4. ACTORES Y ROLES (objetivos)
    • Selección de técnicos de pruebas del sistema
    • Jefe, Autor, Moderador, Tipos de Revisores, Escriba
    • Incluyen pruebas funcionales y no funcionales
    • Misión de identificar casos, condiciones y datos de pruebas
    • Objetivo de revisar normativas, cond.contractuales, riesgos, etc

TEMA-5: GESTION DE LAS PRUEBAS

  • Organización de pruebas independientes (documentación y criterios E/S)
  • Planificación y estimación  de las pruebas (calendario, metricas, expertos)
  • Seguimiento y Control de pruebas (calendario, validación)
  • Gestión de la Configuración, Capacidad, Disponibilidad
  • Gestión de los Requisitos y Riesgos en las pruebas
  • Gestión de las Incidencias (Anomalias y defectos)

Software y Herramientas

Una pequeña lista de software para Testing y QA que seguramente ya conoceréis:
Sobre Pruebas Unitarias
Una de las pruebas más importantes en todo proyecto, son las pruebas unitarias, intentaré explicar de forma resumida en que consisten, lo primero es saber dividarlas en tres partes fundamentales, conocido como la “Triple AAA”:
  • Arrange: Donde se inicializan los objetos necesarios para ejecutar la prueba.
  • Act: Donde se ejecuta el método a probar y se obtiene el resultado.
  • Assert: Donde se comprueba que el resultado obtenido es el esperado.
Las características que definen un buen test unitario son:
  • Debe ser automatizable y repetible
  • Es fácil de leer, entender y mantener
  • Un test nunca debe depender de otros (recuerda unitarios)
  • Se ejecutan rápidamente y siempre en memoria
  • Se pueden ejecutar en cualquier orden aleatorio
  • Testean una única funcionalidad y devuelven siempre mismo resultado

Reflexiones Finales

Como cierre, comentar una serie de reflexiones que siempre debemos tener en cuenta y la más importante en mi opinión, un producto de software y su calidad es tan bueno o malo como lo son todas sus pruebas.

  • Todo código es “CULPABLE” hasta que se demuestre lo contrario.
  • Los TEST deber ser: legibles, confiables, rápidos y fáciles de mantener.
  • Los TEST nos dan: calidad, fiabilidad, seguridad y robustez en el desarrollo.
  • Los TEST son la mejor documentación técnica de nuestro código.
  • Los TEST son un blindaje para el proyecto, futuros cambios y bugs colaterales.
  • Los TEST deben asegurar la funcionalidad de historias/requisitos/caso uso.
  • Los TEST transacción limpiarán contextos para próximas pruebas (Rollback)
  • Al refactorizar TEST damos forma al diseño de nuestro software (artesanos).

 

Anuncios