Resumen de las pruebas multicapa
Creo que un sistema de pruebas automatizadas bien diseñado y una cultura de desarrollo que dé prioridad a las pruebas pueden aumentar drásticamente la calidad y reducir los defectos de producción. Un enfoque bien estructurado de desarrollo de software que dé prioridad a las pruebas garantizará que todos los niveles de funcionalidad (desde la lógica programática hasta los escenarios funcionales y las reglas empresariales) se capturen de forma ejecutable y automatizada.
Además, los errores que lleguen a producción podrán diagnosticarse, envolverse en pruebas y liberarse para que no vuelvan a aparecer.
Por último, la integración de la ejecución automatizada de estas pruebas en el proceso de creación hará que sean rápidas, legibles y fiables para todos los miembros de la organización.
Capas de pruebas automatizadas
Hay muchos artículos en línea que cubren los diferentes tipos de pruebas en el ciclo de vida de desarrollo de software, así como sus detalles de implementación y las razones por las que valorar unos tipos sobre otros.
En este blog, intentaré describir los tres niveles de pruebas que, cuando se implementan al unísono, con el enfoque adecuado y en el lugar correcto del proceso de despliegue, pueden:
Conducir a un aumento de la calidad general del código y el diseño
Detectar errores antes de la puesta en producción (o clasificar los que se cuelan en producción).
Servir como documentación del proyecto
Aumentar la confianza en el equipo de desarrollo para lanzar un producto de la mayor calidad posible.
El nivel más bajo de pruebas con el que la mayoría de los desarrolladores están familiarizados es Pruebas unitarias. El segundo nivel de pruebas que a menudo se pasa por alto es Pruebas de Integración. El último nivel de pruebas que la mayoría de la gente imagina cuando oye hablar de pruebas automatizadas es el nivel de sistema. Pruebas GUI.
Pruebas unitarias
La mayoría de los desarrolladores están familiarizados con las pruebas unitarias, ya que hoy en día forman parte integral del ciclo de vida del desarrollo de software. El objetivo principal de estas pruebas es verificar la funcionalidad de fragmentos de código que contienen lógica simple o compleja. El propósito secundario de las pruebas unitarias es servir como una suite de regresión para futuras modificaciones de fragmentos de código que podrían alterar accidentalmente la funcionalidad.
El valor de las pruebas unitarias aumenta en los grandes proyectos de desarrollo, ya que ayudan a los desarrolladores a documentar la funcionalidad de las unidades individuales de código que podría no ser capturado en el nivel de característica o en una historia de usuario. En mi propia experiencia, escribir código totalmente probado por unidades conduce a unidades de funcionalidad mejor diseñadas, legibles y susceptibles de ampliación en el futuro.
La mayoría de los sistemas de compilación recogen y ejecutan automáticamente las pruebas unitarias que se encuentran en la ubicación adecuada en el proyecto. Ejecutar estas pruebas como parte de la compilación es crucial en el ciclo de vida del desarrollo de software, ya que notifica a los desarrolladores las piezas rotas de funcionalidad antes de que los defectos lleguen al entorno de control de calidad.
Las herramientas de cobertura del código son valiosas extensiones de las herramientas de pruebas unitarias que todos los esfuerzos de desarrollo deberían aprovechar. Estas herramientas muestran qué partes del código no están cubiertas por las pruebas unitarias y pueden ayudar en gran medida a los desarrolladores a ver dónde es necesario realizar pruebas adicionales. Aunque no es necesario aspirar a una cobertura del código del 100% con estas herramientas, una empresa puede elegir un umbral de cobertura del código con el que se sienta cómoda. Entonces, de forma similar a cómo se requiere pasar las pruebas unitarias para que el proceso de compilación finalice con éxito, las herramientas de cobertura de código pueden integrarse en el proceso de compilación y debe alcanzarse un cierto umbral para que la compilación pase.
CUÁNDO Y DÓNDE EJECUTARLAS:
Estas pruebas deben integrarse y ejecutarse en cada proyecto y un fallo en las pruebas unitarias debe hacer fallar la compilación.
Pruebas de integración (pruebas de API)
Las Pruebas de Integración son un nivel de pruebas a menudo pasado por alto, ya que no es tan ampliamente discutido como las pruebas unitarias y no es tan intuitivo o llamativo como las Pruebas GUI. El valor de las Pruebas a Nivel de Integración, sin embargo, no puede ser subestimado. Estas pruebas deben utilizarse para capturar y ejercitar plenamente los requisitos empresariales de forma ejecutable.
El propósito de estas pruebas es agotar las reglas de negocio positivas y negativas que se piden al sistema. Una pieza clave en la creación de estas pruebas para maximizar su valor es hacer que todo el equipo las cree en grupo. Trabajar en grupo permite a todo el equipo comprender el alcance y la cobertura de las pruebas.
Herramientas como Cucumber que utilizan la sintaxis Gherkin son una gran manera de expresar sus reglas de negocio de una manera comprensible para el negocio y requiere un mínimo de codificación para transformar cada línea en un fragmento de código ejecutable para realizar las pruebas. Si es posible, haga que el BA y QA escriban las pruebas juntos como parte de los requisitos de la historia de usuario, luego haga que los desarrolladores escriban la implementación de los casos de prueba que hablan con el sistema.
Además, estas pruebas no interactúan con una interfaz gráfica de usuario y se comunican a través de canales más directos, por lo que son mucho más rápidas de ejecutar que las pruebas de interfaz gráfica de usuario. Las pruebas de integración deben interactuar con un sistema desplegado API en pares de solicitud/respuesta, lo que permite que las pruebas de integración se ejecuten lo suficientemente rápido como para proporcionar información en tiempo real sobre el estado y la validez del sistema implementado.
Una forma de implementar este nivel de pruebas es escribir un programa de pruebas personalizado que tome los casos de prueba Gherkin, construya una solicitud web basada en las entradas de prueba, envíe la solicitud al servidor y capture la respuesta, luego verifique la respuesta contra los resultados esperados de la prueba. Los proyectos que utilizan herramientas como Cucumber para Java o SpecFlow para .NET realizan bien esta tarea. Además, hay herramientas como SoapUI Pro que disponen de conjuntos de programas completos para adaptarse al nivel de las pruebas.
Por último, para maximizar el valor de estas pruebas, es esencial integrarlas en una canalización CI/CD. La creación de un entorno de pruebas de integración y la ejecución de las pruebas contra este entorno antes de desplegar a un entorno de control de calidad es una poderosa manera de validar la funcionalidad del sistema. El despliegue de un entorno de pruebas de integración independiente permite que las pruebas se ejecuten en un entorno similar al de producción, se desplieguen como una aplicación similar a la de producción y se conecten a servicios y fuentes de datos activos, todo lo cual aumentan la confianza en los resultados de las pruebas.. Este entorno adicional también permite detener el despliegue si fallan las pruebas de integración.
CUÁNDO Y DÓNDE EJECUTARLAS:
Estas pruebas deben integrarse en el proceso de compilación y ejecutarse como requisito previo al despliegue en un entorno de control de calidad. Los fallos deberían detener el despliegue en el entorno de control de calidad.
Pruebas del sistema (pruebas GUI)
Desde la misma interfaz con la que interact úa un usuario (persona o proceso) del sistema, estas pruebas verifican que una nueva funcionalidad empresarial funciona como se espera. Deben incluir todos los escenarios positivos y negativos que la empresa desearía ver, pero no todas las permutaciones de datos que lograrían este escenario. Además, si hay alguna lógica de negocio en la capa de presentación, las pruebas de la interfaz gráfica de usuario también deben cubrir todos los escenarios. Existen muchas herramientas para automatizar este paso, como WebDriverpara probar una interfaz de navegador y TestComplete para probar aplicaciones Windows.
Este paso también debe integrarse con el sistema CI/CD, y la prueba debe ejecutarse en el entorno de control de calidad inmediatamente después del despliegue. Estas pruebas sirven para automatizar las pruebas sencillas y sencillas que demuestran que la nueva funcionalidad de la empresa está correctamente representada en el sistema hasta la capa de la interfaz gráfica de usuario.
Automatizar estas pruebas y hacer que se ejecuten después de cada despliegue del entorno de control de calidad refuerza que la funcionalidad correcta está en su lugar, genera confianza en el conjunto de pruebas de regresión y libera el proceso manual de control de calidad para un caso límite y pruebas exploratorias.
UNA ADVERTENCIA:
Sé precavido al escribir estas pruebas. No intentes probar exhaustivamente el sistema desde la interfaz de usuario por motivos de rendimiento y estabilidad. NO querrás que los costes de mantenimiento de estas pruebas se conviertan en una carga.
CUÁNDO Y DÓNDE EJECUTARLAS:
Estas pruebas deben integrarse en el proceso de compilación y ejecutarse automáticamente en un entorno de control de calidad recién desplegado. Los informes deben generarse automáticamente y enviarse a los desarrolladores que hayan realizado cambios en el código.
