Obtenga información sobre las pruebas de aceptación de usuarios

Cameron: Hola a todos. Mi nombre es Cameron Johnson. Soy redactor de contenido de Trailhead y hoy me acompaña la experta en análisis de negocios, Dernie. Dernie, cuéntanos sobre ti y qué función cumples en Salesforce.

Dernie: Hola, Cameron. Soy Dernie Hashemzadeh. Dirijo un increíble equipo de profesionales expertos en análisis de negocios aquí en Salesforce. En pocas palabras, lo que hacemos todos en el equipo de BA es vincular el negocio con los equipos de tecnología, en ese caso TI. Nuestra función principal como analistas de negocios es proporcionar claridad y vincular a las personas con la tecnología para guiar a nuestra organización de ventas en la implementación de soluciones tecnológicas.

Cameron: Eso es increíble. Entonces, ¿eres una analista de negocios de nuestro Salesforce real? ¿Una de nuestros analistas de negocios internos?

Dernie: Así es.

Cameron: Excelente. La razón por la que conversamos con Dernie hoy es para repasar el tema principal de las UAT o pruebas de aceptación de usuarios. Probablemente use el acrónimo, de lo contrario sería un trabalenguas. Uno de los objetivos de nuestra charla es contestar ciertas preguntas, como por ejemplo: ¿Qué es UAT? ¿Cómo participa un BA o analista de negocios en las UAT? ¿Por qué son importantes las UAT para el éxito de un proyecto? Luego, le consultaré a Dernie sobre algunos consejos y trucos eficaces, y las mejores prácticas. Si te parece bien, Dernie, comencemos con la primera pregunta. ¿Qué es UAT?

Dernie: Sí, es un acrónimo largo. Es la sigla en inglés para las pruebas de aceptación de usuarios. Francamente, es la última etapa antes del lanzamiento. Se realiza en un entorno sandbox luego de que el equipo de tecnología evalúe el proyecto o la mejora de manera exhaustiva. Por lo general, se lleva a cabo una garantía de calidad y una ingeniería de calidad. Una vez que se supera esa etapa, se pasa a las UAT. Es una prueba que realizan los usuarios finales de los proyectos para su aprobación antes del lanzamiento. Las pruebas pueden implicar a diversas partes interesadas. Pueden participar las partes interesadas del negocio, así como los usuarios finales. Y también los BA y los equipos de TI. Por lo general, las pruebas también incluyen casos de prueba. El resultado será una aprobación o un fallo. Una vez más, el objetivo general de las UAT es asegurarse de que la entrega final sea lo que se solicitó originalmente. También sirve para certificar que el sistema y la herramienta son suficientes para el uso en el negocio.

Cameron: Excelente. Entonces, cuando mencionas la aprobación o el fallo, significa literalmente que el proyecto se lleva a cabo o se rechaza. Se decide seguir o no seguir.

Dernie: Sí, exactamente. Debemos pensarlo como la última oportunidad y la debida diligencia antes del lanzamiento.

Cameron: Perfecto. Entonces, ¿en qué consiste exactamente? Parecen muchas pruebas, pero ¿qué es exactamente lo que implican las UAT? ¿Cómo se llega a las UAT?

Dernie: Yo diría que mediante la preparación. Mucha, mucha preparación. En especial desde el punto de vista de un BA, las UAT implican la planificación de la ejecución real de esos casos de prueba. ¿Quién hace qué? Confirmar los cronogramas. ¿Qué se probará? Gran parte de las UAT consiste en realizar un trabajo arduo. Hasta ese momento, en particular desde la perspectiva de negocios, y quizás también desde la perspectiva de un BA de Salesforce. No realiza las pruebas, pero sí la preparación y la coordinación. Mediante las UAT, el BA, los usuarios finales y las posibles partes interesadas del negocio prueban el sistema nuevo. Por último, una parte realmente importante de las UAT es la formalidad de conseguir la aprobación oficial de las UAT. Como el pase verde que has mencionado, estamos listos para avanzar.

Cameron: Entiendo. Dijiste que los analistas de negocios están muy involucrados en las UAT. Me gustaría saber cuál es, en la mayoría de los casos, la función de los BA en las UAT.

Dernie: Es una buena pregunta. Como mencioné antes, creo que los BA de Salesforce son el vínculo entre el negocio y los equipos de tecnología. Sus objetivos impulsan la claridad y la calidad de estos proyectos tecnológicos. Una parte fundamental para lograr esa calidad es la etapa de UAT del proyecto. Tiene el objetivo de asegurar que el producto o la mejora que se entrega realmente cumple con la calidad y las expectativas del negocio.

Cameron: Interesante. Según tu experiencia, ¿el BA siempre está a cargo de una UAT?

Dernie: Creo que puede variar mucho en función del equipo, proyecto o negocio. Pero puedo contarte lo que hace mi equipo aquí en Salesforce. Un ejemplo de lo que hacemos en la etapa de UAT es identificar quiénes son los evaluadores de las UAT. Como dije antes, pueden ser varios tipos de personas. El BA suele dirigir y coordinar las UAT. Suele escribir las secuencias de comandos de pruebas UAT, con los evaluadores definidos que van a aprobar. Finalmente, el BA también obtiene la firma oficial por escrito de las partes interesadas del negocio para confirmar que las secuencias de comandos de prueba abordan todas las expectativas. El BA suele validar que los datos están preparados para su ingreso en el sistema. Los BA de mi equipo suelen probar las funcionalidades clave con diferentes personas clave implicadas en el proyecto. Obviamente, el último paso es la coordinación de las UAT. En esta etapa, se aseguran de que haya una firma oficial por escrito antes del lanzamiento.

Cameron: Entiendo. Implica mucha preparación, pero parece que también, como has mencionado antes, un trabajo arduo.

Dernie: Sí, sin dudas.

Cameron: Genial. Digamos que tu perspectiva se vincula con el ecosistema de Salesforce, pero las UAT no son exclusivas de Salesforce. En teoría, podrías lanzar un producto o un proyecto que no se relaciona con Salesforce, pero las UAT siguen aplicadas, ¿verdad?

Dernie: Sí, así es.

Cameron: Solo para asegurarme.

Dernie: Y se trata de la misma idea. El motivo por el que es necesario llevarlas a cabo, ya sea en la plataforma de Salesforce o en una tecnología específica, es que es el último paso antes de que el negocio diga: "Sí, esto funciona y estamos listos para empezar".

Cameron: Es algo universal. No se aplica solo a Salesforce. Excelente. ¿Por qué un analista de negocios debe participar? Sé que se asemeja a la pregunta anterior. Sin embargo, al implicar mucha preparación, ¿qué puede pasar si un BA no participa?

Dernie: Para responder a tu pregunta, diré que el motivo por el que la función del BA es vital para las UAT es porque los BA entienden la funcionalidad y la intención del sistema en desarrollo. Si nos remontamos a una etapa anterior del proceso de un proyecto, sabemos que el BA desempeña un papel fundamental en las primeras etapas de los requisitos de negocio. Por lo tanto, si retrocedes en la fase del ciclo de vida del proyecto hasta las UAT, el BA se incluye con los contactos del proyecto. Por naturaleza, los BA también se centran mucho en los detalles y pueden ayudar a descubrir posibles problemas.

Cameron: Entonces, si tienes a alguien que se encarga solo de llevar a cabo las UAT, es posible que no conozca toda la historia ya que no participó en todas las reuniones previas a las UAT. Claro, eso tiene sentido.

Dernie: Sí, exactamente. El BA participa desde el comienzo del proyecto, se encarga de los requisitos y se compromete con el equipo del proyecto.

Cameron: Eso tiene sentido. ¿Cuáles son algunas de las mejores prácticas adicionales? Sé que tienes mucha experiencia con las UAT y las BAS. Y seguramente con muchos acrónimos adicionales. ¿Cuáles de las mejores prácticas adicionales que se llevan cabo en Salesforce les recomendarías a los BA que realizan sus primeras UAT o aprenden sobre ellas?

Dernie: Resumiré algunos de nuestros principales consejos. La número uno es la preparación. Mucha preparación da lugar a una UAT exitosa. A un alto nivel, cuando piensas en lo que debes tener en cuenta en la lista de comprobación básica al preparar una UAT, que incluye la identificación de recursos, con mi equipo de Salesforce creamos un canal de Slack de UAT donde decidimos y establecemos una cadencia de actualizaciones de estado. Por lo general, el BA crea un programa de UAT. Entonces, pensamos si para un proyecto en particular necesitamos una reunión inicial, planificar reuniones diarias, actualizaciones de estado o crear una clasificación. Se establece un proceso. Por ejemplo, un proceso para informar errores o hacer preguntas. ¿Cómo son estos procesos? Luego, se crea un caso de prueba. Determinamos los escenarios de prueba que queremos abordar y los pasos de la prueba. Por último, suele haber un punto de validación del entorno sandbox real en la que haremos las pruebas UAT. Observamos todo y nos preguntamos si los datos de prueba están listos. Se determina el entorno sandbox. A continuación, pensamos en programar una reunión como conclusión al final de las UAT para completar las pruebas de manera formal. También nos preparamos para eso. Es mucha preparación.

Cameron: Sí, tal vez no se tenga en cuenta gran parte de ese trabajo de backend, pero se debe llevar a cabo sin dudas.

Dernie: Sí, exactamente.

Cameron: Excelente. Terminemos con lo bueno. Compartamos una buena historia. Tanto como creas conveniente compartir. ¿Tuviste alguna experiencia en la que las UAT no se planificaron de manera adecuada? Seguramente no estabas a cargo porque hubiera sido un éxito. Sin embargo, ¿presenciaste alguna situación similar? ¿escuchaste alguna historia en la que una UAT no salió bien y lo que sucedió?

Dernie: Sí, claro. Definitivamente es estresante cuando las cosas salen mal y eso es comprensible. Pero creo que el punto clave que se debe tener en cuenta es que ese es el propósito de una UAT. Asegurarse de que el sistema funciona como esperan los usuarios finales, y a veces se descubren brechas. Claro que presencié situaciones en las que las UAT no eran lo suficientemente sólidas. Por ejemplo, faltaban casos de prueba clave y quizás los evaluadores no eran los adecuados. Tal vez lo eran. Sin embargo, identificamos personas que no conocían realmente la función o eran muy nuevas en ese ámbito. Un ejemplo fue un gran proyecto en el que participé. Las secuencias de comandos de prueba no se parecían a la vida real. Los evaluadores reales de la UAT no eran expertos en la materia ni usuarios finales. Luego sucedió que el negocio firmó la UAT. Sin embargo, cuando se puso en marcha el lanzamiento del sistema, se detectaron brechas importantes. En esta situación, hay otros fallos en el proceso del proyecto, sobre todo en las primeras etapas. Creo que, si se hubieran descubierto las brechas en las UAT y no se hubiera pasado el código para el lanzamiento, nos hubiéramos ahorrado mucho dinero y tiempo. El punto clave es que cuando las cosas salen mal en las UAT, si se realiza una buena planificación, es algo positivo.

Cameron: Claro, a veces puede parecer negativo que no se lance un proyecto, pero al mismo tiempo descubriste las brechas antes de su lanzamiento. Por lo que resulta ser algo positivo. Y parece que en tu historia no sucedió esto. No tuvo tanto éxito. Interesante. Resumamos lo que hemos hablado y retomemos los objetivos que dijimos que íbamos a repasar. Definitivamente abordamos lo que son las UAT y cómo se involucra un BA. Para resumir lo que mencionaste, la mayoría de las veces las dirige un analista de negocios ya que ha participado desde el primer paso hasta el último. ¿Por qué es importante una UAT para el éxito de un proyecto? Creo que abordamos correctamente esta pregunta con la última historia. Luego, nos proporcionaste muchas de las mejores prácticas. Muchas gracias por tu tiempo, Dernie. Lo valoramos enormemente. Creo que realmente aprendimos mucho sobre las UAT.

Dernie: Gracias, Cameron. Fue un placer volver a charlar contigo.

Cameron: Adiós.

Dernie: Adiós.