Desplazamiento a la izquierda Enfoque de prueba

Las pruebas de software son una necesidad. Garantiza que un producto se entrega a los clientes finales sin fallas. Y al ser un tema ampliamente discutido, existen muchos enfoques para probar el software.

Algunas empresas defienden un “ enfoque en cascada ” para el diseño de productos. Aquí, el software está diseñado secuencialmente. Pasa estrictamente por el ciclo de desarrollo de:

1. Requirements/Gathering
2. Design
3. Development
4. Deployment 

Las pruebas se delegan a las etapas finales del diseño del producto (antes de la etapa de implementación). Esto normalmente se denomina «prueba de cambio a la derecha».

Pruebas en las etapas finales: una estrategia inferior:
todos los códigos son propensos a errores. Y los errores pueden ser menores (bajo riesgo) o mayores (alto riesgo) según el tipo de error.

Cuanto antes se detecten esos errores, mejor. Da tiempo a los equipos de desarrollo para arreglar el software sin demoras y evitar fases de prueba finales prolongadas. También es más fácil reparar el software con errores cuando no aparecen demasiados errores al mismo tiempo. Esta es la razón por la que las estrategias de cambio a la derecha son ineficaces en la mayoría de los casos.

Siendo realistas, es agotador pasar por cada línea de codificación de un producto final, solo para encontrar un error o dos. Es mejor corregir cada unidad a medida que se desarrolla el código. ¡Y aquí es donde entra en juego shift-left!

1. Calidad de código mejorada:
   cuanto antes detecte un error, mejor. Permite una mejor comunicación entre los equipos de pruebas y desarrollo. Permite que ambos equipos aborden cada error 1 por 1.

   Compare eso con un enfoque de desplazamiento a la derecha. Aquí, todos los errores se abordan a la vez. Y muchos pueden ser olvidados o ignorados (debido a limitaciones de tiempo o presupuesto).

2. Múltiples tipos de prueba:
   cuando los códigos se prueban en cada etapa de diseño, se pueden aplicar una multitud de tipos de prueba.

   Por ejemplo, la prueba unitaria es una posibilidad con un enfoque de desplazamiento a la izquierda. Aquí, cada componente se prueba por separado para verificar si hay errores individuales. Además, las pruebas de integración se pueden realizar con frecuencia en la etapa de diseño. Y esto asegura que no se desarrollen errores a medida que se asignan diferentes unidades juntas.

   Compare eso con las estrategias de cambio a la derecha, que solo permiten la posibilidad de probar el sistema. E incluso eso no es exacto y no es efectivo para descubrir todos los errores.

   Encontrar defectos de diseño y problemas arquitectónicos: a
   veces, los errores no son el problema. Principales aspectos (o ideas) que se están implementando que pueden ser defectuosas. Esos defectos (que pueden interferir con otros códigos) deben descubrirse temprano. De lo contrario, se desperdicia demasiado tiempo en implementar planes de diseño importantes que son inviables.

   Esta es otra ventaja adicional de las pruebas de desplazamiento a la izquierda. Después de todo, las pruebas de unidades más pequeñas están automatizadas y sus casos de prueba son fáciles de diseñar.

   Compare eso con la prueba del sistema, que lleva tiempo y debe hacerse manualmente. Tampoco se puede repetir a menudo. Y esa repetibilidad es lo que hace que los enfoques de desplazamiento a la izquierda sean mejores. ¡Permite un producto de mejor calidad de código, reduciendo las posibilidades de errores de alto riesgo!

3. Reducción de los costos de desarrollo y prueba: los
   errores que se detectan temprano reducen las posibilidades de efectos secundarios.

   Con menos efectos secundarios de los que preocuparse, los lanzamientos de productos se pueden realizar a tiempo. Se puede entregar un código final al cliente final sin necesidad de arreglos futuros. Aquí, se recomienda que las pruebas de errores se realicen después de cada compilación. Esto permite una mejor prueba continua automatizada, lo que es imposible con errores de gran tamaño.

   Además, los enfoques de desplazamiento a la izquierda reducen la necesidad de probar el sistema. Y, de hecho, eso podría eliminarse por completo si las pruebas se realizan con frecuencia.

   Menos problemas para versiones futuras:
   muchos programas están diseñados con funciones en línea. También están diseñados con la intención de parchear futuras versiones. Esas versiones futuras no se pueden agregar, si las versiones anteriores tienen errores sin corregir.

   Esto conduce a un efecto de «onda de proa», donde se pueden acumular múltiples efectos secundarios de errores. Y el resultado es que ciertos errores se vuelven imposibles de corregir.

