qa - servicios - Aseguramiento de la calidad en pequeños equipos de desarrolladores.

qa de servicios desarrollados (12)

¿Utiliza alguna metodología de desarrollo de software, como por ejemplo Scrum ? Scrum es una buena forma Agile de trabajar, pero también hay otros buenos procesos.

Utilizamos Scrum. Esta es una buena manera de hacer que nuestros equipos sean eficientes, pero también es una buena manera de introducir reglas en la forma en que desarrollamos el software. Como tú, soy parte de un pequeño equipo. Desafortunadamente, no hemos sido bendecidos con un departamento de control de calidad ni con ningún personal de control de calidad dedicado. El trabajo realizado durante el Sprint debe ser potencialmente expedible, por lo que los desarrolladores del equipo deben manejar el trabajo de control de calidad.

En Scrum y, por ejemplo, Kanban, utiliza un Tablero de tareas para realizar un seguimiento del Sprint actual, y estos tableros a menudo tienen una columna para las tareas en espera de la aprobación de QA. Lo que hacemos es que cuando se realiza una tarea, la pasamos a "Listo para verificación". Y luego otro desarrollador en el equipo hace el trabajo de control de calidad. El va a

Asegúrese de que la nueva funcionalidad haga lo que se espera que haga / bug ha sido arreglado / etc.
Verificar que haya suficientes pruebas unitarias.
Haga una revisión rápida del código para verificar que el código se vea limpio y comprensible

Si hay algo que no es satisfactorio en la revisión, volverá a iniciar la tarea, y debe solucionarse antes de que pueda ingresar a otra sesión de control de calidad.

Ninguno de nosotros realmente tiene conocimiento sobre control de calidad, pero experimentamos un aumento en la calidad del código después de introducir la verificación.

Lo ideal es que en un proyecto sean desarrolladores, evaluadores, gestores de control de calidad, etc., los cuales contribuyen a la calidad del código. ¿Pero qué pasa si no tienes ese tipo de recursos? Si solo tiene, por ejemplo, tres desarrolladores y no tiene los recursos para contratar a un gerente de control de calidad a tiempo completo, ¿cómo puede asegurarse de que la calidad del código cumpla con los estándares establecidos?

¿A qué tipo de cosas presta atención en el aseguramiento de la calidad? La calidad no se trata solo de que el código haga lo que se supone que debe hacer (el código se prueba correctamente con pruebas automáticas). La calidad también tiene que ver con la limpieza del código (legible, mantenible, bien estructurado, documentado, etc.).

Espero con interés escuchar qué tipo de procesos ha aplicado a su equipo para garantizar que la calidad cumpla con los estándares establecidos. Hemos aplicado un proceso en el que rotamos el rol de control de calidad entre los desarrolladores. Cada desarrollador es responsable del control de calidad una semana a la vez. Cada conjunto de cambios se revisa y verifica que las pruebas existentes se aprueben, se hayan escrito nuevas pruebas requeridas, que el código esté limpio y, por supuesto, que el proyecto se construya.

Editar:

Por supuesto, parte de este proceso se puede automatizar con CI, pero lo que busco es la experiencia del factor humano. Quiero decir, ¿cómo se asegura de que cada desarrollador escriba un código limpio y realmente pruebe todo? La cobertura de prueba no le dice si todo ha sido probado (desde una perspectiva automática, es prácticamente imposible lograr una cobertura del 100%) a menos que lo inspeccione manualmente. E incluso si la cobertura le indicara que algo se ha probado, no significa que la prueba real haga la prueba para la cosa correcta.

El propósito de un departamento de control de calidad es identificar y:

capacitar a las personas que no conocen la calidad del software
reasignar (o despedir) a personas que no se preocupan por la calidad del software

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

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

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 crítico 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 detectó e informó 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 de manera un poco diferente, pero aún así intentamos crear calidad desde el principio, por lo que tendremos menos problemas más adelante. Tenemos un equipo de pruebas cuyo trabajo es derribar lo que queda de los egos de nuestros desarrolladores, pero no el departamento de control de calidad. Pero, no hay una bala mágica para construir en calidad. Algunas cosas que ayudan en nuestros equipos actuales incluyen ...

Revisiones de código regulares / revisiones de amigos para el código nuevo antes de registrarlo.
Ejecutando herramientas de análisis estático como pelusas.
Dejando el ego en la puerta.
Cumplimiento de normas de codificación.
Comprobación del código de prueba utilizado para desarrollar la característica / corrección. El equipo de pruebas utiliza esto como parte de sus pruebas de regresión.

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

Espero que esto ayude. Espero que esto ayude.

En un equipo pequeño, lo más importante es elegir a las mejores personas que pueda encontrar y evitar a toda costa a cualquiera 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 que alguien desempeñe un papel oficial de control de calidad:

Pruebas unitarias automatizadas
Compilaciones automatizadas, con la frecuencia que puedas administrar
Medida de cobertura de pruebas.
Revisiones de código de pares de checkins
Normas y convenciones de codificación aceptadas.
Ramas personales
Fusiones frecuentes
¡Come tu propia comida de perro!

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

Las sucursales personales permiten que los desarrolladores realicen múltiples inspecciones sin afectar el trabajo de otros desarrolladores hasta que esté listo para fusionarse, pero se fusionan con frecuencia para evitar problemas que no se notan en una sucursal que no se ha probado.

Enchufe descarado aquí, pero puede usarnos: https://99tests.com/crowd-functional-testing-bugbash . Tenemos bastantes clientes que confían plenamente en nosotros para enviar sus productos y nuevas funciones. Te ahorra el dolor de cabeza de administrar y obtener un control de calidad correcto. Nuestra multitud de evaluadores informa, valida y proporciona errores reproducibles detallados que su equipo de desarrolladores puede comprender y corregir fácilmente.

