Cómo escriben los evaluadores de software informes semanales (o diarios)

Antes de escribir un informe, normalmente es necesario considerar dos aspectos para mejorar la legibilidad del informe: cuál es el tema del informe y quién es su audiencia. el informe. Para el mismo tema (o similar), la audiencia es diferente y el contenido específico que el informe debe expresar suele ser diferente.

A continuación, enumeraré el patrón y el contenido del informe de prueba semanal desde la perspectiva de los evaluadores y los líderes del equipo de prueba, respectivamente.

1. Probador (probador)

Los probadores generalmente informan sus informes semanales a los líderes de su equipo. En lo que respecta a mi propia experiencia laboral, el equipo de pruebas de las empresas de software generales lo toma en cuenta. tener en cuenta tanto los aspectos del proyecto como los administrativos, es decir, por un lado, hay que liderar las tareas de prueba asignadas por el equipo de pruebas, y por otro lado, también se debe prestar atención al desempeño de los miembros del equipo y el desarrollo del equipo, etc. Por lo tanto, el informe semanal del líder del equipo de pruebas debe explicar con más detalle su situación laboral durante la semana tanto desde el punto de vista del proyecto como del trabajo en equipo. Probablemente pueda incluir los siguientes puntos:

1. Lista de resumen de contenido y lista de tiempo dedicado

Explique su trabajo principal esta semana, como en qué proyectos relacionados con pruebas participó y qué varias reuniones de la empresa, haber asistido a varios cursos de formación relacionados con la empresa (o externos), qué materiales/libros relacionados con el trabajo se han leído, etc., y al mismo tiempo (se recomienda enumerar cada trabajo (o tabla relacionada) en la tabla formulario) Listar el tiempo (horas de trabajo) dedicado a cada contenido de trabajo (o relacionado)

2. Número de casos de prueba ejecutados

Listar según el proyecto, cuántas pruebas se ejecutaron Esta semana Casos de prueba, cuántos pasaron, cuántos fallaron y cuántos casos de prueba se bloquearon y no se pudieron ejecutar (es necesario enumerar las razones específicas del bloqueo, como cuántos casos de prueba se bloquearon y no se pudieron ejecutar). (Se deben enumerar los motivos específicos del bloqueo, como errores o un determinado recurso de prueba no disponible), cuántos casos de prueba se han asignado pero no se han completado. Se recomienda proporcionar esta información en una tabla; consulte el esquema. a continuación:

PassFailBlockedRemaining

Proyecto A253216

...

Si se realizan pruebas ad hoc o exploratorias, considere enumerarlas en la tabla.

3. El número específico de errores enviados

Un aspecto importante del rendimiento del probador es la cantidad y calidad de los errores enviados. Aquí puede enumerar los errores válidos y los no válidos. (errores duplicados, errores duplicados, etc.) enviados por cada proyecto de prueba dentro de una semana Errores que no se pueden reproducir) y la cantidad de errores verificados (correcciones efectivas - corregidas, correcciones no válidas - rechazadas), también se recomienda que se proporcione esta información. presentado en forma de tabla, vea el esquema a continuación:

Enviar - Envío válido - Envío duplicado - No se puede reproducir la verificación - Verificación fija - Rechazado

Proyecto A52083

......

4. Otros

Otro contenido relacionado con el trabajo. Por ejemplo, desea una plataforma de prueba adicional, necesita un determinado libro profesional, etc.

En segundo lugar, también debe completar cierta información relacionada con el trabajo, por ejemplo, necesita una plataforma de prueba adicional, necesita un determinado libro profesional, etc.

p>

2. Líder del equipo de pruebas

El informe semanal del líder del equipo de pruebas generalmente incluye dos aspectos del contenido. Uno es sobre la situación relacionada con el proyecto. Los lectores objetivo de este contenido son todos el proyecto. -personal relacionado (gerentes de proyecto, gerentes de producto, desarrolladores, evaluadores, editores, etc.) El primer aspecto tiene que ver con la gestión del equipo (a veces, este contenido se envía al director de pruebas en un informe separado, después de todo); , es sólo para personal relacionado con el proyecto).

Después de todo, el personal relacionado con el proyecto solo se preocupa por el progreso de las pruebas del proyecto y básicamente no se preocupa por el trabajo específico de los miembros del equipo de pruebas)

1. Problemas graves

Cualquier problema que obstaculice el progreso fluido de las pruebas debe mencionarse de manera destacada aquí con una fecha límite prevista para resolver el problema, y ​​si se sabe que el destinatario del informe es alguien que puede ayudar a hacer avanzar el problema, el problema debe mencionarse explícitamente. Si sabe quién de los destinatarios del informe podría ayudar a hacer avanzar el problema, debe mencionar claramente el nombre de esa persona.

2. El estado de finalización del caso de prueba de cada proyecto

se puede representar mediante un gráfico de barras similar al siguiente

(Si es necesario, un gráfico de barras específico el enlace apunta a los detalles y resultados de esta ronda de pruebas en la biblioteca de administración de casos de prueba)

3. El aumento o disminución de los errores del proyecto en unidades semanales (generalmente reportados en unidades semanales) dentro de un período fijo de tiempo

Situación (generalmente reportada semanalmente).

(La cantidad de errores puede ser la suma de todos los errores de prioridad/severidad, o la suma de solo los errores de primera y segunda prioridad/severidad, porque la cantidad de dichos errores a menudo afecta directamente si el producto es liberado o no, y este es precisamente el tema que más preocupa al personal del proyecto)

Ejemplo de la siguiente figura

(si es necesario)

Ejemplo de la siguiente figura (Existen diferentes clasificaciones específicas según diferentes productos y diferentes proyectos)

5. (Si es necesario) El contenido general del trabajo de los miembros del equipo de prueba

Puede incluir:

1: Cuántos testers participaron, cuánto tiempo dedicó cada persona a cada proyecto y, a veces, también puede enumerar cuántos casos de prueba ejecutó cada tester, cuántos errores se enviaron y cuántos se verificaron

Error y otra información.

Este informe también sirve como guía para que los testers comprendan cómo funciona el proyecto.

Ver tabla a continuación:

6. Cualquier otra tarea relacionada con el proyecto

.