tutorial sesion iniciar español jira testcase

sesion - jira tutorial español



Jira como herramienta de gestión de casos de prueba (10)

Actualmente utilizamos la herramienta TestLodge Test Case para gestionar nuestros casos y requisitos de prueba y se integra con Jira para crear pruebas de casos de prueba fallidos.

He revisado varias soluciones de administración de casos de prueba disponibles para Jira, tales como:

Me preguntaba si es posible expandir aún más esta solución de administración de casos de prueba. Estoy buscando una solución Jira para tener:

  • Requerimientos
  • Casos de prueba (que van bajo requisitos)
  • Informes de prueba (que van bajo casos de prueba)

Los enlaces publicados anteriormente solo ignoran la parte de "Requisitos" y se centran solo en los casos de prueba y los informes de prueba. Cada herramienta de administración de casos de prueba que he usado antes tiene estas características como HP QualityCenter.

¿Es posible lograr esto en Jira?

TIA

Después de haber pasado las últimas semanas intentando configurar Jira para la gestión de casos de prueba, puedo ofrecer el beneficio de mi experiencia. Las instrucciones mencionadas anteriormente ( http://confluence.atlassian.com/display/CONFEVAL/Customise+JIRA+For+Test+Case+Management ) están defectuosas e incompletas, por lo que debe estar prevenido. El hilo de casos de prueba de Jira en los foros de Atlassian es muy útil.

Edición: este enlace está roto, los "foros" de Atlassian ya no están en uso. Utilice este enlace: Personalice Jira para la administración de casos de prueba .

  1. Las instrucciones son para Jira 3.x. La versión más reciente es 4.2. Hay diferencias.
  2. Paso 5, "Campos personalizados" tiene nombres de campo incorrectos. La primera instancia de "Pasos para completar" debe tener el nombre "Resultado real".
  3. El paso 8.2 requiere que asigne el paso "Crear problema" a "Crear pantalla de caso de prueba". Dado que no ha creado ningún flujo de trabajo o pasos, esto será difícil. Deberá volver a este paso después de finalizar el paso 9.
  4. Paso 9, "Flujo de trabajo personalizado" es profundamente confuso. Se le indica que cree nuevos estados dos veces (Paso 9.1 y Paso 9.4 / 5). En el Paso 9.1 desea crear nuevos "Estados", no "Estados". En el Paso 9.4 / 5 desea crear nuevos "Pasos", no "Estados". Paso
  5. Crear nuevos Pasos requiere que se creen nuevas Transiciones. Cada Transición unirá dos pasos. Necesitará crear las transiciones a medida que crea los pasos.

Hay muchos más errores en los documentos, así que asegúrese de estar cómodo con los flujos de trabajo de Jira y las diversas entidades antes de comenzar. También recomiendo guardar notas cuidadosas.

En nuestro equipo, tenemos un departamento de control de calidad que ha estado usando control de calidad (y lo sigue utilizando en algunos proyectos) y estamos utilizando una organización problemática como esta:

Nivel superior

  • Requisito - capturar la historia del usuario real. Creado por BA, asignado a DEV lead, propiedad de BA.
  • Incidente : captura de un problema que ocurrió con un sistema de producción. Creado por BA / operations, asignado a QA, propiedad de BA.
  • Paquete binario : creado y propiedad del equipo de implementación para rastrear el ciclo de vida de cada paquete binario producido. Hasta ahora estamos rastreando las implementaciones y cambiando las tareas como comentarios, pero si quisiéramos ser más precisos, también podríamos haber utilizado problemas secundarios por separado.
  • Ronda de prueba : nivel superior: por lo general, con el propósito de informar, desea separar los artefactos producidos por cada ejecución / fase de prueba de su equipo de control de calidad. Los problemas de ejecución de prueba son contenedores de defectos.
  • Caso de prueba : creado, asignado y propiedad del gerente de control de calidad. Aquí tienes elección:
    • definido como un problema de nivel superior: puede vincularlo a requisitos, requisitos múltiples o crear un modo independiente (por ejemplo, para capturar un escenario de regresión no rastreado en JIRA).
    • definido como subtarea: lo limita a un padre, pero aún puede vincular los requisitos / incidentes relacionados. La gran diferencia es que esto lo obliga a rastrear el motivo de cada prueba en JIRA.
    • para muchos proyectos todavía mantenemos los casos de prueba en el control de calidad y solo rastreamos los defectos en JIRA.

Subtareas

  • Desarrollo (bajo Requisito): creado por el líder de DEV, asignado al equipo de DEV, propiedad del equipo de DEV. Describir un trabajo o parte del caso de uso que se estima y asigna a una sola persona.
  • Defecto (bajo Prueba-Ronda o Incidente), creado por QA / DEV, asignado a DEV Team, propiedad de QA. Describiendo el defecto aislado. Para la mayoría de los propósitos, se trata de la misma manera que el Desarrollo, excepto que QA debe confirmarla y cerrarla.
  • Ejecución de prueba : documenta los resultados de una única ejecución de prueba. Todavía encontramos que QC es una mejor herramienta para esto, aunque JIRA también puede funcionar, especialmente si escribimos algunos complementos.

Todos estos tipos de problemas utilizan un flujo de trabajo casi estándar (con un paso de confirmación de control de calidad agregado para el tipo de problema de defecto) y algunos campos personalizados. Estábamos considerando un enfoque alternativo del uso de proyectos separados para QA y DEV, en cuyo caso podríamos haber usado versiones en lugar del tipo de problema de Ronda de Prueba, pero por varias razones decidimos no hacerlo (déjeme saber si está interesado, puedo explicarlo) .

Hace unas semanas, JIRA implementó recientemente una "característica" que prefijará todos los clones de subtareas con la palabra "CLONE -". Este no solía ser el caso, y si está utilizando JIRA Studio, no hay una solución adecuada para este problema. Entonces, lo que funcionó bien para nosotros ahora significa que necesitamos usar una herramienta dedicada.

es decir, si está utilizando el método documentado de tener ciclos de control de calidad que contienen un conjunto de casos de prueba que son de un tipo de subtarea, entonces, cuando clone un ciclo de control de calidad para una nueva ejecución de prueba, todos sus casos de prueba se anularán con palabra "CLONE -".

En mi caso, voy a cambiar a una herramienta de gestión de pruebas dedicada ahora.

Prueba los complementos de Kanoah Tests.

Es una solución integral de gestión de pruebas especialmente diseñada para JIRA.

Visite: www.kanoah.com sitio web para más información

Puede almacenar fácilmente los requisitos como problemas de JIRA de nivel superior; muchos proyectos ágiles que utilizan el método de "historia de usuario" para documentar los requisitos hacen esto. Almacenaría los casos de prueba como problemas de JIRA de nivel superior y los vincularía con los requisitos a los que se relacionan, en lugar de convertirlos en subtareas de los requisitos; esto da flexibilidad si un caso de prueba puede aplicarse a más de un requisito, por ejemplo.

Si tiene todos sus casos de prueba como problemas de JIRA individuales, puede crear un informe de prueba como una subtarea para cada caso cada vez que realice una ejecución de prueba. Para hacerlo más sencillo, realmente necesita una instalación de clonación masiva en JIRA donde pueda clonar todos los informes de prueba que desee ejecutar de nuevo, pero no he podido averiguar cómo hacerlo en JIRA.

Recomendaría Zephyr para JIRA, que es un excelente complemento de administración de pruebas que se integra bien con JIRA. Le permite mantener paquetes de casos de prueba y ejecuciones además de la administración de Epic / User Story.

http://getzephyr.com/

El equipo al que me mudé recientemente se había configurado recientemente y no había utilizado ninguna herramienta TM como tal (utilizaron JIRA para el registro de defectos y Excel para mantener TC). Vi una oportunidad para investigar el mercado y comencé a buscar una herramienta que podría encajar y proporcionar más flexibilidad en la gestión de ciclos de prueba.

Zephyr está perfectamente incrustado en las pantallas de JIRA y la apariencia es exactamente igual a la de JIRA. Por lo tanto, si el equipo ya está utilizando JIRA para el registro de problemas / defectos, el aprendizaje de Zephyr no agrega ninguna complejidad al introducir una nueva herramienta a la mezcla.

He usado HP ALM (y QC cuando se llamaba así) para nuestros programas anteriores. Ahora que el impulso es ir ágil, encontramos que ALM es un poco incómodo para Agile ... Puede que esté equivocado, pero después de Zephyr / JIRA optamos por quedarnos con Zephyr para la gestión de pruebas;)

En mi evaluación, Zephyr para JIRA está funcionando bastante bien para nosotros. Hice un POC utilizando uno de los scrums en los que trabajo (¡es un gran programa de 6 scrums diferentes!) Y ahora he comenzado a distribuirme a otros equipos y también les gustó la idea y toda la configuración. El punto de precios tampoco es tan alto.

PD: estamos utilizando Zephyr para el servidor JIRA.

Espero que esta información ayude.

¡Aclamaciones!

Somos expertos de Atlassian Enterprise y Platinum y, si bien puede personalizar JIRA para que se use como una herramienta básica de gestión de pruebas, debe darse cuenta de que se destaca como una herramienta de gestión de incidentes, una herramienta de gestión de tareas y una herramienta de gestión ágil (con el complemento Agile de JIRA ).

Nunca fue diseñado para ser una herramienta de administración de casos de prueba y, como tal, no proporciona la funcionalidad que usted esperaría de una herramienta de administración de prueba pura. Cosas como informes de cobertura, historial de ejecución de pruebas y administración de pruebas manuales y automatizadas en un solo lugar.

Trabajo para Catch Software ( http://www.catchsoftware.com ), creamos Enterprise Tester, una herramienta de gestión de pruebas basada en la web que cuenta con la integración de JIRA líder en el mercado.

Esta integración le permite generar automáticamente resguardos de casos de prueba a partir de historias de JIRA, crear automáticamente problemas de JIRA a partir de ejecuciones de prueba y le permite colocar gadgets de informe en JIRA o Confluence para que su equipo de administración pueda ver todas las métricas en un solo lugar.

Obtiene una herramienta de administración de pruebas que se integra a la perfección (sin necesidad de plugin) con su instancia JIRA interna o OnDemand.

Así que verifique sus necesidades de prueba y si necesita información básica sobre pruebas, podemos ayudarlo con una solución JIRA creada o si necesita una herramienta de administración de pruebas más especializada, no dude en consultar Enterprise Tester ( http://www.enterprisetester.com )

Saludos Bryce

Sugeriría la herramienta qTest Test Case Management de QASymphony . La integración de JIRA es la mejor en su clase. Puede controlar todos los esfuerzos de desarrollo, ya sean historias, tareas o tareas secundarias de JIRA (o tipos de problemas personalizados) y desarrollar la trazabilidad de aquellos a través de la herramienta al asociarles casos de prueba. En última instancia, le permite generar informes de un solo clic.

Todos sus casos de prueba manuales se pueden almacenar allí, los esfuerzos de automatización pueden centralizarse, y también hay una herramienta de documentación ingeniosa para UAT y pruebas exploratorias. La herramienta también se integra en el nivel de defectos, lo que permite a los evaluadores enviar los problemas de JIRA directamente a JIRA desde las ejecuciones de prueba para que el desarrollo pueda trabajar en ellas. Esencialmente, JIRA puede continuar usándose para los esfuerzos de desarrollo y planificación, pero todos los esfuerzos de prueba pueden abordarse dentro de la MTC. Con esta ingeniosa integración de JIRA en una herramienta de escala empresarial, todo el proceso SDLC está más simplificado.