06. Testing Funcional
Las pruebas funcionales se centran meramente en el aspecto funcional del software.
La primera pregunta que surge es: "¿El sistema tiene errores?". En otras palabras, se enfoca en qué tan bien funciona el software de acuerdo con las especificaciones del diseño, y si tiene bajo control todos los posibles incidentes. Las pruebas funcionales verifican las funciones principales, test input, las funciones del menú, la instalación y configuración en máquinas localizadas, etc.
Como se mencionó anteriormente, especialmente en las pruebas funcionales, es importante que los equipos sepan si efectivamente saben qué están probando, qué aspectos ya se han probado y cuáles faltan, y qué tan minuciosamente se prueban.
Desde nuestro punto de vista, hay tres maneras principales de hacer pruebas funcionales:
Ad-hoc
Ad-hoc equivale a solicitar a cualquier persona que "pruebe el sistema por un tiempo". Esto es típico de personas que conciben el testing como hacer clics al azar observando "cómo es" el software. No hay ningún elemento de control, es imposible de rastrear, y no hay manera de saber qué tan bien o mal va. Las pruebas son útiles para obtener información sobre la calidad, y Ad-hoc no nos brinda esa información, por lo que nunca recomendaríamos este enfoque de prueba.
Scripted Testing
En Scripted Testing (conocido también como pruebas guionadas), primero nos preguntamos: "¿Qué es lo que queremos probar?". Luego, se documenta y se ejecutan los tests de acuerdo con el guión de prueba, registrando lo que salió bien y lo que salió mal. El jugador estrella en este contexto es el "caso de prueba".
Las dos etapas, tanto la etapa de diseño como la etapa de ejecución, están separadas entre sí y podrían ser completadas por dos personas con diferentes habilidades. Un experto en negocios que tenga conocimientos en el diseño de casos de prueba, podría crear una hoja de cálculo (o herramienta) con todos los casos que le interese probar. Así, otra persona que quizás no tenga tanta experiencia podría tomar esa documentación y ejecutarla paso a paso, indicando los resultados de cada prueba. Para ello es ideal planificar, dejar un registro de todo lo que se hizo, organizar el equipo y analizar qué tan detalladamente se probó todo. Este método es adecuado para las pruebas de regresión, para transmitir el conocimiento de qué cosas se probaron a otra persona y para documentar el comportamiento esperado del sistema.
Testing exploratorio
Con el auge de las metodologías ágiles y el enfoque en la adaptación al cambio, los casos de prueba pierden relevancia. No siempre es aconsejable esperar a recibir documentos que indiquen qué probar y cuál es el resultado esperado para transmitir una idea de qué tan bien o mal funciona el sistema. Para ello, existe el enfoque de testing exploratorio, donde el objetivo es diseñar y ejecutar pruebas simultáneamente y, con esto, familiarizarnos y aprender más sobre el sistema. La atención se centra en encontrar incidentes y riesgos anticipadamente.
Además, es posible adaptarnos más fácilmente a los cambios dentro de la aplicación o del contexto. Debido a que las pruebas exploratorias eliminan la necesidad de mantener documentos de casos de prueba, permiten una mayor flexibilidad. Cada acción que tomamos se basa en el resultado que obtuvimos, decidiendo qué hacer (y diseñando la prueba) durante el proceso.
Pero ojo, este enfoque no es ad-hoc, ya que hay una metodología bien definida para seguir que nos permite organizar, monitorear, controlar y gestionar todo el proceso. El objetivo del testing exploratorio es mejorar de un ciclo a otro, en vez de ejecutar las mismas pruebas repetidamente en cada ciclo (puesto que es tedioso, propenso a errores y es mejor que simplemente ejecutar una validación automática).
Los casos de prueba comúnmente se informan en hojas de cálculo, o mejor, en herramientas específicas diseñadas para este propósito. Las alternativas más ágiles a los casos de prueba son las sesiones de prueba, checklists de revisión y los mapas mentales para registrar las ideas, en vez de tener una lista paso a paso de acciones para probar. En cualquiera de las estrategias, es fundamental tener una idea general del proyecto (casos de prueba, funcionalidades a probar, historias de usuario a cubrir, etc.), y tener claridad de cómo avanzar. Esto representa la cobertura obtenida. Por supuesto, es necesario priorizar según los niveles de importancia y riesgos, tanto para el negocio como para los usuarios de cada uno de los aspectos mencionados.
Para lograr la madurez de las pruebas y específicamente alcanzar el nivel de testing continuo, debe especificarse qué se está probando, cómo y qué tan bien. En Abstracta recomendamos ampliamente optar por el enfoque scripted testing o el testing exploratorio, y no el de pruebas ad-hoc.
