Es increíble como estando de vacaciones la mente se despeja, las ideas fluyen y la creatividad se potencia. Y si a esto le sumamos los tips diarios de mi amigo Diego, el resultado puede ser un artículo como el siguiente. Los invito a continuar leyendo.
Sentado en la playa leo su tip #44 en donde él habla de cómo nosotros podemos dar por válidas las pruebas sobre un sistema y mandarlo a liberar si no somos capaces de asegurar con 100% de certezas que ese software está libre de fallas.
Sobre este tema es que quiero profundizar, ojos que no ven… bugs que se nos escapan.
Todos sabemos que nuestro peor enemigo a la hora de realizar nuestras tareas es el tiempo, que no siempre podemos ejecutar todas las pruebas que queremos, y de esta manera, “garantizar” la calidad del software.
Pero también sabemos que no solo tenemos esta limitación, sino que existen otros factores como lo son el económico (presupuesto del proyecto para costear el testing), la cantidad de recursos (cantidad de profesionales que están abocados a testear un sistema), que somos humanos y podemos cometer errores, o simplemente que se siguen malos procesos que llevan a una mala calidad.
Ahora, no crean que me olvidé del principal, lo dejé para lo último: es imposible hacer un testing exhaustivo. Imposible por todas las limitaciones citadas anteriormente y por la infinidad de casuísticas que pueden existir a la hora de probar un sistema.
¿Quieren más limitaciones? Les cito el sesgo de quien prueba la aplicación. ¿Acaso ustedes nunca se gastaron 15 minutos buscando y buscando las llaves hasta que viene alguien de afuera y en 5 segundos las encuentra?
Todo esto nos lleva a tener una enorme presión a la hora de dar luz verde y dar por aprobada la aplicación a liberar. Como decía anteriormente, ojos que no ven, bugs que se nos escapan.
¿Cómo podemos maximizar la eficiencia a la hora de testear?
Mientras escribo este post mis manos juegan con la arena y pienso en cuanta de ella se me escapa entre los dedos sin que yo lo pueda evitar. Imagino que, si yo tuviera 2 o 3 manos más, las pondría una encima de la otra, como si fueran filtros a distintos niveles, y de esta manera la cantidad de granos de arena que llega al suelo tendería prácticamente a cero.
De igual manera podemos trabajar nosotros para evitar que los bugs se nos escapen, necesariamente tenemos que tener filtros de calidad durante todo el proceso desarrollo del software.
Nueve filtros de calidad
1. Revisión de requerimientos o Historias de usuario
Generalmente el QA es el responsable de llevar adelante las revisiones de estos documentos. Indudablemente, esto no siempre es así. Responsables de revisar, analizar, buscar ambigüedades y cuestionarse lo escrito allí debe ser tarea de todas las partes interesadas.
2. Revisión de diseño
Al igual que las revisiones anteriores, las de diseño también involucran a partes interesadas en lo que se está implementando. Estas deben ser llevadas a cabo por personas ajenas al equipo de diseño tales como un QA, BA, un desarrollador y hasta el propio Product Owner (PO). Entender muy bien quién será el usuario final y conocer sobre buenas prácticas de usabilidad es muy importante para hacer una correcta revisión de un prototipado.
3. Revisión de código
La revisión de código es una muy buena práctica que debe ser implementada para mejorar los niveles de calidad de lo que estamos construyendo. Ya sea que la revisión sea cruzada (entre desarrolladores) o realizada por algún QA, la misma debe ser llevada a cabo tan pronto como se haya completado la codificación. El objetivo aquí es identificar de manera temprana errores, problemas lógicos o detectar desviaciones de lo requerido por el cliente.
4. Pruebas unitarias
Las pruebas unitarias generalmente son llevadas a cabo por los desarrolladores y el principal objetivo es asegurarse de que cada unidad (función, método, procedimiento, objeto, etc) del código del software funcione como se espera, generando confianza y permitiendo que los defectos no se propaguen a niveles superiores. Son muy importantes ya que son el paso previo a la liberación del objeto de pruebas que estaremos testeando. Una mala prueba unitaria, o la ausencia de ella, lo único que logrará es que se dilaten los tiempos de liberación.
5. Pruebas de integración de componentes
Estas pruebas son llevadas a cabo por el equipo de calidad y se centran en las interacciones entre los componentes del sistema. Detectar manejo de datos incorrectos, mensajes inconsistentes, malas sincronizaciones entre interfaces, fallas de comunicación, son algunos de los defectos que generalmente se encuentran en este nivel.
Como verán, seguimos colocando filtros de calidad a medida que avanzamos en el desarrollo.
6. Pruebas de sistema
Las pruebas aquí son llevadas a cabo con el objetivo de verificar el correcto comportamiento de todo el sistema, cómo cada una de las partes interactúan entre sí para brindar al usuario todas las funciones que éste requiere. En otras palabras, contrastaremos los requerimientos con lo que el sistema efectivamente está haciendo (verificación). Tampoco podemos olvidar asegurarnos de que el mismo debe satisfacer las necesidades del usuario (validación).
7. Pruebas de integración del sistema
Similar a la integración de componentes se encuentra la integración de sistemas, y esto no es más que probar que nuestro sistema es capaz de integrarse de manera correcta con otros sistemas externos. El objetivo aquí es probar las interacciones de las interfaces existentes, pruebas de web services, API´s, microservicios, mensajerías, son algunos ejemplos de las pruebas a realizar.
8. Pruebas de aceptación
Llegando a la recta final tenemos las pruebas que realizará nuestro cliente/usuario (UAT). Las pruebas de aceptación buscarán la conformidad de que el sistema construido es el que él solicitó. El objetivo aquí es asegurarnos de que la aplicación esté completa, que funcionará como se espera y ha sido especificado en los requerimientos funcionales y no funcionales. Generar confianza en el usuario de que el sistema a liberarse es el indicado es otro de los objetivos que se persiguen en esta instancia.
9. Pruebas en Producción
Por último, tenemos la hora de la verdad. Debemos verificar que lo liberado a producción se encuentra efectivamente operativo de acuerdo a lo requerido. Siempre existe la posibilidad de volver atrás ante un riesgo inminente para el usuario, y, por consiguiente, la reputación de la empresa. Monitoreo, Canary Testing, A/B Testing son solo algunas de las pruebas que se pueden llevar a cabo una vez liberado el sistema.
Como les contaba al principio, si yo tuviera 2 o 3 manos más, podría evitar que se filtre arena por mis dedos, pero claramente esto es naturalmente imposible.
Sin embargo, hay ciertas cosas que sí son posibles de realizar. Cuantos más filtros de calidad pongamos en nuestros procesos de desarrollo, más certezas tendremos y menos presión sentiremos a la hora de dar luz verde para liberar una aplicación.
0 comentarios