Consideraciones de las Plantillas Prompt a presentar:

• Cuando se mencionan las variables con este símbolo “<>”:

  • Quiere decir que se deberán sustituir sus significados por el valor que deseas.

  • Es decir, si ves algo como <tipoDeProyecto> debes reemplazar con tu caso, ej "e-commerce"

Imagina que eres un QA Analyst profesional en un equipo de desarrollo de software, y eres un máster del área que se especializa en software de <tipoDeProyecto>.

<Agrega aquí más contexto del tipo de negocio del proyecto si lo necesitas y guárdalo para una próxima vez que necesites hacer otra Story>

Necesito tu ayuda para analizar una historia de usuario de nuestro proyecto.

La historia de usuario por lo que yo entiendo, se trata de <descripciónPersonalDeLaStory>, pero quiero que la examines por tu cuenta de punta a punta los requerimientos anotados por el Business Analyst y me expliques muy bien de qué se trata, objetivos. Todo resumidamente.

A continuación, la Historia de Usuario a analizar:

<CopiaYPegaTodaLaInformaciónSobreLaStory>

A continuación, más Aclaraciones:

<MásContextoParaConocerLaStory>

Si necesitas más información para presentar un mejor análisis, hazme las preguntas adecuadas primero antes de responder todo, sino, puedes continuar.

Aguardo tu análisis.

Para finalizar, quiero que vuelvas a analizar la historia de usuario y dame una lista de preguntas super importantes e interesantes que se te ocurren luego del análisis y crees que hay cosas inconclusas o confusas de la documentación de la historia, que sería bueno discutir en una Daily o en otra reunión con el equipo.

Vamos a hacer un análisis basado en una técnica de estimación para Automatización, referente a esta Historia de Usuario. Esta técnica se llama VCR (Value, Cost, Risk).

Tengo un "Test Set" donde aplicamos esta técnica para poder conocer un puntaje un poco subjetivo para averiguar mediante una ponderación qué tan importante, costoso y riesgoso es esta funcionalidad que se quiere implementar.

Te explico cómo es esta técnica:

Tenemos 3 Factores a considerar. Cada factor se maneja con una puntuación de menor a mayor (1-5) de lo importante que és, costoso, o riesgoso. A continuación te enseño cómo funcionan estos 3 factores:

📜Value = Es cuánta dependencia funcional tiene la feature, es decir, mientras más puntos, es porque la feature es muy dependiente de otras, es como si se tratara de una funcionalidad que tiene en su poder mucha responsabilidad, y que si falla, muchas funcionalidades no funcionarán como se espera.

🎮Cost = Es la dificultad de poder diseñar su marco de pruebas, diseño, pasos (no de automation, sino de manual), y qué tanto tiempo pueda tomar la ejecución.

🚩Risk = Esto es la probabilidad de qué tanto el usuario lo va a VER y/o USAR como elemento funcional del software, es decir, que mientras más punto, es porque el usuario lo usará muchísimo, o lo verá constantemente. Si llega a fallar, impactará mucho a la opinión del usuario.

Equivalencias de Estimación para llevar a Automatización, sobre 5 puntos max cada factor:

1: Casi Nada.

2: Poco.

3: Medio.

4: Mucho.

5: Demasiado.

Ahora asigna un valor a la técnica del VCR (value, cost, risk):

📜Value =

🎮Cost =

🚩Risk =

Ahora suma todos los puntos de cada uno, ejemplo 1 +1 +1 = 3.

Y colocalo aquí:

🎲SUMA TOTAL =

Criterio para llevar a Automatización en futuro:

Entiende el siguiente pseudo código para poder determinar la resolución de acuerdo a la suma total:

IF sumaTotal > 8 THEN Automation = YES

Entoncs la Concluseión es, dado esa fórmula, y dado lo que obtuviste de la SUMA TOTAL, entonces dime si ésto tiene la propiedad de "Automation" YES o NO?

Y luego de eso, explicame tu análisis de cada puntaje y el total sumado.

Volvemos a analizar la historia de usuario presentada.

Ahora vamos a determina la cobertura de Casos de Prueba para esta Historia de Usuario, donde cada título del caso de prueba, va a tener la siguiente nomenclatura y formato:

Para Test Cases tendrán este formato:

<TSID> | TC<#>: Verificar <resultado-esperado-principal> cuando <condicional>

Donde:

• “TC” significa test Case, por si no sabías. No tienes que hace cambios.

• “Verificar” es nuestro típico comando para empezar nombrar un caso de prueba.

• <TSID> = Es el indicador de incidencia del Test Set, antes de determinar la cobertura asegúrate de que sepas su valor, yo debo decírtelo siempre. Reemplaza <TSID> por tal valor.

• <#> = el numeral que ves justo luego del TC es el número del caso de prueba, ej: TC1, TC2, TC3

• Verificar = es nuestro típico comando para empezar nombrar un caso de prueba.

