El Mapa SMART para tu App Bancaria

Definición de Objetivos de Prueba

Imagina que eres el responsable de calidad en el lanzamiento de una nueva función de "Apertura de Cuenta desde el Móvil". No puedes simplemente decir "vamos a probar a ver qué sale"; necesitas un plan con metas claras. Aquí es donde definimos los Objetivos de Prueba y los Criterios de Salida.

Planes de Prueba: El "Qué" y el "Cómo"

Cada proyecto necesita un plan. En tu banco, podrías tener un Plan Maestro para toda la app, pero también planes específicos para áreas críticas: un Plan de Seguridad (para evitar robos de identidad) o un Plan de Rendimiento (para que la app no colapse en quincena). Si trabajas en un equipo ágil, harás un plan pequeño para cada dos semanas (Sprint).

Objetivos S.M.A.R.T.: La Clave del Éxito

Para que un objetivo sea útil, debe seguir esta regla:

• S (Específico): "Validar que el escaneo del INE funcione", no solo "probar la cámara".
• M (Medible): "Encontrar y corregir el 100% de los errores críticos".
• A (Alcanzable): ¿Tenemos los iPhones y Androids necesarios para probarlo en el tiempo dado?
• R (Relevante): Debe ayudar al banco; por ejemplo, asegurar que los datos del cliente estén cifrados.
• T (Oportuno): "Las pruebas deben terminar el viernes a las 5:00 PM".

Ejemplos Reales en el Banco

Tus objetivos podrían ser: demostrar que solo el dueño de la cuenta puede ver su saldo (seguridad), asegurar que la migración de datos de clientes antiguos no perdió información, o confirmar que, tras mejorar el código, las transferencias siguen funcionando igual (prueba de regresión).

En resumen: Sin objetivos claros, no sabes cuándo dejar de probar. Los objetivos S.M.A.R.T. te dan la certeza de que la app es segura y está lista para el usuario.

Criterios de Entrada y Criterios de Salida: Clave para un Control Efectivo de la Calidad del Software

 Amigos, es hora de tomar el control de la calidad de nuestro software. ¿Cómo lo hacemos? ¡Definiendo criterios de entrada y salida!

Cuando se trata de pruebas de software, es esencial tener claras las condiciones que deben cumplirse antes de iniciar una actividad de prueba (criterios de entrada) y las que deben alcanzarse para considerarla completada (criterios de salida). Esto permite ejercer un control efectivo sobre la calidad del software y la misma actividad de prueba.

Los criterios de entrada, también conocidos como "definición de preparado" en el desarrollo ágil, definen las precondiciones necesarias para comenzar una prueba específica. Si estos criterios no se cumplen, la actividad será más difícil, lenta, costosa y riesgosa.

Por otro lado, los criterios de salida, o "definición de hecho" en el desarrollo ágil, establecen las condiciones que deben alcanzarse para poder afirmar que un nivel de prueba o conjunto de pruebas ha sido completado. Estos criterios variarán según los objetivos de la prueba.

Algunos ejemplos de criterios de entrada comunes son:

• Disponibilidad de requisitos, historias de usuario y/o modelos probables.
• Disponibilidad de elementos de prueba que cumplieron criterios de salida anteriores.
• Disponibilidad del entorno de prueba y herramientas necesarias.
• Disponibilidad de datos y recursos de prueba.

Y algunos ejemplios de criterios de salida comunes son:

• Ejecución de todas las pruebas planificadas.
• Logro de un nivel de cobertura definido (requisitos, historias de usuario, etc.).
• Número de defectos no resueltos dentro de un límite acordado.
• Niveles de fiabilidad, eficiencia, usabilidad, seguridad, etc., suficientes.

¡Establecer criterios de entrada y salida claros y apropiados es clave para asegurar un proceso de pruebas efectivo y eficiente! Esto te permitirá tener un mejor control de la calidad del software y tomar decisiones informadas.

¿Quién Hace Qué?

Roles en una Revisión Importante

Cuando realizamos una revisión formal de un trabajo, como un proyecto o un documento, es importante que todos tengan un papel específico para que las cosas funcionen bien. Aquí te explico los roles más comunes que suelen estar presentes en una revisión formal:

• Autor: Es la persona que creó el trabajo que vamos a revisar. Si es necesario, también será el encargado de corregir los errores que encontremos.
• Dirección: Esta persona se encarga de planificar toda la revisión. Decide cuándo se llevará a cabo, quiénes participarán, cuánto tiempo tomará y cuánto costará. También supervisa que todo salga bien.
• Facilitador: Su trabajo es asegurarse de que las reuniones de revisión funcionen sin problemas. Si hay diferentes opiniones, él o ella puede mediar para que lleguemos a un acuerdo. Su papel es muy importante para que la revisión sea un éxito.
• Líder de Revisión: Esta persona es responsable de la revisión en general. Decide quiénes serán los participantes y organiza dónde y cuándo se llevará a cabo.
• Revisores: Son las personas que revisan el trabajo en detalle. Pueden ser expertos en el tema, personas que trabajaron en el proyecto o personas con conocimientos técnicos o de negocios específicos. Su tarea es encontrar posibles errores o mejoras.
• Escriba (o grabador): Su trabajo es tomar nota de todos los posibles errores que encontremos durante la revisión individual y también anotar las decisiones que tomemos en la reunión.

En algunas revisiones, una persona puede tener más de un rol, y las acciones que realiza cada persona pueden variar según el tipo de revisión. Además, hoy en día, con la ayuda de herramientas, a menudo no es necesario tener a alguien específico como escriba, ya que todo se puede registrar fácilmente. 

¡Es un trabajo en equipo para mejorar y asegurarnos de que todo salga bien!

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.

