Categories
54cuatro

¿Cuantos tipos de Testing de Software existe? (parte 2)

Ya revisamos algunas pruebas en la Parte 1 de la entrada.

Continuando con pruebas existentes en el ambiente del Test de Software vamos a seguir con la lista:

Prueba de regresión

El último test mencionado en la entrada anterior hacía referencia a las pruebas de humo. Cuando se configuran pruebas dentro de Pipelines CI/CD, dijimos que ejecutarán pruebas de humo en casi todas las confirmaciones, y como complemento de esas configuraciones, es necesario agregar #pruebas de regresión que pueden ejecutarse a intervalos establecidos o en funciones grandes para garantizar una integración continua sin problemas; esto dado que este tipo de #testing esta orientado a verificar si alguna característica previamente funcional ha cambiado o se ha roto repentinamente.

Pruebas de Carga/Performance

En este caso lo que se busca probar es el rendimiento de un nuevo desarrollo ante una determinada cantidad de carga/tráfico/sesiones; y cual es su respuesta ante la variabilidad de estas condiciones.

Durante esta etapa, es de mucha utilidad probar determinadas situaciones de incremento de tráfico controlado para conocer los límites que la plataforma puede soportar, como también simular el incremento repentino para entender como respondería por ejemplo ante un estampido de conexiones provocadas por DDOS.

Pruebas de Seguridad

Durante estas pruebas, se llevan a cargo ejecuciones controladas donde se busca vulnerar el sistema. Este tipo de test, también llamado Penetration Test, busca controlar los niveles de solidez en materia de seguridad y protección de la información.

Este tipo de pruebas, también es alterada debido a la adopción de #DevSecOps, donde se busca que el aseguramiento de lo que se va desarrollando se haga desde etapas tempranas del desarrollo, controlando librerías, frameworks, llamadas, y todo tipo de cuestiones a medida que se va creando una aplicación, para evitar hacer los controles todos juntos al final; esto da como resultado un software de código mas limpio, con mejores tiempos de entrega y con mayor seguridad.

Testing free icon

Ingeniería del Caos

Estas pruebas, fueron desarrolladas por el equipo ingeniería de Netflix; y consiste en la prueba sobre todo el sistema para entender como se comporta ante fallos inesperados que son generados de forma random para provocar situaciones de desastres.

Esta disciplina nos permite conocer el comportamiento de la aplicación ante ataques, fallas, errores humanos, outages de los datacenters, etc. Cada prueba busca entender como afecta a la aplicación productiva y crear una acción correctiva de manera de ir creando un sistema resiliente capaz de soportar situaciones imprevistas.

La herramienta principalmente conocida para estas pruebas es Chaos Monkey.

Conclusión

Repasamos algunos de los conceptos mas estándares del ciclo de pruebas de software. En la actualidad, se busca incorporar el #testing dentro del esquema #DevOps, como mencionamos en alguna nota posterior, ya existe el término de TestOps y es cada día de mayor importancia el enfoque de agilidad llevado a las pruebas.

Categories
54cuatro

¿Cuantos tipos de Testing de Software existe? (parte 1)

El testing del software es una práctica habitual y que es llevada día a día por miles de testers y especialistas de QA. Pero en la actualidad, el despliegue de pipelines #DevOps obligan a integrar el #testing como parte de los pipelines CI/CD.

Developer free icon

Por eso, hacemos esta entrada para adentrarnos en temas de pruebas de #software.

Esta es una lista de los tipos de pruebas existentes:

Prueba Unitaria

La prueba unitaria nos facilita el test de una parte de código que está realizando alguna acción determinada. Durante la prueba unitaria solamente probamos esa porción de código. Por ejemplo, si estamos haciendo una llamada a una base de datos, posiblemente aun no tengamos la base disponible y emulemos la prueba para saber si el código funciona.

Para esta prueba existen herramientas para los lenguajes mas habituales. En pruebas Java tiene JUnit , Python tiene PyUnit o PyTest , JavaScript tiene Mocha entre otros, .NET tiene xUnit, etc.

Prueba de Integración

En este caso, la prueba de integración nos permite hacer el test sobre varios componentes juntos. Siguiendo con el ejemplo de la prueba unitaria, en este caso, la diferencia sería que la llamada a la base la probaríamos haciendo la llamada realmente a la base destino.

El propósito de este test es justamente probar la interacción entre los diferentes componentes de la app, las relaciones y comunicaciones de los mismos.

Pruebas E2E (Extremo a Extremo)

En este caso las pruebas de Extremo a Extremo, hacen referencia a la ejecución de test sobre toda la aplicación. Seria el broche final de las Pruebas Unitarias y las Pruebas de Integración. En el test E2E, se ejecuta desde principio a fin toda la aplicación y muchas veces es el mismo usuario solicitante el que se encarga de ejecutar este tipo de prueba. Aplicaciones como Cucumber o Postman suelen ser herramientas amigables para la ejecución de estas pruebas.

