Psicologa en el proceso de Pruebas

El xito de las pruebas esta influenciado por factores psicolgicos, es importante tener
objetivos claros, un balance entre testear uno mismo y las pruebas las realice alguien
independiente, tener buenos canales de comunicacin.
La percepcin durante el ciclo de desarrollo del software es que el desarrollador construye y el
tester destruye, pero ambas actividades son constructivas, ya que si bien llevan a cabo distintos
caminos, al final, ambos buscan lograr la calidad del software.
La relacin entre el desarrollador y tester normalmente no es una tarea fcil debido a que:

Los Tester suelen sealar los problemas con el software. Son considerados siempre
como portadores malas noticias (Es como decirle a una madre que su beb es feo). Los
fallos durante las pruebas pueden ser percibidos como una crtica contra el producto y
en contra del autor.
Los desarrolladores tienden a pensar que su cdigo es impecable. Hay un afecto
emocional donde los desarrolladores no quieren encontrar defectos.
Los testers son percibidos como los culpables de retrasar el proyecto buscando fallas en
el sistema.

Por esto tenemos que aprender a lidiar con los defectos de forma constructiva:

Aceptar y esperar errores / defectos

Los errores son naturales hagamos un plan para ellos
Centrarse en el problema a resolver no en la bsqueda de los culpables
Aprender de los errores / defectos

Es importante que colaboren juntos: trabajar hacia una meta comn.

Para poder trabajar de la mejor manera como equipo los resultados se deben comunicar de
manera objetiva, no subjetiva. Si hay errores, defectos o fallos se comunican de una manera
constructiva, los malos sentimientos entre los testers y los analistas, diseadores y
desarrolladores se pueden evitar. Por lo general, el caso es que alguien se molesta con la otra
persona, especialmente cuando estn bajo presin de tiempo.
Sin embargo, hay varias maneras de mejorar la comunicacin y las relaciones entre los testers y
otros:
Comunicar los resultados en el producto de forma neutral, los hechos se centran de
manera que no se critique a la persona que lo cre, por ejemplo, escribir informes de
incidentes y hechos objetivos y resultados de la revisin.
Comenzar a colaborar en lugar de batallar (recordar que el objetivo comn de todos
es mejorar la calidad del sistema).
Tratar de entender cmo siente la otra persona y por qu reacciona como lo hace.
Confirmar que la otra persona ha entendido lo que ha dicho, y viceversa.

Ser corts y servicial, colaborativo con sus colegas.

El modo de pensar a ser usado mientras se prueba y revisa es diferente al usado mientras se analiza o
desarrolla.
La separacin de esta responsabilidad hacia un probador es realizada tpicamente para ayudar a enfocar
el esfuerzo y para proporcionar beneficios adicionales, tales como una
visin independiente.
Varios niveles de independencia pueden ser definidos:
Pruebas diseadas por la(s) persona(s) que escribi (escribieron) el software bajo prueba.
Pruebas diseadas por otra(s) persona(s) del equipo de desarrollo. (bajo nivel de
independencia).
Pruebas diseadas por una(s) persona(s) de un grupo organizacional diferente (por ejemplo, un
grupo de prueba independiente.

Pruebas diseadas por una(s) persona(s) de una organizacin o compaa diferente (es decir
subcontratacin o certificacin por un organismo externo).

Identificar fallas durante la prueba puede ser percibido como una crtica contra el producto y contra el
autor. La prueba es, por lo tanto, a menudo vista como una actividad destructiva, aunque es muy
constructiva en la gestin de riesgos del producto.
Buscar fallas en un sistema requiere curiosidad, pesimismo profesional, un ojo crtico, atencin al
detalle, buena comunicacin con los pares de desarrollo y experiencia en que basar la conjetura de
error.
Si los errores, defectos o fallas son comunicados en una forma constructiva, malos sentimientos entre
los probadores y los analistas, diseadores y desarrolladores pueden ser evitados.

http://istqbexamcertification.com/what-is-independent-testing-its-benefits-and-risks/