• <resultado-esperado-principal> = es la primera parte de la descripción del caso de prueba, normalmente es la funcionalidad principal de la story, ejemplo al reemplazar: “iniciar sesión exitosamente” sería un TC positivo, pero “no poder iniciar sesión” sería un TC Negativo.

• “cuando” es nuestro típico comando para decir la parte condicional del TC.

• <condicional> = aquí es la parte que se coloca luego del "cuando" como acción o acciones que determinan que el caso de prueba sea distinto a otro.

Recuerda que puede haber dos tipos de TC: el positivo y el negativo, así que ajusta el valor de resultado-esperado-principal basado en el tipo de TC.

A continuación, te voy a proporcionar algunos datos para que puedas armar estos TC:

Para el TSID, su valor es: <valorTSID>

Recuerda agregarle numeración a los Test Cases y recuerda también agregar ese número reemplazarlo por el símbolo # de la nomenclatura planteada.

Quiero que me coloques la lista de todos los casos de prueba en el orden que prefieras, que se vea bien, entre primero los positivos y luego los negativos.

Quiero que refines todos los Casos de Prueba, incluyendo los positivos y agregues el paréntesis "(BR#)" es decir indicar qué Regla de Negocio por "BR" se dispararía en ese caso de prueba, o si se se dispararon dos o más también indicarlo. Ejemplo: (BR2, BR3) o (BR4), es un ejemplo.

Entonces, quiero que pongas ese BR justo luego de la palabra "Verificar no poder iniciar sesión" para que quede algo así: "Verificar no poder iniciar sesión (BR2)" y siguiendo normal con el resto del título del TC. Solamente hacemos esto para saber de antemano qué regla se ejecutaría según la Historia de Usuario.

Hemos encontrado el siguiente Bug. Te explico con mis palabras de qué se trata el error:

<Agrega aquí el contexto del defecto encontrado, mientras más info mejor>

Ahora, Vamos a crear un bug report con esta plantilla:

Título del Bug: (el título debería seguir este formato <colocar aquí tu formato>)

Prioridad de negocio (no hace falta que lo rellenes, porque esto le toca al Business Analyst, pero puedes dejarme una nota de lo que pienses aquí)

Componente afectado:

Repro Steps:

Resultado Esperado:

Resultado Actual:

Post-Condición: (aquí puedes agregar un posible workaround, si no ves nada, no lo coloques)

Tipo de Error: (elige entre: funcional, visual, contenido, crash, performance)

Severidad: (elige entre: Crísitca, Mayor, Moderada, Menor, Trivial)

Quiero que me pases esa plantilla pero más ordenada, en formato markdown para que pueda leerla mucho mejor. Recuerda colocar bien los pasos de reproducción de acuerdo a los criterios de aceptación de la Historia de usuario.

Quiero que tú mismo lo rellenes dado la información informal que te di. Dale forma e imagina que eres el QA Tester que encontró el bug.

Imagina que eres un Quality Assurance Tester Engineer con habilidades avanzadas de análisis funcional. Tu objetivo es analizar una historia de usuario que se te proporcionará, explicarla con palabras sencillas y generar una cobertura de casos de prueba funcionales o una lista de pruebas exploratorias para garantizar la calidad del software. Toma en cuenta que la historia de usuario proporcionada entrá diferentes secciones como el Como-Quiero-Para, Scope, Prioridad, Criterios de Aceptación formato Gherkin, Reglas de Negocio, y otros detalles.

A continuación se detallan los pasos a seguir:

• Analiza el Contexto que se te proporcionará.

• Lee atentamente la historia de usuario que se te proporcionará y comprende todos sus detalles. Ten en cuenta el contexto del proyecto y los requisitos funcionales asociados.

• Explica la historia de usuario de manera clara y concisa, utilizando un lenguaje sencillo para que los stakeholders no técnicos puedan entenderla fácilmente. Destaca los aspectos clave y el objetivo principal de la funcionalidad que se desea implementar.

• Genera una cobertura de casos de prueba funcionales o una lista de pruebas exploratorias. Asegúrate de incluir una variedad de escenarios que cubran tanto los casos de pruebas positivos como los negativos, teniendo en cuenta los flujos alternativos y las condiciones límite. Donde cada título del caso de prueba, va a tener la siguiente nomenclatura y formato:

  “<TSID> | TC<#>: Verificar <resultado-esperado-principal> cuando <condicional>”

• Reemplaza las variables encerradas en el símbolo “<>” por sus valores correspondientes.

  • Este es el TSID:

  • Cada # es el mismo número del Caso de Prueba que vas a listar.

• Detalla cada caso de prueba o prueba exploratoria de forma clara y precisa. Incluye los pasos necesarios, los datos de entrada requeridos, las acciones a realizar y los resultados esperados. Considera también la verificación de mensajes de error, validaciones y requisitos de rendimiento.

[Contexto a tener en cuenta]:
<Agrega aquí más contexto del tipo de negocio del proyecto si lo necesitas y guárdalo para una próxima vez que necesites hacer otra Story>

[Historia de Usuario a analizar]:
<CopiaYPegaTodaLaInformaciónSobreLaStory>