Garantía de calidad en pequeños equipos de desarrolladores

Parece que estás haciendo muchas cosas bien y haciendo las preguntas correctas.

Durante los últimos tres años he trabajado en equipos de desarrollo de 2-4 personas sin ningún control de calidad formal. Tenemos clientes muy satisfechos y bajo número de errores.

Esto funciona para nosotros porque:

• La prioridad de todos es el software de calidad. No pasamos un rol de control de calidad, pero todos lo hacemos todo el tiempo. Queremos que nuestro código se vea bien. Y todos los desarrolladores están ansiosos por escribir tanto la unidad como la integración pruebas, y hay presión del equipo para asegurarse de que las pruebas están allí.
• Emparejamos el programa extensivamente. Esta pequeña sobrecarga mejora significativamente la calidad y tiene todo tipo de ventajas. Usted desarrolla una comprensión compartida de lo que significa "calidad", y responde a las preguntas usted mismo.
• Tenemos "retrospectivas" regulares donde preguntamos qué podemos mejorar. En relación con eso, si tenemos problemas de calidad, el equipo se da cuenta de lo que necesita cambiar para abordar esto (5 Por qué análisis). Hemos instigado reglas tales como" dos ojos en cualquier cheque " para abordar los problemas.

Dicho todo esto, la calidad se trata en última instancia de usuarios satisfechos. Trato de traer a la gente de vuelta a eso cuando se discute la calidad en abstracto (y se discute sobre nombres de variables). En última instancia, debe tratarse de cómo el software resuelve los problemas de los usuarios, y no estrellarse es solo el primer paso.

Para empezar, si aún no lo ha hecho, le recomendaría encarecidamente configurar una compilación automatizada que también ejecute las pruebas unitarias, preferiblemente con cobertura de código para verificar si hay áreas que necesitan más cobertura de prueba unitaria. No soy un fanático masivo de requerir una cobertura de código del 100%, pero cualquier cosa que solo tenga alrededor del 60% -80% probablemente necesite ser investigada.

He trabajado en equipos donde la compilación diaria se hacía manualmente y el desarrollador que hacía la compilación tenía que realizar el trabajo de integración también, ya que con demasiada frecuencia los criterios de check-in eran "se basa en mi máquina". Obtener una compilación automatizada que se inicia ya sea en cada registro o al menos una vez cada hora y requerir que el desarrollador cuyo registro rompió la compilación la arregle es un paso masivo en la dirección correcta y (con suerte) asegurará mejorar la calidad con el tiempo.

La limpieza del código es algo que encuentro difícil de impresionar en un equipo desde el exterior. En cierto sentido, esto suena lo que estás haciendo: el rol de control de calidad limpiar el código? - pero tal vez me equivoqué. Si no me equivoqué, creo que tendrás que cambiar eso. La calidad no es algo que puedas o debas aprovechar como una idea de último momento, las personas que trabajan en el código deben esforzarse por lograr los objetivos de calidad y las revisiones del código deben resaltar las áreas donde el desarrollador original necesita mejorar el código, pero no tener una "persona de control de calidad" que lo limpie. Disculpas si he malinterpretado esto, pero si esto es parte de su proceso esto necesita cambiando ahora mismo porque estás haciendo el equivalente de mamá limpiando el dormitorio del adolescente desordenado.

En un equipo pequeño, lo más importante es elegir a las mejores personas que pueda encontrar y evitar a toda costa a cualquier persona que interrumpa su equipo de desarrollo. Si ya tienes a alguien así, deshazte de él.

He encontrado que todo lo siguiente es útil para mantener la calidad con o sin alguien que desempeña un papel oficial de control de calidad:

• Pruebas unitarias automatizadas
• Compilaciones automatizadas-tan frecuentes como pueda administrar
• Medición de la cobertura de pruebas
• Revisiones del código de pares de checkins
• Convenciones y normas de codificación aceptadas
• Ramas personales
• Fusiones frecuentes
• ¡Come tu propia comida para perros!

De estos, las pruebas automatizadas son las más importantes, seguidas por las revisiones por pares. No he encontrado que los tutoriales de código de grupo valgan la pena el tiempo que cuesta, pero las revisiones individuales justo antes o justo después del registro generalmente valen la pena el tiempo. Las revisiones de check-in funcionan mejor cuando se mantienen los check-ins relativamente pequeños y no combinan muchos cambios no relacionados.

