Hace algún tiempo, escribí
un artículo sobre mi experiencia en la organización del trabajo de QA Engineer en un proyecto. Ahora quiero continuar con este tema, pero en una dirección más estrecha: prueba de automatización. Será
sobre el mismo proyecto , es pequeño, pero se desarrolla de acuerdo con las solicitudes de los clientes habituales. Quizás mi enfoque no es muy adecuado para equipos con docenas de empleados y cada uno es responsable de su parte (en mi opinión, cada proyecto debe estar estrictamente regulado, de lo contrario, es simplemente imposible manejar un coloso de este tipo, aunque encontrarán un grano saludable), pero ciertamente será interesante para aquellos que, como yo, una vez vinieron a un nuevo trabajo y se detuvieron en una encrucijada sobre cómo organizar su propio lugar bajo el nuevo sol.
Preparándome para estudiar
Entonces, ¿cómo puede organizar la automatización de pruebas en un proyecto? Si su respuesta es tomar el maravilloso Selenium y algún tipo de marco para ello, entonces, a partir de los 13 años de experiencia en pruebas, no lo haría con seguridad. Tendrá que dominar nuevos horizontes.
¿Qué tiene de lleno el enfoque de "entrar en ciclos en selenio"? Y el hecho de que ya has leído y escuchado más de una vez. El hecho de que estas pruebas sean UI, son caras y largas tanto en escritura como en ejecución, y en el mantenimiento del rendimiento. Todo el mundo lo sabe, pero todo el dolor de esta verdad se encuentra solo cuando se ignora. Las pruebas automáticas de interfaz de usuario de extremo a extremo deben ser obligatorias, nadie, excepto ellas, le dará la confianza de que lo que
ve el cliente después del próximo despliegue no será una decepción para él. Pero no deberían convertirse en el centro de automatización de sus pruebas.
Tome
Test Pyramid Principles como su centro de control de calidad. Los mismos, sobre los cuales ya se ha dicho mucho, pero en la práctica, no todos los controles de calidad comprenden cómo aplicar esta pirámide.
Se dibuja así:
Y así:
Todos encontrarán una opción para su arquitectura.
Poner los principios de la pirámide de prueba en control de calidad
En primer lugar, no importa cuán vago e inusual pueda ser, domine las pruebas de piel blanca y conviértase en un "desarrollador parcial".Levante el proyecto localmente, tal como lo hace todo desarrollador (seguro, el proyecto tiene documentación sobre cómo hacer esto, encuéntrelo). Probablemente maldecirás este negocio una docena de veces, haciéndolo por primera vez, tendrás un millón de preguntas y problemas, pero cuando lo hagas ya sabrás mucho: cuáles son las ideas arquitectónicas, qué base de datos, desde dónde se envían, dónde están las configuraciones necesarias , y lo más importante, dónde se almacenan las pruebas automáticas y cómo ejecutarlas.
En segundo lugar, trate con las pruebas automáticas escritas por los propios desarrolladores.Encuentre su lugar en la estructura del proyecto, qué tipos de pruebas y herramientas se utilizan, cómo se lanzan. Evalúe la cobertura del proyecto con pruebas automáticas, aprenda a navegar por ellas. Hay muchas herramientas para la evaluación automática de cobertura, puede usarla, pero no estoy hablando de eso ahora. Tengo más información sobre el desarrollo de sus instintos: tome una funcionalidad y vea cómo se cubre con las pruebas automáticas: buenas o malas. Si es bueno, debe estar tranquilo para esta parte; si es malo, se ha encontrado un frente de trabajo para esos días en que no hay tareas urgentes en la agenda. Mientras tanto, tenga en cuenta que durante cada ejecución, tenga en cuenta que este lugar en el código es vulnerable.
En tercer lugar, tenga valor, revise la solicitud de extracción de los desarrolladores.Cada vez que comience a desarrollar un nuevo funcional, anote todos los casos de prueba. Marque aquellos que necesariamente debe automatizar para no volver a las pruebas manuales de esta funcionalidad. Revise las solicitudes de extracción de los desarrolladores y exija razonablemente la implementación de las pruebas automáticas que se perdieron. Muchas veces me encontré con desarrolladores geniales que escribieron pruebas geniales, pero incluso se rindieron a un buen control de calidad para comprender cómo exactamente el cliente final probablemente usará el producto. Por lo tanto, incluso para especialistas experimentados, hay algo que recomendar al escribir autotests.
Cuarto, sea aún más valiente y escriba autotests directamente en el código del producto.Sí, tal como lo hacen los desarrolladores. A la par con ellos. Cada vez que se encuentre con un caso de prueba que necesita ser automatizado, no se apresure a implementarlo de inmediato con herramientas separadas que solo se utilizan dentro del equipo de control de calidad. Y antes que nada, hágase la pregunta: ¿se puede automatizar mediante autocomprobaciones de unidad / integración en el código del producto? Si es así, haz eso. Si da miedo, entonces da miedo solo por primera vez, pero qué nivel de sus habilidades, porque los programadores experimentados revisarán sus solicitudes de extracción. Sí, al principio todo lo que has hecho se convertirá en pedazos, pero el desarrollo siempre implica dolor :) Pero al final recibirás maravillosos dividendos:
- tales pruebas serán respaldadas por todo el equipo de desarrollo
- trabajarán de forma continua, continua y rápida
- se integrarán en CircleCi y se ejecutarán cada vez que se implementen automáticamente (si esto se implementa en el proyecto)
- los agujeros se parcharán en las pruebas (usted escribe lo que no se escribió antes)
- puedes ayudar a los desarrolladores a escribir pruebas si no tienen tiempo
Quinto, cree un pequeño conjunto limitado de autotests de interfaz de usuario de extremo a extremo que imiten las acciones de un usuario final en un navegador.Estas serán pruebas que solo serán respaldadas por el equipo de control de calidad. Pueden ser encarnados
- Los escenarios de clientes críticos más populares
- el hecho de que en las pruebas de integración en el código principal no es posible implementar completamente, por ejemplo, trabajar con servicios de terceros
Y sí, ahora tiene acceso al proyecto y no necesita actualizar el front-end del proyecto para tener localizadores convenientes y confiables para Selenium. No es necesario esperar y preguntar por nadie: abra las solicitudes de extracción en el código del producto principal.
Lo que viene de eso
Ahora estoy trabajando en tal escenario. Como resultado, en la parte superior de mi pirámide de pruebas solo hay 9 piezas de pruebas de extremo a extremo. Y su apoyo es mi responsabilidad. Y todas las otras decenas y cientos de pruebas conviven con el código principal del producto, comienzan su trabajo en la computadora local del desarrollador y cuentan con el respaldo de todo el equipo de ingenieros.
Mis pruebas de extremo a extremo funcionan durante bastante tiempo, debido al hecho de que cargan archivos de video a la plataforma y luego los convierten con diferentes parámetros, los envían para su procesamiento a servicios de terceros, esperan una respuesta, etc., sin ningún trozo. Por lo tanto, en las pruebas automáticas hay muchos momentos de espera para el final de la operación. Al equipo no le gustó la posibilidad de tener tales pruebas en CircleCi, y realmente no es necesario. Así que los implementé como trabajo en Jenkins.
Cuando se hayan completado todas las comprobaciones de prueba en el código del producto, implementamos el brunch probado en el entorno de prueba y ejecutamos pruebas de extremo a extremo con Jenkins. Algunas pruebas funcionales manuales más para una mayor fidelidad del control de calidad y eso es todo, puede combinar el brunch en el maestro. Hoy, no soy el único que conduce a Jenkins para realizar pruebas automáticas en un entorno de prueba, los desarrolladores las lanzan constantemente cuando necesitan generar nuevos datos de prueba y simular la actividad del usuario. Hay pocos de ellos, por lo que son estables y siempre funcionan. Conveniente para todos.
Notaré otra ventaja agradable para el ingeniero de control de calidad en tal implementación de la pirámide de prueba. Resulta que te conviertes en parte de un equipo de ingenieros en su totalidad. Realmente haces una parte integral de un solo trabajo: escribe el código junto con todos, mira el código de los desarrolladores, comunícate con ellos y ellos te harán lo mismo. Ves el trabajo del otro, una mejor colaboración, un trabajo en equipo más fuerte. Comprenderá el proyecto no solo desde el exterior, sino también desde el interior, digno de respeto, ¿no?
Despedida final
Mi artículo no pretende ser una píldora universal que se pueda usar en cualquier momento y en cualquier lugar. Todos los proyectos son muy diferentes, todos los equipos son muy diferentes: cada uno debe construir su propio mejor camino, a menudo esta es la quintaesencia de diferentes enfoques y herramientas. Incluso el famoso Scrum, cuántos proyectos he visto, cada uno profesa a su manera :) Por lo general, no creo en instrucciones estrictas, creo que se necesitan como pautas y debo actuar de acuerdo con la situación.
Sin embargo, el mundo de TI se está desarrollando, y cada vez más personas entran en él, por lo que estoy seguro de que entre los lectores de este material habrá alguien a quien mis pequeñas instrucciones me ayudarán a elegir el camino correcto. Sonríeme en los comentarios si fue útil :), ¡los comentarios serán agradables para mí!