¿Dimos en el Blanco?

Métricas y Retos de la Prueba Basada en el Riesgo 

Imagina que acabas de lanzar una actualización para tu app de streaming de música. Como líder de pruebas, no basta con decir "terminamos"; hay que demostrar que probamos lo que realmente importaba. Aquí evaluamos el éxito y los baches del camino.

¿Cómo medimos si nuestra estrategia funcionó?

En la reunión de cierre (retrospectiva), nos hacemos preguntas clave para saber si nuestra "apuesta" por el riesgo fue correcta:

• Representación: ¿Estuvo el experto en audio y el de pagos cuando definimos qué era peligroso?
• Detección temprana: ¿Encontramos los fallos graves (como que no cargue la letra de la canción) al principio y no al final del proyecto?
• Comunicación: ¿Pudimos explicarle al dueño de la app que no probamos el "cambio de color de botones" porque el riesgo era bajísimo comparado con la seguridad?
• Fugas: Si hubo un fallo crítico en la app ya publicada, ¿lo tenemos bajo control?

Dificultades comunes (y cómo saltarlas)

Incluso con las mejores certificaciones, surgen problemas:

• Subestimar el peligro: A veces es difícil saber qué tan probable es que falle el buscador. Solución: Mira datos de versiones anteriores y pregunta a los que más saben.
• Efecto "Déjà vu": Pensar que "son los mismos riesgos de siempre" y relajarse. Solución: Trae gente nueva a las sesiones para tener ojos frescos.
• Abandono por presión: Con las prisas del lanzamiento, se deja de analizar el riesgo. Solución: Reportes rápidos y constantes a los jefes sobre qué riesgos estamos mitigando hoy.
• Rotación de gente: Si el experto en la base de datos se va, el riesgo cambia. Solución: El análisis de riesgo nunca termina; es un ciclo que se repite.

En resumen: El éxito no es probar todo, sino probar lo correcto y saber explicar por qué lo hicimos.

Integración Continua: ¡Construyendo tu red social pieza por pieza!

Imagina que estás construyendo una red social para probadores de software. En lugar de esperar hasta el final del proyecto para unir todas las piezas, la integración continua te permite ir construyendo y probando tu red social de manera constante.

¿Qué es la integración continua?
Es como armar un rompecabezas, pero en lugar de piezas, son fragmentos de código. Cada vez que un desarrollador termina una parte del código, se integra automáticamente con el resto del proyecto. Luego, se ejecutan pruebas para asegurarse de que todo funciona correctamente.

¿Por qué es importante?

• Detección temprana de errores: Al integrar y probar el código con frecuencia, puedes identificar y corregir errores mucho antes de que se conviertan en un problema mayor.
• Mejora la calidad: Al tener un proceso de construcción y prueba automatizado, puedes asegurarte de que tu red social siempre esté en un estado estable y confiable.
• Aumenta la productividad: Al automatizar muchas de las tareas repetitivas, los desarrolladores y probadores pueden concentrarse en tareas más creativas.
• Mayor visibilidad: Todos los miembros del equipo pueden ver el progreso del proyecto y colaborar de manera más efectiva.

¿Cómo funciona en la práctica?

• Desarrollo: Los desarrolladores escriben código y lo integran en un repositorio compartido.
• Construcción: El código se compila y se crea una nueva versión de la aplicación.
• Pruebas: Se ejecutan pruebas automáticas para verificar que la nueva versión funciona correctamente.
• Retroalimentación: Los resultados de las pruebas se comparten con el equipo para tomar decisiones.

¿Cuál es el rol de los probadores?
Los probadores juegan un papel crucial en la integración continua. Son responsables de:

• Crear pruebas automatizadas: Estas pruebas se ejecutan automáticamente después de cada cambio en el código para detectar cualquier problema.
• Analizar los resultados de las pruebas: Los probadores deben revisar los resultados de las pruebas y proporcionar retroalimentación al equipo.
• Explorar nuevas funcionalidades: Una vez que las pruebas automatizadas han pasado, los probadores pueden explorar las nuevas funcionalidades manualmente para asegurarse de que funcionan como se espera.

En resumen, la integración continua es una práctica fundamental para construir software de alta calidad. Al automatizar el proceso de construcción y prueba, puedes mejorar la eficiencia, reducir errores y entregar un producto final de mejor calidad.