Las 3 pruebas mencionadas hasta aquí suelen ser probadas en un ambiente aislado, con la función específica de conocer el comportamiento de las nuevas piezas de software.

Prueba de aceptación

En este caso, la prueba de aceptación nos lleva a un bloque de pruebas orientado a recibir la aceptación formal de un Cliente o Usuario, confirmando que los requerimientos solicitados fueron cumplidos tal como fueron pedidos.

Debido a la adopción de metodologías ágiles y de testing como TDD, las pruebas de aceptación suelen ser mas cortas que antaño, ya que el usuario suele estar involucrado durante las fases de desarrollo y el testing se va ejecutando como parte del proceso desarrollo (al igual que las pruebas de seguridad y de performance)

Pruebas de Humo (Smoke Testing)

Este tipo de pruebas, tiene vital importancia durante la configuración de los pipelines CI/CD, ya que las pruebas de humo permiten saber si la compilación del software implementado es estable, a partir de la ejecución de un conjunto mínimo de pruebas al azar que se corren en cada compilación para probar las funcionalidades del software.

Este tipo de testing suele llamarse Test de Confianza y como se mencionó anteriormente, agregar este nuevo bloque de pruebas en el pipeline proporcionará una validación de que la aplicación pasó todos los casos de prueba. 

En otra entrada vamos a continuar con testing focalizados a la Performance y la Seguridad.

Categories
54cuatro

El testing dentro de CI/CD

Desde antes de la fiebre #DevOps que sabemos que había que automatizar las pruebas de software, pero no se hizo. Los equipos de desarrollo fueron haciendo mayor énfasis en las pruebas de interfaz de usuario que en pruebas unitarias, y por consiguiente se fue deformando el enfoque propuesto por Mike Cohn, denominada ‘Pirámide Ágil de Automatización de Testing’.

test automation strategy
Agile test automation pyramid – Mike Cohn

Esta pirámide es quizás la mejor definición de como deberíamos ejecutar las pruebas, y concentrarnos en la interfaz de usuario genera un patrón basado en Detectar Errores, cuando lo que debiéramos hacer es Prevenir Errores.

Pruebas unitarias

Esto tipo de testing es el que se realiza en la etapa de desarrollo, ejecutando pruebas unitarias después de cada compilación se consiguen datos específicos para un programador; ej: hay un error y está en la línea 1143.

Además habitualmente las pruebas unitarias se realizan en el mismo lenguaje que la pieza de software de manera que los programadores suelen mantener una cierta comodidad escribiendo pruebas.  

Capa de Integración

En esta capa, se suele probar la integración de todos los componentes. Es donde se controla que todos los componentes funcionen correctamente y donde se busca comprobar que la lógica del software se encuentra alineada al requerimiento. Estas pruebas no solo aplicación a arquitecturas orientadas a servicios (SOA) sino también a variantes modernas de microservicios. En el caso de pruebas de API, necesita saber cuándo fallan sus API, por qué fallaron y necesita un circuito de retroalimentación ajustado para alertarlo lo antes posible. Es importante el testing en esta capa ya que si bien el end-to-end de las aplicaciones están compuestas de varios servicios que se concatenan entre si, hay muchos casos de prueba que deben invocarse de manera individual dado que no todos pueden ser ejecutados a través de la interfaz de usuario.

Pruebas de Interfaz de Usuario

Llegamos al tope de la pirámide. Y es justamente el tope de la pirámide porque este tipo de pruebas deben realizarse lo menos posible. Por motivos varios, son costosas, difíciles de preparar y requieren mucho tiempo. Ademas de que suelen salir muchos falsos negativos y falsos positivos. Pero de todas modas no debe evitarse esta etapa, dado que probando la interfaz de usuario se logra una prueba de extremo a extremo, para verificar el sistema en su totalidad. 

El equipo de desarrollo de Google sugiere que las pruebas deben ser realizadas 70% de pruebas unitarias, 20% de pruebas de integración y 10% en la capa superior.

Integrando el testing en un modelo CI/CD

Which one is right for you: Waterfall or Agile? |

Recordemos que CI/CD es un pilar de #DevOps que busca desplegar aplicaciones de software por medio de la automatización; y como es bien sabido que el #testing es parte de todo esto, debemos tener integradas las pruebas para poder seguir con el circulo virtuoso que propone DevOps.

Integrar el testing bajo el concepto de “Testing Continuo” permite detectar errores de forma temprana y por ende resolverlos con gran rapidez.

