Sesgos Cognitivos, Desarrollo y Pruebas de Software

*Este es un articulo exploratorio, ante la falta, aún de estudios en el tema, considérese esto como un aporte personal y reflexiones bajo la experiencia de quien lo escribe.

Un sesgo cognitivo es un fenómeno natural que se presenta e interviene en la forma en que interpretamos la realidad, comúnmente se atribuye a esta interpretación características negativas o al menos erróneas, como un fallo de interpretación que deriva a su vez en una forma de actuar errada.

En el presente mini-artículo, escindiré a los sesgos de esta atribución como fenómeno de lo equivoco y me concentraré en sus características fenomenológicas con respecto a las pruebas de software presentándolos como una característica humana cuyos efectos adversos pueden ser trabajados con la experiencia.

Existe un numero bastante interesante (y que parece ir cada año en mayor crecimiento) de sesgos cognitivos estudiados por las ciencias de la mente y sociales que se presentan en nuestro ámbito laboral (me refiero a los procesos de calidad en la industria del software); entre algunos de los más interesantes para nuestro caso podemos encontrar los siguientes:

Generalización: Como lo indica su nombre este sesgo se suele presentar cuando basándonos en un incidente aislado lo generalizamos como una realidad mucho más amplia… “no falló la prueba end to end, no fallará ninguna otra”

Post hoc, ergo propter hoc (después de esto, luego a consecuencia de esto): Posiblemente uno de los más comunes de encontrar en los procesos de pruebas y debugging; trata sobre suponer como lógica común (y verdad) que si un hecho ocurre luego de otro, el segundo siempre es consecuencia del primero. En términos de pruebas, esto implica principalmente buscar la solución a un problema de manera inicial en la supuesta causa, es decir en la acción que precede al error.

“algunas veces cuando envío este formulario con cierto mail, ocurre un error no controlado”

Lo lógico es reportar un bug para que se revise el formulario y el método de envió. El desarrollador realiza ajustes, tal vez restricciones de caracteres, etc. Pero el error continúa. En una revisión más exhaustiva (por tanto más costosa) se han percatado que el error se originaba en el campo mail de la base de datos, debido a un mal diseño de la misma este campo solo permitía 10 caracteres, por el contrario, en el formulario del front este campo permitía 20 caracteres. Si bien, se podría establecer una lógica lineal causa-efecto, nótese como el error podría presentarse también en otros usos de la BD, por ejemplo si en otra parte del flujo se requiere actualizar el mail. Por tanto, el problema existe en un ámbito independiente del formulario reportado inicialmente; se podría limitar el campo del mail a 10 caracteres, pero aquello solo solucionaría ese problema particular y no la raíz del mismo.

El tercer sesgo que quisiera mencionar y en el cual me gustaría enfocarme es el “Sesgo de Confirmación”: Esto es una tendencia con la cual buscamos confirmar nuestras propias creencias, tendencias, información previa o hipótesis sobre un tema equis dejando de lado información que va en contra de lo anterior. En lo que respecta a lo psicológico de esta tendencia podríamos encontrar factores como; un intento de disminuir los niveles de ansiedad que provoca confrontar información divergente con nuestras propias ideas, también puede tratarse de un patrón presente en personalidades con rasgos ególatras. Pero no se mal entienda; el sesgo de confirmación está presente en todos nosotros, así como las características antes mencionadas se encuentran en uno u otro grado en cada ser humano.

¿Cómo se manifiesta el sesgo de confirmación en las pruebas de software?

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 espera, el -cómo- lo dictará la técnica propia. Lo relevante aquí es que el dev ya ha generado una idea de lo que se debe hacer y de cómo debe hacerlo, esto podríamos definirlo como el happy path del desarrollo.

En el desarrollo de esta labor intervienen algunos factores psicológicos relevantes como un grado de estrés (véase el punto1 ), 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 allegá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 implica aceptar que se han pasado por alto cosas que creíamos cubiertas.

Dado lo anterior, nuestra construcción de pruebas iniciará validando aquello que sabemos que funciona y por lo general, los casos bordes serán aquellos que no escapan en gran medida de nuestro propio happy path, esta pareciera ser una tendencia común que probablemente deba ser analizada con estudios más certeros que la simple apreciación que acá hago en base a la experiencia. A razón de ello, es que en las atapas posteriores de calidad y pruebas surgen bugs o detalles que podrían haberse detectado en una revisión anterior. Para evitar esta tendencia es que se crearon (en parte) algunas técnicas como el pair programming y la revisión entre pares, aunque en la práctica resultan ser un mecanismo de revisión de código (prueba estática si se quiere) más que de la funcionalidad misma y sus posibles resultados de uso (prueba dinámica, si se quiere).

En el ámbito de las pruebas (etapa de QA, nombre más que discutible  ) el sesgo de confirmación también afecta 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.

Para evitar esto se han desarrollado algunas técnicas que comprometen el desarrollo completo de una aplicación, como la creación de perfiles de usuarios; ej. Usuario 1 – señora juanita de 60 años no nativa tecnológicamente.

En cuyo caso, el equipo de ux, desarrollo y QA deberían considerar ese perfil tanto para la creación de la solución como para las pruebas, sin embargo, esta técnica requiere un alto nivel de conocimiento del equipo y como es de esperarse, perfiles con un nivel de empatía, lo que implica a su vez un trabajo constante en habilidades blandas ¿de qué sirve crear perfiles si el equipo no puede empatizar con el mismo? Tanto el desarrollo como las pruebas se ven y se verían afectadas por mi propia concepción de la idea de quien es la señora juanita y de cómo se comportan frente a una aplicación los adultos de 60 años. Y este es precisamente uno de los desafíos más grandes.

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.