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.
0 Comentarios