La psicología de las pruebas (K2 - entender, explicar , razonar)

Objetivos:

1. Retener los factores psicológicos que influyen en el éxito de las pruebas (K1).
2. Constatar la mentalidad de un probador y la de un desarrollador (K2).

Términos usados en este artículo: PREDICCIÓN DE ERROR, INDEPENDENCIA.

Antecedentes.

La actitud que debe adoptarse durante la realización de las pruebas y la revisión difiere de la actitud que requiere el desarrollo del software. Si mantienen la actitud correcta, los desarrolladores pueden probar sus propios códigos. Sin embargo, normalmente esta responsabilidad se transfiere a un probador independiente con vistas a contribuir a centralizar los esfuerzos y obtener mayores beneficios, tales como una visión independiente de recursos formados y profesionales del ámbito de las pruebas. Las pruebas independientes pueden llevarse a cabo en cualquier nivel del proceso de pruebas.

 Su determinado nivel de independencia a menudo hace del probador la figura más efectiva a la hora de detectar defectos y fallos. No obstante, la independencia no constituye un sustituto del conocimiento, y los desarrolladores también pueden detectar muchos defectos y fallos. No obstante, la independencia no constituye un sustituto del conocimiento, y los desarrolladores también pueden detectar muchos defectos en su propio código de manera eficiente. Pueden establecerse varios niveles de independencia según se muestra a continuación de menor a mayor:

• Pruebas diseñadas por las mismas personas que escribieron el software probado (bajo nivel de independencia).
• Pruebas diseñadas por terceros (por ejempo, por miembros del equipo de desarrollo).
• Pruebas diseñadas por una persona procedente de otro grupo de organización (por ejemplo, un equipo de pruebas independiente) o especialista de pruebas (por ejemplo, especialista en pruebas de usabilidad o rendimiento).
• Pruebas diseñadas por personas de otra organización o empresa (es decir, externalización o certificación por parte de un organismo externo). 

Las personas y los proyectos se mueven por objetivos. Las personas tienden a ajustar sus planes a los objetivos establecidos por la dirección y demás personas interesadas, por ejemplo, para detectar errores o para confirmar que el software cumple sus objetivos. Por lo tanto es importante establecer claramente cuáles son los objetivos de las pruebas.

Identificar fallos durante las pruebas puede percibirse como criticas contra el producto y contra el autor. En consecuencia, el proceso de pruebas a menudo se considera una actividad destructiva, a pesar de que es muy constructiva para la gestión de los riesgos del producto. La búsqueda de fallos en un sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención al detalle, buena comunicación con los compañeros de desarrollo y experiencia sobre la que basar la predicción de error. 

Para evitar malos entendidos al momento de reportar un error, se debe contar con la mejor manera de comunicar los defectos o fallos. La idea es dar a conocer estos defectos o fallos de una manera constructiva para el equipo de desarrollo (analistas, diseñadores y desarrolladores). Esta es la actitud que se debe tener  a lo largo de las revisiones y pruebas.

El testeador y el líder de pruebas deben disponer de buenas aptitudes interpersonales para comunicar  información objetiva sobre los defecto, el progreso y los riesgos de una manera constructiva. EL autor del software o del documento puede aprovechar la información sobre defectos para mejorar sus propias habilidades. El hecho de localizar y corregir defectos durante el proceso de pruebas ahorrará tiempo y dinero en el futuro y reducirá riesgos.

 Los problemas de comunicación pueden surgir, en particular, si los probadores se ven así mismos como mensajeros de malas noticias sobre defectos. Esta no es la mejor actitud que se debe adoptar, se debe tener presente (todo el equipo de trabajo) que mientra más defectos (de negocio, funcionales, cosméticos, etc.) encuentran nuestros partner de Qa, más sólido es el código. 

Por esto es importante que tanto el equipo de Desarrollos como el equipo Qa deben estar comprometidos con las estrategias a utilizar para llevar a cabo el control del proyecto. Hay un dicho chileno que dice "una mano lava la otra" es así como debemos actuar , comunicarnos y sentirnos comprometidos con el trabajo que realizamos, sentirnos un sólo equipo. 

Algunos tips para mejorar la comunicación entre Desarrolladores y QA.

• Empezar juntos en lugar de enfrentados - recordar a todo el mundo el objetivo común de conseguir sistemas de mejor calidad.
• Comunicar los hallazgos del producto de una manera neutral y centrada en los hechos, sin criticar a las personas que lo crearon, por ejemplo, redactando informes de incidencias objetivos y revisando las conclusiones.
• Confirmar que la otra persona ha entendido lo que usted ha dicho y viceversa.