Desde hace varios años venimos hablando de DevOps, una filosofía de trabajo (aunque muchos piensan que es una metodología o un proceso), que ha acelerado brutalmente la tasa de cambio que puede tener un software. Sorprendentemente, en España, estamos a años luz del resto del mundo y aunque hablamos de esta filosofía, muchas empresas no trabajan con ella de manera adecuada o lo confunden con poner en producción algo rápido y sin ninguna garantía.


Evidentemente, para paliar estas situaciones, la calidad debe de ser un pilar fundamental dentro de esta filosofía de trabajo y al aplicar entornos de entrega continua, debemos de tener en cuenta que el ciclo de producción es mucho más corto y tenemos claros unos objetivos inamovibles: desarrollar, probar y poner en producción.

Si la idea es correr mucho, teniendo un equipo de desarrollo modélico, con unas pruebas unitarias y de integración de diez, pero este gran desembolso de dinero se ve frustrado por que al poner en producción el producto, hay un fallo, nada de esto sirve y el dinero y esfuerzo invertido se vendrá abajo.

Si queremos poner algo en producción, es completamente imprescindible la realización de pruebas, y no solo unitarias, si no funcionales y no funcionales. Actualmente, lo que veo, es que incluso desde el mundo del Testing, nos estamos olvidando de las pruebas funcionales, obcecándonos en la realización de pruebas de integración (o unitarias), como las basadas en Gherkin y que, personalmente, os digo, no cubren todo lo que se debe de cubrir, y nos veremos con sorpresas desagradables en producción.

El ciclo completo de pruebas debe de ser completo, teniendo pruebas unitarias, de integración, manuales funcionales y automáticas (basadas en las manuales), sin contar con las no funcionales que nos darán buena cuenta de la seguridad y del rendimiento (entre otras muchas cosas) de lo que estemos probando. No nos olvidemos de que, aunque molan mucho y es más divertido el automatizar todo y solo centrarnos en ello, hay un amplio abanico más de pruebas que se deben de realizar y cubrir.

En un entorno de entrega continua, no nos podemos olvidar de la realización de pruebas en el API, además de todas las mencionadas anteriormente.

El perfil de la persona de QA no solo debe destacar por la realización de las pruebas realizadas, si no que debe de brillar a la hora de evaluar criterios de aceptación, definir estrategias de pruebas o cubrir todas las casuísticas posibles a lo largo del entregable. Esto, unido a los perfiles de desarrollo, harán que se forme una mentalidad de Cultura de Calidad temprana, que será lo que nos permitirá producir de manera segura, garantizada y adecuada.

Dentro de un ciclo de DevOps, debemos de descartar el uso de pruebas manuales al completo, ya que es imposible cubrir la velocidad requerida a lo largo de cada entrega, por lo tanto, si que debe de ser un acompañamiento de cara a la realización de pruebas exploratorias, pero se debe de compatibilizar con baterías automatizadas que puedan utilizarse en dispositivos móviles y en ordenadores.

Es importante, tener claro, que la idea de DevOps no se convierta en un entregar rápido y corriendo sin tener la garantía y la calidad que nuestros clientes nos demandan. Como todos sabemos, el boca a boca positivo es el éxito asegurado y eso se consigue con unos clientes satisfechos y que puedan utilizar nuestro producto de la manera adecuada.