Algunos test que son potencialmente automatizables son las pruebas de regresión, funcionales, de integración y de rendimiento. Algunas herramientas nos permiten facilitar las tareas de automatización de testing, aunque no menos importante es encontrar que será automatizado, y también orquestar inteligentemente las pruebas.

Herramientas para Pruebas Continuas

  • #Katalon. Esta herramienta ofrece una plataforma integral para realizar pruebas automatizadas para interfaz de usuario web, servicios web, servicios API y dispositivos móviles.
  • #Travis CI. Travis CI es un servicio de integración continua alojado que se utiliza para crear y probar proyectos de software alojados en GitHub y Bitbucket.
  • #Selenium es una herramienta de prueba compatible con la mayoría de los navegadores convencionales, como Chrome, Firefox, Safari e Internet Explorer.
  • #Azure Test Plan. En lo que refiere a ambientes #cloud, #Microsoft tiene una gran oferta de soluciones dentro de su suite Azure DevOps, y en este caso un kit de herramientas de pruebas exploratorias y manuales con una interfaz intuitiva e integrada.

Conclusión

Este tema da para largo y en próximas entradas seguiremos explorando el testing en el marco de DevOps, haciendo foco en Microservicios, API e incluso en Data.

El testing como parte de una cadena CI/CD es muy beneficioso, pero también pueden muy desafiante. Es necesario tener un buen plan de testing tradicional antes de incorporar este procedimiento de prueba.

Posterior a tener un buen marco de pruebas es recomendable trabajar en las estrategias de incorporación del flujo de pruebas al pipeline.

Gracias por leernos!


[popup_anything id=”2076″]
Categories
54cuatro

Que es DevOps

Esta nota fue publicada originalmente en Linkedin

Ya es sabido que es #DevOps. Un movimiento cultural combinado con una serie de prácticas de desarrollo de software que permiten entregar productos finales de forma rápida.

DevOps tiene pilares fundamentales como son la comunicación, responsabilidad, respeto y confianza de los miembros de un equipo.

El uso de herramientas y flujos de trabajo aptos para DevOps puede ayudar a su equipo a trabajar de una manera más DevOps “friendly”, pero es crucial crear una cultura que respalde el ideal del movimiento.

Analizando algunos ideales, entendemos que el foco está en el producto. Un equipo DevOps trabaja sobre el rendimiento del producto en todo su ciclo de vida, discutiendo los requisitos, las características, los cronogramas, los recursos y la cantidad de datos que podrían surgir, y genera objetivos conjuntos.

Esos Objetivos medibles comunes pueden ser:

  • Reducir el tiempo de time-to-market.
  • Aumentar la disponibilidad.
  • Reducir el tiempo necesario para implementar.
  • Aumentar el porcentaje de defectos detectados en #testing antes de pasar a producción.
  • Hacer un uso más eficiente de la infraestructura.
  • Proporcionar el rendimiento y la experiencia del usuario al gerente de producto.

Estos objetivos tienen un impacto monetario en su negocio, ya que le cuesta mas horas-hombre cuando el software tarda mas días de lo planificado en ser liberado. Le cuesta ingresos cuando el producto no está disponible para el uso de sus clientes. Aumenta su costo operativo por ejecutar su infraestructura de manera poco eficiente.

Tomando lo que sabe sobre estos valores, puede poner un valor monetario para mejorar cualquiera de ellos.

Su #stakeholder estará interesado en los objetivos mensurables que haya desarrollado.

Los objetivos nos permiten fijar metas.

Recuerde que DevOps es un nombre inapropiado: lleve DevOps más allá de los desarrolladores y las operaciones, para incluir aseguramiento de la calidad, servicio al cliente, personal comercial y liderazgo ejecutivo si es posible.

¿Necesitamos ser 100% Devops?

Tal vez no. DevOps es arriesgado para aplicaciones heredadas y organizaciones establecidas. Quizás deba mantener estos dos modos de operación separados según la aplicación. Tal vez necesitamos un sistema híbrido como el modelo definido por Garnet como IT Bimodal.

#Gartner describe a #IT-Bimodal de la siguiente manera: es la práctica de administrar dos modos separados y coherentes de entrega de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y la precisión. El modo 2 es exploratorio y no lineal, destacando la agilidad y la velocidad. ¿Necesitamos ser 100% DevOps? Quizás no, pero de una forma u otra, se necesita hacer cambios, fundamentalmente romper con los silos y mejorar la productividad.

(Producto = Tiempo + Recursos)

Hay dos formas de aumentar la productividad. Disminuir los tiempos o aumentar los recursos.

Se alienta a los sectores de desarrollo a reducir los tiempos de desarrollo. Y se alienta a los sectores de Operaciones a mantener la productividad. Estos incentivos no son compatibles entre sí.

