![\"Imagen](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2022\/12\/diferencias-testing-funcional-performance-software-1024x683.jpg\")
<\/figure><\/div>\n\n\nAntes de adentrarnos en los caracter\u00edsticas y diferencias entre las pruebas funcionales y no funcionales<\/strong>, es importante destacar que ambos tipos de testing son necesarios para la creaci\u00f3n de software de calidad. Se enfocan en aspectos diferentes, pero en definitiva son complementarios.<\/p>\n\n\n\n Las pruebas funcionales se ocupan de verificar que el sistema y sus funcionalidades se ejecuten como se espera y para lo cual fueron desarrollados.<\/strong><\/p>\n\n\n\n \u201cBaj\u00e1ndolo un poco a tierra, en un sistema web como por ejemplo una tienda online es fundamental que el usuario sea capaz de realizar las compras, ya que es lo que le da sustento al negocio. Para ello, se precisa realizar testing funcional, con foco en verificar que el flujo de compra cumpla su objetivo, su funcionalidad\u201d<\/p>\nAlejandro Aires, tester de software en Abstracta y miembro del equipo de performance<\/cite><\/blockquote>\n\n\n\n Las pruebas no funcionales, por su lado, se enfocan en factores transversales, relacionados con la experiencia de uso del usuario.<\/strong> Algunos ejemplos de ello son la usabilidad, seguridad<\/a>, accesibilidad<\/a> y performance<\/a>.<\/p>\n\n\n\n Alejandro Aires propuso un ejemplo para lograr figurar mejor la tem\u00e1tica: \u201cSupongamos que estamos probando realizar una transferencia bancaria. Las pruebas funcionales se encargan de probar que la transferencia se haga bajo los requisitos previamente establecidos (que llegue al destino correcto, con el monto correcto, etc.), mientras que el no funcional puede verificar otras cuestiones, como que el sistema soporte muchas transacciones simult\u00e1neas o que sea amigable para el usuario\u201d.<\/p>\n\n\n\n Hay otro caso interesante para analizar, que es el del airbag. Si un airbag no funciona r\u00e1pido, con buena performance, entonces no cumple su funcionalidad. Ejemplos como este son los que hacen que la separaci\u00f3n no sea tan clara en algunos casos.<\/p>\n\n\n\n Otra diferencia se encuentra en los requisitos para comenzar con las pruebas. <\/strong>\u201cPor lo general, las pruebas no funcionales suelen requerir que el sistema tenga cierta estabilidad, es decir que ya se haya avanzado con las pruebas y ajustes funcionales\u201d, especific\u00f3 Alejandro. \u201cA\u00fan as\u00ed, esto depende del sistema, no siempre es de ese modo\u201d, a\u00f1adi\u00f3.<\/p>\n\n\n\n En definitiva, se trata de pruebas que se complementan en busca de incrementar la calidad desde una visi\u00f3n hol\u00edstica, teniendo en cuenta distintos factores de calidad.<\/strong><\/p>\n\n\n Existen muchos enfoques y clasificaciones. Por ejemplo, podr\u00edamos comenzar hablando de pruebas exploratorias o planificado (o guionado, scripted <\/em>en Ingl\u00e9s). Existen distintas t\u00e9cnicas de testing funcional para dise\u00f1ar casos o datos de prueba relevantes, que pueden ser utilizadas tanto en un enfoque exploratorio como en uno guionado, pero por lo general se las asocia m\u00e1s con el guionado ya que se les suele llamar t\u00e9cnicas para dise\u00f1ar casos de prueba.<\/p>\n\n\n\n La particularidad del testing exploratorio<\/a> es que presenta una estructura externa que es sencilla de describir, en la que durante un lapso de tiempo preestablecido (de no m\u00e1s de dos horas) el tester interact\u00faa con un producto para cumplir con el objetivo de una misi\u00f3n. El objetivo de esto es poder luego presentar y reportar los resultados del proceso, los cuales ser\u00e1n utilizados por el resto de los integrantes del proyecto para tomar decisiones a conciencia.<\/p>\n\n\n\n Por otra parte, podemos clasificar seg\u00fan el nivel al que realizamos las pruebas o el momento en el ciclo de desarrollo. As\u00ed es que podemos distinguir entre pruebas unitarias, pruebas de componentes, pruebas de humo, pruebas de integraci\u00f3n, pruebas de sistemas, de regresi\u00f3n, pruebas de aceptaci\u00f3n del usuario y m\u00e1s. Me enfocar\u00e9 aqu\u00ed en algunas de ellas:<\/p>\n\n\n\n En otras palabras, y en l\u00ednea con el punto previo, si queremos verificar que las integraciones que realizamos no hayan afectado otra funcionalidad previamente testeada, necesitamos realizar pruebas de <\/strong>regresi\u00f3n<\/a>. Adem\u00e1s, son pruebas muy relevantes para verificar que lo que antes andaba bien ahora siga funcionando.<\/p>\n\n\n\n Hay muchas. Existen t\u00e9cnicas muy conocidas tales como particiones de equivalencia, valores l\u00edmites, combinaciones por pares o tablas de decisi\u00f3n. Tambi\u00e9n existen t\u00e9cnicas m\u00e1s avanzadas como la que implica el uso de m\u00e1quinas de estado.<\/p>\n\n\n\n En lugar de entrar a detallar estas t\u00e9cnicas, que para ello pueden revisar el libro de Federico Toledo<\/a>, quisiera distinguir c\u00f3mo se clasifican, con base en distintos criterios, viendo as\u00ed de qu\u00e9 se tratan los enfoques de caja blanca y caja negra, los casos de prueba espec\u00edficos y abstractos, y el enfoque de pruebas dirigidas por datos.<\/p>\n\n\n\n Si para dise\u00f1ar las pruebas nos basamos en informaci\u00f3n interna del sistema que estamos probando, tal como el c\u00f3digo, esquema de base de datos, etc., entonces se dice que estamos siguiendo una estrategia de pruebas<\/a> de caja blanca. Lo m\u00e1s com\u00fan es basar el dise\u00f1o en el c\u00f3digo fuente para lograr determinados niveles de cobertura<\/a>. Para entender esto, podemos decir que el m\u00e1s simple de estos niveles implicar\u00eda intentar cubrir todas las l\u00edneas de c\u00f3digo.<\/p>\n\n\n\n A veces, algunas personas hablan de \u201ccaja transparente\u201d en lugar de caja blanca. Esto hace referencia a que el objetivo de esta estrategia es poder mirar qu\u00e9 hay dentro de esa caja que estamos probando.<\/p>\n\n\n\n Contrariamente a caja blanca, la expresi\u00f3n \u201ccaja negra\u201d se refiere a que el sistema es una caja cuyo interior no puede ser observado desde afuera. En este modo de trabajo, nos basamos \u00fanicamente en la observaci\u00f3n de entradas y salidas del sistema. Esto puede ser a nivel de sistema, unidad, componente, API, etc.<\/p>\n\n\n\n Podr\u00edamos decir que con caja blanca nos preocupamos por lo que pasa dentro de la caja y con caja negra nos preocupamos por lo que pasa fuera de ella. Muchas veces el l\u00edmite no est\u00e1 claro, o tal vez estamos siguiendo un enfoque de caja negra, pero como sabemos algo de lo que sucede dentro entonces aprovechamos esa informaci\u00f3n. En este sentido, hay quienes hablan tambi\u00e9n de \u201ccaja gris\u201d, que es justamente cuando se combinan ambos enfoques.<\/p>\n\n\n\n Se trata de una clasificaci\u00f3n que refiere a la especificidad con la que est\u00e1 detallado el caso de prueba.<\/p>\n\n\n\n Un caso de prueba abstracto se caracteriza por no tener determinados los valores para las entradas y salidas esperadas, por lo cual se utilizan variables y se describen con operadores l\u00f3gicos ciertas propiedades que deben cumplir.<\/p>\n\n\n\n Un caso de prueba espec\u00edfico es una instancia de un caso de prueba abstracto, en la que se determinan valores espec\u00edficos para cada variable de entrada y para cada salida esperada. No es lo mismo especificar un caso de prueba donde se agrega un producto de valor mayor a 1000 pesos al carrito de compra a indicar espec\u00edficamente que se debe agregar el producto de identificador XYZ, que ya se sabe que tiene un costo establecido mayor a 1000 pesos.<\/p>\n\n\n\n Cada caso de prueba abstracto puede ser instanciado con distintos valores (siguiendo el ejemplo, con cualquier producto que vale m\u00e1s de 1000 pesos), por lo que podr\u00e1 haber distintos casos de prueba espec\u00edficos al momento de ser ejecutado o dise\u00f1ado a bajo nivel. Se asigna un valor concreto a cada variable, tanto de entrada como de salida, de acuerdo a las propiedades y restricciones l\u00f3gicas que tiene determinadas.<\/p>\n\n\n\n El Data-Driven Testing<\/em> es una t\u00e9cnica para construir casos de prueba, en la cual b\u00e1sicamente se separan los datos de entrada y salida del flujo que se ejecuta en la aplicaci\u00f3n<\/strong>. Dicho de otra manera, se parametrizan los casos de prueba. Para ello, se representa el flujo, una serie de pasos para ejecutar el caso de prueba, y se almacenan los datos de entrada y salida esperados en una fuente t\u00edpicamente externa (en un archivo csv, planilla, base de datos).<\/p>\n\n\n\n Esto permite agregar nuevos casos de prueba f\u00e1cilmente, mediante el ingreso de nuevos datos de entrada y de salida esperados que sirvan para ejecutar el mismo flujo.<\/p>\n\n\n\n El flujo de la aplicaci\u00f3n se define con casos de prueba abstractos, que al momento de ser ejecutados con un juego espec\u00edfico de datos se convierten de alguna manera en casos de prueba espec\u00edficos.<\/p>\n\n\n\n Cada tipo de pruebas se asocia a un factor de calidad<\/a>. Algunos de los tipos de pruebas m\u00e1s destacados son:<\/p>\n\n\n\n Las pruebas de usabilidad<\/a> eval\u00faan el grado en que el sistema puede ser utilizado por usuarios espec\u00edficos con efectividad, eficiencia y satisfacci\u00f3n en un contexto de uso espec\u00edfico. Existen varias t\u00e9cnicas para analizar la usabilidad, las cuales buscan detectar mejoras posibles en caracter\u00edsticas asociadas a la experiencia de usuario, como por ejemplo que un sistema sea m\u00e1s intuitivo y f\u00e1cil de utilizar, entre otras cosas.<\/p>\n\n\n\n Es parte de las pruebas de usabilidad, pero su foco es que todas las personas puedan utilizar el sistema, incluso a quienes tienen alg\u00fan tipo de discapacidad, contextual, temporal o permanente.<\/p>\n\n\n\n Las pruebas de accesibilidad<\/a> ayudan a detectar los errores y barreras que pueden existir en el software, pero que no son f\u00e1cilmente detectables si no se realizan pruebas espec\u00edficas para encontrarlas. Las personas expertas en accesibilidad hablan de la importancia de la incorporaci\u00f3n de la accesibilidad en todo el ciclo de vida del desarrollo de software.<\/p>\n\n\n\n Te puede interesar: Testing de software e Inteligencia Artificial, claves para el futuro de la accesibilidad digital<\/a>.<\/p>\n\n\n\n El objetivo de las pruebas de seguridad<\/a> es buscar posibles vulnerabilidades o amenazas que puedan afectar la protecci\u00f3n, disponibilidad e integridad de los datos o la funcionalidad del sistema. El testing de seguridad es importante como mecanismo preventivo, en b\u00fasqueda de posibles vulnerabilidades<\/strong>.<\/p>\n\n\n\n De todos modos, no es posible prevenir todo y es crucial contar con protocolos espec\u00edficos para ser utilizados ante eventuales ataques inform\u00e1ticos.<\/p>\n\n\n\n Seg\u00fan el Informe de Riesgos Globales 2022<\/a> del Foro Econ\u00f3mico Mundial, el malware aument\u00f3 un 358% en 2020, mientras que el ransomware se increment\u00f3 en un 435%.<\/p>\n\n\n\n En las pruebas de performance se analizan tanto los tiempos de respuesta como el consumo de recursos. Para ello, se simulan m\u00faltiples usuarios concurrentes y se analiza el rendimiento de la aplicaci\u00f3n bajo prueba. Cuanto m\u00e1s expuesta, m\u00e1s usuarios y variables haya en torno a una aplicaci\u00f3n, m\u00e1s importante se hace realizar pruebas de performance<\/a>.<\/p>\n\n\n\n Para analizar estos comportamientos, se suele poner al sistema bajo una gran cantidad de usuarios en concurrencia mientras se mide el uso de recursos en b\u00fasqueda de cuellos de botella. Dentro de esta categor\u00eda, podemos encontrar pruebas de carga, volumen y estr\u00e9s entre otras.<\/p>\n\n\n\n Para concluir, nuestro COO Federico Toledo sostuvo que lo ideal es siempre dise\u00f1ar una estrategia<\/a> de pruebas en la que se combinen ambos tipos de testing desde fases tempranas (Shift Left Testing<\/a><\/em>), trabajarlas en todo el proceso (testing continuo), monitorear en producci\u00f3n, y usar esa informaci\u00f3n para mejorar la calidad del software y la calidad de nuestras pruebas (Shift Right<\/em>).<\/strong><\/p>\n\n\n\n \u00bfC\u00f3mo ha sido tu experiencia realizando pruebas funcionales y no funcionales? \u00a1Cu\u00e9ntanos en los comentarios!<\/p>\n\n\n\n\n\n \u00a1S\u00edguenos en LinkedIn<\/a>, Twitter<\/a>, Facebook<\/a>, Instagram<\/a> y Youtube<\/a> para ser parte de nuestra comunidad y afianzar tus conocimientos en testing y calidad de software!<\/p>\n\n\n\n Testing manual vs. automatizado: \u00bfcu\u00e1l elegir para tu proyecto?<\/a><\/p>\n\n\n\n Los 7 principios esenciales del testing de software<\/a><\/p>\n\n\n\n\u00bfQu\u00e9 son las pruebas funcionales?<\/strong><\/h2>\n\n\n\n
\n
\u00bfQu\u00e9 son las pruebas no funcionales?<\/strong><\/h2>\n\n\n\n
![\"Alejandro](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2022\/12\/alejandro-aires-software-tester-abstracta-1024x486.png\")
<\/figure><\/div>\n\n\n\u00bfQu\u00e9 tipos de pruebas existen dentro de funcional?<\/strong><\/h2>\n\n\n\n
\n
\n
\n
\u00bfQu\u00e9 t\u00e9cnicas se pueden utilizar para dise\u00f1ar casos de prueba en funcional?<\/strong><\/h2>\n\n\n
![\"Imagen](\"https:\/\/es.abstracta.us\/wp-content\/uploads\/2024\/06\/tecnicas-crear-casos-pruebas-funcionales-1024x683.jpg\")
<\/figure><\/div>\n\n\nPruebas de caja blanca<\/strong><\/h3>\n\n\n\n
Pruebas de caja negra<\/strong><\/h3>\n\n\n\n
Casos de prueba abstractos y espec\u00edficos<\/strong><\/h3>\n\n\n\n
Pruebas dirigidas por datos (Data-Driven Testing<\/em>)<\/strong><\/h3>\n\n\n
![\"Imagen](\"https:\/\/es.abstracta.us\/wp-content\/uploads\/2024\/06\/pruebas-caja-negra-blanca-1024x523.jpg\")
<\/figure><\/div>\n\n\n\u00bfQu\u00e9 tipos de testing existen dentro del no funcional?<\/strong><\/h2>\n\n\n\n
Pruebas de usabilidad<\/strong><\/h3>\n\n\n\n
Pruebas de accesibilidad<\/strong><\/h3>\n\n\n\n
Pruebas de seguridad<\/strong><\/h3>\n\n\n
![\"Imagen](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2022\/12\/tipos-pruebas-sotware-no-funcionales-1024x683.jpg\")
<\/figure><\/div>\n\n\nPruebas de performance<\/strong><\/h3>\n\n\n\n
\n\n\n\n
\n\n\n\nContenidos relacionados<\/h3>\n\n\n\n