Software Gurú 2008: Pruebas de Aceptación
•
2 gefällt mir•2,492 views
Presentación en la conferencia Software Gurú 2008 sobre "Pruebas de Aceptación, el camino hacia Clientes satisfechos"
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Software Gurú 2008: Pruebas de Aceptación
Ähnlich wie Software Gurú 2008: Pruebas de Aceptación (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
Software Gurú 2008: Pruebas de Aceptación
- 1. Pruebas de Aceptación, el camino hacia Clientes satisfechos Disertante: Ernesto Kiszkurno Autores: Alfonsina Morgavi – Ernesto Kiszkurno
- 2. Objetivo El objetivo de este trabajo es compartir con los asistentes nuestra metodología de trabajo y experiencias respecto del Test de Aceptación de Usuario, bajo la óptica de que es un proceso formal y continuo y no solo una etapa al final del desarrollo, antes de la puesta en producción. ¿Qué sucedería, si les entregáramos a nuestros usuarios un sistema que funciona correctamente “en el escritorio”, pero que no les permite llevar adelante su negocio “en el mundo real”…? El final de un proyecto es sin lugar a dudas el peor momento para enterarnos de esto. Bien se dice popularmente que en el “arte” de desarrollar software, el peor riesgo es fracasar por no construir el producto correcto.
- 11. Defina claramente los Criterios de Aceptación
- 19. Preguntas
Hinweis der Redaktion
- Cuanto dura la presentación?
- Qué chiste puedo hacer acá? Formal = documentado, difundido e institucionalizado. El usuario debe saber de antemano “cómo” van a ocurrir las cosas. Debemos entrenarlo para que pueda desempeñar su papel “smooth” Continuo = iterativo, incremental, a lo largo de las etapas de testing La última iteración es solo para “la foto”. Los problemas deben detectarse lo antes posible. La respuesta a la pregunta es: el software estaría listo más tarde y a un mayor costo, si es que alguna vez está listo.
- El problema es conocido: alinear la idea mental que tiene el usuario del sistema con el sistema finalmente construido. Escribir los requerimientos es un medio (no un fin en si mismo) para lograr este alineamiento. Los requerimientos, además, son la columna vertebral de un proyecto de desarrollo de software. Todo el proyecto, en mayor o menor medida, dependerá de lo definido allí. El test de aceptación tradicional, practicado al final de la etapa de testing y, antes de la implementación del sistema, tiene por único objetivo obtener la aprobación formal y escrita del usuario.
- Cual es la idea de este slide? Cuando la aceptación de usuario se concibe como “one-shot” corremos riesgos: Que el sistema frustre al usuario. Impacto: no uso del sistema, no aceptación, enemistad con el área de sistemas. Que el sistema domine al usuario (los procesos de negocio se adaptan al sistema “a medida”). Impacto: ineficiencias en la empresa, complejidad adicional. Si el área usuaria tiene más fuerza, que los requerimientos cambien constantemente. Impacto: proyecto sin fin Si el área de sistemas tiene más fuerza, que el sistema no sea lo que se necesita
- Los requerimientos como contrato (o acuerdo) entre usuarios y sistemas Visión compartida del negocio implementado en el sistema Premisas: las decisiones sobre requerimientos impactan sobre la economía del proyecto (costos, fechas, esfuerzo) Èxito compartido en el proyecto construido a lo largo de TODOS los días del proyecto Todos los días hay un test de aceptación (empezar apurado!)
- La idea es: Gestionar el cambio (minimizar los miedos y las resistencias) Gestionar el conocimiento (aprender de los usuarios también durante la construcción y no solo durante el análisis) Manejar la incertidumbre del usuario Acostumbrarlo a ver el sistema como nosotros lo vemos Anécdota Movicom: Revisiones iterativas de prototipos y requerimientos Revisiones de diseño
- La aceptación del sistema está más cerca si los testers también aceptan los requerimientos Un interlocutor interesante para manejar la interacción con los usuarios es el tester pues es alguien que habla los dos idiomas: el técnico y el del negocio.
- Hay que entender qué se está aceptando a quién le estamos aceptando Quién está aceptando Qué estamos aceptando Por qué se está aceptando Hay compañías donde hay diferentes niveles de aceptación. Un ejemplo implementado: Aceptación del desarrollo para testear (prueba tercerizada) Aceptación del desarrollo por parte del área Técnica (sistemas; documentación, código, etc) Aceptación del usuario (para ponerlo en producción; el usuario acompañado de sistemas)
- Hay que facilitar esta definición mostrando casos de prueba definidos por sistemas, ayudando a romper la hoja en blanco, etc. Los atributos de calidad a validar son parte de la especificación del sistema. Receta: En proyectos críticos, escribir una estrategia de prueba que permita discutir y consensuar qué se hará en términos de calidad es una práctica muy recomendable. Aquí se definirán cosas como “para que el sistema sea aprobado por el usuario podrán quedar incidentes de criticidad alta abiertos”.
- ¿y acá que querés decir?
- Dado que la calidad siempre es una decisión económica. Hacer visible la estrategia de pruebas al usuario permite evaluar las zonas de riesgo y a partir de eso decidir donde pondremos el esfuerzo. Un error muy común es pensar que la prueba de usuario debe tener el mismo alcance que la prueba de sistemas.
- La estrategia de pruebas es la herramienta ideal para documentar estas decisiones y el proceso de elaboración de una estrategia de pruebas permite validar las decisiones con todos los involucrados en el proyecto.
- Los criterios para tomar esta decisión deben estar claros y documentados. Las decisiones tomadas en cada prueba de aceptación también deben ser documentadas. Documentar en este caso incluye informar a los involucrados.
- Receta: elegir bien a los usuarios Estar presente es distinto de estar todos juntos. Es conveniente trabajar por grupos de usuarios y estos grupos deben estar formados de acuerdo a sus características (area, funcion, compromiso con el proyecto, etc.)
- Está mal el formato