¡Hola, ciudadanos de Habrovsk!
Decidí escribir un artículo sobre el proceso de interacción entre nuestros probadores y analistas y sobre los bonos que la empresa SuperJob recibe de este proceso.
El trabajo de los evaluadores con requisitos consta de tres etapas: revisión FT, cobertura FT, revisión de casos.
Revisión de FT
Los requisitos son mantenidos por los analistas en Enterprise Architect, desde donde se copian a Confluence. Después de escribir los requisitos, se envían para su revisión a los evaluadores.
Si bien esta interacción se lleva a cabo a través de Hojas de cálculo de Google, donde hay:
- Nombre FT
- Enlace a FT
- Responsable de FT Analyst
- Estados de analistas
- Probador responsable
- Estados de probadores
El analista coloca el estado "En revisión" en el párrafo correspondiente de la tabla:
En esta etapa, como parte de Confluence, se hacen preguntas sobre ciertos puntos de requisitos, ya que la funcionalidad le permite agregar comentarios a partes arbitrarias del texto. En los comentarios, las discusiones están en curso, como resultado de lo cual se actualiza el FT.
Una vez que los requisitos se han agregado y actualizado, se transfieren al desarrollo y las pruebas.
Cobertura FT
Los casos de prueba están escritos en TestRail; la arquitectura de almacenamiento de casos de prueba repite completamente la arquitectura de almacenamiento de requisitos. Esto es necesario para facilitar la búsqueda, y para no reinventar su bicicleta, es más fácil tomarla de un analista vecino.
Las pruebas cubren los requisitos: cada artículo de requisitos, cada oferta está cubierta.
Cada elemento de requisitos está numerado; hay un rastro de casos de prueba para elementos de requisitos. Por separado, quiero señalar que en cada caso hay una versión del FT en la que se escribió este caso: los requisitos pueden cambiar y los puntos también, si no tiene en cuenta la versión del FT, entonces no puede encontrar los extremos.
De esta manera:
- Es fácil verificar la calidad de la cobertura del caso. Ante mis ojos no hay una hoja de 50 casos y la misma hoja FT cerca, pero seleccionas un punto de requisitos y luego ves qué casos cubren este punto en particular;
- En caso de un cambio en los requisitos, puede ver de inmediato qué casos deben corregirse.
Los casos están escritos en tres versiones:
- Encabezado de casos (la mayoría de estos). Cuando el caso solo tiene un encabezado, por el cual queda claro lo que hay que hacer. Son más rápidos de escribir que los casos de prueba detallados y, al mismo tiempo, tienen una cobertura transparente:
- Casos de prueba. Un caso de prueba detallado con pasos cuando hay muchos matices en el caso y no se pueden poner todos en el encabezado;
- Casos, listas de verificación. Cuando un caso consiste en una lista de verificación para verificar alguna dirección de funcionalidad. Para resaltar tales casos, use en el encabezado (casos):
En las secciones del FT, donde hay maquetas, se crea el caso de prueba "Reconciliación con el diseño M ...". Sirve simplemente como un recordatorio de que hay un diseño y la implementación debe verificarse con él. Este caso sin una descripción interna: la lista de verificación para la reconciliación con el diseño que hemos descrito en las regulaciones.
Revisión de caso
Después de escribir casos, el estado de "Revisión de caso" se coloca en la tabla general, esto es una señal de que otro probador puede tomar este FT y realizar una revisión de caso. Esto es necesario para que los casos sean igualmente claros para todos los evaluadores y para poder cumplir con los requisitos con una nueva apariencia.
En caso de que la revisión no se apruebe, por ejemplo, nuevas preguntas aparecieron en el FT o la cobertura es insuficiente; el requisito se transfiere al estado de "Finalizar". No hay suficientes comentarios en TestRail para describir todos sus deseos, mientras que esto sucede por escrito en Slack, que no es muy conveniente para el seguimiento.
Si la revisión es exitosa, el FT está en el estado "Finalizar".
En casos raros, cuando los requisitos se actualizaron después de escribir casos de prueba en ellos, el FT se transfiere al estado "Actualizado". Además, el probador que cubre el FT se suscribe a las actualizaciones de la página Confluence. Si los requisitos han cambiado mucho, se crea una tarea para que el probador actualice los casos.
Conclusión
¿Qué nos da este enfoque?
- Primero, los requisitos probados caen en desarrollo. Esto ahorra tiempo a los desarrolladores, a los que las ilógicas, las deficiencias y las jambas de FT simplemente no llegan;
- En segundo lugar, los evaluadores se están preparando para realizar pruebas en paralelo con el desarrollo, por lo que reducimos el tiempo que lleva lanzar las funciones. Los evaluadores pueden abordar con calma y responsabilidad el proceso de redacción de casos, y no en el formato "Ahhh, cayó una gran característica, tienes que verterla esta noche. ¡Probemos más rápido!
- En tercer lugar, este es un aumento en la calidad de las pruebas debido a la revisión de casos. Di "¡No!" Una mirada borrosa.
¿Qué no te gusta?
- Existe un intervalo de tiempo bastante grande entre escribir casos y ejecutarlos en una función: aunque los casos están listos y solo se pueden verificar, el probador, sin embargo, se sale de contexto;
- Como escribí anteriormente, en TestRail no hay suficientes comentarios, como en Confluence, no puede simplemente tomar y marcar el lugar del problema, dejando un comentario.
Eso es todo por ahora. Gracias por su atencion!
¿Y cómo es el proceso de trabajar con sus requisitos?