Este artículo será de interés para quienes, como nosotros, se enfrentan al problema de seleccionar un especialista adecuado en el campo de las pruebas.
Curiosamente, con el aumento del número de empresas de TI en nuestra república, solo aumenta el número de programadores dignos, pero no de probadores. Mucha gente está ansiosa por dedicarse a esta profesión, pero no muchos entienden su significado.
No puedo hablar por todas las empresas de TI, pero hemos asignado la función de control de calidad a nuestros especialistas en calidad. Forman parte del equipo de desarrollo y participan en todas las etapas del desarrollo, desde la investigación hasta el lanzamiento de una nueva versión.
Un evaluador en un equipo, incluso en la etapa de planificación, debe pensar en todos los requisitos funcionales y no funcionales para aceptar una historia de usuario. Debe comprender las características operativas del producto y de los programadores, y mejor aún, ayudar al equipo a no tomar decisiones equivocadas incluso en la etapa de planificación. El evaluador debe tener una comprensión clara de cómo funcionará la funcionalidad implementada y qué dificultades pueden surgir. Nuestros probadores crean ellos mismos planes de prueba y casos de prueba, además de preparar todos los bancos de pruebas necesarios. Probar de acuerdo con una especificación ya preparada como un clicker de mono no es nuestra opción. Trabajando dentro del equipo, debe ayudar a lanzar un producto digno y hacer sonar la alarma a tiempo si algo sale mal.
Lo que encontramos al buscar probadores
En la etapa de estudio de muchos currículums, parecía que había especialistas con la experiencia adecuada para nosotros y no habría problemas a la hora de elegir un tester para nuestro equipo. Pero, durante las reuniones personales, nos encontramos cada vez más con candidatos que en realidad estaban bastante alejados del mundo de la tecnología de la información (por ejemplo, no sabían los principios de interacción entre un navegador y un servidor web, los conceptos básicos de seguridad, relacional y no- bases de datos relacionales, no tenían idea sobre virtualización y contenerización), pero al mismo tiempo se evaluaron a sí mismos en el nivel Senior QA. Después de decenas de entrevistas llegamos a la conclusión de que el número de especialistas adecuados para nosotros en la región es insignificante.
A continuación les contaré qué pasos dimos y qué errores pisamos para encontrar esos ansiados luchadores por la calidad.
Cómo intentamos arreglar la situación
Habiéndose agotado de buscar especialistas ya preparados, comenzamos a apuntar a áreas cercanas:
- Intentamos aplicar prácticas de evaluación para identificar, entre las muchas personas que “lo dejan”, aquellas a partir de las cuales podemos desarrollar fuertes especialistas.
Le pedimos a un grupo de candidatos potenciales con aproximadamente el mismo nivel de conocimiento que completaran tareas. Observando su proceso de pensamiento, intentamos identificar al candidato más prometedor.
En particular, se nos ocurrieron tareas para evaluar la atención, la comprensión de las capacidades de la tecnología y las características del multiculturalismo:
- Realizamos reuniones de testers para ampliar los límites de la comprensión de la profesión entre el contingente existente.
Te contaré un poco sobre cada uno de ellos.
Ufa Software QA and Testing Meetup #1 es nuestro primer intento de reunir a aquellos que se preocupan por la profesión y al mismo tiempo comprender si el público estará interesado en lo que queremos transmitirles. Básicamente, nuestros informes trataban sobre dónde es mejor empezar si ha decidido convertirse en tester. Ayude a los principiantes a abrir los ojos y mirar las pruebas como un adulto. Hablamos sobre los pasos que los evaluadores novatos deben seguir para unirse a la profesión. Sobre qué es la calidad y cómo conseguirla en condiciones reales. Y también qué son las pruebas automáticas y dónde es más apropiado utilizarlas.
Luego, con un intervalo de 1 a 2 meses, realizamos dos reuniones más. Ya había el doble de participantes. En el “Encuentro n.° 2 de pruebas y control de calidad de software de Ufa” nos sumergimos más profundamente en el área temática. Hablaron sobre sistemas de seguimiento de errores, pruebas de UI/UX, tocaron Docker, Ansible y también hablaron sobre posibles conflictos entre un desarrollador y un evaluador y las formas de resolverlos.Nuestra tercera reunión, “Ufa Software QA and Testing Meetup #3”, se relacionó indirectamente con el trabajo de los evaluadores, pero fue útil para recordar oportunamente a los programadores sus deberes técnicos y organizativos: pruebas de carga, pruebas e2e, Selenium en pruebas automáticas, vulnerabilidades de aplicaciones web. .
Todo este tiempo hemos ido aprendiendo a crear luz y sonido normal en las retransmisiones de nuestros eventos:
→
→
→ - Y al final decidimos intentar realizar un hackathon para probadores.
Cómo preparamos y llevamos a cabo un hackathon para evaluadores
Para empezar, intentamos entender qué tipo de "bestia" es y cómo se suele llevar a cabo. Al final resultó que, eventos de este tipo no se han celebrado muchas veces en la Federación de Rusia y no hay ningún lugar para tomar prestadas ideas. En segundo lugar, no quería invertir inmediatamente muchos recursos en un evento que a primera vista parecía dudoso. Por lo tanto, decidimos que realizaríamos mini-hackatones cortos, no para todo el ciclo de trabajo de control de calidad, sino para etapas individuales.
Nuestro principal dolor de cabeza es la falta de práctica entre los evaluadores locales a la hora de crear mapas de prueba claros. No dedican tiempo a investigar historias de usuarios previas a la implementación ni a crear criterios de aceptación que sean claros para los desarrolladores en cuanto a requisitos funcionales y no funcionales, UI/UX, seguridad, cargas de trabajo y cargas máximas. Por lo tanto, decidimos, por primera vez, abordar la parte más interesante y creativa de su trabajo: el análisis y la formación de requisitos durante la investigación previa al proyecto.
Estimamos el número potencial de participantes y decidimos que necesitábamos al menos 5 trabajos pendientes para los lanzamientos de MVP, 5 productos y 5 personas que actuarían como propietarios de productos, descifrarían las necesidades comerciales y tomarían decisiones sobre restricciones.
Esto es lo que tenemos: .
La idea principal era proponer temas lo más alejados posible del trabajo diario de todos los participantes y darles margen para un vuelo creativo de la imaginación.
¿Qué errores cometimos y qué podríamos hacer mejor?
El uso de prácticas de evaluación, tan populares en el campo de la contratación de vendedores y gerentes de nivel inferior, requirió un gran esfuerzo, pero no nos permitió prestar suficiente atención a cada participante y evaluar sus habilidades. En general, esta opción de elección crea una imagen negativa de la empresa, ya que muchas personas reciben una retroalimentación insuficiente y posteriormente crean en sí mismos y en los demás el efecto de la tiranía del empleador (las comunicaciones en las comunidades de TI están muy desarrolladas). Como resultado, nos quedamos literalmente con dos candidatos potenciales con un futuro muy lejano.
Las reuniones son algo bueno. Se crea una base extensa para la elaboración y aumenta el nivel general de los participantes. La empresa es cada vez más reconocible en el mercado. Pero la intensidad laboral de tales empresas no es pequeña. Debe comprender claramente que la celebración de reuniones requerirá aproximadamente entre 700 y 800 horas-hombre por año.
En cuanto al hackathon de pruebas. Este tipo de eventos aún no se han vuelto aburridos porque, a diferencia de los hackathons para desarrolladores, se llevan a cabo con mucha menos frecuencia. La ventaja de esta idea es que de forma relajada se puede intercambiar una gran cantidad de conocimientos prácticos y determinar con bastante precisión el nivel de cada participante.
Después de analizar los resultados del evento, nos dimos cuenta de que cometimos muchos errores:
- El error más imperdonable fue creer que 4-5 horas nos bastarían. Como resultado, sólo la introducción y familiarización con los trabajos pendientes llevó casi 2 horas.
Trabajar con los propietarios de productos en la etapa inicial y sumergirse en el área temática tomó la misma cantidad de tiempo. Por lo tanto, el tiempo restante claramente no fue suficiente para desarrollar exhaustivamente los mapas de prueba. - No hubo suficiente tiempo y energía para comentarios detallados sobre cada mapa, ya que ya era de noche. Por lo tanto, claramente fallamos en esta parte, pero inicialmente pretendíamos que fuera la más valiosa del hackathon.
- Decidimos evaluar la calidad del desarrollo mediante una simple votación de todos los participantes, asignando 3 votos para cada equipo, que podrían otorgar por el trabajo de mayor calidad. Quizás sería mejor organizar un jurado.
¿Qué has logrado?
Hemos resuelto parcialmente nuestro problema y ahora tenemos 4 hombres guapos y valientes trabajando para nosotros, cubriendo la retaguardia de 4 equipos de desarrollo. Aún no se ha notado un grupo significativo de potenciales candidatos fuertes y cambios tangibles en el nivel de la comunidad de control de calidad de la ciudad. Pero hay algunos avances y esto no puede dejar de alegrarnos.
Fuente: habr.com