defect severity priority testing with examples
En este tutorial, aprenderá qué es la gravedad y prioridad de los defectos en las pruebas, cómo establecer la prioridad y los niveles de gravedad de los defectos con ejemplos para comprender el concepto con claridad.
También cubriremos en detalle cómo clasificar los defectos en diferentes categorías y su relevancia en el ciclo de vida de los defectos. También cubriremos el papel crucial de la clasificación con un conjunto de ejemplos en vivo.
La presentación de defectos es una parte integral parte del ciclo de vida de las pruebas de software . Hay varias mejores prácticas definidas para Notificación eficaz de defectos a través de Internet o en organizaciones.
cómo abrir el archivo json en windows
Lo que vas a aprender:
- Descripción general del seguimiento de defectos
Descripción general del seguimiento de defectos
Uno de los aspectos importantes del ciclo de vida de los defectos en un nivel genérico incluye el seguimiento de defectos. Esto es importante porque los equipos de prueba abren varios defectos cuando prueban una pieza de software que solo se multiplica si el sistema particular bajo prueba es complejo. En tal escenario, manejar estos defectos y analizarlos para impulsar el cierre puede ser una tarea abrumadora.
De acuerdo con los procesos de mantenimiento de defectos, cuando cualquier probador presenta un defecto, además del método / descripción para reproducir el problema visto, también debe proporcionar alguna información categórica que ayude a una clasificación inexacta del defecto. Esto, a su vez, ayudaría en procesos eficientes de seguimiento / mantenimiento de defectos y también formaría la base para un tiempo de respuesta de defectos más rápido.
Los dos parámetros principales que forman la base para un seguimiento y resolución de defectos efectivos son:
- Prioridad de defectos en las pruebas
- Severidad de defectos en las pruebas
Estos suelen ser un concepto confuso y casi se usan indistintamente no solo entre los equipos de prueba sino también entre los equipos de desarrollo. Existe una delgada línea entre los dos y es importante comprender que, de hecho, existen diferencias entre los dos.
Entendamos brevemente las definiciones teóricas de los dos parámetros en la siguiente sección.
¿Qué es la gravedad y la prioridad de los defectos?
La prioridad según la definición en inglés se usa en la comparación de dos cosas o condiciones, donde a una se le debe dar más importancia que la otra (s) y se debe abordar / resolver primero antes de pasar a la (s) siguiente (s). Por lo tanto, en el contexto de los defectos, la prioridad de un defecto indicaría la urgencia con la que sería necesario corregirlo.
La severidad según la definición inglesa se usa para describir la gravedad de un suceso indeseable. Por lo tanto, cuando se trata de errores, la gravedad de un error indicaría el efecto que tiene en el sistema en términos de su impacto.
¿Quién los define?
QA clasifica el defecto con la gravedad adecuada en función de la complejidad y criticidad de los defectos.
Todas las partes interesadas del negocio, incluidos los gerentes de proyecto, los analistas comerciales y el propietario del producto, definen la prioridad de los defectos.
La siguiente figura muestra el rol que posee y clasifica la criticidad y severidad de los defectos.
¿Cómo elegir estos niveles?
Como ya hemos comentado, el evaluador evalúa el parámetro de gravedad, mientras que el parámetro de prioridad lo evalúa principalmente el Gerente de Producto o básicamente el equipo de clasificación. Incluso si este es el caso, la gravedad de un defecto es definitivamente uno de los factores que gobiernan e influyen para priorizar el defecto. Por lo tanto, es importante como evaluador seleccionar la gravedad correcta para evitar confusiones con los equipos de desarrollo.
Diferencia entre gravedad y prioridad
La prioridad está asociada con la programación y la 'gravedad' está asociada con los estándares.
“Prioridad” significa que algo se otorga o merece atención previa; precedencia establecida por orden de importancia (o urgencia).
'Severidad' es el estado o la calidad de ser severo; severo implica adherencia a estándares rigurosos o principios elevados y, a menudo, sugiere dureza; severo está marcado o requiere una estricta adherencia a estándares rigurosos o principios elevados, Por ejemplo, un código de conducta severo.
Las palabras prioridad y gravedad aparecen en el seguimiento de errores.
Se encuentra disponible una variedad de herramientas comerciales de software de seguimiento / gestión de problemas. Estas herramientas, con la información detallada de los ingenieros de pruebas de software, brindan al equipo información completa para que los desarrolladores puedan comprender el error, hacerse una idea de su 'gravedad', reproducirlo y solucionarlo.
Las correcciones se basan en las 'prioridades' y la 'gravedad' de los errores del proyecto.
La 'gravedad' de un problema se define de acuerdo con la evaluación de riesgos del cliente y se registra en la herramienta de seguimiento seleccionada.
El software defectuoso puede afectar 'severamente' los horarios, lo que, a su vez, puede conducir a una reevaluación y renegociación de las 'prioridades'.
¿Qué es la prioridad?
La prioridad, como su nombre indica, se trata de priorizar un defecto en función de las necesidades comerciales y la gravedad del defecto. Prioridad significa la importancia o urgencia de reparar un defecto.
Al abrir un defecto, el evaluador generalmente asigna la prioridad inicialmente cuando ve el producto desde la perspectiva del usuario final. En consonancia con estos, existen diferentes niveles:
En términos generales, la prioridad de los defectos se puede clasificar de la siguiente manera:
Prioridad # 1) Inmediato / Crítico (P1)
Esto debe solucionarse de inmediato en un plazo de 24 horas. Esto generalmente ocurre en los casos en que una funcionalidad completa está bloqueada y no se pueden realizar pruebas como resultado de esto. O en algunos otros casos, si hay pérdidas de memoria importantes, generalmente el defecto se clasifica como una prioridad -1, lo que significa que el programa / función no se puede utilizar en el estado actual.
Cualquier defecto que necesite atención inmediata que afecte el proceso de prueba se clasificará en la categoría inmediata.
Todos Severidad crítica los defectos entran en esta categoría (a menos que la empresa o las partes interesadas vuelvan a priorizarlos)
Prioridad # 2) Alta (P2)
Una vez que se han corregido los defectos críticos, un defecto que tenga esta prioridad es el próximo candidato que debe corregirse para que cualquier actividad de prueba coincida con los criterios de 'salida'. Normalmente, cuando una función no se puede utilizar como se supone que debe ser, debido a un defecto del programa, o cuando se debe escribir un nuevo código o, a veces, incluso porque algún problema ambiental debe manejarse a través del código, un defecto puede calificar para una prioridad 2 .
Este es el defecto o problema que debe resolverse antes de que se haga el lanzamiento. Estos defectos deben resolverse una vez que se resuelvan los problemas críticos.
Todos Importante gravedad los defectos entran en esta categoría.
Prioridad # 3) Media (P3)
Un defecto con esta prioridad debe estar en disputa para ser solucionado, ya que también podría lidiar con problemas de funcionalidad que no se ajustan a las expectativas. A veces, incluso los errores cosméticos, como esperar el mensaje de error correcto durante la falla, podrían calificar como un defecto de prioridad 3.
Este defecto debería resolverse después de que se corrijan todos los errores graves.
Una vez finalizados los errores críticos y de prioridad alta, podemos optar por los errores de prioridad media.
Todos Menor gravedad los defectos entran en esta categoría.
Prioridad # 4) Baja (P4)
Un defecto con baja prioridad indica que definitivamente hay un problema, pero no es necesario solucionarlo para que coincida con los criterios de 'salida'. Sin embargo, esto debe arreglarse antes de que se realice la GA. Por lo general, algunos errores tipográficos o incluso errores cosméticos, como se discutió anteriormente, podrían clasificarse aquí.
A veces, los defectos con prioridad baja también se abren para sugerir algunas mejoras en el diseño existente o una solicitud para implementar una pequeña función para mejorar la experiencia del usuario.
Este defecto puede resolverse en el futuro y no necesita ninguna atención inmediata y el Gravedad baja los defectos entran en esta categoría.
Como ya se ha comentado, la prioridad determina qué tan rápido debe ser el tiempo de respuesta del defecto. Si hay varios defectos, la prioridad decide qué defecto debe corregirse y verificarse inmediatamente frente a qué defecto puede corregirse un poco más tarde.
¿Qué es la gravedad?
La gravedad define el grado en el que un defecto en particular podría generar un impacto en la aplicación o el sistema.
La severidad es un parámetro para denotar la implicación del defecto en el sistema: ¿qué tan crítico es el defecto y cuál es el impacto del defecto en la funcionalidad de todo el sistema? La severidad es un parámetro establecido por el probador mientras abre un defecto y está principalmente en control del probador. Una vez más, diferentes organizaciones tienen diferentes herramientas para usar en caso de defectos, pero en un nivel genérico, estos son los siguientes niveles de gravedad:
Por ejemplo, Considere los siguientes escenarios
- Si el usuario intenta realizar compras en línea y la aplicación no se carga o aparece un mensaje de servidor no disponible.
- El usuario realiza la adición de un artículo al carrito, la cantidad de cantidades agregadas es incorrecta / se agrega un producto incorrecto.
- El usuario realiza el pago y después del pago, el pedido permanece en el carrito como reservado en lugar de confirmado.
- El sistema acepta el pedido pero finalmente lo cancela después de media hora debido a cualquier problema.
- El sistema acepta 'Agregar al carrito' solo con un doble clic en lugar de con un solo clic.
- El botón Agregar al carrito se escribe como Agregar al carrito.
¿Cuál sería la experiencia del usuario, si pudiera ocurrir alguno de los escenarios anteriores?
En términos generales, los defectos se pueden clasificar de la siguiente manera:
# 1) Crítico (S1)
Un defecto que obstaculice o bloquee completamente la prueba del producto / característica es un defecto crítico. Un ejemplo sería en el caso de las pruebas de IU, donde después de pasar por un asistente, la IU simplemente se cuelga en un panel o no avanza para activar la función. O en algunos otros casos, cuando la característica desarrollada en sí misma falta en la compilación.
Por cualquier motivo, si la aplicación falla o se vuelve inutilizable / no se puede continuar, el defecto podría clasificarse como de gravedad crítica.
Cualquier falla catastrófica del sistema podría llevar al usuario a la imposibilidad de usar las aplicaciones y podría clasificarse en la categoría de gravedad crítica.
Por ejemplo, En el proveedor de servicios de correo electrónico como Yahoo o Gmail, después de escribir el nombre de usuario y la contraseña correctos, en lugar de iniciar sesión, el sistema se bloquea o arroja el mensaje de error, este defecto se clasifica como crítico ya que este defecto inutiliza toda la aplicación.
El escenario del punto 1 discutido anteriormente podría clasificarse como Defecto Crítico, ya que la aplicación en línea se vuelve completamente inutilizable.
# 2) Mayor (S2)
Cualquier característica principal implementada que no cumpla con sus requisitos / casos de uso y se comporte de manera diferente a lo esperado, se puede clasificar en Gravedad mayor.
Un defecto importante ocurre cuando la funcionalidad está funcionando muy lejos de las expectativas o no está haciendo lo que debería estar haciendo. Un ejemplo podría ser: Supongamos que es necesario implementar una VLAN en el conmutador y está utilizando una plantilla de interfaz de usuario que activa esta función. Cuando esta plantilla para configurar VLAN falla en el conmutador, se clasifica como un grave inconveniente de funcionalidad.
Por ejemplo, En el proveedor de servicios de correo electrónico como Yahoo o Gmail, cuando no se le permite agregar más de un destinatario en la sección CC, este defecto se clasifica como el defecto mayor ya que la funcionalidad principal de la aplicación no funciona correctamente.
Lo que se espera es el comportamiento de la sección CC en el correo, debe permitir al usuario agregar varios usuarios. Entonces, cuando la funcionalidad principal de la aplicación no funciona correctamente o cuando se comporta de manera diferente a lo esperado, es un defecto importante.
Los escenarios en los puntos 2 y 3 discutidos anteriormente podrían clasificarse como Defecto Mayor, ya que se espera que el pedido se mueva sin problemas a la siguiente fase del ciclo de vida del pedido, pero en realidad, su comportamiento varía.
Cualquier defecto que pueda dar lugar a una persistencia de datos incorrecta, problemas de datos o comportamientos de aplicaciones incorrectos podría clasificarse en términos generales en la categoría de gravedad Mayor.
# 3) Menor / Moderado (S3)
Cualquier característica implementada que no cumpla con sus requisitos / casos de uso y se comporte de manera diferente a lo esperado, pero el impacto es insignificante hasta cierto punto o no tiene un impacto importante en la aplicación, puede clasificarse en Severidad menor.
Un defecto moderado ocurre cuando el producto o la aplicación no cumple con ciertos criterios o aún presenta algún comportamiento antinatural; sin embargo, la funcionalidad en su conjunto no se ve afectada. Por ejemplo, en la implementación de la plantilla de VLAN anterior, se produciría un defecto moderado o normal cuando la plantilla se implementa correctamente en el conmutador, sin embargo, no hay ninguna indicación de que se envíe al usuario.
Por ejemplo, En el proveedor de servicios de correo electrónico como Yahoo o Gmail, hay una opción llamada 'Términos y condiciones' y en esa opción, habrá varios enlaces con respecto a los términos y condiciones del sitio web, cuando uno de los múltiples enlaces no funciona bien, se denomina gravedad menor ya que solo afecta la funcionalidad menor de la aplicación y no tiene un gran impacto en la usabilidad de la aplicación.
El escenario en el punto 5 discutido anteriormente podría clasificarse como Defecto menor, ya que no hay pérdida de datos o falla en el orden de flujo del sistema, pero sí un pequeño inconveniente en lo que respecta a la experiencia del usuario.
Estos tipos de defectos dan como resultado una pérdida mínima de funcionalidad o experiencia del usuario.
# 4) Bajo (S4)
Cualquier defecto cosmético, incluidos los errores ortográficos o los problemas de alineación o la carcasa de la fuente, se pueden clasificar en Gravedad baja.
Se produce un error menor de gravedad baja cuando casi no hay impacto en la funcionalidad, pero sigue siendo un defecto válido que debe corregirse. Ejemplos de esto podrían incluir errores ortográficos en los mensajes de error impresos a los usuarios o defectos para mejorar la apariencia de una función.
Por ejemplo, En el proveedor de servicios de correo electrónico como Yahoo o Gmail, habría notado la 'Página de licencia', si hay algún error ortográfico o desalineación en la página, este defecto se clasifica como Bajo.
El escenario en el punto 6 discutido anteriormente podría clasificarse como Defecto bajo, ya que el botón Agregar se muestra en la carcasa incorrecta. Este tipo de defecto no tendrá ningún impacto en el comportamiento del sistema o la presentación de datos o la pérdida de datos o el flujo de datos o incluso la experiencia del usuario, pero será muy cosmético.
Para resumir, la siguiente figura muestra la amplia clasificación de defectos basada en la gravedad y la prioridad:
Ejemplos
Como ya se mencionó, dado que diferentes organizaciones utilizan diferentes tipos de herramientas para el seguimiento de defectos y sus procesos relacionados, se convierte en un sistema de seguimiento común entre los distintos niveles de gestión y el personal técnico.
Dado que la gravedad del defecto está más dentro del ámbito de la funcionalidad, el ingeniero de pruebas establece la gravedad del defecto. A veces, los desarrolladores intervienen en influir en la gravedad del defecto, pero sobre todo depende del evaluador, ya que evalúa cuánto puede afectar una característica en particular al funcionamiento general.
Por otro lado, cuando se trata de establecer la prioridad de defectos, Aunque inicialmente, el originador del defecto establece la prioridad, en realidad la define el Product Manager, ya que tiene una visión general del producto y la rapidez con que se debe abordar un defecto en particular. . Un evaluador no es la persona ideal para establecer la prioridad de los defectos.
Por sorprendente que parezca, hay dos ejemplos distintos de por qué:
Ejemplo 1) Tenga en cuenta que existe una situación en la que el usuario encuentra un error en el nombre del producto en sí o algún problema con la documentación de la interfaz de usuario. Un probador normalmente abriría un defecto menor / cosmético y puede ser muy simple de solucionar, pero cuando se trata de la apariencia del producto / experiencia del usuario, podría causar un impacto grave.
Ejemplo # 2) Puede haber ciertas condiciones bajo las cuales ocurre un defecto en particular que puede ser una posibilidad extremadamente rara o nula en el entorno del cliente. Aunque en términos de funcionalidad, esto puede parecer un defecto de alta prioridad para un evaluador, considerando su rareza de ocurrencia y alto costo de reparación, esto se clasificaría como un defecto de baja prioridad.
Por lo tanto, en efecto, la prioridad de defectos generalmente la establece el gerente de producto en una reunión de “clasificación de defectos”.
Niveles diferentes
La prioridad y la gravedad tienen algunas clasificaciones entre ellas que ayudan a determinar cómo se debe manejar el defecto. Muchas organizaciones diferentes han diferentes herramientas de registro de defectos , por lo que los niveles pueden variar.
Echemos un vistazo a los diferentes niveles de Prioridad y Gravedad.
- Prioridad alta, severidad alta
- Prioridad alta, gravedad baja
- Severidad alta, prioridad baja
- Gravedad baja, prioridad baja
La siguiente figura muestra la clasificación de las categorías en un solo fragmento.
# 1) Alta severidad y alta prioridad
Cualquier falla en un caso de negocios crítico / importante se promueve automáticamente a esta categoría.
Cualquier defecto por el cual la prueba no pueda continuar a ningún costo o cause una falla severa del sistema para caer en esta categoría. Por ejemplo, hacer clic en un botón en particular no carga la función en sí. O realizar una función en particular hace que el servidor se caiga de manera constante y cause la pérdida de datos. Las líneas rojas en la figura anterior indican este tipo de defectos.
Por ejemplo,
El sistema se bloquea después de realizar el pago o cuando no puede agregar los artículos al carrito, este defecto se marca como defecto de alta gravedad y alta prioridad.
Otro ejemplo sería la función de moneda expendedora de cajeros automáticos en la que, después de ingresar el nombre de usuario y la contraseña correctos, la máquina no dispensa dinero sino que deduce el dinero transferido de su cuenta.
# 2) Alta prioridad y baja gravedad
Cualquier defecto de gravedad menor que pueda afectar directamente la experiencia del usuario se promueve automáticamente a esta categoría.
Los defectos que deben solucionarse pero que no afectan a la aplicación se incluyen en esta categoría.
Por ejemplo, Se espera que la función muestre un error particular al usuario con respecto a su código de retorno. En este caso, funcionalmente el código arrojará un error, pero el mensaje deberá ser más relevante para el código de retorno generado. Las líneas azules de la figura indican este tipo de defectos.
Por ejemplo,
El logo de la empresa en la portada es incorrecto, se considera Alta prioridad y baja gravedad defecto .
Ejemplo 1) En el sitio web de compras en línea, cuando el logotipo de FrontPage está mal escrito, por ejemplo, en lugar de Flipkart, se escribe Flipkart.
Ejemplo 2) En el logotipo del banco, en lugar de ICICI, está escrito como ICCCI.
En términos de funcionalidad, no está afectando nada por lo que podemos marcar como de Baja Severidad, pero tiene un impacto en la experiencia del usuario. Este tipo de defecto debe corregirse con alta prioridad a pesar de que tienen un impacto muy menor en el lado de la aplicación.
# 3) Alta severidad y baja prioridad
Cualquier defecto que no cumpla funcionalmente con los requisitos o que tenga implicaciones funcionales en el sistema, pero que las partes interesadas hayan dejado de lado cuando se trata de la criticidad del negocio, se promociona automáticamente a esta categoría.
Defectos que deben repararse pero no de inmediato. Esto puede ocurrir específicamente durante las pruebas ad-hoc. Significa que la funcionalidad se ve afectada en gran medida, pero se observa solo cuando se utilizan ciertos parámetros de entrada poco comunes.
Por ejemplo, una funcionalidad particular se puede usar solo en una versión posterior del firmware, por lo que para verificar esto, el probador realmente degrada su sistema y realiza la prueba y observa un problema de funcionalidad grave que es válido. En tal caso, los defectos se clasificarán en esta categoría indicada por líneas rosadas, ya que normalmente se espera que los usuarios finales tengan una versión superior del firmware.
Por ejemplo,
En un sitio de redes sociales, si se lanza una versión beta de una nueva función sin muchos usuarios activos que utilicen esa función a día de hoy. Cualquier defecto que se encuentre en esta función se puede clasificar como de baja prioridad, ya que la función pasa a un segundo plano debido a la clasificación comercial como no importante.
Aunque esta característica tiene un defecto funcional, ya que no afecta directamente a los clientes finales, una parte interesada comercial puede clasificar el defecto como de baja prioridad, aunque tiene un impacto funcional severo en la aplicación.
Esta es una falla de alta gravedad, pero se puede priorizar a baja prioridad, ya que se puede solucionar con la próxima versión como una solicitud de cambio. Las partes interesadas del negocio también dan prioridad a esta función como una función que se usa con poca frecuencia y no afectan a ninguna otra función que tenga un impacto directo en la experiencia del usuario. Este tipo de defecto se puede clasificar en el Severidad alta pero prioridad baja categoría.
# 4) Baja gravedad y baja prioridad
Cualquier error de ortografía / mayúsculas y minúsculas / desalineación en el párrafo del 3rdo 4thpágina de la aplicación y no en la página principal o portada / título.
Estos defectos se clasifican en las líneas verdes como se muestra en la figura y ocurren cuando no hay impacto en la funcionalidad, pero aún no cumplen con los estándares en un pequeño grado. En general, los errores cosméticos o, por ejemplo, las dimensiones de una celda en una tabla en la interfaz de usuario se clasifican aquí.
Por ejemplo,
Si la política de privacidad del sitio web tiene un error de ortografía, este defecto se establece como Gravedad baja y prioridad baja.
Pautas
A continuación, se presentan algunas pautas que todo evaluador debe intentar seguir:
- En primer lugar, comprenda bien los conceptos de prioridad y gravedad. Evite confundir uno con otro y utilizarlos indistintamente. De acuerdo con esto, siga las pautas de gravedad publicadas por su organización / equipo para que todos estén en la misma página.
- Elija siempre el nivel de gravedad según el tipo de problema, ya que esto afectará su prioridad. Algunos ejemplos son:
- Para un problema que es crítico, como que todo el sistema falla y no se puede hacer nada, esta gravedad no debe usarse para abordar los defectos del programa.
- Para un problema que es importante, como en los casos en que la función no está funcionando como se esperaba, esta gravedad podría usarse para abordar nuevas funciones o mejorar el funcionamiento actual.
Recuerde que elegir el nivel de gravedad correcto, a su vez, le dará al defecto la debida prioridad.
- Como probador - comprender cómo una funcionalidad en particular, en lugar de profundizar más - comprender cómo un escenario particular o caso de prueba afectaría al usuario final. Esto implica mucha colaboración e interacción con el equipo de desarrollo, analistas comerciales, arquitectos, jefe de pruebas, jefe de desarrollo. En sus discusiones, también debe tener en cuenta cuánto tiempo tomaría corregir el defecto en función de su complejidad y tiempo para verificar este defecto.
- Finalmente , siempre es el propietario del producto quien posee el poder de veto de la versión que debe solucionarse el defecto. Sin embargo, dado que las sesiones de clasificación de defectos contienen varios miembros para presentar su perspectiva sobre el defecto según el caso, en un momento en el que los desarrolladores y probadores están sincronizados, sin duda ayuda a influir en la decisión.
Conclusión
Al abrir defectos, es responsabilidad del probador asignar la gravedad correcta a los defectos. La gravedad incorrecta y, por lo tanto, el mapeo de prioridades pueden tener implicaciones muy drásticas en el proceso STLC general y en el producto en su conjunto. En varias entrevistas de trabajo, se hacen varias preguntas sobre la prioridad y la gravedad para asegurarse de que, como evaluador, tenga estos conceptos impecablemente claros en su mente.
Además, hemos visto ejemplos en vivo de cómo clasificar el defecto en varios depósitos de gravedad / prioridad. A estas alturas, me gustaría que tuviera suficiente aclaración sobre la clasificación de defectos tanto en categorías de gravedad / prioridad.
Espero que este artículo sea una guía completa para comprender los niveles de prioridad y gravedad de los defectos. Háganos saber sus pensamientos / preguntas en los comentarios a continuación.
Lectura recomendada
- ¿Qué es la técnica de prueba basada en defectos?
- ¿Qué es el ciclo de vida de defectos / errores en las pruebas de software? Tutorial del ciclo de vida de los defectos
- Proceso de gestión de defectos: cómo gestionar un defecto de forma eficaz
- Cómo reproducir un defecto no reproducible y hacer que el esfuerzo de prueba valga la pena
- 7 principios de las pruebas de software: agrupamiento de defectos y principio de Pareto
- Métodos y técnicas de prevención de defectos
- Diferencia exacta entre verificación y validación con ejemplos
- Tres estrategias para lidiar con un defecto de bloqueador