los orígenes: Testing”. Espero poder aportarte los conocimientos mínimos y necesarios con este curso para que puedas ponerlo en práctica. Jose María Flores Zazo, autor
a familiarizar con los tipos de pruebas más comunes que necesitan la mayoría de las aplicaciones de hoy en día. Sobre las pruebas, ¿qué vamos a ver?: • Los principios fundamentales. • Las diferentes pruebas. Una vez que tentamos claros los conceptos principales, vamos a ver una serie de puntos que viven en torno a los test: • ¿Que diferencia existe entre Quality Assurance (QA) y Quality Control (QC)? • ¿Qué papel juega el Testing en DevOps? Toda la teoría que se presenta aquí nos ayudará para que el equipo hable el mismo lenguaje y no de lugar a equívocos, muchas veces me he encontrado que se debate innecesariamente debido a que las definiciones o la nomenclatura no es la adecuada. Shift-left Testing – “Prueba temprano y frecuente” Larry Smith 2001
en el software es eliminar posibles errores y mejorar la calidad en diversos aspectos como son el rendimiento, la experiencia de usuario (UX) y la seguridad. Antes de comenzar cualquier prueba se debe establecer una serie de pautas o principios para asegurarnos que el resultado se ajusta a los objetivos principales: • Todos los casos de prueba deben preparase basándose en los requisitos del cliente; de lo contrario estaremos probando los requisitos equivocados. Cada característica o función del sistema debe probase con uno o varios casos de pruebas. • Alguno de los tipos de prueba de software, como las de rendimiento y las de aceptación deben realizarlas expertos. Estos pueden ser: personal de QA o desarrolladores seniors. • Logicamente, planifica para probar primero las funcionalidades básicas y luego amplia estas pruebas para funcionalidades avanzadas. • Se recomienda comenzar con las pruebas en fases tempranas del proyecto ya que, en coste de corrección que cuando se relegan a fases posteriores del proyecto. Mejorar la calidad del software – Objetivo principal
Testing: el 80% de los errores son causados por el 20% de las características del sistema. Es decir, que, durante las pruebas, un gran numero de errores estarán asociados a un pequeño numero de funcionalidades. • No es recomendable repetir los mismos casos de prueba una y otra vez porque, después de cierto tiempo, no encontraremos ningun problema nuevo. La mejor práctica es ajustar los casos de prueba con el objetivo de encontrar nuevos errores. Dicho de otra forma, pasado un tiempo estos test se convertirán en simples pruebas regresivas y no ayudarán a localizar problemas de las nuevas funcionalidades. • Las pruebas dependen del contexto. Significa que tenemos que aplicar metodologías y técnicas específicas basadas en e l contexto del sistema que estamos probado, por ejemplo, probar un ERP difiere mucho de una aplicación de e-commerce.
ciclo de vida del proyecto, ya que ayudan a garantizar que un producto no contenga errores ni defectos y, del mismo modo, se verifican las funcionalidades implementadas para asegurar que se ajustan a los requisitos definidos por el cliente. Existen 2 categorías principales: • Pruebas funcionales: se utilizan para validar cada característica y funcionalidad del sistema. • Pruebas no funcionales: se usan para validar aspectos no funcionales del sistema, como, por ejemplo, el rendimiento, la usabilidad y la conformidad (compliance). Falta calidad del producto – Una de las razones principales del fracaso Funcional Unit Test Regression Test Smoke Test E2E Test UI Test Aceptance Test No Funcional Perfomance Test Stress Test Complinat Test DR Test
prueba que se realiza para probar cada función o modulo individual de un sistema. Generalmente, las realizamos los desarrolladores de .NET que trabajamos en el producto, porque requieren codificación. Se consideran pruebas de bajo nivel, ya que se centran en el comportamiento del código. En este diagrama, típico y que ya habrás visto en cientos de ocasiones podemos observar todo el ciclo de vida de pruebas y donde se integran las pruebas unitarias. Unit Test – La base, los test unitarios Aceptance Test E2E Test Integration Test Unit Test Coste del arreglo de errores/defectos
de prueba que debe realizar antes de cualquier otra de las pruebas, ya que el coste de corrección de los defectos es mayor en los niveles superiores de las pruebas. Veamos alguna de las ventajas de las pruebas unitarias: • Las pruebas unitarias nos permiten corregir los defectos de las primeras fases del ciclo de desarrollo. Esto ahorrará tiempo y costes para arreglar los mismos defectos durante la fase de aceptación. • Ayuda a documentar el codigo fuente. • Permite a los desarrolladores refactorizar el código y reutilizar las funcionalidades disponibles para eliminar cualquier redundancia. • Son esenciales para probar las dependencias cuando estamos realizando cambios. • Ayuda a reducir la complejidad del codigo. En el siguiente enlace a la documentación de Microsoft podrás ver procedimientos recomendados para tus pruebas unitarias, así como las herramientas recomendadas (xUnit, Nunit y MSTest): https://docs.microsoft.com/es-es/dotnet/core/testing/unit-testing-best-practices
probar dos o más módulos de una solución para verificar si funcionan bien juntos. Por ejemplo, puedes probar si la autenticación de tu aplicación enlaza correctamente con Azure Active Directory o bien probar si la función de ventas se integra bien con la función de generación de la factura o probar si la capa de servicio se integra correctamente con la capa de datos. Las pruebas de integración se deben realizar después de completar el desarrollo de los modulos que están sujetos a las pruebas que estamos realizando. Veámoslo mejor con el siguiente diagrama donde podemos observar que las pruebas van dirigidas únicamente a la parte de integración entre el Módulo A y Módulo B: Integration Test – La integración Módulo A Módulo B Test de Integración
test de integración: • Ayuda a garantizar que los modulos integrados funcionen tal y como se esperaba. • Permite simular la transición entre varios módulos del sistema. • Ayuda a detectar los errores que pueden producirse en la interacción de los modulos. Tienes varias aproximaciones que nos ofrecen algun beneficios más concreto: • Big-Bang, solo se puede ejecutar cuando se envia el software final al equipo de pruebas, ya que se prueban todas las unidades o métodos de una sola vez. • Top-Down, vas probando la capa más externa para llegar a la más interna. • Bottom-Up, donde primero probamos los niveles inferiores para llegar al superior. • Hibrida, es una combinación entre Top-Down y Bottom-Up.
cambios funcionen, sin embargo, es no es suficiente, ya que, en la mayoría de los casos, el código que añadimos o cambiamos tendrá un impacto directo o indirecto en otras funcionalidades, y probablemente también en cosas que ni te imaginas. Por eso, es obligatorio realizar pruebas de regresión, nos asegurará que el nuevo ciclo no a causado ningun problema. A continuación, os muestro los tres pasos principales en las pruebas de regresión: Regression Test – Todo continúa funcionando con los test de regresión Test de Regresión Probar todo Escoger que test pasar Priorizar casos de prueba
nos ayuda a verificar la integridad. • Escoger que test pasar, se usa en detrimento de probar todo, ya que es menos costosa y puedes elegir subconjuntos de cada elemento, minimizar el probar todo. • Priorizar casos de prueba, es una forma de ordenar que test han de pasarse primero, si un test es muy imporante que lo pase, para ¿que pasar primero unos más básicos?. Por ejemplo, podrás dar una prioridad especifica para la version, es decir, probar primero lo nuevo y luego lo que no cambió. Alguno de los beneficios que nos dan estos test: • Garantizan que las características existentes permanezcan intactas en caso de un cambio en un módulo o del código. • Las pruebas de regresión automatizadas ayudaran que podamos implementar Integración Continua (CI). • Permite detectar defectos causados por los cambios en el sistema. • Aumenta la confianza y satisfacción de los clientes, lo que siempre es bueno para el negocio.
software, estas pruebas se usan para verificar la funcionalidad básica de una compilación. Si una prueba falla, la compilación se considera inestable, y el sistema no esta listo para realizar ninguna otra actividad. Este diagrama nos ayudar a entenderlo mejor: Smoke Test – Usado antiguamente en fontanería, donde el humo blando detectaba fugas Version 1.0 Priorizar casos de test Ejecutar test de humo Test funcionales El equipo de desarrollo debe arreglar los errores Pasa Falla
la prueba, al construir una versión. Después, tenemos que priorizar los casos de prueba y decidir que probar exactamente, para certificar que la nueva version puede ir a la fase de pruebas funcionales. Si las pruebas de humo fallan, hay que corregir los problemas y volver a empezar, construir una nueva build. Alguna de las ventajas de los test de humo: • Ayuda a detectar los problemas importantes en las etapas tempranas antes de comenzar con cualquier otro tipo de prueba. • Mejora la eficiencia de QA mediante la detección de problemas que en las pruebas funcionales tararían más en ser detectados.
una aplicación, de extremo a extremo. Es normal y conveniente probar las funcionalidades de todo el sistema; es imporante replicar el entorno de producción para llevar a cabo este tipo de pruebas, y los escenarios de prueba deben imitar el comportamiento del usuario. El objetivo de este tipo de pruebas es certificar que los diferentes flujos de usuario funcionan correctamente, sin errores y de acuerdo a los requisitos. El diagrama, muestra los tres pasos fundamentales de las pruebas E2E: End-2-End / E2E – End-2-End, nos acercamos a la cúspide de la pirámide Funciones de Usuario Condiciones basadas en funciones de usuario Crear casos de test
realizadas en una determinada funcionalidad del sistema, las condiciones representan los diversos datos de entrada y la secuencia que pueden aplicarse en cada función de usuario. En cuanto a los casos de prueba, se crean basándose en las dos acciones anteriores, es decir, las funciones de usuario junto con las condiciones. Alguna de las ventajas de un test E2E: • Ayuda a garantizar la salud del sistema. • Permite probar el sistema completo, desde la perspectiva del usuario. • Ayuda a probar escenarios reales que pueden ser aplicados por los usuarios finales.
mismo. Vamos a probar que el GUI (la interface gráfica) de la aplicación. Con estos test nos vamos a asegurar que se desarrolla dehacuerdo a los requisitos y que es fácil de usar. Veamos en que capa se encuentran pruebas: UI Test –User Interface, de interface de usuario Interface de usuario Capa de negocio Capa de datos Capa de almacenamiento Test unitarios Tes de Interface de usuario
• Ayuda a comprobar el diseño de la aplicación: fuentes, alineaciones, colores, etc. • Nos permite comprobar si el producto se representa adecuadamente en el dispositivo o pantallas compatibles. • Ayuda a comprobar los mensajes de error y advertencia. • Nos ayuda a ver si el comportamiento y resilencia de la aplicación, es el adecuado.
las pruebas y suelen ser realizadas por usuarios claves del cliente para que verifique que todos los requisitos empresariales se han desarrollado, que el sistema funciona correctamente, tal y como los usuarios finales esperan. Normalmente, las pruebas de aceptación se realizan basadas en casos de prueba que se generan a partir de los casos de usuarios durante la fase de análisis de un proyecto. El siguiente diagrama, muestra UAT como la última fase antes de pasar a un entorno productivo: Alguno de los beneficios de usar UAT: • Ayuda a validar que todos los requisitos de negocio definidos al principio del proyecto se implementan correctamente y funcionan sin errores. • Permite corregir errores en entornos de desarrollo y no en producción. • Ayuda a aumentar la confianza de los usuarios en el nuevo sistema antes de la puesta en marcha. Acceptance Testing – A veces conocido como User Acceptance Test o UAT Desarrollo QA UAT Producción Funcional (13/13) Testing
requisitos de rendimiento definidos por el cliente y las bases que nos hemos marcado. Al realizar las pruebas de rendimiento se tienen en cuenta cuatro elementos principales si estamos trabajando con un API: • Los cuellos de botella, problemas que pueden hacer que un sistema se caiga. • El tiempo de carga necesario para una página o formulario. • El tiempo de respuesta para activar una acción o completar un proceso. • La escalabilidad para manejar un numero grande de respuestas. Nos ayuda a: • Medir el tiempo de respuesta, precisión y estabilidad de un sistema. • Detectar problemas que reducen el tiempo de respuesta de la aplicación. • Mejora el tiempo de carga de una página y aumentar la satisfacción del usuario Perfomance Testing – Un test que pocas veces veo Cuellos de botella Tiempos de carga Escalabilidad Tiempos de respuesta No Funcional (1/5) Testing
sistema. Siendo su objetivo principal medir la resistencia y capacidad cuando se somete un sistema a una carga extremadamente pesada (cientos de miles de request por segundo) que van más allá de la situación normal del funcionamiento del sistema. Su propositivo es comprender como se comporta un sistema con una carga muy pesada. Inicialmente una prueba de stress comienza con la planificación y decisión de los casos de test. Después, creamos scripts y ejecutamos automáticamente. Arrojando unos resultados que nos permitirán identificar la raíz de un problema. Tras testo, corregimos el problema ya sea optimizando codigo o aumentando recursos y volvemos a ejecutar el proceso para ver si hemos estabilizado la version. Ventajas: • Nos permite comprobar y manejar los errores que se producen en estas situaciones. • A comprobar que los datos continúen siendo consistentes antes de un problema de stress. Stress Testing – Lleva al limite y más allá a tu sistema Planificar los test de stress Crear script automatización Ejecutar scripts Analizar resultados Optimizar y mejorar No Funcional (2/5) Testing
auditoria técnica que suele realizarse para verificar que un producto cumple una serie de normas externas e internas antes de decidir si el sistema esta listo para ser lanzado o no. Las normas internas suelen ser establecidas por la organización, por ejemplo: un sitio web debe estar diseñador para varios tipos de pantallas y dispositivos, por tanto, deben ofrecer una interface responsibe. Mientras que los estándares externos, son normas establecidas por un consorcio mundial u organización de terceros que se especializa en este tipo de pruebas. Un ejemplo son la GDRP o las reglas de accesibilidad WCAG o de seguridad en pagos con tarjeta PCI. Atributos que suelen medirse con este tipo de pruebas: Compliance Test – Tambien conocidos como conformance testing Robustez Rendimiento Interoperatividad Funciones Comportamiento del sistema
atributo contribuye al cumplimiento del sistema. Y a continuación desarrollo un poco los conceptos: • Robustez, muestra la capacidad de un sistema de funcionar con normalidad en caso de perturbación. • Rendimiento, representa el tiempo que necesita el sistema para realizar una sola tarea. • Interoperatividad, muestra la capacidad de intercambio de información con terceros. Además de medir lo bien que interactúa con las distintas fases del sistema para cumplir el proceso. • Funciones, evalúa interfaces y funcionalidades del sistema y confirma si cumple los requisitos de las primeras fases. • Comportamiento del sistema, evalúa el comportamiento del entorno que lo aloja. Tambien evalúa como se comporta el sistema después de ejecutar cada user story definida previamente.
DRP (disaster revovery plan). Consiste en un conjunto de directrices y estrategias detalladas que deben hacer frente a incidentes imprevistos que puedan interrumpir el funcionamiento normal de un sistema. Un buen DRP debe permitir recuperar rápidamente ante eventos perturbadores, ya sean ciberataques, cortes de energía, rotura del hardware o cualquier otro incidente que se te ocurra. Debe poder garantizar la continuidad de los procesos de negocio y minimizar los datos en la medida de lo posible. Los test de DR es el proceso que nos permiten identificar un DRP mediante la evaluación de cada paso del proceso para asegurar que funcionará de la forma esperada cuando se produzca un incidente. DR testing – Disaster recovery testing No Funcional (5/5) Testing
lo que es lo mismo en español: diferencias entre la garantía de calidad (QA) y control de calidad (QC). Es un termino relativamente nuevo en el software y muchas personas confunden QC con QA. Los nombres son parecidos, pero se refieren a partes el proceso muy diferenciadas, si ya añades que QA se basa mucho en el feedback que da QC, terminamos por liar más la madeja. QA & QC –Qualilty Assurance & Quality Control QA QC Se diseñan y definen los parámetros de aceptación de un software Se controla el comportamiento final del producto Es un sistema de PREVENCIÓN de fallos y se generan medidas correctivas para evitar salidas a producción Es un sistema de CORRECIÓN de fallos e introducción de mejoras Los QA son cada miembro del equipo involucrado en el desarrollo de producto, desde el desarrollador, pasando por el manager y clientes El departamento de QC trabaja junto a QA. Siendo un equipo totalmente independiente Presente desde la fase 0, por eso los desarrolladores son los que inician la mecha del QA QC entra en el terreno de juego cuando el producto esta finalizado QA esta orientado al proceso QC orientado al producto QA se asegura de que siguen el mismo estándar de calidad y se realizan auditorias desde un punto de vista proactivo QC se asegura de que el producto funcione de la forma esperada. Se orientan a la reactividad: identificar y corregir QA se diseña y ejecuta antes de terminar el producto QC se ejecuta durante la puesta a preproducción Se ejecuta todo el WHITE BOX TESTING que van desde los Unit Test hasta los Acceptance Test Pruebas no funcionales: perfomance, stress, pruebas realizadas por humanos, … es decir, se ejecutan el BACK BOX TESTING
confusión que generan estos conceptos de QA y QC es muy grande. Espero que la tabla lo dilapidará para la mayoría. Los tecnicos de QC solo necesitan saber como funciona el producto o, mejor dicho, como debería funcionar el producto y están orientados al cliente. Por eso anteriormente he dicho que un buen candidato a QA pueden ser desarrolladores senior, pero si son personas especializadas dentro del equipo de desarrollo su tarea será completar pruebas que los desarrolladores no han podido completar por falta de tiempo o debido a que el numero de test es suficiente pero no necesario (tu organización puede exigirte un Code Coverage del 99,00% que has de alcanzar), pero en este caso, la falta de contexto del desarrollo inicial puede verse como una ventaja (no esta condicionado ya que no es su desarrollo) o desventaja (ralentiza tener que explicar la funcionalidad por parte del desarrollador anterior) y para ellos existen otras tecnicas como programación colaborativa, pero lo que indudablemente aporta una pieza del equipo como QA es velar por la estandarización y normativa. Para terminar, la ISO 9000 en la clausula 3.2.10 define control de calidad como: una parte de la gestión de calidad enfocada a cumplir con los requisitos de calidad; mientras que la clausula 3.2.11 define la garantía de calidad como: una parte de la gestión de calidad centrada en proporcionar confianza en que se cumplirán los requisitos de calidad. Si quieres ampliar más información sobre la ISO 9000 y profundizar en los fundamentos y vocabulario puedes acceder al siguiente enlace: https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:es
si conoces DevOps, conoces de sobra estos diagramas: Pero más allá de esto voy a comentar donde debe entrar en juego cada tipo de test dentro de un ciclo estandar de Azure DevOps, muy a grandes rasgos para que puedas implementar un mínimo calidad en tu software. DevOps – Mejora continua
la Integración de codigo Establece una PR donde se pasen los Unit Test, Integration Test, Code Coverage (este termino genera mucha controversia) y un control estático del codigo fuente via herramientas como SonarCloud, lograrán que la integración del codigo no contenga ningun problema que aflore en fases futuras. Tambien es buena práctica hacer Regression Test, ya que puede ahorrar en la introducción de inestabilidades en el codigo. Y otras acciones que seguro has podido poner en práctica; aquí solo os muestro la punta del iceberg. Durante el despliegue Esta claro que pasar test, como hemos visto en UAT, durante la promoción de tu funcionalidad en diversos entornos, nos ayuda a que minimizar una llegada a producción con problemas. Existe todo un mundo asociado a como minimizar riesgos en un despliegue en producción usando técnicas como Canary Testing, A/B Testing, Blue-Green deployments, que requeriría un documento a parte. Si te interesa, puedes ir a este video de introducción de 30 min : https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/THR2155
jmfloreszazo
ishikawa_satoru
sinsoku
ronnnnn
miu_crescent
tsumita
tenshoku_draft
rrreeeyyy
chou500
oracle4engineer
koichiotomo
ryosukeigarashi
lmi
kneath
jrom
addyosmani
maltzj
chriscoyier
tammyeverts
tanoku
yeseniaperezcruz
samlambert
brianwarren
colly
swwweet
