Antecedentes
Recientemente, uno de mis conocidos ingenieros de control de calidad, que trabajó durante mucho tiempo en un proyecto lento, donde sus responsabilidades estaban estrictamente descritas, cambió su trabajo y se metió en un proyecto recién lanzado. Después de pasar un par de días sin las tareas indicadas anteriormente, y francamente aburrida, fue a la gerencia con la pregunta "¿Qué debo hacer?" a lo que recibió una respuesta significativa "Organiza tu trabajo". Y luego cayó en un estupor "¿Y cómo es esto?" Y de verdad, ¿cómo?
Hace unos meses, cambié mi trabajo y me metí en un proyecto en inglés que nunca antes había tenido un control de calidad. El proyecto en sí ha existido durante mucho tiempo. Como suele suceder, una empresa en la que hay mucho dinero ha comprado una empresa en la que hay menos dinero, pero hay clientes. Como resultado, una gran empresa recibió nuevos clientes y menos un competidor en el mercado. Mi proyecto recibió un cambio de gestión y principios de gestión.
En los primeros días de conocer a un nuevo equipo, escuché una pregunta honesta y desconcertada de uno de los desarrolladores de la oficina de Londres: "¿Qué harás aquí?"
En verdad, después de haber venido a este proyecto y mirar alrededor durante varios días, yo, como mi colega, al principio caí en un estupor. No porque no supiera qué hacer. Más bien, no sabía cómo encajarme correctamente en los cimientos que se han desarrollado aquí. El equipo de desarrollo tuvo una existencia maravillosa sin probadores. Usaron kanban, los principios de entrega continua, desplegados sin miedo, con calma y confianza en la producción casi todos los días, incluso los viernes. Y todo porque tenían una excelente cobertura con autotest. Quizás el mejor que he conocido. Al revisar las solicitudes de cada uno, no dudaron en decirse qué otras pruebas automáticas agregar. El propio autor del cambio actual desplegó su trabajo en producción, lo que significa que era totalmente responsable de su trabajo. Y lo llevó, a pesar del hecho de que aparecí en el proyecto ... y antes del despliegue sería bueno escuchar mi opinión.
Pero, sin embargo, por supuesto, el proceso no fue perfecto: sucedió que los desarrolladores no entendieron los requisitos, perdieron errores y, con frecuencia, del lado de los clientes hubo algunos problemas que requirieron acción.
Ante la necesidad de determinar mi posición en el equipo, también fui al liderazgo. Solo nuestro diálogo fue construido de manera bastante diferente, no como el de mi amigo.
Organización del trabajo del ingeniero de control de calidad.
Haz las preguntas correctas.
Entonces Para un diálogo convoqué a los líderes y desarrolladores líderes del proyecto. Hay una maravillosa regla de gestión que, por supuesto, no podría olvidar: expresar el problema, expresar la opción de resolverlo, al menos una.
Sin embargo, tenía dos preguntas, cuyas respuestas no podía saber. La forma más fácil de comenzar con ellos.
Primera pregunta ¿Cuál es la estructura de la organización, es decir, quién está parado sobre quién y quién es responsable de qué?Idealmente, las compañías deberían tener un esquema presentado jerárquicamente que ilustre la estructura de la compañía. Pero no soy el ideal, por lo que fue importante averiguar a quién con qué preguntas y sugerencias puede dirigirse.
La segunda pregunta. La compañía introdujo al ingeniero de control de calidad en el proyecto, ¿cuáles son sus expectativas para mí, cuáles eran sus objetivos al abrir este puesto?Cuando la respuesta es muy específica, determina en gran medida el frente del trabajo. En mi caso, la respuesta contenía muchas frases borrosas generales, que percibí como "haz lo que quieras, pero para que todo esté bien para nosotros".
Sobre esto, la primera parte de la discusión terminó.
Discutimos el plan de acción.
La segunda parte de las discusiones, y quizás la más importante, fue la presentación de mi plan de trabajo y su justificación. Necesitaba recibir la bendición de mis superiores por la introducción sin trabas de mí y mis actividades en el proyecto.
Es gratamente obvio que los libros inteligentes y la teoría no existen desde cero, así que me armé con el conocimiento adquirido en preparación para la certificación ISTQB, una vez por curiosidad leí libros sobre teoría de pruebas y Scrum, dejé que todo esto pasara por un tamiz de diez años de experiencia y compilé un piloto proyecto para la estrategia de control de calidad.
Negociado con la gerencia y totalmente respaldado por él, más tarde adquirió el formato del documento oficial de la compañía. A continuación, quiero compartir ideas sobre cómo elaborar dicho documento. Formaron la quintaesencia de la experiencia previa y el camino recorrido en el proyecto actual.
Y, tal vez, en forma de citas, volveré a imprimir aquí algunos fragmentos en mi forma original: en inglés. Estoy seguro de que para cada ingeniero de control de calidad, la preparación de dicho plan será la respuesta clave a la pregunta "Cómo organizar su trabajo"
Formamos estrategia de control de calidad
1. Introducción al aseguramiento de la calidad.
Recordar / presentar el término Garantía de calidad por primera vez. Créame, su equipo está lleno de personas que imaginan muy vagamente de qué se trata. Se pueden tomar prestadas definiciones bastante generales
de Wikipedia . Indique tácticamente que la presencia del equipo de control de calidad en el proyecto no significa que toda la responsabilidad de la calidad del trabajo se transfiera ahora solo a ellos:
Las pruebas son parte del control de calidad. Nos permite determinar el nivel de calidad de las características que estamos evaluando.
No es responsabilidad exclusiva de los evaluadores llevar a cabo el control de calidad. Todo el equipo puede y debe contribuir para garantizar un alto nivel de calidad de los productos y servicios que se entregan.
2. Introducción a la estrategia de control de calidad
Prepárese para lo que leerán más personas.
La estrategia de prueba es un documento en evolución que detalla los procesos y la forma en que vamos a garantizar la calidad de nuestro producto en el futuro.
Sonar el contenido. Puede ser solo una tabla de contenido o más oraciones abstractas. Aquí, mencione la existencia de un Enfoque de prueba, Proceso de prueba, Estrategia de automatización de prueba y la necesidad de un Plan de prueba.
Es importante Indique el intervalo de tiempo para revisar este documento. Y el proyecto y los procesos en la empresa se están desarrollando, este documento no debe convertirse en un dinosaurio. Por lo tanto, planifique una fecha en la que se revisará y cambiará su estrategia. En mi opinión, seis meses son suficientes para volver con nuevos pensamientos.
3. Enfoque de prueba
¿Qué es un enfoque de prueba? Alejándome un poco de la voluminosa redacción oficial de esta definición, me permito simplificarla a la tesis de que estos son "pensamientos básicos con los que comenzamos a trabajar todos los días". Escriba aquí: ¿cuál es el motor de su progreso?
Los clásicos del género y los enfoques que funcionan bien son "proactivos" y "basados en el riesgo".
Adoptaremos un enfoque de prueba proactivo y basado en el riesgo.
Proactivo: esto significa que el proceso de diseño de prueba se inicia lo antes posible para encontrar y corregir los defectos antes de crear la compilación.
Basado en el riesgo: esto significa que organizaremos nuestros esfuerzos de prueba de una manera que reduzca el nivel de riesgo del producto cuando se envíe el sistema. Según el plan de estudios ISTQB “Las pruebas basadas en el riesgo son la idea de que podemos organizar nuestros esfuerzos de prueba de una manera que reduzca el nivel residual de riesgo del producto cuando se envía el sistema. Las pruebas basadas en el riesgo utilizan el riesgo para priorizar y enfatizar las pruebas apropiadas durante la ejecución de la prueba, pero se trata de algo más que eso. Las pruebas basadas en el riesgo comienzan temprano en el proyecto, identificando los riesgos para la calidad del sistema y utilizando ese conocimiento del riesgo para guiar la planificación, especificación, preparación y ejecución de las pruebas. Las pruebas basadas en el riesgo implican mitigaciones, pruebas para proporcionar oportunidades para reducir la probabilidad de defectos, especialmente defectos de alto impacto, y pruebas de contingencia para identificar soluciones alternativas para hacer que los defectos que nos superan sean menos dolorosos. Las pruebas basadas en el riesgo también implican medir qué tan bien lo estamos haciendo para encontrar y eliminar defectos en áreas críticas »
Cuando hablamos de ser proactivos, primero debemos hablar sobre la especificación de los requisitos de control de calidad. Los gerentes que compilan las especificaciones de los elementos del próximo ciclo de desarrollo, en su mayor parte, piensan como usuarios ordinarios del sistema, mientras que la lógica de los pensamientos de los desarrolladores existe en otra dimensión. En primer lugar, más de una vez vi que un desarrollador, al leer una especificación, no puede traducirla a un lenguaje de programación. Por ejemplo, no puede hacer coincidir el usuario mencionado en la especificación con los roles / derechos de acceso existentes en el sistema. Como resultado, puede elegir el rol más adecuado, en su opinión personal, que resultará incorrecto y tendrá que devolver la funcionalidad para trabajar más tarde y perder tiempo; o haga una pregunta al gerente, quien, tal vez, se fue de vacaciones y nuevamente perdió tiempo en anticipación. QA Engineer es esa maravillosa capa entre el administrador centrado en el usuario y el desarrollador con mentalidad técnica, especialmente si el QA Engineer no descuida las pruebas de caja blanca. Somos nosotros los que podemos entender a los gerentes y traducir sus pensamientos a los desarrolladores. A tiempo
Las pruebas basadas en el riesgo tienen métodos formales interesantes para evaluar los riesgos del proyecto y los riesgos del producto. Es genial poder ponerlos en práctica. Pero personalmente, nunca tengo tiempo suficiente para pintar las probabilidades de ocurrencia, la gravedad de sus consecuencias, etc. y calcule los riesgos de acuerdo con todas las reglas. Aquí confío más en mis instintos y sentido común. Cuando se realizan pruebas o se cubren autotests con una zona de riesgo (lo que debe recibir la primera y principal atención) en su mayor parte:
- funcionalidad diseñada directamente
- áreas adyacentes e interactuando
- funcionalidad comercialmente importante
- lo que se rompe con mayor frecuencia
- compatibilidad con versiones anteriores (si, por ejemplo, se cambia el formato de metadatos, la información existente funcionará correctamente)
4. Proceso de prueba
Díganos a qué secuencia metodológica de trabajo planea adherirse. No inventé nada complicado, pero tomé la
idea de ISTQB y la
usé .
Si sigues mi camino, familiarízate con la secuencia de trabajo recomendada por los autores de ISTQB, ten en cuenta qué pasos tomarás y cómo. Comenzamos con la planificación y el control. Estos dos viven juntos porque Sobre la base de monitorear sus propias actividades, los planes pueden ser rediseñados regularmente. Luego viene el trabajo con documentación y redacción de casos de prueba, poniéndolos en funcionamiento (utilizando los datos de prueba planificados y un entorno adecuado), completando las pruebas y la limpieza después de uno mismo (eliminar archivos temporales, etc.)
Utilizaremos el proceso de prueba que se describe en el programa de estudios ISTQB de la Fundación: Planificación y control de pruebas, Análisis y diseño de pruebas, Implementación y ejecución de pruebas, Evaluación de criterios e informes de salida y Actividades de cierre de pruebas.
5. Responsabilidades
Identifique sus responsabilidades y las de los demás en el campo de mejorar la calidad del producto. Reporte su misión.
Primero, enfatice nuevamente que
cada miembro del equipo es un probador por derecho propio , todos están probando con qué se relacionan. Código escrito: pruébelo.
En segundo lugar, aclarar y comprender la dirección de su desarrollo continuo.
QA Engineer es el experto principal en funcionalidad del producto : sabe cómo y qué funciona, puede explicar cómo y qué debe probarse. Es una persona que predice el comportamiento operativo del cliente, lo que significa que no permitirá que se desarrollen problemas graves.
Tercero, indique
cómo interactúa con los gerentes y desarrolladores . Por ejemplo, deténgase en el
enfoque ágil de Tres amigosColaboración entre negocios, desarrollo y control de calidad
a. Negocios - ¿Qué problema estamos tratando de resolver?
b. Desarrollo: ¿cómo podríamos construir una solución para resolver ese problema?
c. Pruebas: ¿qué pasa con esto? ¿Qué podría pasar?
6. Niveles de prueba y estrategia de automatización de control de calidad
Hoy, esta sección se ha convertido en un documento independiente autosuficiente para mí. Pero a nivel de la organización del incipiente proceso de control de calidad en el equipo, indique qué tipos de pruebas realizará quién. Qué se hará manualmente, qué se automatizará y con qué principio. Quién es responsable de qué pruebas automáticas.
Por ejemplo, en el proyecto actual, escribo solo pruebas de extremo a extremo, cuyo buen funcionamiento es estratégicamente importante desde el punto de vista comercial. Al mismo tiempo, miro la solicitud de extracción del desarrollador y, si es necesario, doy recomendaciones sobre la cobertura de la prueba. Todo lo demás (unidad, integración, carga, etc.) es obra de los desarrolladores. En el proyecto anterior, las pruebas de carga estaban sobre mí y escribí pruebas de integración junto con los desarrolladores.
7. Flujo de trabajo de funciones
Hoy, mi proyecto funciona en Scrum usando sprints de dos semanas. Por lo tanto, tengo un documento de ciclo de vida escrito paso a paso para cada historia.
Cualquiera sea la metodología a la que se adhiera el proyecto, describa cómo hacer el trabajo diario paso a paso. Si arriba hablamos más sobre tácticas de acción, entonces debería haber indicaciones claras de lo que viene primero, y luego qué.
Por ejemplo, mi versión es
El siguiente flujo de trabajo detalla el proceso que adoptaremos internamente.
1. Obtenga una historia antes de planificar la sesión
2. Cree una lista de verificación de acuerdo con los criterios de aceptación y la descripción
3. Tenga en cuenta detalles / preguntas poco claros
4. Aclarar preguntas sobre planificación
5. Actualice la lista de verificación
6. Resalta las dependencias y cómo las vas a superar.
7. Cuando la historia esté en revisión, verifique si los criterios de aceptación están cubiertos por las pruebas automáticas
8. Anime al desarrollador a cubrir todos los criterios de aceptación con autotest o hágalo usted mismo
9. Cuando la historia esté lista para la prueba, realice la prueba manual usando la lista de verificación
10. Crea errores para la historia si existen y devuelve el elemento al desarrollo
11. Cuando los errores se corrijan, realice nuevamente las pruebas manuales utilizando la lista
12. Compruebe si se pasan todas las pruebas automáticas
13. Cree una tarea para implementar pruebas automáticas de integración adicionales si es necesario
14. Mueve la historia en QA Estado aprobado
8. Plan de prueba
Elija el tipo de plan de prueba, la plataforma en la que lo almacenará y el propósito de su existencia. Proporcione una manera para que cualquiera pueda mirar allí.
En este proyecto, mi plan de prueba es un conjunto de listas de verificación para cada historia. Con el nivel actual de automatización, esto es suficiente por ahora.
En el proyecto anterior, el Plan de prueba se utilizó para pruebas manuales exhaustivas y como base ideológica para futuras pruebas automáticas.
Si tiene muchas pruebas manuales, escriba casos de prueba en detalle, para que cualquier nuevo ingeniero de control de calidad, que haya llegado al proyecto, pueda realizarlos de forma independiente.
Cómo trabajar con un documento
Escribir todo este plan y palabras efectivas es muy bueno. Las autoridades lo apreciarán, no tengo dudas. Pero hay un punto importante en la existencia de este documento. Estas son respuestas honestas a las preguntas para quién y por qué se escribe todo esto.
Al escribir cada oración, sería bueno pensar en las preguntas:
"¿Realmente quiero trabajar así?" ,
"¿Realmente voy a darle vida a esto en el proyecto?"Si ambas respuestas son positivas, imprima con confianza.
Si una de las respuestas es "No", en mi opinión, esta es una señal segura de no colgar tareas innecesarias.
Si una de las respuestas es de la serie "Todavía no lo sé", deje que siga en sus páginas.
Tengo esos momentos en la lista de lo que se revisará primero en unos meses.
En primer lugar, escribí mi documento por mí mismo. Tengo momentos en los que retrocedo de los procesos descritos e incluso voy un poco en contra de ellos. Adaptarse a la situación para utilizar los recursos de manera eficiente aquí y ahora es normal. Pero la gran mayoría, con el trabajo habitual de rutina, mi documento es mi guía. Más de una vez estaba convencido de que el plan / estrategia existente en cualquier campo siempre se acerca más a los resultados deseados más rápido y con menos dolor que su falta total. ¡Deseo que construyas tu trabajo de manera fácil y eficiente!
Antes de la publicación en sí, el artículo se redujo considerablemente, me pareció dolorosamente grande para Sandbox. Estaré encantado de continuar este tema más adelante. Sin embargo, siempre estoy feliz de desarrollar, si hay algo que olvidé por completo, escríbeme un comentario.
Gracias