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

DevSecOps, el camino al desarrollo seguro

Si DevOps te parece bueno, DevSecOps te parecerá mejor

El año pasado hubo un gran crecimiento en la adopción de #DevOps en Latinoamérica, pero aun estamos lejos de modelos como los de EEUU y Europa.

Accelerate: State of DevOps 2019

#DevSecOps viene a llenar el hueco que existe en los controles de Seguridad al momento de desarrollar un software. Y tal como DevOps, es una practica de ingeniería de software que tiene como objetivo unificar el desarrollo de software y la operación del software, Sec aparece entre medio de ellos para lograr que cada implementación salga con un nivel base de seguridad alto.

Como las siglas lo indican, se realiza el desarrollo (Dev), se ejecutan los controles de seguridad (Sec) y por último se realiza la implementación (Ops), todo de forma automatizada, claro está.

Es por eso que herramientas como a raxisSonarqubeFortifyKiuwanCrucible son tan importantes para el proceso de revisión de código.

En las cadenas automatizadas CI/CD, lo que hacemos posterior a desarrollar es ejecutar controles en cualquier herramienta de Revisión y en caso de que dicho control no sea satisfactorio paramos el build (proceso de construcción), regresando a su fase anterior para la revisión y mitigación por parte de desarrollo.

Hacking Continuo?

La inmensa cantidad de desarrollos que se realizan de manera evolutiva en un codigo fuente hacen necesario tener una inmensa cantidad de test y controles. Es por ello que el proceso de control de seguridad, conocido como #PenTest debe efectuarse de forma continua, para evitar quedar expuesto a riesgos por el tiempo que pasa entre un proceso de pentesting y otro.

En DevSecOps la seguridad es responsabilidad de todos, y es por eso que nos parece tan importante.


Contactate

Categories
54cuatro

SRE: Observabilidad y Monitoreo

Nota publicada originalmente por el CTO de #54cuatro en Linkedin.

La #observabilidad es una característica dentro de un sistema de control que permite dar con una solución prediseñada a un problema que surja. Dentro del mundo TI, la observabilidad de un sistema permite evaluar resultados para llegar a conclusiones sobre los estados de un recurso.

Si bien han surgido distintos puntos de vista sobre la definición, a partir de la masificación de #DevOps (y #SRE), el crecimiento de las instalaciones #Cloud, el uso intensivo que hacen las plataformas de #bigdata y la adopción de #Contenedores, la observabilidad se volvió una palabra en constante crecimiento.

A diferencia de las actividades de monitoreo tradicionales, donde el objetivo es “observar” el estado, la salud y #performance de #Redes, #Servidores, #Servicios, #Redes, Aplicaciones, etc para luego tomar acciones, la observabilidad podriamos definirla como un componente mas del diseño de una aplicación que permite tener en cuenta todos los elementos de la misma para saber como monitorearlas y operarlas.

Al igual que el análisis de la seguridad en nuevos desarrollos (#DevSecOps), es de esperar que también se realicen los diseños de monitoreo de los componentes en etapas tempranas de la construcción del software y no al momento de la implementación.

Sin ir a mas, en el sitio de SRE de Google, indican que la operación exitosa de un servicio implica una amplia gama de actividades: desarrollar sistemas de monitoreo, capacidad de planificación, responder a incidentes, asegurar que se aborden las causas fundamentales de las interrupciones, y ponen esta pirámide que permite ver los elementos que intervienen para hacer que un servicio sea confiable, desde el más básico hasta el más avanzado.

No hay texto alternativo para esta imagen

Diseñar y desarrollar aplicaciones “observables” permite ser proactivo y prever los posibles puntos de fallas, con el objetivo de lograr rápidas recuperaciones ante fallos y administrar de forma eficiente el capacity planning y junto a ello la performance.

Podemos pensar un sistema observable a partir del control de todas las partes, conociendo como se desarrolló, como estará montado y como se comportará, podremos definir el monitoreo horizontal (servidores, redes, transacciones, logs) y el monitoreo vertical (experiencia de usuario, tracing, debug) mas acorde. El Monitoreo y la Observabilidad son cosas diferentes y también complementarios.

De hecho, el concepto de observabilidad no tiene que estar ligado al incidente. Una aplicación observable puede reportar datos que permitan mejorar la arquitectura, la performance, el escalamiento automático sin la necesidad que haya un perjuicio o incidencia dentro de la plataforma.

Para ir finalizando, podemos decir que debemos de adoptar una estrategia que consista en diseñar aplicaciones observables desde su nacimiento, diseñando de que manera vamos a controlar y monitorear la nueva aplicación, entendiendo que componentes vamos a usar y cuales son las mejores métodos y/o herramientas para respaldas la salud de esas aplicaciones; de allí el nacimiento de grandes conjuntos de tools que funcionan muy bien juntas. Se me vienen a la cabeza soluciones basadas en #ELK, en #Influx o la dupla #Prometheus y #Grafana, básicamente Prometheus recopila datos y métricas de diferentes servicios y los almacena de acuerdo con un identificador único, el nombre de la métrica, y una marca de tiempo (en una base time series) y Grafana se encarga de realizar hermosos dashboards donde mirar dicha información. Toda esta informacion puede ser “cruzada” con aquellos datos adicionales que tengamos configurada en nueva navaja suiza del monitoreo como las experiencias de los usuarios y con toda la correlación de los eventos determinar que todos los servicios de monitoreo estén vivos y saludables.

Video de Monitoreo de Infra

No hay texto alternativo para esta imagen

Video de Monitoreo #Netflow

Como siempre… Gracias por leerme! Hasta la próxima!

Contactate

    Por favor, demuestra que eres humano mediante la selección la taza.