También acabamos de comenzar con una nueva oferta llamada CrowdCI, donde las implementaciones en el servidor activan automáticamente los ciclos de prueba y los errores encontrados desaparecen en tiempo real.

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 varios pares de ojos ven el código antes de que entre en el proyecto . He estado en equipos que lo hicieron con éxito de dos maneras:

Revisión grupal del código crítico. A menudo, el código es presentado por alguien que no sea su autor.
Revisión individual del código de alguien más fuera de línea.

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 sea que cree), 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 aún así es mejor que nada.

La revisión de los conjuntos de cambios regularmente es genial; sin embargo, mirar el código y luego volver a escribir una respuesta en el elemento de trabajo asociado con el conjunto de cambios y enviarlo al desarrollador puede llevar demasiado tiempo o se pueden cruzar los cables. Revisiones de código son el camino a seguir.

Una vez que se haya completado un trozo 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, el implementador puede hablar sobre lo que han hecho, por qué lo han hecho de esa manera, etc. De esta manera, el revisor puede mirar el código y no tener que perder tiempo tratando de entender "por qué ¿Lo hicieron de esa manera? De esta manera, el revisor también puede sugerir otras formas mejores de hacer una determinada rutina o enseñarle al implementador una determinada característica en el marco que se está utilizando y que tal vez no conozcan.

Se trata de aprender y transmitir la información; Esto ayuda a mejorar el código.

Espero que esto ayude.

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

He trabajado en equipos en los que la compilación diaria se realizó manualmente y el desarrollador que realizó la compilación también tuvo que realizar el trabajo de integración, ya que, con demasiada frecuencia, los criterios de registro fueron "se basa en mi máquina". Poner en marcha una compilación automatizada que se inicia ya sea en cada registro o al menos una vez cada hora, y exigir que el desarrollador cuyo registro rompió la compilación sea un paso masivo en la dirección correcta y (con suerte) garantizará una mejor calidad a lo largo del tiempo.

La limpieza del código es algo que me cuesta impresionar en un equipo externo. En cierto sentido, esto suena lo que estás haciendo: ¿el rol de control de calidad que limpia el código? - Pero tal vez me equivoque. Si no me equivoqué, creo que necesitarás cambiar eso. La calidad no es algo que se pueda o se deba seguir como una idea de último momento, las personas que trabajan en el código deben esforzarse por alcanzar los objetivos de calidad y las revisiones de código deben resaltar las áreas donde el desarrollador original necesita mejorar el código, pero no tener una "QA Persona "entra y límpialo. Le pido disculpas si he entendido mal esto, pero si esto es parte de su proceso, esto necesita cambiar en este momento porque está haciendo el equivalente a limpiar la habitación de la adolescente desordenada.

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 a 4 personas sin ningún control de calidad formal. Tenemos clientes muy satisfechos y bajos conteos 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 las pruebas de unidad como las de integración, y existe la presión del equipo para asegurarse de que las pruebas estén ahí.
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 las preguntas usted mismo.
Tenemos "retrospectivas" regulares donde preguntamos qué podemos mejorar. En relación con eso, si tenemos problemas de calidad, el equipo determina qué debe cambiar para solucionarlo ( análisis de 5 por qué). Hemos instigado tales reglas como "dos ojos en cualquier registro" para abordar los problemas.

Todo lo dicho, la calidad es, en última instancia, sobre los usuarios satisfechos. Intento hacer que la gente vuelva a eso cuando discute la calidad en el resumen (y discute sobre nombres de variables). En última instancia, debería tratarse de cómo el software resuelve los problemas de los usuarios, y no bloquearse es solo el primer paso.

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

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

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

Si tiene una caja de repuesto, puede configurar las compilaciones automatizadas para que se realicen cada noche, cada hora o incluso después de cada registro, e incluso realizar pruebas de unidad en esas compilaciones automatizadas.

Sin embargo, el mayor aumento de calidad que he hecho nunca se produjo después de enviar accidentalmente una versión no funcional a un cliente. Después de quitarnos el huevo de la cara, creamos una lista de verificación formal de seis páginas para crear y verificar lanzamientos, comenzando con diferentes máquinas de compilación y prueba, cada una con un sistema operativo recién instalado y herramientas adecuadas y bien definidas. Hubo tres roles diferentes (ingeniero de construcción, probador, ingeniero de lanzamiento), verificaciones cruzadas, y cada individuo puso sus iniciales en cada paso del que era responsable cuando lo terminaron. Si algo no funcionó exactamente de acuerdo con el plan, solucionamos el problema y comenzamos de nuevo. Para la mayoría de los proyectos, tomaron alrededor de 4 a 8 horas, y cuando las cosas no funcionaron y tuvimos que volver a empezar, a veces teníamos noches muy tarde, pero nunca más enviamos un lanzamiento escamoso.

Podría configurar un servidor que haga análisis de código estático como Sonar . Puede configurarse para realizar el checkout y construir su código una vez al día y ejecutar la sintaxis y las comprobaciones semánticas proporcionadas por diferentes complementos (Checkstyle, Findbugs, etc.) sobre su código y produce una salida HTML agradable para que todos en el equipo puedan ver los posibles problemas encontrados. en el codigo

Tenga en cuenta, sin embargo, que puede haber falsos positivos.

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 el control de calidad, surgirá un conflicto de intereses, ya que el administrador de desarrollo normalmente querrá lanzar el producto para cumplir sus objetivos (que generalmente están relacionados con el tiempo). En una estructura organizativa donde QA / QC informa al Dev manager, nos referimos a este QA / QC como "servicios de ingeniería" (pruebas, documentación) y no como una verificación / validación independiente (IV&V) del software que se entrega.