Los 12 Principios Ágiles

Imagina que estás creando una nueva plataforma de streaming de música. En lugar de seguir un plan rígido y esperar años para lanzar el producto final, el desarrollo ágil te permite lanzar nuevas funcionalidades de forma regular, como si estuvieras creando una playlist personalizada, agregando nuevas canciones y mejorando la calidad del sonido a medida que avanzas.

¿Cuáles son los secretos de este éxito?

Los 12 principios ágiles son como los ingredientes de una receta mágica que te permiten crear una plataforma de streaming increíble:

• Prioriza la satisfacción del cliente: Lo más importante es que a los usuarios les encante tu plataforma. Entrega nuevas funcionalidades regularmente para mantenerlos felices.
• Sé flexible: Los gustos musicales cambian constantemente, así que tu plataforma también debe adaptarse.
• Entrega rápido: No esperes a tener todo perfecto. Lanza nuevas versiones con frecuencia para obtener feedback de los usuarios.
• Trabaja en equipo: Los desarrolladores, diseñadores y tú, como probador, deben trabajar juntos para lograr un objetivo común.
• Confía en tu equipo: Dale a tu equipo la libertad y las herramientas necesarias para hacer un gran trabajo.
• Comunícate claramente: La comunicación directa es clave para resolver problemas y tomar decisiones rápidamente.
• El software que funciona es lo más importante: No te enfoques solo en la documentación. Lo que importa es que la plataforma funcione bien y que los usuarios la disfruten.
• Sé sostenible: No trabajes a un ritmo insostenible. Busca un equilibrio entre la velocidad y la calidad.
• Mejora continuamente: Siempre busca formas de mejorar tu plataforma y tus procesos de trabajo.
• Mantén las cosas simples: No compliques las cosas innecesariamente.
• Empodera a tu equipo: Permite que tu equipo tome decisiones y encuentre las mejores soluciones.
• Reflexiona y mejora: Reúnete regularmente con tu equipo para analizar lo que funciona bien y lo que se puede mejorar.

En resumen, los principios ágiles te ayudan a crear una plataforma de streaming de música que sea adaptable, de alta calidad y que satisfaga las necesidades de tus usuarios. ¡Es como crear la mejor playlist del mundo, una canción a la vez!

Calendario de Ejecución de Pruebas: ¡Organizando tu maratón de pruebas!

Imagina que estás organizando una carrera. 

Tienes a un montón de corredores (tus casos de prueba) listos para empezar, pero no puedes simplemente decirles a todos que corran al mismo tiempo. Necesitas un plan para que la carrera sea eficiente y justa, ¿verdad?

En las pruebas de software pasa lo mismo. Tienes un montón de casos de prueba que ejecutar, pero ¿en qué orden los ejecutas? Aquí es donde entra en juego el calendario de ejecución de pruebas.

¿Qué es un calendario de ejecución de pruebas?

Es un plan que te dice cuándo y en qué orden debes ejecutar cada caso de prueba. Es como un mapa de ruta para tus pruebas.

¿Por qué es importante?

• Eficiencia: Te ayuda a aprovechar al máximo tu tiempo y recursos.
• Organización: Evita que te pierdas entre tantos casos de prueba.
• Dependencias: Asegura que los casos de prueba se ejecuten en el orden correcto, considerando las relaciones entre ellos.
• Priorización: Te permite enfocarte en los casos de prueba más importantes primero.

¿Cómo se crea un calendario de ejecución de pruebas?

• Prioriza tus casos de prueba: Los casos más importantes (por ejemplo, los que cubren funcionalidades críticas) suelen ejecutarse primero.
• Identifica las dependencias: Si un caso de prueba depende del resultado de otro, asegúrate de ejecutarlos en el orden correcto.
• Considera las pruebas de confirmación y regresión: Estas pruebas verifican que los cambios no hayan introducido nuevos errores y deben programarse de manera estratégica.
• Busca la secuencia más eficiente: A veces hay varias formas de organizar las pruebas. 

Elige la que te permita completarlas más rápido sin comprometer la calidad.

En resumen:

El calendario de ejecución de pruebas es una herramienta esencial para cualquier tester. Te ayuda a organizar tus pruebas de manera eficiente y efectiva, asegurando que tu software sea de alta calidad.

