Y si, has leído bien. En la época de Docker, integración continua, devops…etc, etc…aún nos encontramos con sitios donde no existen entornos de pruebas estables y decentes, que aseguren la correcta ejecución de nuestras pruebas.
Con un entorno inestable, un tester, reporta falsos negativos o tambien positivos, reporta errores que al final no lo son, nos dificulta la tarea de acceder correctamente a ciertos módulos de la aplicación y sobre todo hará que nuestras tareas se ralenticen o tengamos que reprobar defectos que ocurren por la inestabilidad.Esto, sucede exactamente igual que si hablamos de automatización. En un entorno en ese estado, la batería de pruebas fallará y nos encontraremos con que no se ha realizado el despliegue en el ciclo de CI apropiado.
Una de las peores cosas que nos puede suceder (aparte de no poder acceder al entorno) es que nos encontremos con falsos negativos o falsos positivos. Un falso negativo es en realidad un defecto que no es defecto en sí, un defecto que sucede por la inestabilidad del entorno, por incoherencia de datos o porque un despliegue puede haber estropeado el entorno y nos frene totalmente la realización de pruebas. Un falso positivo, nos puede ocurrir cuando creemos que está OK y en realidad no es así, dándonos bastantes quebraderos de cabeza.
Otro de los problemas que nos encontramos con los falsos negativos o positivos, es que si llegamos a abrir esos defectos y luego no ocurren, tendremos un peloteo con nuestros compañeros de desarrollo y ambos, perderemos bastante tiempo.
Para optimizar y garantizar nuestro trabajo al 100% necesitamos lo siguiente:
- Un entorno lo más parecido al de producción posible.
- Datos “reales” o en su defecto muy similares a los que podamos encontrarnos en producción. Con la nueva ley de protección de datos, hay que ofuscarlos obligatoriamente.
- Una base de datos con las mismas características que la de producción.
- Que el entorno sea únicamente de testing, que no tenga interferencias de desarrollo de ningún tipo.
Muchas veces, puede ocurrir que un entorno inestable pueda reportarnos la pérdida de muchas horas de trabajo y por lo tanto, que el visto bueno de la versión a desplegar se retrase por la falta de validación o incoherencia en sus datos.
En muchos casos, el entorno de pruebas es también un entorno de desarrollo, cosa que jamás debería de suceder, ya que si por un casual, se integra algo incorrecto y es propagado a este entorno y se cae o deja de funcionar, las pruebas se verán puestas en riesgo, además de que se necesitará una validación continua de todas las pantallas ya que no sabremos exactamente qué es lo que se toca y lo que no. Esto, aunque parezca mentira, es el pan de cafa día de much@s compañer@s y no suele ser por gusto, si no que, sus empresas no son lo suficientemente maduras para aportarles procesos de QA adecuados y tienen que luchar a contracorriente, día tras día, para sacar su trabajo adelante.
Lo ideal, en un entorno de testing es tener versiones cerradas cada cierto tiempo y ciclos de CI con baterías de pruebas automáticas. Pongamos un ejemplo práctico:
Desarrollo termina una serie de tareas e integra en su entorno, ejecutando los test unitarios y de integración oportunos. Así constantemente, con varias de estas tareas hasta completar una historia de usuario. Testing, lanza su automatización y mientras, sigue realizando pruebas con su propia versión, en su propio entorno, de momento inalterable.
Una vez que la persona de testing da el OK a esa versión, esta se sube al siguiente entorno de certificación (si existe) o se despliega a Producción. La validación finaliza y se puede garantizar que esa versión en concreto está OK y es 100% funcional. Esta labor, se puede realizar de manera más tradicional en entornos en los que aún no existe devops o ciclos de CI y también en entornos con integración continua que manejen correctamente el versionado, a través de Jenkins o similar.
Así, una vez que testing ha dado el visto bueno, avisará al desarrollo para que despliegue esa nueva versión para poder probarla en el entorno de pruebas (o en su defecto, se desplegará automáticamente si los test están en verde). De esta manera, mientras tanto, desarrollo podrá seguir integrando sin problema en su entorno y sin interferir en los demás.
Trabajando con versiones cerradas y atómicas, hacemos que las subidas puedan estar mucho más controladas y podemos acotar las pruebas mucho más, sabiendo exactamente a que atacar y donde reforzar la validación.
Cuando estemos en un proyecto de cualquier tipo, siempre debemos de luchar por que tengamos nuestro propio entorno, así podemos asegurar, casi en su totalidad, una calidad realmente buena en el trabajo que realizamos y que los factores externos no estropeen nuestras pruebas.
0 Comentarios