Fallas, defectos y errores

 ¿Acaso no es lo mismo falla, error y defecto?

A veces, las personas cometen errores, y esos errores pueden resultar en defectos en el software o en otros productos relacionados. Por ejemplo, un error en la captura de requisitos puede llevar a un defecto en el requisito, lo que a su vez resulta en un error de programación y un defecto en el código. ¡Es como una cadena de eventos desafortunados!

Si ejecutas una parte de código con un defecto, esto puede causar un fallo, pero no siempre ocurre en todas las circunstancias. Algunos defectos requieren condiciones muy específicas para que se produzca un fallo, lo que puede suceder rara vez o incluso nunca. ¡Es como un secreto que solo se revela en circunstancias particulares!

Los errores pueden ocurrir por diferentes razones, como la presión por el tiempo, los errores humanos, la falta de experiencia o calificación de los participantes en el proyecto, la falta de comunicación entre ellos, la complejidad del código o el diseño, entre otros. ¡Es como un montón de obstáculos en el camino hacia el software perfecto!

Además de los defectos en el código, también existen fallos causados por condiciones del entorno. Por ejemplo, la radiación, los campos electromagnéticos o la contaminación pueden afectar el funcionamiento del hardware o el firmware, generando fallos en el software. ¡Es como elementos externos que interfieren en el funcionamiento correcto!

No todos los resultados inesperados de las pruebas son fallos. A veces, ocurren falsos positivos, que son errores en la forma en que se realizaron las pruebas o en los datos de prueba, el entorno de prueba u otros elementos relacionados. También puede suceder lo contrario, donde errores o defectos pasan desapercibidos y se producen falsos negativos. ¡Es como una confusión momentánea en el proceso de detección de errores!

En resumen, los errores pueden llevar a defectos y fallos en el software. Pueden ocurrir por diversas razones, y también hay situaciones en las que los resultados de las pruebas pueden no reflejar la presencia de defectos. ¡Es todo un desafío garantizar que el software funcione de manera correcta y confiable!

Contribución de las pruebas de software

 ¿En que contribuyen las pruebas de software?

En el mundo de la informática, a veces sucede que el software o los sistemas se entregan y luego causan problemas porque tienen defectos. ¡Pero no te preocupes! Hay técnicas de prueba que pueden ayudar a reducir estos problemas y hacer que todo funcione mejor.

Por ejemplo, si los probadores están involucrados en revisar los requisitos o en mejorar las historias de usuario, pueden detectar defectos en esas partes del trabajo. ¡Es como si fueran detectives buscando pistas ocultas!

También, cuando los probadores trabajan de cerca con los diseñadores del sistema, pueden entender mejor cómo se debe diseñar y cómo probarlo. Esto ayuda a reducir el riesgo de tener problemas fundamentales en el diseño y permite identificar pruebas desde etapas tempranas. ¡Es como trabajar en equipo para construir algo sólido desde el principio!

Lo mismo ocurre cuando los probadores colaboran estrechamente con los desarrolladores mientras están escribiendo el código. Esto ayuda a que todos entiendan mejor el código y cómo probarlo. ¡Es como tener a un compañero que te ayude a revisar tu tarea de matemáticas y encontrar errores!

Además, si los probadores verifican y validan el software antes de lanzarlo, pueden detectar fallos que de otra manera se habrían pasado por alto. Esto ayuda a eliminar los defectos que causaron los problemas (también conocido como depuración). ¡Es como revisar tu trabajo antes de entregarlo para asegurarte de que esté perfecto!

En resumen, la prueba adecuada y la colaboración entre probadores, diseñadores y desarrolladores son clave para evitar problemas y hacer que el software funcione de manera exitosa. Trabajar juntos, revisar y mejorar constantemente nos ayudará a tener un software genial y confiable. ¡Vamos por el éxito en cada entrega!

Objetivos de las pruebas

¿Qué objetivo tiene realizar pruebas de software?

Cuando probamos algo, como un software, tenemos objetivos especiales en mente. ¿Quieres saber cuáles son? ¡Te los cuento!

En primer lugar, queremos evaluar diferentes cosas, como requisitos, historias de usuario, diseños y código. ¡Es como revisar cada pieza de un rompecabezas para asegurarnos de que encajen bien!

Además, buscamos encontrar fallas y defectos, desencadenarlos para ver qué pasa. ¡Es como jugar a ser detectives de errores!

También queremos asegurarnos de que estamos probando todo lo necesario, de que nada se nos escape. ¡Es como revisar todas las páginas de un libro para no perder ningún detalle importante!

Una meta muy importante es reducir los riesgos de que el software tenga problemas de calidad. Queremos evitar sorpresas desagradables, ¿verdad?

Por supuesto, también verificamos que se cumplan los requisitos especificados. Es como comprobar si un pastel tiene todos los ingredientes que dice la receta.

¡Ah, y no podemos olvidarnos de las reglas y regulaciones! También nos aseguramos de que el software cumpla con los requisitos contractuales, legales y reglamentarios. ¡Es como seguir las normas del juego!

Además, queremos proporcionar información a las personas interesadas para que puedan tomar decisiones informadas. ¡Como darles todos los datos necesarios para que decidan sabiamente!

Y, por supuesto, queremos generar confianza en la calidad del software. ¡Que todos se sientan seguros de que funciona bien!

Por último, también validamos si el software está completo y funciona como esperamos. ¡Es como asegurarnos de que el pastel esté delicioso y listo para comer!

Los objetivos de las pruebas pueden variar según el contexto, como el tipo de software que se está probando, el nivel de prueba, los riesgos y el ciclo de vida de desarrollo del software. ¡Cada prueba es un desafío emocionante y único!