Este artículo será de interés para aquellos que, al igual que nos enfrentamos con el problema de seleccionar un especialista adecuado en el campo de las pruebas.
Por extraño que parezca, pero con el aumento en el número de empresas de TI en nuestra república, solo está aumentando el número de programadores dignos, pero no los probadores. Muchos están ansiosos por esta profesión, pero no muchos entienden su significado.
No puedo decirlo para todas las empresas de TI, pero hemos asignado el papel de QA / QC a nuestros especialistas de 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.
El probador en el equipo, incluso en la etapa de planificación, debe considerar todos los requisitos funcionales y no funcionales para aceptar la historia del usuario. No debería ser peor que los programadores, o incluso mejor, para comprender las características operativas del producto y ayudar al equipo a no tomar decisiones equivocadas en la etapa de planificación. El probador debe tener una idea clara de cómo funcionará la funcionalidad implementada y cuáles pueden ser los escollos. Nuestros probadores elaboran planes de prueba y casos de prueba ellos mismos, y preparan todos los soportes necesarios para la prueba. La prueba de acuerdo con la especificación terminada como un mono clicker no es nuestra opción. Trabajando dentro del equipo, debe ayudar a lanzar un producto decente y hacer sonar la alarma a tiempo si algo sale mal.
Lo que encontramos al buscar probadores
En la etapa de estudiar muchos currículums, parecía que había especialistas con la experiencia adecuada para nosotros y que no habría problemas para elegir un probador en nuestro equipo. Pero, en las reuniones cara a cara, nos enfrentamos cada vez más con candidatos que en realidad estaban muy lejos del mundo de la tecnología de la información (por ejemplo, no podían distinguir los principios de la interacción del navegador y el servidor web, los principios básicos de seguridad, las bases de datos relacionales y no relacionales, no tenían idea de la virtualización y contenedorización), pero al mismo tiempo se evaluaron a nivel de QA Senior. Después de más de una docena 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, te diré qué pasos tomamos y qué rastrillo pisamos para encontrar a los luchadores tan esperados por su calidad.
Cómo tratamos de arreglar la situación
Habiendo sufrido con el abastecimiento de especialistas ya preparados, comenzamos a disparar a las áreas cercanas:
- Intentamos aplicar la práctica de evaluación para identificar entre la gran cantidad de "personas que escapan", de quienes podemos hacer crecer especialistas fuertes.
Un grupo de candidatos potenciales, con aproximadamente el mismo nivel de conocimiento, nos ofrecieron completar tareas. Observando su proceso de pensamiento, trataron de seleccionar al candidato más prometedor.
En particular, se nos ocurrieron tareas para verificar la atención, comprender las capacidades de las tecnologías y las características del multiculturalismo:
- Se realizaron reuniones para evaluadores para ampliar los límites de la comprensión de la profesión para el contingente existente.
Te contaré un poco sobre cada uno de ellos.
Ufa Software QA y Testing Meetup # 1 es nuestro primer intento de reunir a aquellos que no son indiferentes a la profesión y al mismo tiempo entender si el público estará interesado en lo que queremos transmitirles. Básicamente, nuestros informes fueron sobre dónde comenzar, si decidió convertirse en un probador. Ayuda a los principiantes a abrir los ojos y mirar las pruebas para adultos. Hablamos sobre los pasos que los probadores principiantes deben seguir para unirse a la profesión. Sobre qué es la calidad y cómo lograrla en condiciones reales. Y también qué es la prueba automática y dónde es más apropiado aplicarla.
Además, con un intervalo de 1-2 meses, realizamos dos mitaps más. Ya había dos veces más participantes. En Ufa Software QA y Testing Meetup # 2, nos sumergimos más en el área temática. Hablamos sobre sistemas de seguimiento de errores, pruebas de UI / UX, hablamos de Docker, Ansible, y también hablamos sobre posibles conflictos entre el desarrollador y el probador y cómo resolverlos.
Nuestro tercer metap "Ufa Software QA and Testing Meetup # 3" se refería indirectamente al trabajo de los probadores, pero fue útil para recordar a los programadores a tiempo su deber técnico y organizativo: pruebas de carga, pruebas e2e, Selenium en autocomprobación y vulnerabilidades de aplicaciones web.
Todo este tiempo aprendimos a hacer luz y sonido normales en las transmisiones de nuestros eventos:
→ Primeros pasos en las pruebas: Ufa Software QA y Testing Meetup # 1
→ Pruebas UI / UX - Ufa Software QA y Testing Meetup # 2
→ Pruebas de seguridad, pruebas de carga y pruebas automáticas: Ufa QA y Testing Meetup # 3 - Y al final decidimos probar un hackathon para probadores
Cómo se preparó y realizó el hackathon para los probadores
Para empezar, trataron de entender qué tipo de "bestia" es y cómo se lleva a cabo generalmente. Al final resultó que, eventos de este tipo en la Federación de Rusia se han celebrado no tantas veces, y no hay lugar para pedir ideas prestadas. En segundo lugar, no quería inmediatamente, en un evento dudoso a primera vista, invertir muchos recursos. Por lo tanto, decidimos que haríamos mini hackatones cortos, no para todo el ciclo de trabajo de control de calidad, sino para etapas separadas.
Nuestro principal dolor de cabeza es la falta de práctica de probadores locales en la formación de mapas de pruebas inteligibles. No dedican tiempo a la investigación en la etapa previa a la implementación de historias de usuarios y la creación de criterios de aceptación comprensibles para los desarrolladores sobre requisitos funcionales y no funcionales, UI / UX, seguridad, trabajo y cargas máximas. Por lo tanto, decidimos, por primera vez, pasar por la parte más interesante y creativa de su trabajo: el análisis y la formación de requisitos para la investigación previa al proyecto.
Estimaron el número potencial de participantes y decidieron que necesitamos al menos 5 pedidos pendientes para lanzamientos de MVP, 5 productos y 5 personas que actuarán como propietarios de productos, descifrarán las necesidades comerciales y tomarán decisiones sobre las restricciones.
Esto es lo que tenemos:
atrasos para el hackathon .
La idea principal era crear temas que estuvieran tan lejos del trabajo diario de todos los participantes y darles espacio para la imaginación creativa.
¿Qué errores hemos cometido y qué se puede hacer mejor?
La aplicación de prácticas de evaluación, que son tan populares en el campo de recibir vendedores y gerentes de nivel inferior, requirió una gran cantidad de energía, pero no nos permitió prestar suficiente atención a cada participante y evaluar sus habilidades. En general, esta opción de selección crea una imagen negativa de la empresa, ya que muchas personas reciben comentarios insuficientes y, en el futuro, forman el efecto de la tiranía del empleador (la comunicación en las comunidades de TI está muy desarrollada). Como resultado, tenemos literalmente dos candidatos potenciales con una perspectiva muy lejana.
Aquí las mitapas son algo bueno. Se está creando una amplia base para el estudio, se está elevando el nivel general de participantes. La empresa es cada vez más reconocible en el mercado. Pero, la complejidad de tales empresas no es pequeña. Debe entenderse claramente que se necesitarán aproximadamente 700-800 horas hombre para celebrar reuniones en un año.
En cuanto a los probadores de hackathon. Tales eventos aún no han tenido tiempo de aburrirse, porque, a diferencia de los hackatones para desarrolladores, se llevan a cabo con mucha menos frecuencia. La ventaja de esta empresa es que de manera inequívoca puede intercambiar una gran cantidad de conocimiento práctico y determinar con bastante precisión el nivel de cada participante.
Después de analizar los resultados del evento, nos dimos cuenta de que los montones cometieron errores:
- El error más imperdonable fue creer que 4-5 horas serían suficientes para nosotros. Como resultado, solo la introducción y el conocimiento de los retrasos demoraron casi 2 horas.
Trabajar con los propietarios de los productos en la etapa inicial y el tiempo para sumergirse en el área temática tomó tanto tiempo. Entonces, el tiempo restante claramente no fue suficiente para un estudio exhaustivo de las tarjetas de prueba. - No hubo suficiente tiempo y energía para una retroalimentación detallada de cada tarjeta, ya que ya era de noche. Por lo tanto, esta parte fue claramente fallada por nosotros, y originalmente se suponía que era la más valiosa en el hackathon.
- Decidimos evaluar la calidad del estudio mediante un simple voto de todos los participantes, asignando 3 votos para cada equipo que pudieran dar para el trabajo de más alta calidad. Quizás sería mejor organizar un jurado.
Que has logrado
Resolvimos parcialmente nuestra tarea y ahora tenemos 4 hombres valientes y guapos que cubren la parte trasera de 4 equipos de desarrollo. Todavía no se ha notado un grupo significativo de posibles candidatos fuertes y cambios tangibles en el nivel de comunidad de control de calidad de la ciudad. Pero, hay algunos progresos y esto no puede sino alegrarse.