Introducción al proceso de clasificación de defectos ortogonales (ODC) e intercambio de experiencias de aplicaciones

Introducción a la clasificación de defectos ortogonales (ODC)

La clasificación de defectos ortogonales (en adelante ODC) es un método de análisis de defectos propuesto por IBM en 1992. Agrega algunos atributos adicionales a cada defecto y utiliza la inducción y el análisis de estos atributos para reflejar diversas cuestiones, como el diseño del producto, la calidad del código y el nivel de prueba. Esto conducirá a algunas soluciones de mejora. Por ejemplo, para el equipo de pruebas, ODC se puede utilizar para saber si el trabajo de pruebas se ha vuelto más complejo; si cada fase de prueba utiliza suficientes condiciones de activación para encontrar defectos; cuáles son los riesgos de salir de la fase de prueba actual; qué fase de prueba es ¿Está bien y qué fase de prueba es mejor? La fase de prueba necesita mejorar, etc. Para el equipo de desarrollo, ODC se puede utilizar para conocer la calidad del diseño del producto y la escritura del código. Los beneficios para los usuarios del producto son mejorar la satisfacción del cliente y reducir los costos de mantenimiento después de que el producto se lanza al mercado.

El flujo de trabajo de ODC se divide en cuatro partes: "Clasificación de defectos", "Verificación de defectos clasificados", "Evaluación de datos" y "Toma de acciones para mejorar el trabajo". Te los explicamos uno a uno a continuación.

1. Etapa de clasificación

La clasificación es el primer paso en el flujo de trabajo de ODC, que requiere que los evaluadores y desarrolladores completen los atributos de ODC para cada defecto. Es especialmente importante que los miembros del equipo comprendan correctamente el valor de cada atributo, para asegurarse de que intentan elegir la opción correcta al clasificar.

Requisitos previos

Algunas herramientas de gestión de defectos no admiten ODC de forma predeterminada, lo que requiere mejorar la herramienta de gestión de defectos y configurar atributos adicionales antes de completar la información. Las herramientas de gestión de defectos más utilizadas incluyen Clear Quest (CQ) y Control de versiones de gestión de configuración (CMVC). Los 9 atributos relacionados con ODC que deben agregarse son.

1. Actividad: Indica los defectos encontrados durante qué tipo de prueba. Por ejemplo: UT (prueba unitaria), FVT (prueba funcional), SVT (prueba del sistema), etc.;

2. Trigger; indica qué método se utiliza para desencadenar el defecto. Diferentes actividades corresponden a diferentes tipos de desencadenantes;

3. Impacto: Indica el impacto que tendrá el defecto en los clientes;

4. Objetivo: indica qué modificaciones debe realizar el desarrollador para corregir este defecto. Por ejemplo, los aspectos que pueden modificarse incluyen: diseño del producto, código y documentos correspondientes, etc.;

5. Tipo de defecto: tipo de defecto;

6. Calificador: indica si el defecto se debe a la falta de un código relevante o a un código incorrecto. O es causado por un código proporcionado por un tercero;

7. Fuente: Indica si la fuente del defecto es causada por un código escrito internamente o un código proporcionado por una empresa de subcontratación, etc.;

8. Antigüedad: indica si el defecto es causado por un código nuevo o modificación de otros defectos, o es un problema que ya existía en la versión anterior;

9. Tipo de Contenido: Indica el tipo de documento de reparación. Válido únicamente para defectos de clase de documento.

Para CMVC, desde la versión 1.7, tiene atributos ODC integrados y se puede utilizar directamente. Para CQ, necesita instalar un paquete ODC. El paquete ODC se puede descargar desde el archivo adjunto. Después de la descompresión, hay documentos detallados para enseñar a los lectores cómo instalar el paquete en CQ.

Después de configurar ODC, aparecerán nuevas pestañas en la ventana de la aplicación CQ: ODC Submitter y ODC Responder, como se muestra en la Figura 1 y la Figura 2.

