Una cualidad muy importante en un tester, más importante cuanto más testing funcional y pruebas de aceptación haga, es la capacidad de “meterse en el papel” del usuario que finalmente va a usar el software que se esté probando. Cuando estás probando un programa, el que sea, necesitas obligatoriamente ponerte en el papel del usuario final que va a usar esa aplicación. Y es aquí cuando creo que muchos de los principios del método Stanislavski son aplicables a las pruebas de software.
Principios del Sistema Stanislavski
- Concentración: Responder a la imaginación aprendiendo a pensar como el “personaje” que estamos interpretando.
- Sentido de verdad: Diferenciar entre lo orgánico y lo artificial. Stanislavski creía que existen leyes naturales de la actuación que se deben seguir.
- Circunstancias dadas: Desarrollando la habilidad de usar las habilidades anteriores para crear el mundo del libreto (circunstancias dadas en el texto) por medio de verdad y medios orgánicos.
- Relajación: Eliminación de la tensión física y relajación de los músculos mientras se hacen las presentaciones.
- Trabajar con los sentidos: Descubrir la base sensorial del trabajo; aprender a memorizar y recordar sensaciones, comúnmente llamada “memoria sensorial” y/o “memoria afectiva”; aprendiendo a trabajar desde pequeñas sensaciones, expandiéndola, técnica llamada por Stanislavski “esferas de atención”.
- Comunicación y Contacto: Sin violar el contenido del libreto desarrollar la habilidad de interactuar con otros personajes espontáneamente.
- Unidades y Objetivos: Aprender a dividir el papel o rol en unidades sensibles que puedan ser trabajadas individualmente. Desarrollar la habilidad de definir cada unidad del rol, por un deseo activo de objetivos, en lugar de una mera idea literaria.
- Estado mental creativo: Es una culminación automática de todos los pasos previos.
- Trabajar con el texto del libreto: Desarrollando la habilidad de descubrir el sentido social, político y artístico del texto, y viendo que esas ideas están contenidas en la actuación.
- Lógica y credibilidad: Descubrir cómo es verdadero que la suma de objetivos combinados son consistentes y coherentes, y que ellos se encuentran en línea con el libreto como un todo.
Principios del Sistema Stanislavski aplicados a las pruebas de software
- Concentración: Es bastante claro que probar software requiere un alto grado de concentración. Cuanto más concentración, mejores serán nuestras pruebas. De ahí la necesidad de aislarnos, en la mayoría de los casos, escuchando música mientras realizamos las pruebas.
- Sentido de verdad: Debemos tener un sentido de la verdad que nos permita diferenciar entre lo que necesita el usuario, lo que hay en los requisitos, o lo que ha pedido el cliente, y lo que quienes se han encargado de codificar el programa han entendido que debía hacerse. Debemos tener claro cuál debe ser el resultado y no permitir que nos convenzan de otras cosas.
- Circunstancias dadas: Dicho lo anterior, también debemos ser capaces de poner esa ‘verdad’ en su contexto, y entender que las circunstancias pueden modificar en cierta manera el resultado, pero siempre respetando el resultado final buscado. Se pueden dejar cosas para una fase 2 si todas las partes están de acuerdo, pero no debemos permitir que se cambie lo que el software debe hacer, y lo que no debe hacer.
- Relajación: Algo clarísimo, pero mayormente olvidado. Cuanto más relajados estemos, más errores encontraremos y mejor probaremos. Debemos trabajar concentrados, pero relajados. Que el software que debe certificarse mañana, o ponerse mañana en producción, se vaya a entregar al equipo de pruebas en algún momento del día, seguramente más allá de las seis de la tarde, no ayuda a esa relajación. Las prisas sólo generan tensión y malos resultados.
- Trabajar con los sentidos: Otro principio que debemos tener presente el 100% de nuestro tiempo de trabajo. Debemos memorizar ciertos datos, sobre tamaños, incompatibilidades, reglas de negocio, etc. Debemos además estar atentos a la información que circula en nuestro entorno de trabajo, pues en ocasiones ciertos datos importantes circulan a nuestro alrededor, sin ser plasmados oficialmente en documentos. Debemos estar atentos a estas informaciones, pues a veces son la diferencia entre unas pruebas de éxito o no. El haber detectado un error importante, por un cambio de última hora en la legislación, por ejemplo, que nadie ha plasmado aún en un requisito, puede ser la diferencia entre un éxito y un desastre.
- Comunicación y Contacto: “Desarrollar la habilidad de interactuar con otros personajes espontáneamente” dice Stanislavski. Está claro que debemos comunicarnos mucho y muy bien con los que nos rodean (en muchos casos, con mucha “mano izquierda”). Probablemente los testers somos quienes hablamos con más gente de distintos equipos: Otros desarrolladores, a quienes comunicamos bugs, o con quienes discutimos sobre comportamientos correctos o no; Personas de negocio que nostransmiten comportameintos correctos, requerimientos, preocupaciones…; Compañeros de sistemas, que en muchos casos se encuentran en producción con problemas que nos hemos encontrado antes en los entornos de prueba, etc. Mucha comunicación, que requiere paciencia y mucho tacto.
- Unidades y Objetivos: En el caso de las pruebas de software, debemos aprender a dividir nuestro trabajo en “unidades sensibles que puedan ser trabajadas individualmente”. Tenemos que dividir las tareas en otras más pequeñas, y después abordar primero las más importantes, intentando probar más y mejor las partes más sensibles, por importantes, de nuestro software. En muchos casos debemos aplicar técnicas de pruebas basadas en el riesgo, intentando reducir este al mínimo.
- Estado mental creativo: Buscar comportamientos no deseados y errores en un programa, o conjunto de programas, claramente requiere un estado mental creativo. Hay que pensar caminos alternativos, poner el software en situaciones límite, pensar soluciones a problemas que surgen durante las pruebas… En resumen, estado mental creativo 100% del tiempo.
- Trabajar con el texto del libreto: Idealmente aplicacaría este principio a trabajar con requisitos, planes de prueba, casos de prueba documentados y, en general, toda aquella documentación que esté disponible sobre lo que estamos probando. Debemos empaparnos de documentación, y documentar nosotros mismos, de esta manera nuestras pruebas serán más robustas, y cualquier en el equipo podrá colaborar con nosotros en cualquier momento.
- Lógica y credibilidad: Están al final, pero son 2 principios básicos para el testing. La lógica será nuestra aliada a la hora de encontrar errores en el software, aunque en ocasiones encontraremos comportamientos correctos, y totalmente ilógicos. Nos tocará hablar con product owners y stakeholders, para ver si hay que cambiar el requisito, o este está mal. El último principio, pero probablemente el más importante, es la credibilidad. Si reportamos 20 errores, pero los encargados de resolver esos errores no nos creen, de nada servirá nuesto trabajo, y probablemente esos errores ni se mirarán. Debemos ser metódicos y tratar siempre de reproducir los bugs, incluir los pasos para reproducirlo, dar toda la información que podamos, y estar seguros. Si no tenemos algo claro, o hay un comportamiento raro no reproducible, indicar claramente que no es reproducible, y tratar de verlo siempre en persona con el encargado de resolver el problema. Si no somos creíbles, nuestro esfuerzo no sirve de nada.