Software Gurú 2008: Pruebas de Aceptación

3,718 views
3,570 views

Published on

Presentación en la conferencia Software Gurú 2008 sobre "Pruebas de Aceptación, el camino hacia Clientes satisfechos"

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
3,718
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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
  • Software Gurú 2008: Pruebas de Aceptación

    1. 1. Pruebas de Aceptación, el camino hacia Clientes satisfechos Disertante: Ernesto Kiszkurno Autores: Alfonsina Morgavi – Ernesto Kiszkurno
    2. 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.
    3. 3. Agenda <ul><li>Introducción </li></ul><ul><li>Evite el síndrome de “hable ahora ó calle para siempre” </li></ul><ul><li>El Test de aceptación como un proceso formal y continuo </li></ul><ul><li>No olvide porqué lo hace </li></ul><ul><li>Los criterios de aceptación </li></ul><ul><li>Documento sus decisiones y resultados </li></ul><ul><li>No olvide a los usuarios </li></ul><ul><li>Conclusiones </li></ul><ul><li>Acerca del Grupo Pragma Consultores… </li></ul>
    4. 4. Introducción <ul><li>Desarrollar buen software es un “negocio caro”. Son muchas las etapas que median entre el primer esbozo (a veces tímido y pobre) de un requerimiento inicial y un producto final “fit for use”. Desde luego los recursos, en el amplio sentido de la palabra para realizar esto, no son sin costo. </li></ul><ul><li>No sería la primera vez que se escucha decir a los usuarios: </li></ul><ul><ul><li>pero esto no es lo que yo quería </li></ul></ul><ul><ul><li>por cierto, tampoco es lo que yo pedí </li></ul></ul><ul><ul><li>esto no es lo que yo necesito </li></ul></ul><ul><ul><li>¿quién se va a hacer cargo de esto? </li></ul></ul><ul><ul><li>¿cómo se supone que voy a “operar” con este software? </li></ul></ul>
    5. 5. Evite el síndrome de “hable ahora ó calle para siempre” <ul><li>¿Quien maneja a quien? </li></ul>
    6. 6. Evite el síndrome de “hable ahora ó calle para siempre” <ul><li>El software se construye a partir de requerimientos. Éstos se obtienen a partir de relevar a los usuarios, donde ellos nos cuentan lo que saben del negocio y que nosotros desconocemos. </li></ul><ul><li>Nuestra tarea como especialistas es, dar visibilidad a estos requerimientos, modelando el soporte informático para su negocio. </li></ul><ul><li>Los Usuarios serán responsables de validar, si la solución técnica que se les desarrolló, responde a sus necesidades ó no. </li></ul><ul><li>Es durante el “Test de Aceptación” que se valida formalmente la operatoria total del sistema, y el grado de respuesta que el mismo ha dado a sus requerimientos. </li></ul>
    7. 7. Evite el síndrome de “hable ahora ó calle para siempre” <ul><li>La mejor forma de achicar paulatinamente </li></ul><ul><li>el GAP entre las expectativas del usuario </li></ul><ul><li>y lo construido es: </li></ul><ul><li>someter al sistema a </li></ul><ul><li>revisiones parciales de </li></ul><ul><li>los usuarios </li></ul>
    8. 8. Vea al Test de Aceptación como un proceso continuo <ul><li>El test de aceptación debería ser considerado como un proceso contractual e incremental. </li></ul><ul><li>Es de esperar que se logren obtener “aprobaciones de entregables intermedios” a lo largo de todo el proceso de desarrollo. De esta manera, si por ejemplo desarrollamos un prototipo, el usuario tendrá una primera visión del modelado que se les está realizando. </li></ul><ul><li>Si definimos casos de prueba y se los damos para opinar (e inclusive para aprobar), tendremos la certeza de que vamos por buen camino. </li></ul>
    9. 9. No olvide porqué lo hace <ul><li>Cada organización deberá definir, a priori, bajo qué circunstancias y con que objetivos realizará Test de Aceptación. </li></ul><ul><li>Si el software fue desarrollado bajo régimen de outsourcing: </li></ul><ul><ul><li>el proceso de aceptación del producto es un tema contractual </li></ul></ul><ul><ul><li>el objetivo aquí es decidir si se acepta el desarrollo o no </li></ul></ul><ul><li>Si el producto está desarrollado por una organización con una metodología de producción de software que incluye las sucesivas etapas de Test: </li></ul><ul><ul><li>estaremos entonces frente a una etapa de test, en la que solamente nos ocuparemos &quot;del negocio y su operatoria” </li></ul></ul><ul><ul><li>el objetivo aquí es obtener la aprobación del usuario para que el sistema entre en producción </li></ul></ul>
    10. 10. Defina claramente los Criterios de Aceptación <ul><li>Es el área Usuaria, quien debe definir los criterios de aceptación. </li></ul><ul><li>Esta información debería quedar escrita en los requerimientos, es decir, definida desde el inicio, de forma tal que los atributos &quot;nazcan&quot; con el producto y no sean un “injerto”. </li></ul><ul><li>Algo interesante en el momento de definir los criterios de aceptación, es intentar ver en funcionamiento aplicaciones similares, de otras organizaciones; algún producto que pueda dar algunos parámetros de qué se puede solicitar, entre otros temas, para no crearse falsas expectativas… </li></ul><ul><li>La bala de plata sigue sin existir (Brooks sigue vigente…). </li></ul>
    11. 11. Defina claramente los Criterios de Aceptación
    12. 12. Defina claramente los Criterios de Aceptación <ul><li>En el momento de definir los criterios de aceptación es importante tener en cuenta por ejemplo: </li></ul><ul><ul><li>¿Qué tan crítico será ese sistema para la organización? </li></ul></ul><ul><ul><li>¿Qué funcionalidades serán las más críticas para el propósito del negocio? </li></ul></ul><ul><ul><li>¿Qué funcionalidades serán las más visibles para el Usuario? </li></ul></ul><ul><ul><li>¿Qué aspectos de proyectos previos o similares, causaron problemas? </li></ul></ul>
    13. 13. Defina claramente los Criterios de Aceptación <ul><ul><li>¿Qué aspectos de proyectos previos o similares, causaron más gastos de mantenimiento? </li></ul></ul><ul><ul><li>¿Qué clase de problemas, causarán la peor publicidad? </li></ul></ul><ul><ul><li>¿Qué clase de problemas, causarían la mayor cantidad de quejas de los Clientes? </li></ul></ul><ul><ul><li>¿Cuál es el costo que ocasionaría una falla en el sistema? </li></ul></ul><ul><li>En este sentido, muchas veces el criterio de aceptación y el criterio de puesta en producción, se parecen. </li></ul>
    14. 14. Defina claramente los Criterios de Aceptación <ul><li>Los criterios de aceptación deberían definirse y documentarse a priori. </li></ul><ul><li>Es necesario especificar : </li></ul><ul><ul><li>qué producto/s pasarán por el filtro de aceptación </li></ul></ul><ul><ul><li>cuáles son los objetivos para cada uno de ellos </li></ul></ul><ul><ul><li>los tipos de decisiones de aceptación </li></ul></ul><ul><ul><li>los criterios de priorización que se utilizarán </li></ul></ul>
    15. 15. Documente sus decisiones y resultados <ul><li>En función de los resultados del proceso de pruebas, los responsables del Área Usuaria deberán indicar su decisión de: </li></ul><ul><ul><li>Aceptar el producto: Todos los casos de prueba, fueron aprobados y el software responde a los requerimientos </li></ul></ul><ul><ul><li>Aceptar el producto con reservas: El software tiene defectos pero los mismos no invalidan, por su criticidad, la puesta en producción </li></ul></ul><ul><ul><li>Rechazar el producto: El software tiene defectos que por su criticidad, invalidan la puesta en producción </li></ul></ul>
    16. 16. No olvide a los usuarios <ul><li>Todos los grupos usuarios a quienes afecte el nuevo software, cambio o mantenimiento, deben estar presentes en la aceptación. Tendrán mayor o menor representación dependiendo de cuánto se vea impactada su área, pero deben ser representados. </li></ul><ul><li>No necesariamente, aquellos usuarios que llevan más tiempo dentro de la organización, son los que más conocen del proceso del negocio, ni los mejor dispuestos a colaborar en el proceso de test de aceptación. </li></ul><ul><li>La elección de los usuarios campeones es fundamental para el éxito del proyecto pues un usuario que directa o indirectamente se siente perjudicado por la aparición de un nuevo aplicativo, o con los cambios realizados a uno ya existente, no será muy colaborador. </li></ul>
    17. 17. No olvide a los usuarios <ul><li>Identificar líderes (Usuarios Campeones) </li></ul><ul><ul><li>¿Cuál es su historia en la organización? </li></ul></ul><ul><ul><li>¿Qué es lo que saben del negocio? </li></ul></ul><ul><ul><li>¿Qué es lo que no saben del negocio? </li></ul></ul><ul><ul><li>¿Cuál es su tarea? </li></ul></ul><ul><li>Seleccionar </li></ul><ul><ul><li>Usuarios con visión macro del negocio </li></ul></ul><ul><ul><li>Usuarios con conocimiento del detalle </li></ul></ul><ul><ul><li>Entrenamiento requerido </li></ul></ul>
    18. 18. Conclusiones <ul><li>La prueba de aceptación no debe ser una actividad al final del desarrollo, sino un “proceso” a desarrollar por etapas (cómo nos comemos el elefante?). </li></ul><ul><li>La definición de dicho proceso, los roles y el alcance, deben estar claramente documentados al inicio del proyecto (Estrategia de Calidad o Pruebas. </li></ul><ul><li>Defina claramente los objetivos de la prueba (Contrato / Acuerdo) </li></ul><ul><li>Los criterios de aceptación y de puesta en producción del software, deben estar documentados y comunicados a todos los participantes del proyecto desde sus etapas más tempranas. </li></ul><ul><li>Cuanto más tempranamente abordemos las expectativas de nuestros usuarios, menor será el GAP entre lo requerido y lo construido. No perdamos la oportunidad de transformar a la prueba de aceptación formal que se hace al final del proyecto en una “formalidad”! </li></ul><ul><li>La elección de un usuario campeón para ayudarnos en un proyecto no es trivial. Debe hacerse tempranamente y teniendo en cuenta la representatividad en el resto de los usuarios. </li></ul>
    19. 19. Preguntas
    20. 20. Visite nuestros WEBSITES y contactenos: <ul><li>Argentina: San Martín 575 • 2º | (C1004AAK) Buenos Aires | Tel (+54-11) 4327-1999 | [email_address] </li></ul><ul><li>Córdoba 524 1er Piso | (Q8300BLL) Neuquén | TE: (0299) 4424044 </li></ul><ul><li>España: Santa Hortensia 15, Of. A3 | (28002) Madrid | Tel (+ 34) 91-515-0558 | [email_address] </li></ul><ul><li>Chile: Luis T. Ojeda 0191 • Of. 701 | Providencia, Santiago | Tel (+56-2) 334-3361 | [email_address] </li></ul><ul><li>México: Prol. Corregidora No. 338 Oficina 3 y 4 | Fracc. Alamos 3ra. Sección | Querétaro ,Qro. C.P. 76160 | Tel. 442 245 2151/52 </li></ul>www.pragmaconsultores.com.ar

    ×