Figura 1. Pestaña Remitente ODC en CQ

Figura 2. Pestaña ODC Responder en CQ

Una vez que la herramienta de gestión de defectos admite ODC, los evaluadores y desarrolladores deben completar los atributos de ODC respectivamente, y estos datos se utilizarán en procesos posteriores.

Probadores clasificados

En la Figura 1 podemos ver que hay tres opciones en la pestaña ODC Submitter, a saber, Actividad, Activador e Impacto. Estas tres opciones las completa el evaluador que descubre el defecto. A partir de estos atributos, podemos saber qué tipo de prueba se realizó y qué método de activación se utilizó para descubrir el defecto. Al mismo tiempo, ¿cuál es el impacto en los usuarios? Simplemente confiando en estos tres atributos ODC se puede ver de un vistazo.

Desarrolladores clasificados

En la Figura 2 podemos ver que hay seis opciones en la pestaña Respondedor de ODC, a saber, Destino, Tipo de defecto, Fuente del calificador, Edad y Tipo de contenido. Estas seis opciones las completa el desarrollador, quien es quien repara el defecto. A partir de estos atributos, ¿podemos saber qué modificaciones ha realizado el desarrollador para resolver el problema? ¿Son grandes los cambios? ¿Falta algo en el código original? ¿Incorrecto? ¿O es necesario eliminar algunas partes? ¿Existe este problema en la versión original? etc. Con los valores de estos atributos, podrás conocer rápidamente la causa raíz de este defecto.

Preguntas y sugerencias frecuentes

Las herramientas de gestión de defectos tienen soporte incompleto para ODC

Algunos atributos ODC están relacionados. Por ejemplo: en la pestaña Remitente ODC, si se selecciona "Prueba de función" en la propiedad Actividad, entonces la propiedad Desencadenador solo se puede seleccionar entre "Cobertura", "Secuencia", "Variación" e "Interacción". Si se selecciona "Prueba del sistema" en el atributo Actividad, el valor del atributo Activador opcional es completamente diferente y hay varias otras opciones: "Carga de trabajo", "Recuperación", "Inicio/Reinicio", "Configuración de hardware" y " Configuración del software”. En la herramienta de gestión de defectos, si no hay restricciones en la correlación entre estos atributos, se enumerarán todos los valores para que el usuario los elija al seleccionar cada opción, lo que fácilmente puede provocar una falta de coincidencia entre las opciones. Como resultado, cuando se cuentan los datos finales de ODC, los resultados no son razonables.

Además, no hay verificación de las operaciones requeridas en los elementos de atributos de ODC, lo que también es una de las manifestaciones del soporte incompleto de la herramienta de gestión de defectos para ODC. Por ejemplo, si solo completa el atributo Actividad, indica en qué tipo de prueba se encontró el defecto, pero si no completa el atributo Trigger, es decir, si no indica bajo qué condición de disparo se encontró el defecto. encontrado, causará que falte información y los resultados del análisis no serán precisos.

Por lo tanto, recomendamos encarecidamente que al configurar la herramienta de gestión de defectos para admitir ODC, agregue restricciones en los atributos relacionados y realice una verificación obligatoria de los atributos ODC requeridos, obligando a todos a completarlos; de lo contrario, el envío no será exitoso. Esto garantiza la integridad y corrección de la entrada de datos ODC a nivel de herramienta.

Los evaluadores o desarrolladores no están familiarizados con los atributos ODC que deben completar

El método de análisis de defectos de ODC no se ha popularizado en todos los proyectos, por lo que en el primer proyecto en el que se aplica ODC, se debe realizar una capacitación sistemática sobre el conocimiento de ODC dentro del proyecto antes de la etapa de clasificación. No es sólo una simple comprensión, sino que es necesario conocer el significado de todas las opciones para cada atributo. De esta manera no te quedarás perdido una vez que comience la fase de clasificación. Además, debido a la gran cantidad de opciones de atributos ODC, es imposible recordarlas todas a través de varias capacitaciones previas. Se recomienda imprimir un documento similar al Manual de referencia rápida de propiedades de ODC. De esta manera, al completar los datos ODC, puede consultar los documentos que tiene a mano mientras los completa.

