En el ámbito del desarrollo, un Dev se enfoca en la construcción de una pieza de software bajo ciertas especificaciones y/o criterios definidos –sabe lo que se espera de la funcionalidad– esto estará además, sustentado en algún diagrama, mapa u otro medio que dará una guía de lo que se espera (esto sería lo ideal, pero la realidad indica que muchas veces solo se cuenta con la idea de lo que se debe realizar). Todo esto ayuda a construir una imagen mental de lo que se desea como producto, el –¿cómo?– lo dictará la técnica propia. Lo relevante aquí, es que el Dev, con el conocimiento que logra adquirir sobre el producto que debe desarrollar ya ha generado una idea de lo que se debe hacer y de cómo debe o puede hacerlo, esto podríamos definirlo como el happy path del desarrollo.
En el flujo de esta labor intervienen algunos factores psicológicos relevantes de mención; uno de ellos es cierto grado de estrés (véase el punto 1 ), ansiedad, autopercepción de las capacidades técnicas, personales, entre otras emociones presentes en el acto propio de realizar un trabajo. Es importante mencionar la emocionalidad, pues el sesgo de confirmación se hace presente en mayor medida cuando factores emotivos están involucrados, y como mencionan algunos autores como Lazarus y Folkman (1986) es imposible escindir el factor emotivo de las expectativas de realizar una determinada acción o labor, pues cuando realizamos un trabajo (por ejemplo) esperamos que el resultado sea acorde a nuestra propia autopercepción de lo que creemos saber al respecto.
En palabras simples y acercándonos más al ejemplo del Dev, esperaremos que nuestra función trabaje de buena forma y según lo esperado porque este resultado nos ayuda a confirmar nuestra propia creencia respecto a nuestras capacidades, confirmar o buscar un comportamiento errado, aumentaría los niveles de estrés, ansiedad y, en cierta medida, podría incluso disminuir nuestro bienestar psicológico… Después de todo, encontrar fracturas o bugs en nuestros desarrollos o pruebas implica aceptar que se han pasado por alto cosas que creíamos cubiertas, y esto es normal, somos humanos.
Dado lo anterior, en el caso de los testers, y al igual como ocurre con el mencionado Happy path del Dev. Nuestra construcción de pruebas iniciará validando aquello que sabemos que funciona o se esperaría que lo hiciera y por lo general, los casos bordes serán aquellos que no escapan en gran medida de nuestro propio happy path mental de QA (ej cosas que sabemos que suelen fallar), y es que cuando construimos pruebas las hacemos en base a nuestras experiencias previas, nuestra construcción mental de cómo debe funcionar el producto, muy probablemente guiados además, por alguna declaración de reglas de negocio o criterios de aceptación que ya tienen sus propios sesgos. En resumen, la calidad de las pruebas dependerá en gran medida de una capacidad crítica sobre lo conocido y las expectativas del producto, el sesgo de confirmación, buscará por otro lado satisfacer el problema solo con lo necesario para evitar las contradicciones mentales sobre el posible vacío de información.
El sesgo de confirmación afecta también en gran medida a la construcción de los planes de pruebas, incluso en la definición de los pasos de estas. Inicialmente porque estamos empapados de toda la información que tenemos previamente de la aplicación o funcionalidad, si trabajamos con scrum ya tendremos consciencia del happy path por los diversos refinamientos y reuniones técnicas, los criterios de aceptación de las historias de usuario, reglas de negocio etc. Y no me refiero a que esto sea negativo, por el contrario ¿Cómo podríamos certificar la funcionalidad sin saber exactamente que hace y cómo? Sin embargo, esta información tan vital para nuestras certificaciones también nos ciega respecto a otros factores, pues a final de cuentas construimos pruebas que buscan certificar lo que conocemos, inclusive probamos y definimos los pasos según nuestro estilo de navegar en la web, nuestros tiempos y formas de completar datos, etc… Dado que la prueba, incluso la automatizada no es más que el reflejo del estilo y las formas que tiene el ingeniero de QA (o de pruebas, el nombre es indiferente) no puede abstraerse de la propia persona que la crea, la ejecuta y/o la programa, por consiguiente la prueba existe también con el sesgo de su creador.
Si bien, no podemos evitar del todo el sesgo confirmación (o cualquier otro), si podemos trabajar para disminuir sus efectos en nuestro día a día, a continuación, algunas técnicas que pueden ser útiles.
Pruebas con arquetipos de usuario: En pruebas, crear un arquetipo de usuario es construir un cliente/usuario imaginario que actúa de cierta forma, ej: Arquetipo 1: Señora Luisa, de 65 años, no es nativa digital, generalmente requiere ayuda para realizar trámites por internet. Arquetipo 2: Pedro, 25 años, nativo digital, se conecta al sistema desde diversos dispositivos, prefiere la rapidez, pocas veces lee rápidamente las descripciones de los campos y completa todo muy rápido.
En este simple ejemplo, nos plantea diversas posibilidades de pruebas para abarcar los posibles usos de una APP, con el arquetipo 1 podrías generar pruebas para validar cómo interactúan las opciones de accesibilidad, por su parte desde la perspectiva del arquetipo 2, se podrían priorizar pruebas de adaptabilidad en dispositivos, velocidad de respuesta, llenado de campos en diferentes órdenes, etc.
Pruebas exploratorias o Ad Hoc: Este tipo de pruebas nos ponemos en la posición (real o deliberada) de un usuario que no tiene información sobre cómo se utiliza el software, uno de los objetivos es descubrir las funcionalidades del producto precisamente mediante la utilización experimental. En este tipo de pruebas se suelen utilizar preguntas inusuales del tipo ¿Qué pasa si completo el formulario en un orden inverso? ¿y si refresco la página en la pantalla de carga?
Aprendizaje continuo: Una buena técnica es llevar un registro de detalles o bugs encontrados en etapas posteriores a las pruebas, esto te permitirá analizar lo que se ha pasado por alto, si es abordable y proponerte mejorar en aquello que sea necesario para la siguiente iteración.
“El primer paso para evitar que los sesgos cognitivos nos lleven por el mal camino es admitir que los tenemos, que todos los tenemos. Incluso el experto más inteligente no es inmune a los sesgos cognitivos.” – Daniel Kahneman, Psicólogo y Economista, premio Nobel de economía.
(1) El estrés es una respuesta fisiológica normal del organismo que emerge como respuesta a alguna demanda física o psicológica (permítanme la distinción a modo de ejemplo) del ambiente y que nos permite movilizar recursos internos para su resolución (Ávila, 2014). En sus niveles normales, el estrés nos permite ser eficaces.
Ávila Jacquline. (2014), El estrés un problema de salud del mundo actual. Revista CON-CIENCIA, 2(1), 117-125.
Lazarus RS, Folkman S. (1986), Estrés y Procesos Cognitivos. (Stress and Cognition) Barcelona: Martínez Roca.