Si bien todo el concepto de cambio a la izquierda es increíblemente valioso, puede acelerar las pruebas para mantenerse al día con el desarrollo simplemente reduciendo la repetición de las pruebas funcionales y mejorando la colaboración entre los equipos. Es decir, si tienes la herramienta adecuada. Al comenzar el 2019, tuve que reflexionar sobre las miles de conversaciones que he tenido durante el último año con QA, ingenieros de pruebas y gerentes. Este año, especialmente en el último trimestre, estuvo dominado por conversaciones sobre la aceleración de las pruebas, especialmente sobre cómo alinear las estrategias de las pruebas al mismo tiempo que el desarrollo. Así que tuve el gran placer de compartir con muchas personas cómo reducir la repetición del trabajo en las pruebas funcionales y no funcionales con Parasoft SOAtest, mejorando simultáneamente la colaboración entre equipos y acelerando las pruebas para continuar con el desarrollo.
Puedo decir con confianza que SOAtest es la solución completa para la creación y automatización de pruebas funcionales. Es la sangre, el sudor y las lágrimas de más de 17 años de desarrollo, producidos por una compañía cuyo enfoque único y obstinado es la automatización de pruebas, que facilita y agiliza las pruebas para sus clientes. En términos de pruebas de extremo a extremo, reduce el esfuerzo manual de creación de pruebas para varios tipos de pruebas funcionales, como la definición de servicio / pruebas de contrato, pruebas de humo, pruebas de componentes API, pruebas de escenario API, pruebas de interfaz de usuario web, pruebas de base de datos , pruebas omnicanal, pruebas de microservicios, pruebas de rendimiento / carga y pruebas de seguridad API, que se pueden automatizar fácilmente y pueden vincularse a su canalización de CI / CD a través de una interfaz de línea de comandos o la premiada API REST de SOAtest.
Hay una gran cantidad de elogios que puedo hacer acerca de SOAtest y su profunda tecnología, las innovaciones en inteligencia artificial y el aprendizaje automático, y el éxito que ha tenido al permitir que nuestros clientes alcancen sus objetivos de calidad y entrega; sin embargo, hoy quiero hablar sobre el valor que se desbloquea cuando una organización usa SOAtest para cerrar la brecha entre el desarrollo, el control de calidad y los equipos de pruebas de rendimiento, para alcanzar una sinergia completa en una organización de pruebas.
El desarrollo sienta las bases para las pruebas
Así que solo voy a arrancar la tirita y ponerla ahí: el desarrollo debería probar. Y no solo digo pruebas de unidad (lo que obviamente es valioso).
El desarrollo debe involucrarse en la prueba de cualquier API nueva o modificada. Ahora, no estoy diciendo que el desarrollo deba estar construyendo escenarios de prueba completos, y creo que cuando realmente lo investigas, lo más probable es que el desarrollo ya esté realizando algunas de las pruebas de las que estoy hablando aquí. Cuando se está construyendo una nueva API, o si una API ha sufrido un cambio de esquema o servicio, el desarrollo generalmente crea mínimamente pruebas de contrato y pruebas de humo para cada una de esas API para validar que el contrato de servicio se escribe de acuerdo con las especificaciones y para validar el esquema (solicitud y respuesta) y puntos finales (HTTP, MQ / JMS Topic / Queue, etc.).
Si los desarrolladores pueden comenzar a utilizar la misma herramienta de prueba funcional para crear pruebas, el equipo de control de calidad puede simplemente aprovechar estas pruebas para formar los escenarios de prueba más complejos que necesitan validar. Entonces, ¿cómo pueden los desarrolladores aprovechar Parasoft SOAtest para ayudar a acelerar las pruebas?
Los desarrolladores pueden crear pruebas de definición de servicios
Con Parasoft SOAtest, los desarrolladores pueden validar muy fácilmente: ¿Es la definición de servicio semánticamente correcta? ¿Es válido el servicio descrito? ¿El servicio cumple con los estándares de interoperabilidad? ¿El servicio ha cambiado recientemente? Los desarrolladores que utilizan SOAtest crean fácilmente pruebas para validar y aplicar políticas de WSDL, Swagger, RAML, etc., a través del consumo de ese archivo de definición de servicio. SOAtest realizará el esquema y las pruebas de validez semántica para asegurarse de que el archivo de definición sea legible y consumible por máquina. Validará la interoperabilidad para asegurarse de que cumple con los estándares de la industria de un archivo de definición de servicio, y finalmente creará una prueba de regresión para validar que nada ha cambiado desde la última ejecución de la prueba. Estas pruebas proporcionan esa base estable que QA puede aprovechar para construir de manera eficiente una estrategia de prueba sólida y resistente (más sobre esto en un momento).
Los desarrolladores pueden crear pruebas de componentes (pruebas de humo)
Usando Parasoft SOAtest, el desarrollo puede crear fácilmente sus pruebas de componentes, para probar los componentes individuales de un servicio que busca validar que: La carga útil de solicitud / respuesta está bien formada El estado de respuesta es el esperado Las cargas útiles de error de respuesta tienen los mensajes de error correctos La respuesta cumple con los criterios de referencia La respuesta se recibe dentro de un plazo previsto Con SOAtest, crear estas pruebas de humo funcionales es tan fácil como cargar su archivo de definición a SOAtest y seleccionar «crear prueba funcional». Esto analizará su API automáticamente, creando una prueba para cada servicio individual contenido dentro de esa API. Estas pruebas se ejecutan inmediatamente y permiten a los desarrolladores dedicar un tiempo mínimo a validar que los errores que pueden haber recibido son los mensajes de error y las respuestas correctamente esperados.
Acelerando las pruebas mejorando la colaboración y aprovechando el trabajo en todos los equipos
El desarrollo en este punto ha cumplido su función: han validado la funcionalidad básica de cada servicio y ahora es el turno de QA. Los evaluadores deben crear pruebas que van más allá de la funcionalidad básica y probar la lógica empresarial real y los escenarios complejos de la API para descubrir comportamientos imprevistos e inesperados. Dev hace un hermoso trabajo de construcción, y el trabajo de QA es crear escenarios complejos destinados a probar la estabilidad de los servicios mientras funcionan en concierto. Me gusta verlo así: cuando el desarrollo ha utilizado SOAtest para sus pruebas de contrato y componentes, el control de calidad llega a una cocina que ya cuenta con ingredientes listos para ser mezclados, mezclados y ensamblados en una comida. Es sorprendente para mí lo valiosa que es esta reutilización de los artefactos de prueba y cuánto puede acelerar las prácticas de prueba, simplemente eliminando la repetición del trabajo de control de calidad que crea las pruebas que ya se han hecho con el desarrollo. En el paradigma de trabajo inteligente, el control de calidad comienza con la cocina surtida y puede hacer más en menos tiempo. Es simplemente lógico. Veamos cómo esto puede acelerar las pruebas.
Reutilización de los artefactos de prueba de los desarrolladores para crear eficientemente pruebas de escenarios significativos
El control de calidad puede reutilizar las mismas pruebas de componentes que los desarrolladores crearon en Parasoft SOAtest para asegurarse de que todo funcione en un escenario específico. Ellos pueden: Asegúrese de que las API funcionan cuando se combinan en un escenario Conduce la prueba con datos. Utilice los datos de respuesta para alimentar las solicitudes posteriores Opcionalmente aproveche las pruebas de arranque y demolición. Debido a que el control de calidad ya tiene los bloques de construcción que necesita (cortesía de desarrollo), pueden seleccionar y elegir sin script, con simples comandos de copiar y pegar, los componentes individuales que se utilizarán para probar su escenario. Estos componentes se pueden arrastrar y soltar en el orden correcto y reestructurarse para crear cada escenario. Las respuestas y la información de la primera prueba se pueden parametrizar con unos pocos clics, y se pueden usar para conducir los datos de solicitud de la segunda prueba, y así sucesivamente, y así sucesivamente en la línea. Estas pruebas de escenarios se crean de manera más eficiente, beneficiándose de los componentes provistos por el equipo de desarrollo. Con SOAtest, puede llevar esta eficiencia un paso más allá, reduciendo aún más el trabajo al «templar» la lógica empresarial (es decir, afirmaciones, validaciones, autenticación) en reglas, con aprendizaje automático. La reutilización de la lógica de prueba mejora la consistencia de las pruebas API, al tiempo que acelera las pruebas al eliminar el trabajo que otro miembro del equipo completó previamente.
Reduciendo el Ping Pong entre desarrollo y prueba para acelerar los tiempos de remediación de defectos
Una lucha constante que surge debido a la brecha entre el desarrollo y el control de calidad es el ping pong en la comunicación que se produce cuando QA encuentra un defecto. Es una tarea que lleva mucho tiempo documentar ese defecto, tomar las capturas de pantalla, escribir los pasos exactos de la prueba que revelaron el defecto y luego comunicarlo al desarrollo, que a menudo responderá con la frustrante respuesta de que funciona bien en su entorno. Este ping-pong entre Dev y QA ralentiza los tiempos de remediación de los defectos y le quita un tiempo valioso tanto al desarrollador (ya que se esfuerza por recrear el entorno de prueba) como al probador (que queda atrapado en un ciclo de comunicación y comunicación roto en lugar de gastar su tiempo creando mas pruebas). En cambio, cuando ambos equipos están usando Parasoft SOAtest, esta brecha de comunicación / colaboración se llena con la creación de escenarios de prueba re-ejecutables, acelerando dramáticamente el intercambio de conocimientos entre los evaluadores y el desarrollo. Cuando un miembro de control de calidad encuentra un problema, puede crear rápidamente un escenario de prueba (archivo .tst), mostrando el comportamiento, que luego puede compartirse con el equipo de desarrollo.
Administración del esquema de API y cambio de servicio para reducir la deuda del mantenimiento de prueba
QA ahora está trabajando de manera inteligente. Han creado una estrategia coherente para probar sus API que se basa en las pruebas de componentes existentes creadas por el Desarrollo, que reduce el re-trabajo al templar la aplicación de la lógica empresarial para que pueda reutilizarse y aprovecharse en todo el equipo de pruebas. Pero, ¿qué sucede cuando se introduce el cambio en sus aplicaciones? El cambio puede tomar muchas formas tales como: Protocolo de cambio de formato de mensaje Elementos añadidos o eliminados de la API Cambios de código efectuando el formato de datos. Servicios en re-arquitectura a microservicios. Por lo general, un gran dolor de cabeza para las organizaciones de control de calidad es comprender esos cambios, identificar los casos de prueba afectados por el cambio y actualizar y volver a ejecutar esos casos de prueba para validar que los cambios no han roto nada. Sin SOAtest, estas cosas requieren una gran cantidad de estudio de las dos versiones de un archivo de definición de API junto con un esfuerzo hercúleo para comprender las pruebas afectadas y cómo editar o reescribir cada prueba afectada para validar ese cambio. SOAtest le brinda a QA una forma fácil de administrar y mitigar el impacto del cambio a través de su módulo de Asesor de Cambio. ¿Recuerda aquellas pruebas de definición de servicio o contrato que eran tan importantes para almacenar la cocina de QA? Esos archivos de definición de servicio vuelven para ayudar con la gestión de cambios. Cuando ocurra un cambio dentro de su esquema o servicios de API, el Desarrollo actualizará ese archivo de definición y proporcionará el control de calidad con la versión más reciente. El módulo Change Advisor de SOAtest entra y compara automáticamente la nueva versión del archivo de definición con la versión anterior, crea dos mapas que representan gráficamente las operaciones y los esquemas entre los archivos de definición antiguos y nuevos, y luego puede ingresar el control de calidad, identificar fácilmente lo que se necesita cambiar, y con unos pocos clics, revise y actualice en función de los cambios. Y una vez que se han revisado todos los cambios, esa plantilla de cambios se puede aplicar fácilmente para refactorizar automáticamente todas las pruebas existentes afectadas por esos cambios.
Re-utilización de artefactos de prueba existentes en el rendimiento
QA ahora ha hecho su trabajo. Los evaluadores han creado múltiples escenarios de prueba complejos destinados a probar la lógica de negocios de la API y validar la funcionalidad de los servicios de forma conjunta. La lógica de negocios es sólida, y cada caso de uso ha sido probado y validado. Todos los defectos encontrados se han comunicado fácilmente al desarrollo en forma de un archivo .tst para una rápida reproducción. Existe una estrategia integral y mínimamente manual para mantener esas pruebas de API y actualizar las pruebas cuando se produce un cambio. Ahora es el momento de romper la aplicación: es el momento para que los evaluadores de rendimiento prueben el comportamiento de la API cuando tiene más de 100, 500, 1000 usuarios intentando realizar los mismos escenarios al mismo tiempo desde diferentes lugares en todo el mundo. En muchos casos, un evaluador de rendimiento necesitaría crear sus propios escenarios de prueba específicamente bajo estas condiciones. Afortunadamente, al aprovechar Parasoft SOAtest, el equipo de rendimiento no necesita reinventar la rueda. Pueden utilizar la combinación de pruebas de componentes creadas por Desarrollo y las Pruebas de escenario creadas por QA para validar sus SLA y el desempeño oportuno de la aplicación, todo dentro del módulo de Prueba de carga de SOAtest. Dentro del módulo de prueba de carga, las pruebas existentes de componentes o escenarios de SOAtest pueden ser fácilmente aprovechadas e impulsadas por cualquier número posible de usuarios virtuales y distribuidas en cualquier número de máquinas esclavas para probar escenarios bajo diferentes tipos de carga como timbre, búfer, lineal y constante. carga, lo que le permite validar que la aplicación puede comportarse como se espera en los distintos tipos de estrés.
En conclusión….
«Trabajar de manera inteligente no es difícil» debe ser el objetivo final de su estrategia de prueba funcional, pero hacer las mismas acciones una y otra vez ha sido la norma para los equipos de pruebas cuando se trata de pruebas de API. Muy a menudo, hablo con los gerentes de control de calidad y los entrenadores de DevOp que tienen la tarea de identificar formas de acelerar su velocidad de prueba y aumentar la colaboración, y lo que he descrito aquí es la respuesta. Los equipos pueden reducir el re-trabajo y aumentar la eficiencia al aprovechar las capacidades de SOAtest. Es fácil de adoptar tanto a nivel de proyecto individual como empresarial o de inicio, ya que se ha creado para escalar con destreza, y requiere un bajo nivel de experiencia técnica para la creación y automatización de pruebas. Tener una herramienta unificada para las pruebas funcionales utilizadas por Desarrollo, Control de Calidad y Rendimiento permite un nivel de colaboración innovador y una reducción en el re-trabajo que puede afectar los resultados, reduciendo los esfuerzos, el tiempo y los costos generales de las pruebas.
Comentarios recientes