4. Mantiene informadas a todas las partes interesadas del proyecto:
   con el enfoque de desplazamiento a la izquierda, las pruebas se realizan en cada etapa crítica del desarrollo del software. Como resultado, el equipo de pruebas termina (por necesidad) involucrado en la planificación del proyecto. También están informados sobre sus objetivos comerciales.

   Esto les permite obtener una mejor perspectiva sobre el propósito del software. Y les permite encontrar ideas y soluciones creativas en medio de las pruebas. Además, los mantiene motivados. Porque los equipos de prueba entienden a qué contribuyen sus esfuerzos a largo plazo.

5. Mantiene al equipo de desarrolladores consciente:
   muchos proyectos de diseño ponen a los desarrolladores en la posición de crear código. Pero, ¿qué hay de verificar la calidad mientras se escribe cada línea?

   Esta mentalidad está arraigada en los desarrolladores al alentar las pruebas frecuentes. Y dado que las pruebas requieren revisiones que consumen mucho tiempo, garantiza que un desarrollador minimice los errores al escribir el código.

   Con un enfoque de desplazamiento a la izquierda, se alienta a los desarrolladores a ser más responsables. ¡Y también mejora sus habilidades y niveles de competencia!

6. Colaboración de prueba mejorada:
   los enfoques de desplazamiento a la izquierda aprovechan la «automatización» frecuente. Les permite realizar pruebas continuas para reducir el tiempo. Pero, eso aún deja el problema de diseñar esas pruebas. Y esto a menudo se deja en manos del equipo de pruebas para que lo averigüe.

   Además, el problema aquí es que diseñar las mejores pruebas requiere conocer el propósito del producto y sus objetivos comerciales.

   Con un enfoque de cambio a la izquierda, dado que los equipos de desarrollo y prueba trabajan juntos, pueden diseñar pruebas automatizadas con la información de los demás. Esto lleva al desarrollo de escenarios de prueba que son realistas y precisos para encontrar errores y problemas.

Elegir el enfoque que funcione para usted:
los enfoques de desplazamiento a la izquierda se pueden practicar de muchas maneras. Y se adaptan a software de todos los tamaños (desde grandes plataformas en línea hasta pequeñas aplicaciones móviles). Como resultado, encontrará que su fecha límite de diseño difiere según el proyecto. Y como resultado, el enfoque que elija es diferente.

• Basado en modelos:
  al menos la mitad de los errores de un software determinado aparecen durante la fase de recopilación de requisitos. Encontrar errores en esa etapa reduce la necesidad de corregir errores más adelante. Además, mantienen informados a los equipos de pruebas sobre los objetivos básicos del proyecto.
• Pruebas tradicionales:
  aquí, el enfoque está en las pruebas continuas, a través de pruebas unitarias y de integración. Se enfoca en la automatización tanto como sea posible, ahorrando así tiempo y costos de desarrollo.

  Esta forma de prueba tiende a ignorar las pruebas de aceptación y del sistema (cuyos resultados están más o menos garantizados a través de frecuentes pruebas unitarias/de integración).

• Pruebas incrementales:
  esto intenta imitar un modelo de prueba tradicional, pero está dirigido a proyectos grandes. La prueba se divide en partes menores, donde se prueba un conjunto de códigos. Una vez que los códigos se integran, se prueban nuevamente para garantizar que no haya errores.
• DevOps/Fragile testing: se
  realiza con menos frecuencia que los modelos tradicionales, esta forma de prueba funciona para proyectos más pequeños que tienen plazos ajustados.