Hoy, el mundo celebra el día del probador. En esta ocasión, decidimos ayudarlo a ver el trabajo de estos especialistas desde diferentes puntos de vista, para que la cooperación brinde a todos los participantes el máximo beneficio y el mínimo estrés.
Crédito de la foto: David Goehring CC BY
1. "Vuelva a verificar, definitivamente no hay ningún error"
Comencemos con el problema fundamental. El foro de Ars Technica tiene un viejo hilo en el que un desarrollador habla sobre el odio profundo de los probadores "pedantes". Está terriblemente molesto porque algunos expertos en pruebas pasan horas buscando los errores más pequeños. Y lo que es más desagradable, todavía los encuentran.
Qué podría salir mal : no todos están dispuestos a admitir sus errores. Alguien comienza una vieja canción sobre "no un error, sino una característica", tratando de demostrar que todo estaba destinado. Otros solicitan persistentemente que verifiquen nuevamente el código y se aseguren de que no haya ningún error. El probador solo intenta hacer bien su trabajo, y en lugar de gratitud, lo envían a un nuevo examen.
Cómo ser : es simple: si el probador encontró una falla en su código y usted comprende que tiene razón, es mejor admitir este hecho. Ambos tienen el mismo objetivo: lanzar un producto depurado y funcional. El humor ayuda a llegar a un entendimiento sobre este tema. Aquí hay un artículo en el que los evaluadores reunieron un "fondo dorado" de declaraciones de desarrolladores que intentaban proteger su código. Le recomendamos que los revise e imagine cómo suenan estas frases "clásicas" desde el punto de vista del probador.
2. “Una semana antes del lanzamiento. Espero que no hayas planeado otras cosas para los próximos dos días ".
A veces, el código llega a los probadores unos días antes del lanzamiento. Luego tienen que trabajar a toda prisa. Algunos expertos en control de calidad creen que los colegas simplemente subestiman su trabajo. Supuestamente, piensan que encontrar errores es fácil y rápido, por lo que posponen la depuración en el último momento.
Lo que puede salir mal : en caso de emergencia, los evaluadores no solo se molestan, sino que pierden la vigilancia. La falta de tiempo es una de las principales razones por las que los evaluadores omiten errores.
Cómo ser : hay varios modelos de desarrollo. Desde el punto de vista de QA, hay dos enfoques principales: en cascada y Agile. En el primer caso, los evaluadores reciben fragmentos de código en etapas. En el segundo caso, prueban el código en paralelo con su escritura.
Agile ayuda a involucrar a los profesionales de QA en el proyecto desde el principio. Gracias a esto, no tienes que probar "una hora antes del lanzamiento". Además, este enfoque permite no encontrar errores, sino evitar su aparición. Si sus evaluadores se quejan de la presión constante del tiempo y fallan errores, eche un vistazo a esta metodología.
Foto: Tim Regan CC BY
3. “Rápidamente modifiqué el código. Mira, por favor.
Suponga que su equipo trabaja en un modelo en cascada y sabe cómo planificar correctamente las fases de desarrollo. Los probadores obtienen el código, y parece que hay tiempo suficiente para la depuración. Pero los desarrolladores tienen la costumbre de hacer un mínimo esfuerzo en esta etapa. Reciben un informe detallado de errores, lo leen superficialmente, eliminan rápidamente los errores obvios y envían el código al siguiente ciclo de prueba.
Lo que puede salir mal : el problema es que el código después de cambios superficiales a menudo regresa con aún más errores. El probador dedicó tiempo a preparar un informe detallado y, en respuesta, recibió algún tipo de respuesta. Tiene que ir por este camino varias veces más solo porque el desarrollador no quiere pasar tiempo en "errores menores".
Cómo ser : Obviamente, no te apresures. Pero esto no es suficiente. Debe averiguar por qué no está prestando la debida atención al informe. Si esto es pereza banal, solo tú puedes ayudarte a ti mismo. Hay otras razones Por ejemplo, cree que los ingenieros de control de calidad lo inundan con informes de errores insignificantes. Luego, debe aclarar este problema a nivel de liderazgo, en caso de que los evaluadores lo distraigan "en los detalles". Lo más probable es que la respuesta sea sí. Algunos gerentes de productos incluso piden a los desarrolladores que agreguen específicamente errores menores al código para que los evaluadores estén siempre en guardia. Es importante adoptar este enfoque y tratar los informes de errores con la debida atención.
4. “Parece que ya me he ocupado de este error. Pero no recuerdo exactamente "
A veces, un enfoque superficial es un problema sistémico. En algunos equipos, los informes de errores se pierden en el tiempo y el espacio. Nadie responde adecuadamente a los informes, sin marcar si el problema se ha resuelto o si todavía está en el limbo.
Lo que puede salir mal : los desarrolladores corrigen algún tipo de error, hacen lo que creen que son cambios "menores" en el código, se olvidan de notificar a los probadores al respecto y envían el código a la versión. Como resultado, el problema aparece cuando es demasiado tarde. Y el probador es a menudo el "extremo".
Cómo ser : el problema del caos debe resolverse sistemáticamente. El desorden perjudica el desarrollo, por lo que debe reestructurar completamente el proceso de comunicación en un equipo. Aquí vale la pena usar los consejos básicos para establecer la comunicación entre los desarrolladores y los ingenieros de control de calidad: para determinar la terminología; formular claramente los requisitos; Introducir una jerarquía de prioridad para varios errores. En cuanto a la confusión con los errores, hay buenos consejos prácticos: a) dejar que los errores informen todo; b) entonces es importante priorizarlos; c) cualquier error cerrado implica que se escribirá una prueba funcional; d) el estado "resuelto" no lo asigna el desarrollador, sino el probador. Este enfoque garantiza que el problema se resuelva realmente.
Foto: Tim Regan CC BY
5. “¿Por qué debería probar esto? ¡No soy un probador!
En algunos equipos, la responsabilidad de la depuración recae completamente en los probadores. Los desarrolladores no se molestan en perder el tiempo en las pruebas unitarias más obvias. Están seguros de que este no es su trabajo. En general, lo es, aunque hay diferentes puntos de vista sobre el tema (con las opiniones de la comunidad se puede encontrar aquí ).
Qué podría salir mal : los evaluadores en esta situación tienen que lidiar con todas las deficiencias seguidas, incluso con los errores más primitivos y estúpidos. Por supuesto, esto es molesto.
Cómo ser : muchos desarrolladores prefieren las pruebas independientes antes de enviarlas al departamento de control de calidad. Esto ayuda no solo a aliviar a los evaluadores, sino también a aprender a mirar el producto desde el punto de vista del crítico y del usuario. Se cree que esto es útil para los profesionales y tiene el mejor efecto en el resultado final. Para aquellos que no quieren molestarse con los cheques, existen herramientas automáticas. Ayudan a encontrar los errores más obvios. En cualquier caso, incluso si el equipo tiene ingenieros de control de calidad, una separación estricta entre los desarrolladores y el control de calidad no es el mejor enfoque.
6. “Igor, hoy trabajas en conjunto con Oleg. Te gustará
Los gerentes de producto no se limitan al enfoque en cascada y Agile. A algunos les gusta experimentar. Por ejemplo, organice sesiones de programación y prueba de pares.
Lo que puede salir mal : esta es una forma efectiva de atrapar errores, pero también tiene desventajas: las personas pueden no estar entusiasmadas con las innovaciones. Un especialista en control de calidad, acostumbrado a trabajar solo, en otro piso y en su equipo, puede simplemente sentirse incómodo al abandonar el entorno familiar. Además, puede que no sea trillado con la experiencia y el conocimiento de un compañero. Como resultado, en lugar de pruebas productivas, los gerentes de producto obtienen dos empleados insatisfechos.
Cómo ser : el consejo principal es no cortar el hombro. Las prácticas ágiles y DevOps pueden parecer atractivas, pero sin una preparación adecuada no funcionarán.
7. "Llevaré tu dispositivo a pruebas, ¿te importa?"
El desarrollador tiene tiempo para comenzar a depurar, le pide al probador un dispositivo de prueba "literalmente durante 20 minutos" y se va con él durante largas horas.
Lo que puede salir mal : la mayoría de las veces, el desarrollador no devuelve el dispositivo a su lugar, y si lo hace, se descarga por completo. Teniendo en cuenta que los probadores pueden tener tareas paralelas en este dispositivo, esto no puede sino molestar.
Cómo ser : ponte recordatorios, pega calcomanías, haz cualquier cosa, pero devuelve las cosas de los evaluadores a su lugar y a tiempo.
Foto: Dave Allen CC BY
Y el consejo principal para desarrolladores y gerentes de producto, que se sugiere a partir de todos los anteriores: respetar el trabajo y el tiempo de otras personas, y ponerse lo más a menudo posible en el lugar de un probador. Después de todo, si no fuera por él, todo el mundo habría sabido de tus errores.