Cómo organizar el trabajo de QA. Una forma práctica

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 amigos
Colaboració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

Source: https://habr.com/ru/post/439128/


All Articles