2. Fase de verificación

En el primer paso, los evaluadores y desarrolladores completaron los datos ODC. Entonces se necesitan expertos de la ODC para verificar los datos. Porque completar datos ODC incorrectos hará que los dos pasos siguientes del proceso de evaluación y acción carezcan de sentido. Por lo tanto, es particularmente importante verificar la exactitud de los datos.

Preguntas y sugerencias frecuentes

¿Cómo se reflejan los resultados de la verificación en la herramienta de gestión de defectos?

Una vez que el verificador ha verificado un defecto y confirmado que el personal pertinente ha completado la modificación, el trabajo de verificación aún no ha terminado. Para analizar solo los defectos que se han verificado en la siguiente etapa, la etapa de evaluación, es necesario que haya un lugar en la herramienta de gestión de defectos para marcarlos y filtrar los defectos que no se han verificado.

Puede agregar un elemento de atributo llamado "ODC validado" en la pestaña ODC Responder. Como se muestra en la Figura 3.

Figura 3. Atributo ODC validado recientemente agregado en la pestaña Respondedor de ODC:

Hay cuatro opciones para elegir.

• "Vacío": de forma predeterminada, este elemento de atributo está vacío. Indica que el personal de verificación no ha comenzado a verificar el defecto;

• "Sí": se ha verificado y el personal pertinente ha modificado los atributos ODC incorrectos;

• "No": Se ha verificado, pero el personal pertinente no ha realizado ninguna modificación;

• "N/A": Los defectos no válidos no se incluyen en las estadísticas finales. La aparición de defectos no válidos puede incluir: defectos no válidos (Error de usuario) abiertos debido a problemas de los probadores; el problema encontrado no es un defecto, sino exactamente como está en el diseño del producto (Como Diseño); el defecto es diferente del anterior. otro defecto abierto está duplicado;

¿Cómo pueden los miembros del equipo de verificación comunicarse más eficazmente?

Los miembros del equipo de validación generalmente se seleccionan entre los evaluadores y desarrolladores por separado. En muchos proyectos grandes, es posible que los equipos de prueba y desarrollo no estén en la misma región o incluso tengan diferencias horarias. ¿Cómo mejorar la comunicación entre los miembros del equipo interregional para que el intercambio de recursos y la comunicación puedan ser oportunos y precisos? Esto requiere una plataforma para compartir información. Según nuestra experiencia práctica, wiki es una buena opción. Una wiki es una herramienta de escritura colaborativa donde todos pueden expresar sus opiniones. El siguiente es el contenido de la wiki del equipo de verificación de ODC utilizado por un equipo de proyecto en el que participa el autor, incluidos los siguientes aspectos.

• Propósito: Aclarar el propósito del trabajo de verificación;

• Lista de miembros del equipo de verificación: incluidos nombres e información de contacto;

• Descripción del proceso de verificación: En base a las características de este proyecto, se ha desarrollado un proceso de verificación adecuado para este proyecto. Tomando como ejemplo el proyecto en el que participó el autor, el proceso de verificación puede incluir:

  • Todos los lunes, el líder del equipo de verificación de ODC asigna a cada persona los defectos que deben verificarse esa semana (el método de asignación se mencionará en el "Acuerdo de trabajo semanal" a continuación);

  • Cada miembro del equipo de verificación comienza a verificar uno por uno los defectos asignados. Si se descubre que el atributo ODC del defecto se completó incorrectamente o se olvidó, debe enviar inmediatamente un correo electrónico al descubridor o solucionador del defecto para modificarlo. Si la información de descripción del defecto en sí es suficiente para que el verificador analice la opción correcta, entonces las opiniones y motivos de la modificación del verificador deben indicarse en el correo electrónico. Si la descripción del defecto no es clara y el verificador no puede emitir un juicio preciso, también debe indicarse en el correo electrónico. Después de que el evaluador o desarrollador agregue información más detallada al defecto, el verificador lo volverá a verificar.

  • Una vez que se completa la verificación, el verificador debe identificar el defecto en la herramienta de gestión de defectos, como el atributo "¿Se ha verificado ODC" que mencionamos anteriormente, y luego cambiar su valor del valor predeterminado de "No" a "sí"? . Para indicar que el defecto ha sido comprobado. La próxima vez que el líder del equipo de verificación asigne defectos a verificar, se filtrarán los defectos que ya se hayan verificado.

  • El verificador proporciona comentarios sobre los problemas descubiertos durante el proceso de verificación, como tendencias de clasificación errónea;

