Técnicas Avanzadas de Automatización de Pruebas IV
Psicología de las Pruebas
Diferencias entre diseñar, desarrollar y probar
Las pruebas requieren una forma diferente de pensar de las de aquellos que diseñan o desarrollan sistemas La misión del diseñador (ingeniero de sistemas y arquitectos) es ayudar al cliente suministrándole los requisitos correctos. La misión del desarrollador es convertir los requisitos en funciones. La misión del probador es examinar la correcta implementación de los requisitos de usuario.
El objetivo común de las pruebas es proporcionar buen software.
En principio, una persona puede asumir los tres roles, ss difícil pero es posible. Se deben tener en cuenta las diferencias en los objetivos asociados a cada rol, aunque hay otras soluciones (como tener un equipo de pruebas independiente) suelen ser más fáciles y producir mejores resultados.
Las personas y los proyectos se conducen en base a objetivos. Las personas tienden a alinear sus planes con los objetivos establecidos por los gestores u otros responsables, por ejemplo: encontrar defectos o confirmar que funciona el software. Por eso es importante establecer de una forma clara los objetivos de las pruebas.
La mentalidad a utilizar durante las pruebas y revisiones es distinta a la que hay que tener durante el desarrollo
El desarrollador
- Transforma los requisitos
- Desarrolla estructuras
- Programa el software
- Consigue el producto
- ¡El desarrollador es constructivo!
El probador
- Planifica sus pruebas
- Especifica casos de prueba
- Sólo quiere encontrar errores
- Los errores del programador son su éxito
- ¡El probador es destructivo!
¡Falso!
¡También las pruebas son constructivas, ya que su objetivo es un producto libre de errores!
Las dificultades
El probador experimentado mantiene una distancia suficiente respecto del objeto de la prueba. Cuanto más alejado esté el probador del desarrollo más independientemente y más objetivamente podrá llevar a cabo su trabajo. Una distancia demasiado grande respecto del objeto de prueba puede, sin embargo, provocar que se necesite más tiempo para las pruebas.
Posibles formas de llevar a cabo las pruebas
Pruebas del desarrollador
El desarrollador nunca se mantiene neutral respecto de su “creación”. En definitiva conoce el objeto de prueba mejor que nadie. No se producen costes adicionales por tener que ponerse al corriente respecto del objeto de prueba. El hombre tiende a ser ciego respecto a sus errores, por eso existe el peligro para el desarrollador de no ver fallos evidentes. Los errores como consecuencia de una mala interpretación de los requisitos quedan sin descubrir. Estos errores se pueden evitar, o al menos reducir, mediante la formación de equipos de desarrollo en los que los desarrolladores comprueban mutuamente sus productos.
Pruebas diseñadas por otras personas del equipo de desarrollo
La formación de equipos de pruebas con miembros de diferentes áreas del proyecto mejora la calidad de las pruebas. Es importante que estos equipos puedan trabajar lo más independientemente posible.
Pruebas diseñadas por personas integrantes de un grupo organizativo distinto
Como un equipo de prueba independiente o especialistas en pruebas (como los especialistas en pruebas de usabilidad o prestaciones)
Pruebas diseñadas por personas de otras organizaciones (Outsourcing de pruebas)
Una separación completa de las pruebas consigue la mayor distancia posible entre el objeto de prueba y el probador, en todo caso se dispone de poco conocimiento sobre el objeto de prueba y el proyecto. Se requiere un gran esfuerzo de puesta al corriente. Los expertos externos deberían ser por ello involucrados desde las fases tempranas del proyecto. Los expertos externos tienen en todo caso un know-how muy desarrollado acerca de las pruebas. La definición óptima de los casos de prueba queda así garantizada. Como otra ventaja, la utilización óptima de métodos y herramientas, además de una ejecución de las prueba acorde.
Personalidad de un buen probador
Curioso, atento a los detalles, para comprender los escenarios prácticos en los que se mueve el cliente, para ser capaz de analizar la estructura de la prueba y para descubrir detalles que pueden identificar fallos.
Tiene que ser escéptico y tener ojo crítico, pensar que los objetos de prueba contienen defectos y su trabajo consiste en encontrarlos.
No se debe ver limitado por el hecho de que un error grave pueda afectar a (por ejemplo) las fechas del proyecto.
Debe tener buenas capacidades de comunicación, para dar malas noticias a los desarrolladores, para no perder la perspectiva ante situaciones frustrantes y para establecer rápidamente una relación de trabajo con los desarrolladores. Una comunicación positiva puede ayudar a evitar o facilitar situaciones complicadas.
Tiene que tener experiencia. Los factores personales influyen en la ocurrencia de errores y la experiencia ayuda a identificar donde se pueden acumular los errores.
Problemas de comunicación
Especialmente en fases del proyecto estresantes la notificación de los errores puede generar problemas, sobre todo si los probadores son vistos como portadores de malas noticias. La manera de notificar el error y la descripción del mismo son decisivos. No de debe criticar a las personas si no mostrar el error de forma objetiva. Se debe facilitar la solución del error al desarrollador mediante la notificación. El objetivo común debe estar siempre en primer plano. Una comunicación insuficiente o la ausencia de ésta entre probadores y desarrolladores puede impedir el buen trabajo en equipo. En ocasiones, no hay entendimiento entre el equipo de pruebas y el de desarrollo . Los desarrolladores deberían tener nociones básicas de pruebas. Los probadores deberían conocer las características esenciales del desarrollo de software.
Hay sin embargo, varias formas de mejorar la comunicación y las relaciones entre los probadores y el resto. Empezar a colaborar, en vez de entrar en refriegas – recordar a todos que el objetivo común es obtener sistemas de mejor calidad. Comunicar lo que se ha encontrado en el producto de forma neutra, enfocada a los hechos, sin criticar a la persona que lo ha creado, por ejemplo, redactando informes de incidencia y revisiones de forma objetiva y atendiéndose a los hechos. Intentar comprender como se siente la otra persona y por qué reacciona como lo hace (Empatía). Confirmar que la otra persona ha entendido lo que has dicho y viceversa.
Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.