Automation Guild – S.A.C.R.E.D.


En esta entrada vamos a hablar sobre algunas notas que tomé en la presentación de Richard Bradshaw en Automation Guild 2018.  La presentación se llama “Don’t be SCARED of automated checks/tests” pero después corrigió las siglas por S.A.C.R.E.D.

Estas charlas son extensas y con mucho material, en esta entrada no intento resumir el contenido, solo compartir algunos de los conceptos de la misma.

Si te interesa el contenido completo de esta conferencia(videos, textos, etc..), deja un comentario y me contactare contigo. En total son 25Gb de contenido(Listado de Charlas)

S.A.C.R.E.D.

Con estas siglas se busca sintetizar las distintas claves a tener en cuenta al momento de evaluar nuestros checks en las pruebas automatizadas.

Estado (State)

Para poder llevar a cabo las pruebas de un escenario, ya sea por medio de la Interfaz del Usuario o un servicio, necesitamos conocer y definir el ESTADO de la aplicación. Este estado es el que determina las condiciones en que se encuentra la aplicación antes de las pruebas y por ende va a determinar el estado de la misma cuando realicemos la validación. Para poder hacer esto necesitamos conocer la aplicación bajo pruebas, como funciona, que base de datos usa, qué servicios usa para poder lograr ese ESTADO deseado. Cuando controlamos el ESTADO de la aplicación podemos ejecutar nuestras pruebas una y otra vez teniendo mayor certeza de lo que verificamos.

Algoritmo

La definición de los pasos a llevar a cabo durante la prueba para llegar al punto que se quiere ejercitar/verificar. Una prueba bien diseñada desde el punto de vista algorítmico, tendrá un propósito bien claro, será fácil de mantener y se ejecutara con velocidad. Para lograr este algoritmo es necesario tener un buen conocimiento de la aplicación bajo pruebas,  esto nos permitirá saber cual es el mejor camino para llevar a cabo el escenario de pruebas, repetirlo varias veces manualmente, evaluar si realmente estamos llevando a cabo el camino correcto.

Oráculos Codificados (Codified Oracles)

El oráculo es lo que usamos para definir si algo esta bien o mal. Esto nos permite saber si hay un problema o no, nos permite definir si la prueba obtuvo el resultado esperado o no.

Cuando ejecutamos pruebas manuales, estos artículos disponen de mucha información ya que el que ejecuta estas pruebas manuales no solo verifica que un mensaje de error de se muestre, también verifica donde se muestra, como se muestra, si el error es legible, si el error es claro para el usuario y demás. Toda esta información muchas veces no esta en los requerimientos, no hacen falta porque son cosas de sentido común que como humanos nos resultan muy fáciles de detectar. En cambio, en las pruebas automatizadas cuando verificamos un error, probablemente solo verificamos que el error se muestra en pantalla, ya que nuestro oráculo codificado es más limitado, no tiene experiencia, no tiene sentido común, generando información limitada sobre el resultado de esa prueba. Por esto es importante brindar de la mayor información posible a nuestros oráculos codificados y mejorar las verificaciones de nuestras pruebas.

Reportes

Podemos ver los reportes desde dos puntos de vista, uno seria el resultado de la verificación, fallo/paso y cualquier información que se agregue a eso. El otro seria el reporte sobre la verificación en si misma, si sigue teniendo valor, si la información que aporta es adecuada. Tener en cuenta esto es importante porque escribimos checks/verificaciones para dar visibilidad sobre el estado de la aplicación bajo pruebas, para que se puedan tomar decisiones basándonos en esa información. Los reportes nos sirven también como evidencia de las pruebas que se hicieron y esta evidencia nos ayuda a poder encontrar rápidamente donde esta la falla, ya sea del check mismo o de la aplicación bajo pruebas.

Ejecución

En cuanto a la ejecución, es importante saber donde y como ejecutamos nuestro checks/validaciones. Corremos los checks en paralelo? cuantos threads? Agrupamos los checks similares? Nuestros checks son parte de un modelo CI que puede bloquear la salida del código a Producción? Para maximizar los checks deben poder correr en cualquier ambiente de pruebas, deben ser reusables y poder correr en forma independiente todas las veces que sean necesarias así que necesitamos asegurarnos de que los hemos diseñado para poder ejecutarlos con tanta frecuencia.

Determinista

Este es básicamente el objetivo, el determinismo es básicamente la meta, es lo que estamos tratando de lograr, queremos que nuestros checks sean deterministas porque queremos saber exactamente que es lo que van a hacer, como lo van a hacer y qué significa cuando pasa, falla o detecta cambios. Queremos saber que cada vez que corra va a hacer exactamente los mismo.

Esto provee la confiabilidad en los tests. Dependiendo de la confiabilidad de estos checks/verificaciones vamos a agregar mas o menos pruebas al producto. Si los checks son confiables y las pruebas pasan, no vamos a llevar a cabo pruebas extras, en cambio si los tests no son confiables, vamos a tener que revisar en forma manual la aplicación bajo pruebas para ganar la tranquilidad que nos debería haber dado las pruebas automatizadas.

Así cerramos las notas.

Qué te parecen los conceptos? estas de acuerdo? Deja tu comentario!


Te gustó el post? Quieres contribuir?
Contribute with the Blog

 

Anuncios

2 Comentarios Agrega el tuyo

  1. Oscar dice:

    Gracias por tu articulo. Me gustaria que me compartas el contenido de la charla que mencionas. Gracias.

    Me gusta

    1. Con Mucho gusto! Respondido por privado.

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s