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

Diseño y Desarrollo de Aplicaciones aplicando SOLID

Si hablamos de diseño y desarrollo de #aplicaciones, Cuando mencionamos el principios #SOLID nos referimos a un acrónimo con 5 definiciones que nos ayudan a determinar los patrones de la #arquitectura y el #desarrollo de #software.

Los 5 principios SOLID

Los objetivos de estos 5 principios a la hora de escribir código son los de crear un software que cumpla con el objetivo por el cual fue creado y que sea robusto y estable. El código debe ser limpio y fácil de mantener. El código debe ser reutilizable y mantenible, de manera que puedan incorporarse cambios, nuevas funciones y mejoras de manera ágil. Los 5 principios son:

  • S – Single Responsibility Principle (SRP)
  • O – Open/Closed Principle (OCP)
  • L – Liskov Substitution Principle (LSP)
  • I – Interface Segregation Principle (ISP)
  • D – Dependency Inversion Principle (DIP)

Principio de Responsabilidad Única

La primera letra del acrónimo. Es el principio más importante. La responsabilidad única refiere a la definición teórica que indica que “una clase debería tener una, y solo una, razón para cambiar”, es decir que cada clase que definamos debe tener una única responsabilidad. Si nos encontramos que para agregar una nueva funcionalidad debemos modificar más de una clase o que nuestro software tiene muchas relaciones entre sus clases, evidentemente no estamos cumpliendo este principio.

Principio Abierto/Cerrado

En este principio, se entiende que una entidad de software (clase, módulo, función, etc)  deberían estar abiertas para poder extenderse (lo que significa que una entidad de software debe poder adaptarse a los cambios y nuevas necesidades) y cerradas para modificarse (significa que la adaptabilidad de la entidad se da como resultado de un diseño que facilite la extensión sin modificaciones, no por modificaciones realizadas en el core de dicha entidad)

Principio de Sustitución de Liskov

En el punto 3, se da nombre a este principio gracias a Barbara Liskov, la primera ingeniera en lograr el doctorado en Ciencias de la Computación. El principio de Liskov brinda pautas para trabajar con la herencia entre clases. La principal que debe cumplir si estamos realizando la herencia de una manera correcta es que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. Los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema.

Principio de Segregación de la Interfaz

En este método se hace hincapié, en hacer interfaces específicas, es decir, tener interfaces con pocos métodos para finalidades concretas. Las interfaces nos dan una capa de abstracción que nos ayudan a desacoplar módulos; por lo tanto la interfaz es lo que nos da el comportamiento que nuestro código espera para comunicarse con otros módulos a través de métodos y propiedades.

Principio de inversión de dependencias

Último de los principios de SOLID. En este último punto, se especifica cómo deben ser las relaciones entre componentes para evitar el acoplamiento entre los módulos de un software, lo que busca reducir las dependencias entre los módulos del código para lograr un bajo acoplamiento de las clases.

Conclusión

SOLID tiene muchos detractores que suelen indicar entre sus criticas que solo toma algunos principios muy generales para un buen diseño de software de programación orientada a objetos y luego les coloca etiquetas.

Los principios SOLID son una guía de buenas prácticas, que están relacionados entre sí de forma muy estrecha y que al aplicarlos en nuestros desarrollos facilitan la creación de un código limpio, con menor acoplamiento, más flexible, más estable y más fácil de mantener.


Contactate
Categories
54cuatro

DevOps – Los desarrolladores están en el centro de la innovación

No solo sus competidores tradicionales lo reconocen: hay nuevos competidores que comienzan a lanzar #software innovador, trabajando dentro de su sector, pero al revés.

¿Usted elegiría software creado por un puñado de desarrolladores aislados o software creado por miles de personas que trabajan en colaboración para construir algo más sólido? 

Innove a gran escala. Confíe en lo que entrega.

Microsoft #Azure es la nube con servicios de desarrollador integrados y #GitHub construye sobre esta base para convertirse en la Plataforma #DevOps central de #Microsoft.

Aproveche Microsoft DevOps con GitHub para entregar innovación rápida y eficiente. ​

Innovación de producto

Herramientas de administración confiables y escalables en todos los niveles, además de una comunidad diversa detrás de todo

Rapidez de entrega

Para innovar, las empresas deben moverse rápidamente.

Flexibilidad y control

Cualquier desarrollador, cualquier #nube. Use las herramientas que elija, solo traiga el código.

Seguridad

Un líder confiable en seguridad, el mejor.

Acelere la entrega con #DevOps.

Su producto necesita llegar rápidamente a los clientes
y mantenerse disponible.

  • Objetivos y herramientas compartidos
  • Colaboración
  • Automatización de procesos
  • Entrega y mejora continuas

Implementación continua y conforme con la normativa

Servicios integrados de #seguridad, #monitoreo y administración de nivel empresarial

GitHub: El desarrollador de plataformas
nro 1 en el planeta

  • Mayores contribuciones: 1,100 millones en 2018
  • Más desarrolladores: 33 millones
  • Mayor crecimiento: 8 millones de nuevos desarrolladores en 2018
  • Más Repos: 96 millones
  • Mayor actividad: 200 millones de PR, 800 millones de solicitudes diarias de #API 
  • Más estudiantes: 1.1 millones
  • Más organizaciones: 2.2 millones
  • Mayor seguridad: 5 millones de alertas de vulnerabilidad en 2018

Desea crear su plan de desarrollo para implementar DevOps, contactenos

Contactate

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