Las ramas personales permiten a los desarrolladores hacer múltiples check-ins sin afectar el trabajo de otros desarrolladores hasta que esté listo para ser fusionado, pero se fusionan con frecuencia para evitar problemas inadvertidos de una rama bajo prueba.

La revisión de los conjuntos de cambios regularmente es excelente; sin embargo, mirar el código y luego escribir una respuesta en el elemento de trabajo asociado con el conjunto de cambios y enviarlo de vuelta al desarrollador puede consumir demasiado tiempo o los cables pueden cruzarse. Las revisiones de código son el camino a seguir.

Una vez que se haya completado un fragmento de código/funcionalidad, organice una revisión del código entre el desarrollador y el desarrollador de control de calidad designado semanalmente o el otro desarrollador. Pueden sentarse y mirar el código, la el implementador puede hablar de lo que ha hecho, por qué lo ha hecho de esa manera, etc. De esta manera, el revisor puede mirar el código y no tener que pasar tiempo tratando de entender "¿por qué lo han hecho de esa manera?". De esta manera, el revisor también puede sugerir otras, mejores, formas de hacer una cierta rutina, o enseñar al implementador una cierta característica en el marco que se está utilizando que puede no haber conocido.

Se trata de aprender y transmitir la información; esto ayuda a mejorar codificar.

Espero que esto ayude.

Hice algunas investigaciones relacionadas hace más de 20 años. No creo que la respuesta haya cambiado. En un equipo pequeño, lo más importante es que múltiples pares de ojos ven el código antes de que entre en el proyecto. He estado en equipos que hicieron esto con éxito de dos maneras:

• Revisión grupal de código crítico. A menudo el código es presentado por alguien otro que su autor.

• Revisión individual del código de otra persona offline.

En estos días estoy mucho menos involucrado en los esfuerzos de software que realmente tienen que funcionar (es uno de los inconvenientes de mi trabajo que los incentivos no son para crear un buen software sino para publicar artículos sobre lo que creo), pero probablemente agregaría un tercer método:

• Programación de pares.

Tengo mucha experiencia con la programación de pares, y creo que es más adecuado para resolver problemas difíciles que para garantizar la calidad, pero es aún mejor que nada.

Ya sea en equipos pequeños o grandes, la función de control de calidad (incluidas las pruebas) debe ser independiente de la función de desarrollo. Si el administrador de Desarrollo tiene control sobre QA, entonces surgirá un conflicto de intereses, ya que el administrador de Desarrollo normalmente querrá lanzar el producto para cumplir con sus objetivos (que generalmente están relacionados con el tiempo). En una estructura organizacional donde QA\QC informa al Dev manager, nos referimos a este QA\QC como "servicios de ingeniería" (pruebas, documentación) y no como verificación independiente\validación (IV & V)del software que se entrega.

El propósito de un departamento de QA es identificar y:

• Capacitar a las personas que no conocen la calidad del software

• Reasignar (o despedir) personas que no se preocupan por la calidad del software

Como tal, es una forma especializada de recursos humanos, uno que piensa en agregar una vez que su departamento de recursos humanos crezca por encima de 3 personas. Si conoce los nombres y capacidades de todos los que trabajan en su empresa, es muy probable que haga un mejor trabajo @120 minutos a la semana que el especialista promedio a tiempo completo lo haría.

Esto ignora el caso (por ejemplo, algunos contratos del sector público) donde 'documentación de QA' es un entregable en sí mismo, en cuyo caso probablemente necesite una persona para hacer eso y otra persona para hacer QA.

En mi primer trabajo de software fuera de la escuela, estábamos generando grandes conjuntos de datos de acuerdo con las especificaciones del cliente. Era fundamental que estos datos fueran correctos, ya que millones de dólares dependían de cada uno de ellos. Teníamos un pequeño equipo de tres personas. Una persona escribiría / modificaría el código para generar el archivo de datos. La segunda persona escribiría / modificaría el código para verificar el archivo de datos. La tercera persona certificaría corrompiendo intencionalmente una copia del archivo de datos para asegurarse de que el programa de verificación captó y reportó correctamente todos los tipos de errores. Rotamos a través de cada una de estas posiciones.