DevOps debería ayudar al negocio de la compañía a actuar por igual sobre los responsables del tiempo y los recursos.

El desafío para cualquier compañía es tener diferentes equipos que funcionen como uno solo.

Y en ese marco es importante gestionar el Estancamiento y Obsolescencia. Las organizaciones deben asegurarse que los sistemas de información con los que trabajan estén en un proceso continuo de actualización de los componentes. Es por ello que se debe crear un plan de obsolescencia.

La tendencia actual de IT, es tener todo definido como servicio. #IaaS, #PaaS, #SaaS. Todo será definido por el software. Los sectores de infraestructura deben superar el desafío de la transformación. El modelo de infraestructura actual está orientado a servicios y no a la granja de servidores. “El software se está comiendo el mundo”.

¿Cómo llevar un desarrollo obsoleto y estático a un modelo DevOps?

Una forma de actualizar una aplicación obsoleta es dividir las funciones en microservicios. Un microservicio debe hacer una sola cosa, pero debe hacerlo bien.

Los microservicios son simples, fáciles, pero es necesario mantenerlos estrechamente controlados y tomar precauciones para que no haya creación descontrolada de microservicios en toda la compañía.

Tener una entrega continua ayuda a las empresas a mantenerse alineadas con el objetivo de tener un producto de acuerdo con los requisitos del mercado, gracias a la reducción del tiempo de lanzamiento al mercado.

Y si algo funciona, hay que seguir mejorandolo. No importa qué tan bien funcione un sistema, siempre se puede mejorar. Mejorar y aprender nos ayuda a tener un sistema “vivo” que se adapta mejor a las demandas del negocio.

Mucho se habla acerca de Herramientas DevOps. Pero… ¿Cuáles son herramientas DevOps?

  • Cualquiera que nos permita automatizar
  • Cualquiera que maneje configuraciones
  • Cualquiera que realice implementaciones automáticas
  • Cualquiera que maneje registros
  • Cualquiera que monitoree desempeño y capacidades

No existe un método de implementación de herramientas DevOps. Cada uno debe crear su propia caja de herramientas, pero debe centrarse en la automatización. Es importante lograr que cualquier tarea repetitiva sea automatizada. Automatizar aumenta las capacidades de los sistema, reduce las fallas, reduce el tiempo de ejecución y principalmente, puede medirse.

Que se puede automatizar?

  • Creación de #nubes y #VM
  • #Despliegues de la aplicación
  • Planificación de capacidades
  • Control de Intentos de acceso no permitidos
  • #Backup/#Restore
  • Gestión de configuración
  • Gestión de #parches
  • Actualizaciones de #CMDB (Y acá existe algo importante para mencionar. No importa cuán malo sea tu CMDB, necesitas tener una)

Lograr el despliegue automático tiene grandes implicancias en la reducción del time-2-market, en reducir la fricción entre desarrollo y operaciones, permite un rollback de manera rápida y disminuye en gran medida los downtimes provocados por fallas.

Para el control de funcionamiento y fallas, es necesaria una gestión inteligente de eventos ayuda a identificar problemas, errores y posibles desviaciones en el funcionamiento de un sistema. Esta informacion, junto a la medición de rendimiento nos permite medir la capacidad de los recursos para cumplir los objetivos establecidos y saber qué tan bien estamos utilizando nuestros recursos. Y junto con saber sobre la utilización de los recursos, es importante realizar la planificación de capacidades de nuestra plataforma. Conocer el uso de los recursos (y optimizarlos), proponer alternativas tecnológicas, analizar el cumplimiento de SLA, listar riesgos y principalmente aumentar la alineación entre negocios y tecnología.

DevOps nos permite aumentar el ROI. Porque? Porque en muchas casos nos permite reutilizar infraestructura o aprovechar las ventajas de plataformas más elásticas que se adaptan mejor a la estrategia de la empresa. La nube ofrece un concepto de “pago por uso”, lo que se traducido a gastos permite un ahorro en costos y convertir CAPEX en OPEX.

¿Que se puede esperar a corto plazo en materia de DevOps?

Creo que es importante llevar la conversación de DevOps más allá del ámbito técnico. Participar a la cadena de negocios completa para entregar valor de extremo a extremo. Esto incluye grupos como marketing, ventas, finanzas, legales, recursos humanos y más. Involucrar a estos grupos tan pronto como sea posible en el proceso ayudará a las organizaciones a construir mejores soluciones, al tiempo que evitarán los retrasos que se suelen generar por la burocracia del propio funcionamiento de silos verticales tradicionales.

Actualización 31/05/2019: esta nota fue publicada en #Infotechnology, mi ultima nota como #CTO de #Nubiral antes de emprender www.54cuatro.com

[popup_anything id=”2076″]