Uno , complementado por
otro , mis artículos resultaron ser una posible guía de acción para aquellos que aún no han encontrado "su propio estilo" y no están seguros de por dónde empezar.
Algunos respondieron que estaba escribiendo sobre "verdades comunes", pero recibí una buena respuesta en los comentarios y mensajes personales de la categoría "fue útil", "lo que necesito ahora", etc. Pero hubo preguntas. Las preguntas, en su mayor parte, se redujeron al "dolor" que no ha pasado un solo control de calidad en su carrera:
- ¿Cómo interactuar efectivamente con los desarrolladores?
- cómo organizar el trabajo con ellos para que acepten: ¿hay otra opinión sobre el proyecto, la opinión de QA, y también es importante?
- ¿Cómo animarlos a interactuar, por ejemplo, al construir una automatización de prueba conjunta cuando no están configurados para trabajar juntos?
- ¿Cómo actuar en el caso cuando sus habilidades técnicas en la pila de tecnologías utilizadas simplemente no son suficientes?
Inmediatamente haga una reserva de que el tema es muy delicado, al hablar de eso siempre tiene que equilibrarse a punto de no dañar el orgullo de los desarrolladores y el control de calidad. Por lo tanto, le ruego que lea con un corazón frío y solo trate de resaltar algunos puntos útiles y probarlos en la práctica.
Introduccion
En primer lugar, como lo demuestra la práctica, a menudo aquellos QA que no logran entrar en el desarrollo como lo requiere la profesión
- simplemente no seguro de sí mismo. No pueden lograr que se les escuche, porque hablan de manera inaudible, no razonable, expresando dudas constantes;
- tienen miedo de cometer errores e incurrir en una responsabilidad adicional;
- complejo debido al imperfecto conocimiento técnico.
En segundo lugar, los desarrolladores del equipo perciben el control de calidad como un apéndice que simplemente presiona los botones antes de entregar el producto al cliente, o simplemente no imagina cómo interactuar con ellos. Esto puede deberse al hecho de que
- Todavía piensan en QA como probadores hace 10-20 años, cuando realmente lo eran;
- todos los controles de calidad anteriores con los que trabajaron exactamente de la misma manera y se comportaron, y simplemente no saben qué sucede de otra manera;
- en principio, no saben cuál es la esencia del trabajo del ingeniero de control de calidad en esencia, porque simplemente no lo necesitan: desarrollan sus habilidades;
- el desarrollo del código ya está bien establecido y cambiar algo en él es solo pereza.
Comencemos con el primer problema.
Ingeniero de Control de Calidad! Haz una limpieza de primavera en tu cabeza
Trabaja para entender tu profesión
Si quieres cambiar el mundo, comienza contigo mismo. La verdad bien conocida y muy relevante en nuestro tema.
Como ingeniero de control de calidad, realmente no te hace daño saber para qué puesto trabajas. Si su proyecto aún se rige por los principios de la arquitectura en cascada, y usted fue contratado simplemente por un probador manual, que, como OTK en las empresas, verifica la disponibilidad del producto final, entonces esto es una cosa, y aquí todo es bastante transparente.
Y si está en la posición de un ingeniero de control de calidad completo, que ahora es casi universal, significa que su responsabilidad, establecida por los cánones de esta profesión en [1], no solo es probar el producto terminado, sino también participar directamente en la organización de los procesos de su creación y la interacción de los participantes todo el proyecto Recuerde que sin procesos claros y la organización del equipo es casi imposible obtener un producto de calidad, por lo tanto, en este campo, la voz de QA debe sonar segura y clara. Para evitar la aparición de errores y no reparar después del hecho, esta es la gran cantidad de equipos bien organizados. Y hacer esfuerzos para minimizar la cantidad de errores es tarea del equipo de control de calidad. (El círculo se cierra)
Por lo tanto, lo primero es recordar todas las cosas fundamentales sobre los principios, tipos, niveles de prueba y la redacción de la definición de la profesión de ingeniero de control de calidad. Comprender el notorio "¿Quién soy yo?" y "¿Por qué estoy aquí?"
Encuentra respuestas a preguntas
Cuando termine la excavación profesional, esboce un plan para usted, lo que hará, puede tomar ideas de mis artículos o elaborar su propio plan que se adapte a sus circunstancias. Cada punto de su actividad debe ser claro para usted: por qué, cómo implementarlo, cuál es el beneficio.
Solo en este caso podrá hablar con confianza sobre el proyecto. Incluso si hasta ahora solo conoce las respuestas a las preguntas "por qué" y "cuál es el beneficio", pero no sabe "cómo". Siéntase seguro por el hecho de que ve el frente del trabajo, la formulación correcta de la tarea es un 80% de éxito.
El siguiente paso es escribir las preguntas que necesita resolver para responder la pregunta "cómo". Y diríjase a las personas con esto, es decir, discuta con el equipo: en una reunión especialmente organizada, charlando entre negocios o informalmente en la cocina con una taza de café, no importa. Es importante que su proyecto esté lleno de personas que tengan diferentes experiencias, otros conocimientos, utilicen este almacén de información útil, se comuniquen, pregunten y todo se aclarará.
Deja la experiencia de que no eres perfecto
Si eres muy tímido o en la vida un maximalista que siempre se esfuerza por ser un líder, entonces será difícil desempeñar el papel de QA. Debido a que QA Engineer es ingeniero, es una persona involucrada en el desarrollo, pero al mismo tiempo nos encontramos en proyectos con una pila diferente de tecnologías y arquitectura, mientras que los desarrolladores tienen su propia especialización. Reconocer que estás "fuera de tema" para algunas personas significa escribirte en un "eslabón débil". Y este fue mi problema, que luché durante mucho, mucho tiempo. "¿Es eso lo que necesito decir que no sé, que no sé qué, no lo entiendo?" - Más de una vez caí en un estupor al discutir los aspectos técnicos completos.
Pero solo en algún momento finalmente me di cuenta de que no saber no es una pena. Me da vergüenza continuar "escondiéndome en el caparazón" y no tratar de averiguarlo. Y permanecer en silencio, parecer comprensivo, es más querido para uno mismo.
Fuiste contratado, leyeron tu currículum (estarás seguro de tus habilidades;)), hablaste contigo en la entrevista y fuiste contratado. Por lo tanto, su conjunto de habilidades técnicas está bien con todos y aquellos que lo contrataron han adivinado qué esperar. Por lo tanto, saltar por encima de tu cabeza ahora no tiene sentido. Y cuando dices "Nunca he trabajado con esto, pero quiero resolverlo, ayúdame a entender esto y esto": esta es una situación absolutamente normal, saludable y correcta (no traigas lo más primario al punto del absurdo conocimiento - definiciones y formulaciones - aprenda de Internet). Y cuando le indicas a otros que no entiendes estos antecedentes técnicos, en primer lugar, ellos ya sienten que es necesario comunicarse de manera más simple y, en segundo lugar, puedes hacer preguntas aclaratorias con la conciencia tranquila. Si escribiste el código una o dos veces y entendiste completamente la arquitectura interna del proyecto, entonces probablemente estarías directamente involucrado en el desarrollo, ¿verdad?
Y mi pequeño truco favorito es ayudar siempre a los demás, cuando puedo; de hecho, consejos, palabras amables, esto vuelve con el deseo mutuo de otros de ayudarme.
No tengas miedo de cometer errores.
Dé por sentado que los flujos de trabajo implican una discusión de todas las opciones posibles. La verdad nace en una disputa. Su tarea no es estar en lo correcto, sino encontrar las mejores soluciones. Y si quieres ofrecer algo, pero tienes miedo de que suene tonto, entonces créeme cuántos equipos vi, los colegas silenciosos más indiferentes parecen perdedores. Reconocer algunos de nuestros errores, respaldar las mejores ideas y contribuir con entusiasmo a su implementación es un flujo de trabajo saludable.
Recuerde, la heroína de Muravyeva en la película "Moscú no cree en las lágrimas" se instaló antes de ir a la biblioteca: "si se escabulle, se escabulle con confianza, entonces esto se llama un punto de vista". Realmente funciona
No tenga miedo de recurrir a tareas que no puede manejar. Recuerde, usted está trabajando en un equipo y dice que algo no está funcionando y pedir ayuda al equipo es normal.
E incluso si en el curso de su trabajo llega a la conclusión de que "no tiene que hacer esto", será un progreso, porque el siguiente paso es encontrar la mejor solución.
Libere estándares obsoletos, mire hacia el futuro
Estos fundamentos de que el control de calidad es una posición baja, no es tan importante ni tan significativo de una forma u otra que se encuentra en los equipos. Y aunque usted mismo lo cree, está subestimando esta tendencia, por desgracia, la alimentación.
Trabaja todos los días, hace esfuerzos todos los días, mejora el producto y el equipo, gasta tiempo y energía, su posición se establece en el marco de los proyectos, esto significa que es importante y necesario. Eso es todo. No deje espacio para la automutilación, y no deje espacio en su cabeza para las "burlas" de aquellos que consideran que tiene un estado inferior al suyo. En estos tiempos, cuando había simples probadores manuales de probadores de monos, se han hundido en el olvido, en el futuro, los ingenieros de control de calidad son "un destacamento de fuerzas especiales de élite cuyo éxito depende de tácticas excelentes y armas modernas" [2].
Recuerde que hoy en empresas líderes como, por ejemplo, Microsoft y Google, “los desarrolladores son responsables de la calidad. Si el producto se rompe después del lanzamiento, los conos volarán al desarrollador que creó el problema y no al probador que no lo encontró ”[2]. Por lo tanto, en tales empresas, contar con un equipo de control de calidad que ayudará a crear un producto de calidad es un privilegio para los desarrolladores.
Y está en sus manos introducir principios avanzados en sus empresas, en lugar de mirar hacia atrás a los estereotipos pasados.
Pero nuevamente, vuelvo al hecho de que necesita crecer constantemente en su proyecto. Si llegaste al proyecto, pasaron seis meses y aún no has logrado una automatización de prueba efectiva, no trates de descubrir qué está haciendo el equipo, no analices las pruebas automáticas existentes, entonces no eres la élite sobre la que escriben los libros.
Hay equipos que viven sin un puesto de ingeniero de control de calidad, los conozco. Y si hoy se esfuerza por sumergirse en el proyecto y aprender a escribir autotests con desarrolladores, un día puede vender sus competencias incluso allí y convertirse en un ingeniero de software en pruebas allí.
Ingeniero de Control de Calidad! Afina el trabajo en equipo
Cuando termine el trabajo sobre usted mismo, es hora de trabajar para establecer una colaboración con los desarrolladores.
Lo mas importante
- Sus acciones deben ser claras y transparentes para el equipo. Lo más simple y efectivo es transmitirles su misión. Si, sin ninguna razón, comienza a subir a su grupo con solicitudes que preguntan "¿qué tipo de pruebas tiene aquí?", "Pero debe escribir una prueba de este tipo", la primera reacción (protectora) será " ¿a dónde vas? ”,“ ¿quién eres / tal para criticar mi trabajo? ”. Él pudo haber cocinado este brunch durante una semana, finalmente exhalado, y luego QA lo consiguió. Por lo tanto, dígales de antemano qué va a hacer, por qué y cuáles son los beneficios de esto para el proyecto y el equipo. Prepara el suelo.
- Su participación en el desarrollo a priori debe ser percibida como una bendición, como algo que mejora cualitativamente el trabajo del desarrollador. Conviértete en su compañero. Por ejemplo, eduque: diga cómo es probable que los clientes usen la funcionalidad, qué errores ya han sucedido y cuáles deberían evitarse, lo que significa pensar juntos qué pruebas y por qué son importantes. No se comunique en un estado de ánimo imperativo. Incluso puede recurrir a trucos psicológicos: observar a aquellos que aumentaron la cobertura de las autoevaluaciones en algunos informes finales en el formato "¡estamos todos bien!". Siempre es agradable cuando tu trabajo es apreciado. Y las revisiones tradicionales de control de calidad con cobertura de prueba automática también son una motivación para trabajar juntos.
Deje que los cambios en el proyecto sean suaves. Si vienes a trabajar una mañana y dices: "He leído un artículo sobre Habré, y comenzarás a azotar un zapato en una plataforma condicional, sacudiendo el aire, dicen, ¡ahora te mostraré a la madre de Kuzkin!", Te mirarán como extraño, esto es un hecho. Sí, y será difícil para usted, frente a problemas en todos los frentes, habrá un deseo irresistible de abandonar toda la idea de mejorar el trabajo de QA.
Es mejor establecer pequeñas tareas comprensibles para todos, lograrlas y asumir lo siguiente. Avanza con cuidado, el tiempo vuela rápidamente, algún día será bueno regresar.
Respuestas a preguntas específicas.
Después de
mi segundo artículo , que ofreció un trabajo minucioso de control de calidad y desarrollo, la audiencia expiró de la categoría "lo intentamos, pero el líder del equipo de desarrolladores realmente no quería reunirse". Desde mi nivel actual de desarrollo profesional, solo puedo aconsejar lo siguiente.
Sea amigable y trate con sabiduría calme a quienes no aceptan su trabajo como espera. En mi práctica, conocí a muchos desarrolladores diferentes y todos aquellos que eran verdaderamente maduros profesionalmente siempre vinieron a conocerme, siempre me ayudaron, y logramos excelentes resultados conjuntos, todos estaban satisfechos. Quienes "resoplan" y "se alejan de ti", por desgracia, pertenecen a la categoría de "adolescentes profesionales". Todavía no han aprendido a lidiar con sus sentimientos, considerándose los más derechistas (y la edad física no juega un papel aquí). Simplemente no saben cómo trabajar en equipo, y tú eres su parte integral. Puedes ayudarlos a crecer, pero, desafortunadamente, algunos nunca crecen. Y aquí solo puede influir en ellos a través del apoyo del liderazgo y la autoridad colectiva del resto del equipo que lo apoyará. Si conoce las mejores formas, ¡comparta!
También hubo una pregunta interesante acerca de cómo ser si aún no sabes cómo leer el código del desarrollador, no puedes entender sus autotests.
Dejaré mi respuesta aquí, para que no se pierda, tal vez alguien sea útil. Si no puede leerlo, insistiría en incluir una lista de pruebas automáticas desarrolladas en la descripción del RP y centrarme en ello. Creo que este es el derecho completo y el deber del equipo de control de calidad de estar lo más informado posible sobre la cobertura del producto con las pruebas automáticas, de lo contrario se pierde toda la idea del control de calidad ... Si consideramos la situación de limitaciones de tiempo severas de todo el equipo, incluido el desarrollador, entonces insistiría en la revisión Cobertura de escenarios críticos / estratégicos mediante autotests de integración. Y para todos los demás escenarios, documenté tareas separadas para hacerlas más tarde. En cualquier proyecto, hay períodos tranquilos en los que no hay plazos, entonces vale la pena enfocar al Gerente de Producto / Líder de Equipo / Maestros Scrum en cómo incluir estas tareas: es más complicado: deje que los desarrolladores lo hagan, aprenda las más simples usted mismo.
Conclusión
No puedo decir que todo lo que está escrito arriba ciertamente te ayudará, después de todo, tengo la sensación de que mi propia voz y estilo profesional vienen con experiencia y a través de golpes de relleno. Es imposible tomar y cómo aplicar el guión de trabajo de otra persona a su proyecto a través de una plantilla. Pero si mi garabato te incitaba a no soportar los momentos que no te gustan, y tenías ideas en tu cabeza de que puedes hacer el bien por ti mismo, por el equipo, por el producto, entonces pasé el tiempo no en vano. Y sí, no pienses que retrato a QA Shark, que lo sabe todo, lo sabe todo. Estudio y cambio constantemente. Soy consciente de que en un año mis principios de trabajo pueden cambiar. Siempre muy contento con los comentarios y con mucho gusto aprenderé de su experiencia, escriba;)
Y si desea leer algo para fortalecer su propia motivación, comience con dos libros maravillosos, una referencia a la que le di en el texto:
1. Fundamentos de las pruebas de software: certificación ISTQB
por Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Cómo probar en Google
James Whittaker, Jason Arbon, Jeff Carollo
¡Gracias a todos por su atención!