¿La prueba manual de software es necesaria? ¿Es suficiente? ¿Y la prueba automatizada?
Es tentador pensar que si estudiamos el problema (prueba de software) lo suficiente y somos buenos profesionales, podremos encontrar “la mejor manera” de hacerlo. Si conocemos “la mejor manera”, los que realizan la prueba de otra manera están equivocados.
Alguna vez pensé conocer cual era “la mejor manera”. Luego, aprendí o cambié de contexto, y “la mejor manera” cambió.
A partir de estas experiencias soy algo escéptico cada vez que escucho (de otros, o de mí!) afirmaciones en este sentido. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en que contexto está siendo usada?
Voy a comentar mi experiencia personal con diferentes formas y contextos de prueba. En cada contexto, analizaré los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en Ágiles 2010 – Lima.
No trato el problema más general de la calidad de software, sino solamente sobre la prueba.
El modelo
La comparación de los contextos está organizada utilizando el modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory, a su vez basado en las propuestas Mike Cohn y Brian Marick. En este modelo, tenemos 4 tipos de prueba (de arriba hacia abajo):
Pruebas Manuales
Pruebas de Interfase Usuaria (automatizada)
Pruebas de Aceptación o API (automatizada)
Pruebas técnicas o unitarias y de componentes (automatizada)
El costo de ejecución es menor en las Pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de Interfase Usuaria. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.
La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.
Contexto: Prueba Ad hoc
Durante los primeros 10 años de mi carrera, trabajé en grupos de 5 personas o menos, trabajando en desarrollo de software en áreas tan variadas como aplicaciones administrativas (ERP), adquisición y procesamiento de imágenes médicas (de medicina nuclear), y sitios de Internet que brindan información bursátil en tiempo real.
En estos equipos, no había separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles, probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.
Al no haber responsables definidos la prueba solía quedar huérfana, sin mejora. En este contexto es un problema realizar pruebas de regresión, una tarea poco atractiva y compleja.
La evolución de este contexto suele ser incorporar un tester o área de testing para Prueba Manual (camino tradicional) o que los programadores empiecen a desarrollar Pruebas Técnicas o incluso TDD (camino del desarrollo ágil).
Cualquier camino de evolución pasar por un cambio cultural, ya que en estos grupos la prueba no suele ser valorada lo suficiente. Se suele escuchar “si los programadores hacen bien su trabajo, ¿por qué senecesitaría probar?”
Los problemas se hacen más notorios cuando el grupo debe crecer, tiene mucha rotación o debe mantener muchos productos.
Caso: en una importante compañía de fondos de pensión y seguros de retiro pidieron presupuesto para mantenimiento de muchas aplicaciones existentes (legacy: sin pruebas automatizadas). El cliente no aceptó una propuesta de equipo con cuatro personas, en la que una cumplía el rol de tester; sin embargo, aceptó un equipo de 4 personas con 3 programadores. Internamente el equipo se manejó con uno de los 'programadores' actuando como tester, con buenos resultados.
Motto: ¡No vale la pena probar!
Problemas: baja calidad, baja previsibilidad, regresiones
Cobertura: no hay métricas.
Responsable: todos y ninguno. Pruebas por el usuario.
Organización: generalmente chicas y con poca estructura
Contexto: Prueba Manual
En mi siguiente reencarnación, estuve 8 años en una compañía que trataba de convencer y ayudar a empresas de contexto Ad hoc a que la prueba es algo útil y necesario.
Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de la persona en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.
El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran 
quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), y por el recambio hay mayoría de novatos en los roles de prueba. Los que se mantienen en el rol suelen ser personas con poca inclinación a lo técnico. Para crecer profesionalmente, los testers se dedican a tareas de QA (procesos) o de Analistas de negocio, que son más valoradas en el mercado.
En este contexto, los problemas son que la prueba de regresión de productos medianos y grandes se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para ejecutar pocas veces las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).
La salida parece ser la automatización, pero lamentablemente no es una salida fácil, ya que las personas que están en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.
En algunos casos se pasa a Prueba Manual Optimizada.
Motto: ¡No vale la pena automatizar las pruebas!
Problemas: costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases
Cobertura: requerimientos, casos de uso
Responsable: Testers / QA.
Organización: testing separado
Prácticas: casos de prueba manuales, checklist
Contexto: Prueba Manual Optimizada
Luego de 6 años en Prueba Manual, reencarné en Prueba Manual Optimizada. Algo bueno habré hecho en mi vida anterior, porque un cliente exigió en un proyecto que automaticemos.
¿Por qué automatizar? Por criticidad del negocio o cuando se logra volumen suficiente en el área de prueba como para justificar la inversión.
¿Cómo hacerlo? Se suele incorporando programadores al grupo de prueba con el rol de Automatizadores de la Prueba.
Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten hacer pruebas de regresión en forma rápida, lo que permite mejorar la calidad, confianza y tiempo de respuesta. Pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Ysi sumamos el hecho que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.
Es una situación extraña, ya que en muchos casos nos damos cuenta que podríamos ser mucho más eficiente si algunas pruebas fueran de caja blanca y las hicieran los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto. Pero no podemos influir en la forma en que se programa, es otro grupo.
Esta tensión puede resolverse cuando los grupos de programación y prueba empiezan a trabajar juntos y se pasa al contexto Técnico++ o al Nirvana.
Motto: No podemos mejorar la producción del código.
Problemas: mantenimiento de las pruebas
Cobertura: requerimientos, riesgos
Responsable: Testers, Testers automatizadores, QA.
Organización: organizaciones grandes, grupos de homologación separado
Prácticas: pruebas automatizadas de interfase de usuario
Contexto: Prueba Técnicas
Algunos equipos en los que trabajé (entre 2 y 40 desarrolladores) tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de Integración Continua, TDD y Pair programming incorporadas.
En estos equipos la calidad es alta comparada con los contextos de Prueba Manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son: mantener el tiempo total de ejecución de las pruebas bajo (<10 min)
La evolución natural es hacia Pruebas Técnicas++, ya que en este contexto ante los problemas la primera solución que se piensa es agregar pruebas automatizadas.
Caso: en un proyecto Ruby on Rails comenzamos con una funcionalidad de CMS sencillo para seguir luego con funcionalidad más compleja. Se trabajaba con coberturas de código por arriba del 80%. A los dos meses del proyecto, el usuario vuelve a utilizar la funcionalidad de CMS sólo para encontrarla rota, debido a un cambio en las vistas que pasó desapercibida por mucho tiempo. El análisis del problema llevó al equipo a agregar pruebas automatizadas con Cucumber y Selenium (API y UI).
Motto: Sólo vale la pena las pruebas automatizadas
Problemas: usabilidad, cumplimiento de requerimientos y regresiones en cuanto a requerimientos
Cobertura: líneas de código
Responsable: programador
Organización: equipo de programadores
Prácticas: TDD, CI
Contexto: Prueba Técnicas++
Los equipos en este contexto vienen de la Prueba Técnica, agregando prueba de APIs y quizás de UI, o de la Prueba Manual Optimizada, agregando prueba unitaria y quizás de API. En ambos casos, tienen des-balanceada la pirámide de prueba. En el caso de los que vienen desde Prueba Manual Optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).
Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización (¡ningún programador las quiere hacer!) y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional y de robustez, pero que no son sobresalientes, ya que no se detectaron puntos a mejorar en forma temprana.
Motto: Sólo vale la pena las pruebas en automatizadas
Problemas: usabilidad, cumplimiento de requerimientos
Cobertura: líneas de código y requerimientos
Responsable: usuario y programador
Organización: equipo de programadores
Prácticas: ATDD, BDD, TDD, CI
Contexto: Nirvana
Aunque no he llegado aún al Nirvana. Pero estoy atento a los reporte de gente que estuvo, como Lisa Crispin.
Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, la organización, el producto y nuevos desarrollos de prácticas en el equipo y la comunidad. Se preocupan por la cadena de valor completa.
Motto: Optimizamos el todo
Problemas: buscar el balance óptimo
Cobertura: líneas de código y requerimientos, riesgos
Responsable: equipo completo (whole team)
Organización: Lean
Prácticas: ATDD, BDD, TDD, CI
Re-visitando
Las descripciones dadas en cada contexto plantean la visión que tenía de lo 'correcto' cuando estuve en ellos, aunque algunas cosas me hacían ruido. Mirando ahora hacia atrás, tengo una visión distinta, que comento a continuación.
Re-visitando: Nirvana
Hay quienes quieren ir más allá de las prácticas de XP.
Los usuarios se equivocan tanto como los desarrolladores, ¿podemos hacer algo para ayudarlos? Hace 5 años Sebastián Elbaum nos comentaba sobre las pruebas para los usuarios finales. Actualmente Excel indica (subraya) las fórmulas que considera “raras” y co posibles errores del usuario, como el caso de una columna con fórmulas que totalizan filas, excepto en una celda que tiene un valor (no una fórmula).
Soporte a la prueba exploratoria: Brian Marick nos comentaba el año pasado sobre experimentos que estaba haciendo para potenciar el mecanismo de UNDO de una aplicación, de manera de poder volver atrás en una prueba para tomar otro camino en la exploración de la misma.
Re-visitando: Ad hoc
¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido?
Caso: hace un año, poniendo en marcha nuestro primer evento usando Open Space (Agile Open Bs As 2009), teníamos que decidir como hacer la registración de los participantes. Luego de evaluar un par de alternativas, incluyendo desarrollar, decidimos realizar la registración utilizando la funcionalidad de Formularios que brinda Google Docs. Una de las personas se quejó del formulario de registración, la pregunta “¿Le interesaría un evento de dos días?”, tenía sólo alternativas de dos días (dos días de semana, viernes y sábado, sábado y domingo) y era obligatoria. Hasta ahí, entendible. Pero la sugerencia que nos hacia era que deberíamos tener pruebas automatizadas. Probablemente esta persona se imaginaba que eramos un equipo de desarrollo en el contexto de Prueba Manual o Ad hoc, y nos sugería que deberíamos estar en Prueba Manual Optimizada o Técnica. ¡Pero la realidad fue que una sola persona configuró el formulario en media hora! Y el problema no tenía que ver con funcionalidad implementada, sino con la semántica del texto y la consistencia del mismo con el tipo de control utilizando. Este problema semántico pasó desapercibido por los revisores. Automatizar la prueba del formulario no hubiera encontrado el problema, y hubiera sido más costosa que el 'desarrollo'.
En algunas situaciones, la prueba Ad hoc podría ser lo mejor: desarrollo de sitios sencillos usando CMS, creando contenido y configuración.
Re-visitando: Prueba Manual
¿Podemos siempre tener un equipo integrado? ¿Podemos siempre confiar en el equipo?
Homologación de plataformas: cuando debemos proteger una plataforma, como en el caso de Microsoft, Apple o el entorno de producción de un banco, nos interesa validar algunos puntos mínimos, y simplemente no podemos confiar en que el equipo que realizó el producto (en muchos casos un tercero), haya realizado bien su trabajo. Pero por otro lado, aunque automaticemos algunas partes de la prueba (preparación de ambientes, comparaciones de antes y después), hay una buena parte de la prueba que es exploratoria, y que no tiene mucho sentido automatizar, ya que es de única vez.
Alto riesgo: aunque podamos ser un sólo equipo, cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar pruebas manuales para lograr independencia (dos grupos, con dos técnicas distintas)
Productos que no controlamos, open source o no: cuando construimos sobre otros productos, la ecuación que justifica las pruebas automáticas nos juega una trampa, si el dueño del producto decide cambiar la aplicación, él solo evalúa sus costos, pero puede romper nuestras pruebas automáticas. (ej. en los que trabajé: Outlook y Liferay)
En algunas situaciones, la Prueba Manual podría ser lo mejor, buscando el mejor punto en el continuo que hay entre prueba manual totalmente definida y la prueba exploratoria. También debe considerarse tener ayudas automatizadas.
Re-visitando: Prueba Manual Optimizada
Cuando el producto no es sólo software, puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual.
Algunos casos de esta situación podrían ser
CMS complejos, en los que no sólo se desarrolla contenido, sino también extensiones o aplicaciones.
Productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales
Soluciones que incluyan procesos: probar que los procesos se realicen correctamente (por ejemplo que las personas estén entrenadas y sepan qué hacer) es algo que debe probarse con las mismas personas.
Re-visitando: Prueba Técnica/ Técnica++
No encontré situaciones en las que convenga quedarse en estos contextos, siempre me parecieron pasos hacia el Nirvana. ¡Pero creo que es sólo cuestión de tiempo!
Conclusiones
Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas.
Por otro lado, he escrito críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes, ya que se interpretan como un ataque a las técnicas de automatización de la prueba.
Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tu que opinas?
