2do Encuentro de Testers / Probadores - Presencial y Online Realizado el 18 Abril 2015, en la empresa Baufest (Argentina) Tema a Debatir: Los Requerimientos. ¿Cómo llegan al Tester? ¿De qué manera participan en la documentación los Testers?

1. 2do Encuentro de Testers
2015-04-18
Requerimientos

2. Tema a debatir: Los Requerimientos
Esta presentación sirvió como primer disparador de ideas para comenzar
el debate que se celebró el 18 de Abril del 2015 por la mañana en una de
las salas que posee la empresa Baufest (Buenos Aires, Argentina), y que
nos has facilitado gracias a la gestión de Nadia Cavalleri.

3. Introducción
"Los requerimientos", son la base de la que parte el proceso de desarrollo
y pruebas, y a pesar de todo, suele subestimárselos.
Con mucha frecuencia tenemos que se presentan desvíos en tiempos
debido a reprocesos por mal levantamiento y mala definición de
requerimientos.
Es muy interesante saber la opinión de las personas que han tenido
experiencia en esta área, puesto que tendrán estrategias y enfoques que
que podremos complementar.

4. Testimonio 1
•Llegan en formato típico
•Se los clasifica por importancia y riesgo
•Se levantan ciertas características
•Se solicita la aprobación del Usuario
•Se definen los REQ Func y No Func
•Se realiza el siguiente análisis:
Términos que no deben ser utilizados
Referencia a Variables Temporales
Ciclo de tareas repetitivas
Descomposición funcional
Flujos Alternativos identificados
Flujos de Excepción identificados

5. Testimonio 2
•Se recibe Req aprobado por el usuario
•Se arma el Test plan (TP) y Test Cases (TC)
•La Especif Func no se escribe como UC
•La Especif Func se escribe con un template
•Se dificulta identificar los casos de prueba
•No se participa en el armado de los Req
•Se busca la aprobación del usuario en el TP y TC
•Se espera devolución
de lo que vamos a probar
sugerencias de más casos a contemplar

6. Testimonio 3
•No llegan los requerimientos
•Trato de asistir a todas las reuniones
•En la reunión se discuten los módulos de app
•En caso de no poder asistir, confeccionan el acta
•Se realiza un Diagrama de flujo

7. Testimonio 4
•Normalmente nos llegan con escaso detalle
•A veces sólo son una frase de lo que el cliente quiere hacer
•Se confunden historias de usuario con casos de uso
•No hay descripciones en las historias de usuario
•Se pierde el tiempo en la creación de los planes de prueba
•Se pierde el tiempo en las ejecuciones
•Las reuniones con el product owner son muy largas
•Gente sin conocimientos de IT realizan las especificaciones de requisitos
•Se diseñan todos los procedimientos de SQA que debería tener el cliente
•Se diseñan los diferentes reportes tras la ejecución
•Se lo ayuda al cliente a mejorar en sus procesos de Calidad

8. Testimonio 5
•Muchas veces no llegan completos
•Llegan con demasiados items confusos y sin aclarar con el cliente.
•En otras ocasiones solo es hablado
•Todo queda muy en el aire
•Al comenzar el proceso de planeación o diseño se presentarán demasiadas dudas y confusiones
•Ayudamos a completar los documentos en donde se especifican los requerimientos
•Contamos con una visión más completa acerca de los criterios de aceptación y determinados detalles
•Le damos importancia a que el equipo de pruebas pueda interactuar con el product owner
•También que pueda interactuar con el mismo cliente
•Intentamos desde el inicio identificar defectos

9. Testimonio 6
•Los requerimientos, muchas veces nos vienen como:
un documento escaso y mal especificado
un manual de usuario
documentación desactualizada que tenían por ahí olvidada
código del programador
documentación incompleta, paso de un estado a otro, sin contemplar los estados intermedios.

10. Testimonio 7
•a veces llegan
•a veces llegan en forma y tiempo
•a veces llegan desactualizados
•a veces no llegan
•Si participamos desde la concepción del documento sin duda el valor es otro que si solamente leemos el
documento final.
•Personalmente considero que el rol de revisor de documentación (validación, correctitud, etc) también es
parte en la calidad del producto como un todo.
•Si dicha tarea la hace un tester o no, podrá ser decisión tal vez de algún integrante de nivel gerencial del
proyecto o tal vez por iniciativa del propio tester.

11. Testimonio 8
¿Cómo llegan los requerimientos a los testers?
Depende del enfoque o metodología de desarrollo de software.
Lo que he visto por aquí es que van desde "No hay documentación" hasta "documentación extensa" y
muchas veces desactualizada.
En los mantenimientos muchas veces la documentación es nula o no esta actualizada, el tester tiene que
completarla.
En los desarrollos nuevos, si es "tradicional" muchas veces derivan el testing al final y le dan la
documentación (casos de uso, diseño) poco antes de comenzar las pruebas.
En los desarrollos nuevos con enfoque tradicional, el testers trabaja desde el inicio junto al analista
definiendo los criterios de aceptación para luego comenzar a diseñar sus pruebas.

12. Testimonio 9
He tenido oportunidad de trabajar en empresas con manejo completamente distitnto de los requerimientos.
1. En algunas organizaciones los requerimientos son 2/3 escasas líneas en un mail. Esta info luego se
actualiza via skype u otros mails y desde luego finalmente esta info se pierde por estar diseminada en
manos de varios actores.
2. En otras organizaciones, los requerimientos esta registrados en un template, cuyo grado de completitud
y actualización dista de ser siquiera útil para comenzar.
3. Otras organizaciones tienen requerimientos escritos, pero los mismos, son pobres, incompletos u
obsoletos.
4. En mi extensa trayectoria, he visto pocas veces requerimientos claros, concisos, concretos y
actualizados y mucho menos firmados por los key users.

13. Testimonio 9 (continuación)
•Importante: según el Quality Assurance Institute, y algunas otras organizaciones (generalmente de fuera
de Latinoamérica) sus publicaciones informan que más del 50% de los problemas en el software es por las
deficiencia en los requerimientos, tanto funcionales como no funcionales.
•Mi recomendación siempre es realizar una revisión de los requerimientos (revisión formal con informe de
hallazgos) que permita mejorarlos, completarlos, etc.etc. de forma tal que los mismos ingresen en el
circuito o proceso de desarrollo con cierto nivel de "certeza" acerca de su contenido y completitud.
•Rescato la vieja frase de William Perry "Si se pueden testear( armar casos de prueba" seguramente se
pueden programar. Si desde Testing no somos capaces de armar casos de prueba por ejemplo por falta de
información, esa misma información es la que le faltará al programador.

14. Grabación del 2do Encuentro de Testers
Encuentro Online de Testers
Requerimientos
Nro 2/2015
TestingBaires
https://youtu.be/eS4hr3OrBow
Si quieres acceder a las grabaciones de
los anteriores Encuentros de Testers:
http://testingbaires.com/encuentros/

15. 2do Encuentro de Testers
Consultas:
gustavo@testingbaires.com