• Horario de trabajo semanal:

  • La siguiente tabla se puede utilizar para la asignación de trabajo y el seguimiento del progreso. Las dos primeras columnas las completa el líder del equipo de verificación de ODC al asignar el trabajo. Los verificadores de ODC completan las dos últimas columnas al realizar el trabajo de verificación. La Tabla 1 enumera algunos escenarios posibles.

Tabla 1. Tabla de seguimiento/asignación del trabajo de verificación de ODC

verificador	Número de defecto	¿Ha sido verificado?	pregunta
Zhang San	00001	Sí
	00002	No	Cierto día, envié el primer correo electrónico al personal correspondiente y les pedí que hicieran cambios, pero todavía no recibí respuesta dentro de tres días.
	00003	N / A	Este defecto está duplicado con 00001 y no está incluido en las estadísticas de datos de ODC.
	00004
Juan Pérez	00005	No	Cierto día, se envió un segundo correo electrónico de recordatorio al personal correspondiente para pedirles que hicieran cambios, pero no se recibió respuesta dentro de los tres días.

La tercera columna de la tabla, "¿Se ha verificado?", corresponde al elemento de atributo "Se ha verificado el ODC" en la herramienta de gestión de defectos. También hay cuatro opciones para elegir: Si no se completa, significa que el El personal de verificación aún no ha comenzado. Verificar el defecto; "Sí" significa que el defecto ha sido verificado y puede usarse como datos estadísticos en la etapa de evaluación; "No" significa que el defecto todavía está en el proceso de verificación y está esperando. modificaciones por parte del personal relevante de acuerdo con las instrucciones del inspector. Los comentarios se modifican en la herramienta de gestión de defectos. Si no hay respuesta de la persona relevante dentro de los tres días posteriores al envío del primer correo electrónico por parte del verificador, el verificador debe enviar un segundo correo electrónico y enviar copia al gerente directo de la persona relevante. Esto insta al personal relevante a cambiar los atributos de ODC lo antes posible para que el defecto se marque como "verificado"; "N/A" indica que el defecto no es válido.

• Actas de reuniones: registre y comunique el estado de cada reunión ordinaria para facilitar su revisión y seguimiento en el futuro. El siguiente es un ejemplo de un proyecto en el que participó el autor. El acta de la reunión incluye los siguientes aspectos:

  • Con base en los resultados de la reunión, es necesario tomar algunas acciones después de la reunión. De esta forma, es necesario registrar el contenido y el responsable de cada acción para poder seguir y confirmar la próxima reunión. A continuación se muestran ejemplos. Si se registran las siguientes dos acciones en esta reunión: Al comienzo de la próxima reunión, primero confirme si estas dos acciones de la última reunión se han implementado. Y explicar los avances o resultados en el apartado de anuncios del acta de esta reunión.

  • Alguien se pone en contacto con el administrador de la herramienta de gestión de defectos y agrega un atributo adicional para registrar si el defecto ha sido verificado;

  • Fulano de tal invitó al experto de ODC, David, a participar en nuestras reuniones semanales para ayudarnos a responder los problemas encontrados durante el proceso de verificación.

  • Participantes: Listado de participantes.

  • Anuncio: Generalmente una descripción del progreso o resultados de los asuntos que se resolverán en la reunión anterior. También puede ser un aviso importante.

  • Contenidos discutidos en esta reunión: Detalles de los contenidos discutidos en esta reunión.

  • acción:

