Tanto en mi Equipo Scrum como en el Departamento de TI en general, no tenemos un solo personal de control de calidad contratado. De hecho, la alta dirección nos ordena que no podamos contratar a uno (y no creo que esto cambie). A pesar de esto, todavía existe un requisito de calidad y funcionamiento del trabajo, incluso antes de que se entregue a los usuarios (internos) para pruebas beta/UAT.
La forma en que esto se ha resuelto hasta ahora es que el PO también actúe como control de calidad. Sin embargo, vale la pena señalar el hecho de que también se desempeña como PM para cada proyecto que tiene el departamento y , a veces, incluso como secretaria. Como resultado, las historias a menudo se consideran 'Terminadas' solo hacia el final de un Sprint, o bien adelantan uno (o más) Sprints antes de que pueda encontrar el tiempo para realizar el control de calidad. Obviamente, no podemos hacer que los desarrolladores se queden sentados durante un mes para permitir que ella se ponga al día.
Tal como lo veo, las únicas soluciones que he encontrado son:
No me gusta mucho ninguna de estas opciones; ¿Existe una ruta mejor para mejorar nuestro proceso?
Hemos tenido problemas con el mismo problema en mi equipo, aunque no hay reemplazo para un control de calidad de calidad en el equipo, hemos logrado llevarnos bien usando múltiples sombreros.
Este es nuestro flujo de trabajo:
Un par de puntos de interés que hacen que esto sea efectivo.
Estamos constantemente ampliando nuestro conjunto de pruebas automatizadas. Las regresiones se están convirtiendo en bestias raras.
El "control de calidad" también es el revisor por pares y revisa el código antes de probarlo.
Esto significa que tienen la oportunidad de probar el código con una "caja blanca". Dado que ya tienen cierta comprensión del código, es más fácil encontrar casos extremos que pueden haberse pasado por alto y, en general, formas extrañas de romper la nueva función. También significa que los informes de errores a menudo incluyen el número de línea donde se encuentra el error y una sugerencia sobre cómo solucionarlo. (pero nunca una solución real, no queremos incentivar el descuido).
Sin embargo, con toda seriedad, siga presionando para obtener un control de calidad. En mi experiencia, ni siquiera el desarrollador más preocupado por la calidad puede compararse con lo que puede hacer un excelente control de calidad. Hemos podido salir adelante, pero no todos los desarrolladores están hechos para hacer que el contexto cambie de "hacer que funcione" a "¿cómo puedo romperlo?"
Ya hay algunas buenas respuestas sobre cómo cubrir las tareas de prueba por parte del equipo. Espero agregar algo un poco diferente con esta respuesta:
En mi experiencia, la mayor habilidad que un ingeniero de control de calidad aporta al equipo no es la capacidad de ejecutar pruebas (como han cubierto otras respuestas, eso es bastante fácil de automatizar o delegar). Más bien, es la perspectiva que aportan de una carrera de buscar casos extremos, grietas en el plan, etc. Si no puede contratar a alguien para ese rol, le recomiendo buscar y cultivar esa habilidad en sus desarrolladores o nuevos empleados. .
También recomendaría investigar cómo Lean recomienda incorporar calidad. Cree hábitos para identificar fuentes comunes de problemas en su código y abordarlos. Construir prácticas de desarrollo de calidad es mejor que tratar de detectar los problemas en el camino cada vez.
Creo que debería contratar a una persona con experiencia en control de calidad, pero no como alguien que haga las pruebas reales, sino como alguien que infecta a todos los demás con el virus de prueba . Si no puede contratar a un probador, contrate a un desarrollador con experiencia en pruebas o busque a alguien en el equipo que quiera especializarse un poco más en las pruebas.
Creo firmemente que parte de ser un buen desarrollador de software es ser un buen probador.
-- John Sonmez
Las pruebas deben realizarse por adelantado y en paralelo con la codificación, no al final. Por lo tanto, tiene mucho sentido que las personas del equipo Scrum realicen las pruebas reales. Ambos automatizados y con sesiones de pruebas exploratorias. Obtenga información sobre los cuadrantes de pruebas ágiles y encuentre un buen equilibrio entre los esfuerzos de prueba.
Lecturas sugeridas:
Pruebas de IU automatizadas
Solicite a los desarrolladores que escriban pruebas automatizadas que demuestren la funcionalidad de las características que desarrollan. es decir, seleninum/TestUI/CodedUI, etc.
Esto aumentará la carga en la escritura de especificaciones y disminuirá la carga en las pruebas.
Haz pruebas en grupo:
Desafortunadamente, no tenemos un probador dedicado en nuestro equipo, lo que significa que dependemos de las capacidades de prueba de todos los miembros del equipo. Eso podría ser correcto según los libros, pero mi experiencia es que los desarrolladores no tienen la misma mentalidad que tiene un evaluador. Intentamos compensar esto organizando sesiones de prueba internas explícitas en las que todo el equipo prueba una función terminada. Nos animamos mutuamente a planificar sesiones de prueba internas tanto como sea posible. Estas sesiones de prueba internas son extremadamente valiosas.
Luego haz una demostración:
Sí; para el viernes, generalmente tenemos algunas funciones listas para mostrar al propietario del producto. Por lo tanto, necesito verificar con él que la nueva funcionalidad que estamos implementando durante este sprint está haciendo lo esperado. Escribimos un breve escenario de cómo vamos a utilizar esta nueva funcionalidad y agregamos una lista de preguntas para eliminar cualquier duda. Después de que el propietario del producto nos envíe sus respuestas, podemos continuar con la implementación.
y finalmente ejecute una copia de los datos de producción en un entorno de prueba de ensayo general:
El martes por la mañana, nuestro socio tecnológico implementa nuestro código en el entorno UAT. Cuando el propietario del producto firma la UAT, el código se implementa en el entorno Clones (que es un segundo entorno de aceptación que contiene una copia exacta de los datos en vivo del servidor de producción) el miércoles. En el entorno Clones, probamos para verificar que los datos en vivo no se verán afectados por nuestros cambios y para ver si la funcionalidad agregada está haciendo lo que debería hacer con los datos reales.
Referencias
Secundo el enfoque de Ewan : el código de autocomprobación y las pruebas automatizadas son la forma de resolver esto.
Código de autocomprobación : será necesario volver a trabajar en el código existente y las dudas por parte de su equipo serían comprensibles.
Pruebas automatizadas : lo mejor sería contratar a otro programador , que luego programaría pruebas en lugar de productos, y la gerencia no se daría cuenta.
O, como sugiere en la opción n.º 2, simplemente use parte del tiempo de los programadores existentes para escribir pruebas automatizadas.
Un enfoque diferente, dependiendo de sus productos, sería iniciar un programa Alpha, donde los usuarios esencialmente están probando e informando errores de forma gratuita; sin costo para la administración y usted prueba su producto mientras lo desarrolla.
nathan cooper