Bueno, el título realmente lo dice todo, pero para elaborar un poco, ¿puede tomar un departamento de control de calidad aleatorio y típicamente efectivo y hacer que aprendan a trabajar en un entorno XP (con una curva de aprendizaje para recoger el flujo de trabajo XP, por supuesto) o ¿necesitarían más habilidades de programación para ser efectivos? Si es así, ¿qué necesitarían saber?
Respuestas:
QA ¿Conversión de equipo a XP?
Esta pregunta que hace es una de la que dependen muchos evaluadores tradicionales para sobrevivir en su carrera.
La respuesta corta es quizás. Tiene razón al identificar el flujo de trabajo como un problema, pero el flujo de trabajo es simple en comparación con la capacitación para la programación y el desarrollo. Hacer probadores en programadores puede ser un puente demasiado lejos. Hay muchas otras habilidades que tienen una afinidad más cercana al conjunto de habilidades actual de sus evaluadores.
Creo que los Ingenieros de Pruebas de Software tienen un rol, pero dos nuevas criaturas están en la escena, el Desarrollador Controlado por Pruebas y el Ingeniero de Desarrollo de Software en Pruebas que se harán cargo de una gran cantidad de césped que solía pertenecer al STE.
XP Workflow
Bajo un flujo de trabajo XP, la prueba de la unidad es responsabilidad del desarrollador. Normalmente, el flujo de trabajo implicaría crear la tarjeta de historia, elaborar un diagrama de casos de uso y algunos casos de uso, y luego convertirlos en casos de prueba. Los casos de prueba impulsarían el desarrollo en una metodología llamada Test Driven Development (TDD). Cada minuto que existe el programa, primero se implementa un caso de prueba, seguido de un código que inicialmente fallará, luego, después de un trabajo adicional, pase esa prueba. Cuando pasan todas las pruebas identificadas a partir de las tarjetas de historia, el producto está listo. O al menos se realiza el último incremento. Las pruebas unitarias se crean de forma dependiente del idioma y son parte del código. Hay muchas referencias, pero para una introducción rápida verifique Wikipedia, luego la siguiente página web de Scott Ambler.
http://www.agiledata.org/essays/tdd.html#WhatIsTDD
También hay una superposición significativa con las pruebas de aceptación del sistema porque los casos de prueba provienen de las tarjetas de historias y los casos de uso. ATDD (TDD de aceptación) hace una distinción, pero creo que podría ser algo arbitrario.
No todos toman las pruebas con la misma seriedad. Los gerentes pueden presionar a los desarrolladores para que no prueben. Pueden presionar para que los probadores no prueben también. Un año estuve bastante cansado cuando los desarrolladores de mi equipo estaban por debajo del presupuesto, pero los probadores del proyecto probaron correcciones de errores y nuevas características varias horas a la semana a pesar de que el plan del proyecto solo los tenía trabajando dos semanas al final. Parecía lo correcto, y el proyecto aún era rentable y los clientes tenían un mejor producto gracias a él.
Los desarrolladores deben probar. Es muy derrochador cuando no lo hacen porque los evaluadores deben ejecutar, informar y repetir. La calidad del software no es menos responsabilidad de los desarrolladores que los probadores. Este intercambio debería hacer que la vida del probador sea menos frustrante, pero también amplía la demanda de muchos conocimientos y habilidades para todos.
Si los desarrolladores no toman en serio las pruebas, las demandas de los probadores pueden aumentar porque obtendrá compilaciones diariamente. Durante un tiempo, se puede escuchar a la gente decir: "¿por qué parece que damos un paso adelante y dos hacia atrás"? La respuesta será porque ahora está utilizando un sistema en el que el equipo tiene una visibilidad como nunca antes lo había hecho y antes solo estaba en el 90% que esas personas sabían sobre el inminente desastre.
El cambio de las pruebas a los desarrolladores
Mi experiencia es que para acelerar el desarrollo, puede ayudar a mover los trabajos realizados por los probadores al desarrollo. Esto es cierto para todo, desde la prueba de interfaz de usuario de una pantalla táctil limpia hasta la prueba de laboratorio de calidad de hardware de Windows de elementos muy complejos como un controlador de Windows para WiFi.
Considere los días previos a la PC cuando los ingenieros dictaron memorandos e información técnica para que una secretaria sea escrita, duplicada y distribuida. Compare eso con un desarrollador que usa correo electrónico, un wiki de intranet, comentarios en el seguimiento de errores, control de código fuente o herramientas de revisión de código, mensajería instantánea, etc. Simplemente tenemos demasiados cambios que necesitamos probar y las comunicaciones y la transferencia de conocimiento son muy similares. desalentador que gran parte de nuestras pruebas estén automatizadas para su implementación directa por desarrolladores sin delegación para probar.
Valor agregado para probadores
He trabajado con algunos probadores que podrían ser ingenieros de sistemas, y algunos que tienen excelentes habilidades de comunicación (casi lectura mental / telepatía). Mi trabajo más efectivo con ellos fue cuando hicieron un buen trabajo explicando el comportamiento inesperado que vieron en el sistema, generalmente por escrito en el rastreador de errores, aunque a menudo una demostración fue extremadamente útil.
Otro criterio importante es que el esfuerzo de una transferencia de código fue lo más pequeño posible. Durante un tiempo, los desarrolladores sintieron cierto alivio cuando los evaluadores pudieron generar sus propias compilaciones. Ahora, utilizamos servidores de integración constante, por lo que los desarrolladores solo necesitan confirmar la fuente y siempre que usemos TDD correctamente, hay muchas pruebas que se ejecutan por sí mismas e informan.
La competencia global está presionando los tiempos de ciclo y el retrabajo se está retrabajando del sistema. Si mañana escucho de un probador sobre un defecto que agregué hoy, ¿cómo competiré con el tipo que no hizo un defecto hoy (o lo encontró él mismo)? Todavía no hemos llegado, pero creo que los días de los programadores de corte y prueba están contados. He visto demostraciones de desarrolladores de Google que pueden haber ensayado mucho, pero parecen ser capaces de escribir un programa de principio a fin durante una conferencia de 90 minutos, explicando cómo escriben con pocos o ningún problema en el ciclo de cambio y ejecución . Los evaluadores agregan valor al acortar el tiempo entre el trabajo y la reelaboración, por lo que los informes concisos y tempranos sobre la construcción de hoy son una gran ventaja.
Nuevos roles de prueba
Muchas organizaciones están creando roles para SDET: ingeniero desarrollador de software en prueba. Estos tipos de script, código y revisión de código. El siguiente enlace es a un blog para un SDET en Microsoft.
http://aliabdin.wordpress.com/2007/03/31/what-does-an-sdet-do/
También describe Ingenieros de pruebas de software (STE) que alimentan los errores que encuentran a SDET. Otra cosa que me llamó la atención sobre el papel de SDET es que, a diferencia de los desarrolladores de software tradicionales, cuando tienen sistemas defectuosos, necesitan conocer el código de todo el sistema porque casi cualquier parte podría ser la fuente del problema, por lo que el extenso mapa mental les ayuda rastrearlo.
Formando una visión que conduzca a una transición exitosa
Me he encontrado con un problema similar de un gerente de proyecto que no sabe cómo encajar ese rol en scrum. Ser scrum master era su destino de transición. Es un rol bien definido, y hay capacitación para ello. Siga buscando y puede encontrar algo similar para las pruebas.
Aquí hay más información sobre las pruebas ágiles:
http://www.ambysoft.com/essays/agileTesting.html#AgileTestingStrategies
y sobre el equipo de prueba independiente aquí:
http://www.ambysoft.com/essays/agileTesting.html#IndependentTestTeam
Las observaciones de Scott Ambler sobre la proporción de desarrolladores a evaluadores en enfoques ágiles vs. tradicionales no le alegrarán el día (15: 1 vs. 3: 1). Sugeriría comprender y crear una visión para su equipo de prueba basada en habilidades y experiencia en herramientas:
Buena suerte en la transición a XP y en preparar a tu equipo para hacer lo mismo.
Para el desarrollo típico basado en pruebas, probablemente no sea necesario que sus QA conozcan ninguna programación.
Pero si está haciendo un desarrollo impulsado por el comportamiento, sería beneficioso que sus QA conozcan un idioma como Cucumber . Especialmente, si sus analistas de negocios están escribiendo requisitos de historia en el estilo Dado-Cuándo-Entonces.
Sin embargo, realmente depende de su 'gente' y de las herramientas con las que está trabajando. Diría que es posible que sean efectivos con cero conocimientos de programación, pero ciertamente no perjudicaría y podría hacerlos más efectivos.