• Enlaces a materiales de referencia:

  • Enlaces a materiales de referencia sobre el trabajo de verificación de ODC y las instrucciones de clasificación de ODC.

Para el líder del equipo de verificación, ¿cómo asignar las tareas de verificación de manera más efectiva y directa?

Simplemente enumera la tabla de asignación de trabajo en la wiki, aunque también se puede realizar la asignación de tareas y el seguimiento del progreso, pero como no está asociado con la herramienta de gestión de defectos, el verificador debe verificar la herramienta de gestión de defectos uno por uno según el número de defecto. en la Tabla 1. Encuéntrelo. Obviamente, esto es una pérdida de tiempo e inevitablemente se producirán errores durante el proceso de búsqueda. Por lo tanto, es más apropiado asignar tareas directamente en la herramienta de gestión de defectos, mientras se utiliza la tabla de seguimiento/asignación de trabajos de verificación de ODC que se muestra en la Tabla 1 para el seguimiento del progreso.

En el proyecto en el que trabajó el autor, solíamos agregar un atributo llamado Validador ODC a la herramienta de gestión de defectos, como se muestra en la Figura 4. Para que el líder del equipo de verificación elija al asignar tareas. De esta manera, después de que el personal de verificación inicia sesión en la herramienta de gestión de defectos, puede consultar directamente la lista de defectos cuyo atributo Validador ODC es su propio nombre.

Figura 4. Validador ODC del atributo recién agregado en la pestaña Respondedor ODC:

3. Etapa de evaluación

Bajo la premisa de garantizar la exactitud de los datos ODC de entrada, se pueden analizar estos defectos. Según las estadísticas de clasificación basadas en diferentes atributos de ODC, se pueden sacar diferentes conclusiones. Utilícelo para reflejar problemas en las pruebas, el desarrollo o el diseño de productos y señalar posibles oportunidades de mejora. Por ejemplo: cómo se descubrieron los defectos, si el producto es estable, etc. A continuación se muestran algunos métodos de evaluación típicos para la descripción.

Evaluación de los esfuerzos de prueba.

Utilizando diferentes combinaciones de atributos ODC, la finalización del trabajo de prueba se puede evaluar desde muchos aspectos. Por ejemplo, utilice la fase de prueba y los atributos de actividad para evaluar si los defectos que deberían descubrirse en una determinada fase de prueba se descubrieron en la siguiente fase de prueba; utilice los atributos de actividad y activador para evaluar si cada actividad utiliza suficiente activador correspondiente para encontrar defectos; use el tiempo y las propiedades de activación para evaluar si la prueba se vuelve más compleja con el tiempo, etc. Usemos el primer método de evaluación como ejemplo.

Las diferentes fases de prueba tienen diferentes enfoques de prueba. Por ejemplo, en la fase de prueba funcional, la actividad correspondiente es Prueba de Función. En la fase de prueba del sistema, la actividad correspondiente es Prueba del sistema. Podemos determinar si los defectos que deberían haberse descubierto en esta fase de prueba se dejaron para la siguiente fase de prueba contando las actividades que encontraron defectos en cada fase de prueba. Utilice esto para evaluar la finalización del trabajo de prueba. Como se muestra en la Figura 5.

Figura 5. Diagrama de evaluación utilizando la fase de prueba y los atributos de actividad.

En la imagen de arriba, podemos ver que durante la fase de prueba del sistema del proyecto, casi la mitad de las actividades defectuosas fueron pruebas funcionales. Esto muestra que los defectos que deberían haberse descubierto durante la fase de prueba funcional no se descubrieron hasta la fase de prueba del sistema. Se puede ver que el trabajo de prueba en la fase de prueba funcional no fue lo suficientemente completo.