¡Es como tener un plan de ataque para tus pruebas! 

Asegurando la Calidad de lo que Creamos

Revisión de Trabajos

Cuando creamos algo, como un programa de computadora o una app, es importante revisarlo para asegurarnos de que funcione bien y no tenga errores. Esta revisión puede ser desde algo más informal, como un grupo de personas que se juntan a mirar el trabajo y hablar sobre él, hasta algo más formal, con un equipo organizado y pasos documentados.

En las revisiones informales, no hay un proceso definido y no se documenta todo lo que se habla. Simplemente, se reúnen para mirar el trabajo y dar sus opiniones.

En cambio, en las revisiones formales, hay un equipo más organizado, se documenta todo lo que se dice y se siguen pasos específicos para hacer la revisión.

El nivel de formalidad depende de cosas como cómo se está desarrollando el proyecto, qué tan maduro es el proceso de desarrollo, qué tan complicado es el trabajo que se revisa y si hay requisitos legales o reglas que se deben seguir.

Lo que se busca en estas revisiones depende de lo que se acuerde antes. Puede ser encontrar errores, asegurarse de que todos entiendan bien el trabajo, enseñar a nuevos miembros del equipo o discutir y tomar decisiones en conjunto.

Si quieres saber más detalles sobre cómo hacer estas revisiones, hay un estándar llamado ISO/IEC 20246 que tiene toda la información y técnicas que se pueden utilizar en estas revisiones.

Formas de pensar

 Desarrollo versus Pruebas

¿Sabes?, los desarrolladores y los probadores a menudo piensan de forma diferente. Los desarrolladores se enfocan principalmente en diseñar y construir un producto genial, mientras que los probadores se dedican a verificar y validar ese producto, buscando defectos y problemas antes de lanzarlo. Son dos enfoques distintos que requieren mentalidades diferentes, o formas de pensar. Pero cuando se combinan estas mentalidades, ¡se logra un nivel de calidad aún mayor!

La mentalidad de un probador incluye cosas como curiosidad, ser un poco pesimista (pero de manera profesional), tener un espíritu crítico, prestar atención a los detalles y ser bueno en la comunicación y las relaciones positivas. A medida que ganan experiencia, los probadores van ampliando y madurando su mentalidad. Por otro lado, la mentalidad de un desarrollador puede tener algunos elementos similares a la del probador, pero los desarrolladores exitosos están más interesados en el diseño y la construcción de soluciones, y no tanto en pensar en qué podría salir mal. Además, a veces les cuesta encontrar errores en su propio trabajo debido a algo llamado "sesgo de confirmación".

Pero, con la mentalidad adecuada, los desarrolladores también pueden probar su propio código. En diferentes modelos de ciclo de vida de desarrollo de software, suelen organizarse a los probadores y las actividades de prueba de diferentes maneras. A veces, tener probadores independientes realizando algunas de las pruebas aumenta la eficacia para detectar defectos, especialmente en sistemas grandes, complejos o críticos para la seguridad. Los probadores independientes ofrecen una perspectiva diferente a la de los creadores del software, como analistas de negocio, dueños del producto, diseñadores y programadores. Y eso es genial, porque tienen diferentes formas de pensar y abordan las cosas desde distintos ángulos.

¡Así que recuerda, la combinación de mentalidades de desarrolladores y probadores es clave para lograr productos de alta calidad!

Productos de trabajo

Si no esta escrito, no existe.

¡Manos a la obra! Cuando realizamos pruebas, creamos diferentes cosas llamadas productos de trabajo. Cada organización puede hacerlo a su manera y darles nombres diferentes, pero en general, seguimos un proceso y utilizamos herramientas para gestionarlos.

Vamos por partes. Al planificar las pruebas, creamos planes de prueba que nos dicen cómo hacerlas. Estos planes incluyen información sobre qué se va a probar y cómo se relaciona con otras cosas. También establecen criterios para saber cuándo hemos terminado.

Después, viene la monitorización y el control de las pruebas. Aquí hacemos informes sobre cómo van las pruebas, cómo avanzamos y si hemos encontrado problemas. Estos informes son importantes para la gestión del proyecto, ya que nos ayudan a saber si estamos cumpliendo con nuestras tareas y utilizando los recursos adecuadamente.

