Escribí este artículo en Working Confluence en 2013. Y en el momento de escribir este artículo (2019), todavía era relevante.
Inicialmente, escribí la lista de verificación como recordatorio, incluso para mí mismo. Porque debe volver a las tareas, incluidas las personas que NO las revisaron. Por ejemplo, durante una regresión es necesario verificar al menos un funcional básico.
Entonces, abre la tarea, hojea el último comentario para ver qué documentación, qué funciona y allí ... Está vacío. O el modesto "Todo está marcado, todo está bien". ¿Dónde está la documentación? No estoy en el tema de la tarea, ¡quiero leer más!
O si el cliente escribe que algo no está funcionando para él, y desea verificar si la situación está cubierta por las pruebas automáticas. Vas a la tarea y no hay ningún enlace a las pruebas automáticas. ¿No escribieron en absoluto? ¿O simplemente no le dio el enlace? Tengo que averiguarlo ...
Entonces apareció la lista de verificación para cerrar la tarea:
- Verifique la tarea (hola cap). Use listas de verificación preparadas para tareas comunes + evite errores comunes en las pruebas automáticas.
- Escriba documentación en él (min - usuario, max - usuario y "para colegas").
- En JIRA, deje un comentario "Revisé el núcleo del ensamblaje ***, cliente ***, miré esto, esto y aquello, aquí está".
- Adjunte datos de prueba a la tarea si algo se verificó manualmente.
Es una especie de "sobre nosotros", pero en realidad universal. Bueno, excepto que en su empresa el probador no escribe documentación, entonces cambiamos el segundo párrafo para "verificar que toda la documentación necesaria esté escrita o actualizada".
Analizaremos cada artículo por separado.
La documentación
Si no hay documentación para la tarea (no importa si se trata de un error o una mejora), se vuelve a descubrir.
Si hay documentación, pero en JIRA no hay ningún enlace en el último comentario, la tarea se redescubre.
(tiempos difíciles, medidas duras)Mínima necesidad de escribir / corregir los requisitos del usuario.
Si hubo cambios en las configuraciones del proyecto, debe verificar que haya documentación técnica para tal cambio. Si no es así, escribe.
Si se agregaron tareas de migración, escriba inmediatamente una instrucción general para actualizar la versión.
Comentario
Si tiene que volver a la tarea más tarde, a veces es útil averiguar qué versión probó el probador y qué comprobó (en resumen).
Escribimos las versiones de mercurial, le damos un enlace a la documentación y una breve descripción: lo revisé manualmente a través de la interfaz / SOAP / buffer.
Datos de prueba
Si la tarea se verificó manualmente, asegúrese de adjuntarle datos de prueba (si no pesan 3Tb)
Sí, estos datos se pueden obtener del repositorio compartido, pero allí ya se pueden cambiar o incluso eliminar.
(Tenemos un depósito común de datos de prueba, pero todos los archivos se almacenan en el disco. Lo probamos en el sistema de control de versiones, no me gustó, nadie se compromete allí, pero lo pusieron en el disco de alguna manera)A veces parece que todo esto es basura, crearon una contraparte o recogieron selecciones por vista.
Pero si en medio año surge un problema en el Cliente y se plantean las tareas antiguas para la reproducción, estos archivos ayudarán mucho, verificados más de una vez. Pero los datos reales del almacenamiento ya no están actualizados.
Recuerde: tomará 1 minuto realizar una consulta SQL lista y compararla con la base de datos. Y nuevamente para sentarse y hacer esta solicitud, puede tomar una hora, si no más. ¡Ahorra tu tiempo!
Por lo tanto:
- Creó una base de datos a partir de dbStart: archivo adjunto dbStart (Excel, en el que se guarda una porción de la base de datos para la prueba).
- Descargamos datos de prueba del almacenamiento; adjuntamos el archivo descargado.
- Los descargamos de otro lugar; los agregamos al repositorio y los adjuntamos a la tarea.
Ver también:¿Cómo crear rápidamente una base de datos de plantilla en Maven? - sobre cómo hacemos dbStart para las pruebas.
Los comentarios sobre pruebas, documentos y datos deben ser finales. Y no tanto que "escribí tales pruebas, encontré tales y tantos problemas" y luego correspondencia con el desarrollador para 20 comentarios, y su "final" se perdió en algún punto intermedio. Si se pierde, duplique (el antiguo se puede eliminar).
Ejemplos
Cuando reclutamos nuevos probadores, este artículo no fue suficiente. Porque redescubrí las tareas de los juniors y les dije cómo arreglar el comentario final para que fuera comprensible. Y ellos, a su vez, pidieron ejemplos de "cómo hacerlo".
Entonces, en el artículo apareció otro bloque: "Ejemplos". Es importante proporcionar enlaces a tareas reales en la jira de trabajo + algunos artículos adicionales en confluencia. Los ejemplos deberían ser diferentes: tanto para los grandes comentarios cuando se escribieron 200 autotests en una tarea, como para las pequeñas tareas que los chicos enfrentarán todos los días.
No daré enlaces, pero el significado, espero, es claro. La sección se parece a esto:Ejemplos de tareas grandes donde hay muchos muelles y pruebas:
- TEST-679 - Mejoras a JMS
- TEST-760 : flujo de retorno a diferentes fuentes JMS
Ejemplos de tareas pequeñas:
TEST-816 - extendió el modelo de consentimiento.
Al probar "agregar funcionalidad a la demostración", preste especial atención a la refactorización: envíe la documentación al núcleo, todas las pruebas en la demostración y el resto a través de la inclusión, etc. Ejemplo:
TEST-4519 - Agregue la reconciliación cruzada de FL-IP a la demostración.
Ejemplos de comentarios útiles "cómo probé esto" a los que vuelves (es mejor publicarlos en el CÓMO, pero debes dejarlos en la tarea):
PRUEBA-812 : realiza la reconstrucción del índice sin bloqueo (dónde poner el descanso * para verificar)
* Bryak: Punto de interrupción (argot): el punto de interrupción del código. Esto es cuando ejecuta el código fuente en modo de depuración, tales puntos ayudan a rastrear los parámetros, para localizar el error.PD: vea otros artículos de prueba en mi blog