Experiencia y asesoramiento

• Este método de evaluación se utiliza a menudo para medir si los defectos que deberían haberse descubierto durante la fase de prueba funcional no se descubrieron, sino que se descubrieron durante la fase de prueba del sistema. Por lo tanto, es mejor utilizar este método de evaluación después de que se hayan iniciado las pruebas del sistema, ya que no será de mucha ayuda en esta etapa;

• Objetivamente hablando, es normal encontrar algunos defectos en la fase de prueba funcional durante la fase de prueba del sistema, que no afectarán el funcionamiento normal de la prueba del sistema. Por el contrario, si no hay defectos en la etapa de prueba funcional durante la etapa de prueba del sistema, significa que hay un problema. Lo más probable es que se deba a una entrada incorrecta causada por la comprensión incorrecta del atributo de actividad por parte del evaluador;

• El problema que se muestra en la figura anterior es que durante la fase de prueba del sistema se descubrieron demasiados defectos que deberían haberse descubierto durante la fase de prueba funcional. Para abordar este problema, podemos aumentar la cobertura de las pruebas funcionales agregando casos de prueba en la fase de pruebas funcionales. O modificar los criterios de salida de la fase de prueba funcional, como cuántos defectos se deben encontrar antes de ingresar a la fase de prueba del sistema, etc.

Evaluación de la estabilidad del producto.

Los atributos ODC se pueden utilizar no sólo para evaluar la finalización del trabajo de prueba, sino también para evaluar la estabilidad del producto. Por ejemplo: a medida que avanza el proyecto, cuente periódicamente la tendencia cambiante del atributo calificador para evaluar si el producto se ha vuelto más perfecto; o cuente periódicamente la tendencia cambiante del atributo de impacto para evaluar si hay defectos que afecten la funcionalidad y confiabilidad del producto. está disminuyendo. Tomemos el atributo calificador en una instancia como objeto de investigación para evaluar si la instancia se vuelve más completa a medida que avanza el proyecto. Como se muestra en la Figura 6.

Figura 6. Gráfico de tendencias de atributos de calificador

La Figura 6 muestra las tendencias cambiantes de los porcentajes de faltantes e incorrectos a medida que avanza el proyecto. Para un producto que gradualmente se vuelve más estable, los defectos a los que le falta el Calificador deberían disminuir gradualmente. Porque la adición de cualquier código nuevo que no haya sido probado aumentará los riesgos potenciales.

Pero en la Figura 6 podemos ver que la estabilidad de este ejemplo no es optimista. Al calificador le faltan defectos y no hay tendencia a disminuir con el desarrollo del proyecto.

Experiencia y asesoramiento

• Este gráfico de tendencias le permite ver los cambios de tendencias periódicamente de forma semanal o mensual;

• Al mirar esta imagen, no se pueden simplemente mirar los datos reflejados en la superficie de manera general: cuál es el porcentaje de faltantes y cuál es el porcentaje de incorrectos. También deberíamos analizar contenidos más profundos, como por ejemplo, ¿a qué tipo de defecto pertenecen esos defectos faltantes? ¿En qué componentes ocurren? Sólo de esta manera podremos descubrir dónde residen los riesgos reales y juzgar si el producto es estable. En lugar de simplemente ver el calificador de qué porcentaje de defectos faltan;

• La ordenada en la figura anterior es porcentaje. Este comportamiento puede resultar engañoso si sólo se encuentran unos pocos defectos en un período de tiempo determinado. Por lo tanto, al observar este tipo de diagrama de evaluación, debe observar tanto la vista presentada como porcentaje como la vista presentada utilizando el número de defectos como ordenada.

Evaluación del diseño y código del producto.

Uno de los atributos de ODC que deben completar los desarrolladores se llama objetivo. Indica qué cambios debe realizar el desarrollador para corregir la falla. Por ejemplo, los aspectos que se pueden modificar incluyen: diseño/código, construcción, información, lenguaje, etc. Para evaluar la finalización del producto en términos de diseño y código, podemos analizar los defectos cuyo objetivo es diseño/código, y utilizar su tipo de defecto correspondiente y atributos calificadores para descubrir las deficiencias del producto en los requisitos, diseño y código. etapas y qué eslabones débiles hay. Es más fácil introducir defectos. El siguiente es un caso para ilustrar cómo utilizar el tipo de defecto y los atributos calificadores para la evaluación. Como se muestra en la Figura 7.

Figura 7. Gráfico de evaluación obtenido utilizando el tipo de defecto y el calificador

En la Figura 7 podemos ver que el tipo de defecto es algoritmo/método, falta el calificador y es incorrecto, la proporción y el número de defectos son muy altos. Esto muestra que la descripción detallada del diseño del producto de bajo nivel está incompleta y los desarrolladores no la entienden bien; en segundo lugar, el tipo de defecto es la inicialización de la asignación y la verificación de defectos, y su proporción incorrecta es relativamente alta, lo que refleja que el código todavía tiene deficiencias. por escrito; finalmente vimos que el tipo de defecto es interfaz/mensajes OO, relación y temporización/serialización, etc., y el número de su calificador es incorrecto y falta es relativamente pequeño, lo que demuestra que el producto tiene diseño de alto nivel y requisitos Hice un buen trabajo en análisis y comprensión.

Experiencia y asesoramiento

• Según los diferentes componentes del producto, se realiza un diagrama de evaluación como el de la Figura 7, que es más significativo que una estadística general de la relación entre los atributos calificadores y de tipo de defecto de todo el producto. Esto se debe a que puede ver claramente los problemas de cada componente y luego proponer soluciones mejoradas para cada componente para reducir la inyección de defectos.

4. Etapa de acción

Simplemente descubrir el problema no es suficiente, también es necesario resolverlo. A partir de los diferentes problemas reflejados en el proceso de evaluación, se proponen soluciones específicas y se pide al personal relevante que tome medidas. Esta etapa es también la que más valor aporta al producto.

Experiencia y asesoramiento

• Los equipos de pruebas y desarrollo deben participar en este proceso, ya que son ellos quienes tomarán la acción final;

• Las acciones identificadas deben ser razonables y factibles;

• Cuanto más específicas sean las acciones identificadas, mejor. Por lo general, no señale ninguna mejora en el producto, es mejor actuar sobre un determinado componente o módulo;

• Utilice los distintos diagramas de evaluación generados durante la fase de evaluación para analizar y medir el plan de acción de mejora. No tome decisiones basándose únicamente en un diagrama de evaluación;

• La acción a tomar debe ser mensurable para que se pueda ver si la acción tiene un impacto positivo en el producto.

Resumir

La clasificación de defectos ortogonales (ODC) es un método de análisis de defectos que, si se aplica correctamente en proyectos, puede ayudar a los equipos de pruebas y desarrollo a mejorar su trabajo, mejorando así la calidad del producto. Aclarar el proceso de ODC y las prioridades de trabajo en cada etapa, y aprovechar la experiencia y las sugerencias mencionadas en este artículo, hará que los lectores se sientan más cómodos al utilizar ODC.

Finalmente: se ha compilado y subido el video tutorial completo de prueba de software a continuación. Los amigos que lo necesiten pueden obtenerlo ellos mismos [garantizado 100% gratis]

Documento de entrevista de prueba de software

Debemos estudiar para encontrar un trabajo bien remunerado. Las siguientes preguntas de la entrevista provienen de los últimos materiales de entrevista de empresas de Internet de primer nivel como Alibaba, Tencent, Byte, etc., y algunos jefes de Byte han dado respuestas autorizadas. Después de terminar esto set Creo que todos pueden encontrar un trabajo satisfactorio según la información de la entrevista.