Luego tenemos el análisis de las pruebas, donde definimos las condiciones que vamos a probar y las priorizamos. También buscamos defectos en lo que estamos probando. Con esta información, pasamos al diseño de las pruebas. Aquí creamos casos de prueba y conjuntos de casos para probar esas condiciones. Es buena práctica diseñar casos de prueba sin valores concretos, para poder reutilizarlos más adelante.

Después viene la implementación de las pruebas, donde llevamos a cabo los procedimientos de prueba, utilizamos juegos de prueba y seguimos un calendario para ejecutar las pruebas. Es importante asegurarnos de que estamos cubriendo todas las condiciones y que podemos demostrarlo.

Llegamos a la ejecución de las pruebas. Aquí documentamos el estado de cada caso de prueba y generamos informes de defectos. También mantenemos un registro de los elementos y herramientas involucrados en las pruebas. Al finalizar, podemos determinar el estado de cada elemento que hemos probado y comunicar los resultados de manera clara.

Por último, cuando terminamos todas las pruebas, generamos informes de resumen y tomamos acciones para mejorar en futuros proyectos. También podemos hacer solicitudes de cambio si encontramos algo que necesita ser corregido.

¡Y eso es todo! En resumen, al hacer pruebas creamos diferentes productos de trabajo, desde planes y informes hasta casos de prueba y documentación. Cada paso es importante para asegurarnos de que las pruebas se realicen correctamente y obtengamos resultados confiables.

Valores de las pruebas de software

Principios de las pruebas

1.- ¡La prueba no demuestra que algo está perfecto!

Cuando se hace una prueba, podemos encontrar defectos, pero eso no significa que no haya más. La prueba nos ayuda a reducir la posibilidad de que queden defectos sin descubrir en el software, ¡pero no es una forma de demostrar que todo está perfecto!

2.- ¡No se puede probar absolutamente todo!

Probar absolutamente todo, como todas las combinaciones de entradas, es imposible, ¡a menos que sea algo muy simple! En lugar de intentarlo, es mejor usar técnicas de prueba, análisis de riesgos y establecer prioridades para enfocar nuestros esfuerzos de prueba.

3.- ¡Prueba temprano para ahorrar tiempo y dinero!

Es mejor comenzar las pruebas lo más temprano posible en el proceso de desarrollo de software. Así podemos detectar los defectos rápidamente. Incluso se le llama "desplazamiento hacia la izquierda". Haciendo pruebas temprano en el proceso, podemos reducir o incluso evitar cambios costosos más adelante.

4.- Los defectos suelen agruparse

La mayoría de los defectos se encuentran en unos pocos módulos. Durante las pruebas antes del lanzamiento o cuando el software está en uso, solemos descubrir que los defectos se agrupan en ciertos lugares. Esto es útil para centrar nuestros esfuerzos de prueba y analizar los riesgos.

5.- ¡Cuidado con la paradoja del pesticida!

Si hacemos las mismas pruebas una y otra vez, eventualmente no encontraremos nuevos defectos. Para descubrir nuevos defectos, a veces necesitamos cambiar las pruebas existentes y los datos de prueba, e incluso crear nuevas pruebas. ¡Es como cuando los pesticidas dejan de ser efectivos contra los insectos! En algunas ocasiones, especialmente en las pruebas de regresión automatizadas, esto puede ser útil porque encontramos menos defectos que se repiten.

6.- La prueba depende del contexto

La forma en que hacemos las pruebas varía según el contexto. Por ejemplo, las pruebas de software crítico para la seguridad industrial se realizan de manera diferente a las pruebas de una aplicación de comercio electrónico en un teléfono móvil. ¡Incluso en proyectos de desarrollo de software ágil y en proyectos con un enfoque secuencial, las pruebas se realizan de manera diferente!

7.- ¡No podemos esperar la perfección!

Algunas organizaciones esperan que los probadores puedan hacer todas las pruebas posibles y encontrar todos los defectos, ¡pero eso es imposible! Además, es un error pensar que solo encontrando y corrigiendo muchos defectos, el sistema será exitoso. Por ejemplo, si probamos todos los requisitos y corregimos todos los defectos, podríamos terminar con un sistema difícil de usar, que no cumple las necesidades de los usuarios o que es peor que otros sistemas de la competencia.