Expectativas versus la realidad que nos toca vivir en el día a día
El resultado en la gestión de las expectativas dependerá de la función de cada miembro del equipo, es decir, diferente será el tratamiento de las expectativas que lleva el tester, el analista tester y un líder de testing. Cada uno dentro de su rol efectuará una determinada actividad y las mismas estarán ligadas y orientadas hacia un objetivo en común.
Manejar las diferentes situaciones que se pueden dar dentro del contexto de trabajo, durante la gestión de las expectativas frente a la realidad, hace al manejo de un equipo de testing.
Aquí hay que marcar un punto importante que muchos lo pasan por alto y tiene que ver con el manejo de las expectativas internas y las del usuario final.
Debemos entender que las expectativas que tenemos como testers (más allá de la función que tengamos en un equipo de proyecto) y/o las que recibimos por parte del usuario final, las debemos convertir en realidad, ahora bien, ¿Qué podemos proponer para que los resultados de las acciones representen y ofrezcan valor?
En principio debemos tener en cuenta los siguientes aspectos:
- manejar la asignación de los tiempos.
- proponer en todo momento la colaboración entre los miembros del proyecto.
- -procurar el desarrollo de un buen ambiente de trabajo.
- -cumplir con los acuerdos fijados.
En principio, es lo básico, seguramente podrás agregar otros aspectos a los citados.
Vuelvo entonces al concepto de expectativa y lo estaré orientando al usuario final para profundizar un poco en el otro concepto ligado que es el de requerimiento.
Para ésto hay que pensar en establecer ciertos límites en relación con:
- nuestras tareas.
- las definiciones establecidas para demostrar que hemos finalizado con la tarea.
- las definiciones establecidas para informar que no podemos cumplimentar con alguna tarea.
- por falta de conocimiento.
- por falta de herramientas.
- por falta de infraestructura dentro del entorno de trabajo.
- por falta de definición en el requerimiento.
- por falta de usuario final con suficiente conocimiento para responder nuestras consultas.
- por falta de requerimientos.
- por tiempos que nos superan y no están definidas correctamente las prioridades y criticidades.
- el alcance del plan de pruebas, los casos de prueba involucrados y aquellos que quedan fuera.
- los informes de avance que deberemos presentar conforme a las etapas que correspondan y que requieran las áreas con las que estemos tratando.
- los indicadores que conformarán el tablero de comando para los mandos medios y/o alta gerencia.
Nuestro cliente, al cual lo llamamos habitualmente ‘usuario final’ (también está el ‘usuario clave’), le debemos dar confianza y seguridad que:
- tiene un equipo de testing que podrá soportar y administrar adecuadamente sus requerimientos.
- sus requerimientos se traducirán en un producto usable.
En relación con los requerimientos que recibimos, debemos efectuar sobre los mismos un análisis global y luego un detallado pero de forma práctica que nos permita de manera ágil poder evaluar con qué equipo se podrán gestionar los mismos, es decir, qué funciones, conocimiento y herramientas serán necesarias para organizar una estructura adecuada de equipo para que el usuario final pueda reconocer que se obtendrá el resultado esperado en cuanto a la administración de las actividades que realizará cada uno de los roles definidos.
Una habilidad que deberán tener los miembros del equipo de testing es la de saber efectuar preguntas concretas, cerradas y concisas al ‘usuario final’ con el objeto de levantar la mayor cantidad posible de datos e información del requerimiento recibido y que permitan entender cuáles son las reglas de negocio y los criterios de aceptación para las pruebas. De esta forma se podrá avanzar en el diseño de los escenarios y casos de prueba.
Hay que tener presente en todo momento el manejo de los tiempos personales, aquellos que correspondan al equipo, y los relacionados con nuestro cliente (‘usuario final’), ya que también ésto tendrá que ver con el manejo de las expectativas versus la realidad para ir concretando efectivamente los requerimientos a un producto usable.
No hay que olvidarse que nuestro cliente:
- tiene que solucionar un problema.
- tiene que solventar una necesidad.
- debe satisfacer un deseo (personal y/o el de sus clientes).
- debe superar a su competencia con un producto de mejor calidad.
A continuación, te dejo algunas referencias a los Programas de Estudio del ISTQB.
Respecto del Programa de Estudios del Tester Certificado de Nivel Básico Extensión Ágil (versión 2014) (Certified Tester Foundation Level Extension Syllabus Agile Tester)
En el Programa de Estudios correspondiente al Agile Tester, podemos encontrar:
- 50 referencias del concepto ‘requisitos’
- 3 referencias del concepto ‘expectativas’
Algunos apartados interesantes a mi criterio vinculados con ‘requisitos’ (relacionados con el equipo y con el cliente) son los siguientes:
«Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.» (ref. Desarrollo ágil de software y el manifiesto ágil/Principios)
«Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados». (ref. Desarrollo ágil de software y el manifiesto ágil/Principios)
«Evitar malentendidos en los requisitos, que posiblemente no se hubieran detectado hasta más avanzado el ciclo de desarrollo cuando su reparación sería más cara».(ref. Información de retorno («feedback») temprano y frecuento).
«Backlog del sprint: al inicio de cada sprint, el equipo Scrum selecciona una serie de elementos de la máxima prioridad (denominado el backlog del sprint) a partir del backlog del producto. Debido a que el equipo Scrum selecciona los requisitos de la lista, la selección se realiza siguiendo un principio de pedir (pull-principle) en lugar de un principio de recibir (push-principle)». (ref. Enfoques de desarrollo ágil de software/Scrum)
«Definición de Terminado: para asegurarnos de que existe un producto potencialmente entregable al final de cada sprint, el equipo Scrum debate y define los criterios de finalización del sprint. El debate profundiza en el entendimiento del equipo sobre los elementos del backlog y los requisitos del producto». (ref. Enfoques de desarrollo ágil de software/Scrum)
«Límite de tiempo: solo aquellas tareas, requisitos, o prestaciones que el equipo espera completar dentro del sprint forman parte del backlog del sprint…». (ref. Enfoques de desarrollo ágil de software/Scrum)
«En el desarrollo ágil, las historias de usuario se escriben para establecer los requisitos desde las perspectivas de los desarrolladores, los testers y los representantes del negocio. Una vez los requisitos están escritos; en el desarrollo ágil, esta visión compartida se consigue a través de frecuentes revisiones informales a medida que se escriben los requisitos.» (ref. Creación de historias de usuario colaborativas)
«Normalmente, la perspectiva del tester mejorará la historia de usuario identificando detalles que faltan o requisitos no funcionales». (ref. Creación de historias de usuario colaborativas)
«La entrega de un incremento de producto requiere un software fiable, que funcione e integrado al final de cada sprint». (ref. Integración continua)
«La integración contínua requiere el uso de herramientas, incluyendo herramientas para pruebas, herramientas para automatizar el proceso de construcción y herramientas para el control de versiones». (ref. Integración continua)
«Los productos de trabajo orientados al negocio que describen qué se necesita (por ejemplo, especificaciones de requisitos) y cómo utilizarlo (por ejemplo, documentación de usuario)». (ref. Productos de trabajo del proyecto).
«En un proyecto ágil típico, es una práctica común evitar geerar grandes cantidades de documentación. En su lugar, el foco se centra en disponer de un software que funcione, junto con pruebas automatizadas que demuestren el cumplimiento de los requisitos». (ref. Productos de trabajo del proyecto).
Algunos apartados interesantes a mi criterio vinculados con ‘expectativas’ son los siguientes:
«Para mejorar la calidad general del producto,muchos equipos ágiles llevan a cabo encuestas de satisfacción para recibir información de retorno (feedback) sobre si el producto cumple las expectativas del cliente» (ref. Comunicación del estado de la prueba, progreso y calidad del producto)
«¿Se cumplen las necesidades, requisitos y expectativas del cliente?» (ref. Pruebas exploratorias y pruebas ágiles)
«Comprometido: El tester está comprometido a cuestionar y evaluar el comportamiento y las características del producto por lo que respecta a las expectativas y necesidades de los clientes y usuarios» (ref. Funciones de un tester/Trabajo en equipo)
ISTQB
Respecto del Programa de Estudios del Tester Certificado de Nivel Básico (versión 2018) (Certified Tester Foundation Level Syllabus)
En el Programa de Estudios podemos encontrar:
- 104 referencias del concepto ‘requisitos’
- 5 referencias del concepto ‘expectativas’
Algunos apartados interesantes vinculados con ‘requisitos’ son los siguientes:
«Evaluar productos de trabajo, tales como requisitos, historias de usuario y código fuente. Verificar si se cumplen todos los requisitos especificados. Cumplir con los requisitos o normas contractuales, legales o reglamentarios, y/o verificar el cumplimiento del objeto de prueba con dichos requisitos o normas. Durante las pruebas de aceptación, un objetivo puede ser confirmar que el sistema funciona como se espera y cumple con los requisitos.» (ref. Objetivos típicos de las pruebas).
«Tener testers involucrados en revisiones de requisitos o refinamiento de las historias de usuario podría detectar defectos en estos productos de trabajo. La identificación y eliminación de defectos de requisitos reduce el riesgo de que se desarrolle una funcionalidad incorrecta o no verificable.» (ref. Aportes de las Pruebas al Éxito).
«Un error de obtención de requisitos puede llevar a un defecto de requisitos, lo que a su vez da como resultado un error de programación que conduce a un defecto en el código» (ref. Errores, defectos y fallas).
«Mejorar la capacidad de ser entendidos los informes de avance de la prueba y los informes resúmenes de prueba para incluir el estado de los elementos de la base de prueba (p.e. los requisitos que pasaron sus pruebas, los requisitos que no pasaron sus pruebas y los requisitos que tienen pruebas pendientes.» (ref. Trazabilidad entre las bases de prueba y los productos de trabajo de prueba).
Algunos apartados interesantes vinculados con ‘expectativas’ son los siguientes:
«Es posible que los comentarios de la experiencia del usuario (UX) no cumplan con las expectativas del producto». (ref. Riesgos del producto y del proyecto)
«Puede haber una actitud inapropiada hacia las pruebas, o expectativas (p.e. no apreciar el valor de encontrar defectos durante las pruebas).
«Probar a fondo todos los requisitos especificados y corregir todos los defectos detectados aún podría producir un sistema que fuera difícil de utilizar, que no cumpla con las necesidades y expectativas de los usuarios, o que sea inferior en comparación con otros sistemas de la competencia. (ref. La ausencia de errores es una falacia).
