Brian Marick. Testing y conocimiento del negocio

Hay testing que requiere conocimiento del negocio, en muchos casos si la materia es complicada el conocimiento que se requiere es bastante profundo y no es algo que se pueda conseguir en dos ratos.

Este testing se podría realizar aplicando técnicas de testing exploratorio pero se requeriría un apoyo importante por parte del equipo de proyecto salvo que se disponga del tiempo suficiente para que el tester pueda aprender con el soporte adecuado lo necesario del negocio para realizar las pruebas.

Siempre está la posibilidad de que los casos de prueba vengan desde el equipo de proyecto (con el soporte si se requiere del equipo de testing) en cuyo caso bastará con seguirlos (esta mayor simplicidad al final es fruto de un mayor esfuerzo por parte de otras personas, por lo que al final el esfuerzo lo que hace es distribuirse, si bien no todas las combinaciones son igual de efectivas), combinándose con las exploraciones que se estimen oportunas sobre la aplicación.

Cuanto más complejo sea el sistema desde el punto de vista del negocio más proximidad se requerirá por parte del equipo de testing (o por personas claves de dicho equipo), más interesante resulta el soporte por parte del equipo de proyecto (nunca está de más tener ayuda si es necesario) y más interesante resulta la realización de pruebas por parte del área usuaria (no solo en el momento de la aceptación, sino lo antes posible).

El testing no solo es encontrar bugs sino también localizar discrepancias con respecto a las expectativas de los usuarios.

La opinión de Brian Marick al respecto es la siguiente: “Para encontrar los bugs que los clientes ven – que son importantes para los clientes – necesitas escribir tests que verifiquen las áreas funcionales imitando tareas típicas de los usuarios. Este tipo de testing se denomina testing de escenarios, testing basado en tareas o testing de casos de uso”.

Anuncios
4 comentarios
  1. Ricardo dijo:

    Una pregunta.
    Supongamos que un equipo de desarrollo va implementado historias de usuario a medida que le vienen (y tirándolas a la basura cada vez que acaba). ¿Cómo se puede hacer las pruebas de los casos de uso si simplemente no existen esos casos de uso (que es otra técnica de captura de requisitos)?
    Gracias.

    • jummp dijo:

      Ricardo estás suponiendo que se tiran las historias de usuario y eso condiciona la respuesta a tu pregunta. Habrá quienes la tiren y habrá quienes no, sin un contexto detrás no me atrevería a decir si alguno se equivoca.

      También depende de quién hace el testing (el mismo equipo que desarrolla o un equipo independiente) y su vinculación a lo que es el proceso de desarrollo. También de la experiencia y habilidad de quien hace el testing y de la colaboración que podría tener de quienes están desarrollando.

      Buena pregunta y muy interesante para reflexionar sobre la misma y sus posibles respuestas.

      • Ricardo dijo:

        Supongamos los dos casos.
        Esta claro que si se tiran, será un desastre el testeo porque no sabemos qué debemos de testear.
        Pero si se guardan, ¿acaso no será un caos buscar entre un montón de post-its?
        Realmente mi pregunta es más encaminada a la gestión de requisitos que al testeo, ya que me parece que las historias de usuario y su gestión es bastante pobre.
        Obviamente si tienes un listado de requisitos o casos de uso en una herramienta informatizado, toda su gestión es más fácil e ingenieril, ¿o no? (de bote pronto me viene a la cabeza RequisitePro y para Eclipse http://www.eclipse.org/rmf/pror/)
        Porque básicamente, mi otra pregunta es, ¿como puedes testear algo que no sabes que existe?
        Y no sólo el testeo, sino ya simplemente el mantenimiento y la evolución del sistema.
        Me gustaría conocer vuestras opiniones al respecto.

  2. jummp dijo:

    Cuando hablo de no tirar no me estaba refiriendo a una gestión basada en post-its. Puedes utilizar otro tipo de soluciones y seguir siendo historias de usuario.

    Yo no estoy en contra de la ingeniería del software pero mi enfoque es más evolutivo y dicha forma de entender el desarrollo de software (que no necesariamente es mejor o peor sino la que yo entiendo que es más válida en una serie de contextos (que no en todos)) requiere que el overhead no sea muy alto para permitir que la adaptación al cambio sea lo más rápida posible, ¿por qué no se puede considerar eso ingeniería del software?.

    Cada proyecto es un mundo y lo importante es adaptarnos a su contexto, si un proyecto requiere ser más ortodoxo (por su criticidad, por exigencias de un cliente, por los propios procesos de nuestra organización) pues seamos más ortodoxos, si otro proyecto no lo requiere apliquemos la mejor estrategia posible.

    El testing exploratorio es un complemento totalmente válido a un testing basado en casos de prueba de hecho lo considero necesario en base a que los casos de prueba no van a contemplar todas las casuísticas, de hecho lo mismo proporciona información y un feedback interesante para el proyecto, ¿cómo obtener la información necesaria? con los recursos generados con el proyecto, con conversaciones con el equipo de proyecto y con la experiencia y conocimientos muy importantes del tester (siempre comento eso cuando hago referencia a este tipo de testing).

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: