- ¿Cómo sabemos si una nueva «feature» funcionará correctamente?
- ¿Cómo sabemos que una «feature» interacciona bien con otras funciones y no las rompe?
- ¿Cómo sabemos que el código fuente tiene calidad y no es vulnerable?
- ¿Cómo sabemos que el código fuente es mantenible y que otros pueden entenderlo fácilmente?
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
- Qué es el International Software Testing Qualifications Board (ISTQB)
- Tipos de pruebas de software definidos por el ISTQB
- Cuales son las certificaciones del ISTQB
- Ejemplos de las preguntas del Examen ISTQB
- Curso Online de Software Testing (PMO informatica)
- Curso Online de Unit Testing (Jakob)
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
- 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.
- 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.
- 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.
- AGRUPACION DE DEFECTOS EN AREAS MAS DENSAS O CON MAS FALLOS
- Mayor probabilidad de encontrar +defectos si ya existen.
- NO REALIZAR SIEMPRE LAS MISMAS PRUEBAS (PARADOJA DEL PESTICIDA)
- Si repetimos siempre las mismas pruebas tienden a perder su efectividad.
- LAS PRUEBAS DEPENDEN DEL CONTEXTO
- Cada tipo de aplicación y sistema tendrán sus pruebas especificas, no hay dos iguales.
- 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
- 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.
- 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.
- 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.
- EVALUACION CRITERIOS DE SALIDA E INFORMES
- Comprobar registros de prueba con criterios de salida.
- Elaborar informes resumidos para las partes interesadas.
- 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
- 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
- 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
- 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)
- 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
- 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
- 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)
- 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)
- BASADAS EN LA EXPERIENCIA (intuitivas)
- Pruebas Exploratorias, sin documentacion (pruebas de ataque, intuitivas)
- Predicción de Errores, cazador de errores (habilidades del probador)
- 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
- 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.
- 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
Escenarios de Tests
Unit Testing: Pruebas automatizadas, simples, repetibles y mantenibles que invocan una metodo en el sistema y luego verifican una sola suposición sobre el comportamiento de esa unidad de trabajo. En términos simples, una prueba unitaria proporciona validación a nivel de unidad o método.
-Ejecutar por desarrolladores al inicio/durante el proceso de desarrollo de software
-Ejecutar en cada build para probar unidades individuales del sistema en aislamiento
Integration Tests: Las pruebas de integración validan que los componente/módulos de nuestro software funcionen correctamente cuando se integran con otros módulos.
- Ejecutar en cada compilación para ver cómo diferentes módulos de software / componentes se unen e identifica cualquier problema de integración temprano.
Automated UI Tests: Las pruebas automatizadas se realizan a través de la interfaz de usuario (UI) para probar los componentes juntos en escenarios. Estas pruebas generalmente conducen su aplicación a través de su interfaz de usuario e incluyen pruebas funcionales de los controles de la interfaz de usuario.
- Estas pruebas permiten validar si toda la aplicación (incluida IU) funciona correctamente.
- Muchas veces, se utilizan para automatizar una prueba manual existente.
Performance and Load Tests: Estas pruebas validan la capacidad de respuesta, rendimiento, confiabilidad y estabilidad de la aplicación. Una prueba de carga impone demandas a un sistema para determinar el comportamiento bajo diferentes niveles de carga, identificar los cuellos de botella y validar el rendimiento esperado.
– Debería ejecutarse en cada compilación. Sin embargo, debe ejecutarse antes de su lanzamiento a la producción para garantizar que la aplicación pueda realizar las expectativas del usuario final y manejar los niveles de carga esperados.
– Comprueba si un sistema puede funcionar bajo una gran carga de usuarios para cumplir con requisitos no funcionales, como el tiempo de respuesta de una página web.
Manual acceptance and Exploratory Tests: Una prueba de aceptación manual valida si se cumple un requisito o especificación. Una prueba exploratoria utiliza la inteligencia y la creatividad de un probador para validar la calidad, la usabilidad, el rendimiento, la experiencia y otras métricas.
- Por lo general, se ejecuta manualmente antes de la producción para garantizar que el software cumpla con los requisitos / necesidades del negocio.
- En este tipo de prueba, un probador es responsable de administrar su propio tiempo y encontrar maneras creativas de probar el sistema en cualquier etapa.
Telemetry: Testing continuo en produccion para ver el comportamiento en vivo.
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).
Santimacnet 