Hoy en día, estoy haciendo software en un campo diferente, y organizamos las cosas un poco diferente, pero aún así tratamos de construir calidad desde el principio, por lo que tenemos menos problemas más adelante. Tenemos un equipo de pruebas cuyo trabajo es destruir lo que queda de los egos de nuestro desarrollador, pero no hay un departamento de control de calidad. Pero, no hay una bala mágica para construir en calidad. Algunos las cosas que ayudan en nuestros equipos actuales incluyen ...

1. Revisiones regulares de código/comprobaciones de amigos para nuevo código antes de registrarlo.
2. Ejecutar herramientas de análisis estático como lint.
3. Dejando el ego en la puerta.
4. Hacer cumplir las normas de codificación.
5. Comprobación del código de prueba utilizado para desarrollar la característica/corrección. El equipo de prueba utiliza esto como PARTE de sus pruebas de regresión.

No soy un probador, y hay mucho que no sé al respecto. Sin embargo, el la primera lección que me enseñaron con respecto a esto fue que una prueba escrita para pasar no tiene valor must debe ser escrita para fallar.

Espero que esto ayude. Espero que esto ayude.

Parece que va en la dirección correcta, y confío en que esté utilizando un sistema de seguimiento de errores/problemas. Aquí hay algunas otras ideas.

Si está haciendo software GUI, ayuda tener scripts de prueba escritos, y también hacer pruebas ad-hoc. La trampa con eso es, como los desarrolladores, todo lo que haces es pruebas de caja blanca, por lo que ocasionalmente puedes pedir a amigos o familiares que no saben mucho sobre el software que se metan con él con muy poco entrenamiento.

Otra cosa que puedes hacer con el software GUI es obtener una herramienta automatizada que dispara clics aleatorios del ratón y pulsaciones de teclas en su software, y simplemente dejarlo funcionando durante mucho tiempo. Es sorprendente la cantidad de errores que se pueden encontrar.

Si tiene una caja de repuesto, puede configurar compilaciones automatizadas para que se realicen cada noche, cada hora o incluso después de cada check-in, e incluso ejecutar pruebas unitarias en esas compilaciones automatizadas.

El mayor impulso de calidad individual que he hecho, sin embargo, vino después de enviar accidentalmente un no funcional liberación a un cliente. Después de raspar el huevo de nuestras caras, se nos ocurrió una lista de verificación formal de seis páginas para crear y verificar versiones, comenzando con diferentes máquinas de compilación y prueba, cada una con un sistema operativo recién instalado y herramientas apropiadas y bien definidas. Había tres roles diferentes (ingeniero de construcción, probador, ingeniero de versiones), verificación cruzada, y cada individuo iniciaba cada paso del que eran responsables a medida que lo terminaban. Si algo no salió exactamente de acuerdo al plan, arreglamos cualquiera que fuera el problema y comenzó de nuevo. Para la mayoría de los proyectos, tomó alrededor de 4-8 horas, y cuando las cosas no funcionaban y teníamos que empezar de nuevo, a veces teníamos noches muy largas, pero nunca enviamos un lanzamiento escamoso de nuevo.

Puede configurar un servidor que haga análisis de código estático como Sonar. Se puede configurar para pagar y construir su código una vez al día y ejecutar comprobaciones de sintaxis y semántica proporcionadas por diferentes complementos (Checkstyle, Findbugs, etc.).) sobre su código y produce una buena salida HTML para que todos en el equipo puedan ver los problemas potenciales encontrados en el código.

Sin embargo, tenga en cuenta que puede haber falsos positivos.

Plug desvergonzada aquí, pero usted podría utilizar nosotros: https://99tests.com/crowd-functional-testing-bugbash . Tenemos un buen número de clientes que confían plenamente en nosotros para el envío de sus productos y nuevas características. Le ahorra el dolor de cabeza de administrar y obtener el control de calidad correcto. Nuestra multitud de probadores informa, valida y proporciona errores reproducibles detallados que el equipo de desarrollo puede comprender y corregir fácilmente.

También estamos empezando con una nueva oferta llamada CrowdCI, donde se despliega para el servidor activa automáticamente los ciclos de prueba y los errores encontrados van directamente a slack en tiempo real.