Para cualquier probador en solitario que haya, recomiendo llevar a cabo una actividad regular de pruebas de bug bash/mob. Es una actividad que puedes ejecutar al final de un ciclo de desarrollo de sprint/funciones. Invitas al equipo, tomas algunos refrigerios/bebidas juntos y haces que todos se hagan la prueba durante aproximadamente una hora.
Configuración
Es posible que desee asegurarse de tener una buena cobertura de dispositivo/navegador asegurándose de que todos estén configurados con datos/dispositivos de antemano. También es posible que desee preparar algunos documentos de ayuda para ayudar a las personas a comenzar. Me gusta tener un mapa mental de ideas de cobertura preparado de antemano para que la gente tenga un indicador visual de lo que está probando. También podría crear un montón de cuentas de prueba antes de la mano y distribuirlas al equipo.
Informes de errores ligeros
Debe fomentar los informes de errores ligeros;
- tal vez la gente escriba errores en notas adhesivas
- agregue errores a una hoja de cálculo compartida
- o levante errores de Jira directamente desde Slack utilizando un atajo /jirio create bug
El enfoque debe estar en encontrar errores, no quedar atrapado en cómo informarlos. Siempre puede aclarar los problemas después de la descarga de errores si necesita más información.
Qué probar en un bug bash
Tengo una heurística de 3 pasos para decidir qué probar (piense; guía o regla general):
- ¿qué ha cambiado recientemente? El cambio introduce nuevos riesgos. ¿qué características se han creado? ¿Qué código se ha refactorizado? ¿Qué bibliotecas se han actualizado? Enfoquen al equipo para probar primero estas áreas
- Pruebas de regresión. Tenga una lista de verificación de, como máximo, una docena de escenarios de funcionalidad básica (tal vez alrededor del registro, los pagos y las principales cosas que la gente hace con su producto). Pida a la gente que considere estos casos mientras hace 1), tal vez pida a la gente que ponga el nombre junto a un caso cuando lo prueben para que pueda hacerse una idea de la cobertura
- ¿Qué otras pruebas deberíamos/podríamos hacer? A veces puede tener sentido hacer una sesión de prueba de errores de lápiz, una prueba de rendimiento o una prueba de navegador cruzado, pero no tiene que ocurrir cada vez que
Pruebe en producción
Si puede; pruebe en producción. No hay un ambiente como este.
Pero si no puedes probar en producción, asegúrate de que tu entorno de prueba sea estable, que tus datos estén configurados y que le hayas dado a tu equipo la solicitud de «No tocar excepto para pruebas de errores».
Post Bug Bash
Asegúrese de agradecer a la gente por su tiempo, contar los errores y darle elogios a su mejor cazador de errores. Después de todo, las pruebas y la calidad son una responsabilidad del equipo. Envía un correo electrónico de agradecimiento con los resultados y los trofeos de premio. He entregado este trofeo de un bicho rinoceronte en resina en una base de trofeos a nuestro cazador de insectos número uno antes:
