Puedes comprar las mejores raquetas de tenis, pero mágicamente no aumentará tu habilidad a menos que sepas cómo usarlas. Las pruebas de software no son diferentes; no te darán buenos resultados a menos que sepas cómo, quién, qué y cuándo usarlas.
La prueba de software se define como el proceso de garantizar que el software sea de la mejor calidad posible para los usuarios, y probar un producto para evitar que cualquier problema de software se convierta en un cuello de botella.
Hay muchas maneras de abordar las pruebas de software. Sin embargo, es fácil confundirse por la gran cantidad de tipos de pruebas y cómo se superponen, y mucho menos lo que hace cada uno de ellos.
La prueba de software no se trata solo de encontrar defectos durante la ejecución de la prueba. Las siguientes son las pautas clave para las pruebas de software para mejorar la calidad del producto y entregar un producto de software de calidad.
Es por eso que hemos creado una guía para pruebas de software.
Indice
¿Qué son las pruebas de software?
Software Testing es una actividad en el desarrollo de software. Es una investigación realizada contra un software para proporcionar información sobre la calidad del software a las partes interesadas.
Diferentes personas han ideado varias definiciones para Pruebas de software , pero en general, el objetivo es:
- Garantizar que el software cumpla con los requisitos y el diseño acordados
- La aplicación funciona como se esperaba.
- La aplicación no contiene errores graves.
- Cumple con el uso previsto según las expectativas del usuario
Las pruebas de software a menudo se usan en asociación con los términos verificación y validación.
- Validación : ¿Estamos haciendo el trabajo correcto?
- Verificación : ¿Estamos haciendo bien el trabajo?
La verificación es la prueba de elementos, incluido el software, para verificar su conformidad y coherencia con una especificación asociada.
La validación es el proceso de verificar que lo que se ha especificado es lo que el usuario realmente quería.
Las pruebas de software son solo un tipo de verificación, que también utiliza técnicas como revisiones, análisis, inspecciones y recorridos.
Las pruebas de software no deben confundirse con la depuración. La depuración es el proceso de analizar y localizar errores cuando el software no se comporta como se esperaba.
Aunque la identificación de algunos errores será obvia al jugar con el software, un enfoque metódico para las pruebas de software es un medio mucho más completo para identificar errores.
Por lo tanto, la depuración es una actividad que admite pruebas, pero no puede reemplazarlas. Sin embargo, no se puede garantizar la cantidad de pruebas para descubrir todos los errores.
¿Cómo implementar tu estrategia de prueba?
Hemos dividido esta sección en dos categorías: Pruebas manuales y pruebas automatizadas.
Pruebas manuales
Las pruebas manuales se definen como probadores que ejecutan manualmente casos de prueba sin el uso de ninguna herramienta de automatización. Desempeñan el papel del usuario final y tratan de encontrar errores en la aplicación lo más rápido posible.
Los errores se recopilan en un informe de errores, que se pasa a los desarrolladores para revisarlos y corregirlos.
Una aplicación no se puede probar utilizando la automatización exclusivamente, por lo que las pruebas manuales juegan un papel vital en las pruebas de software. Requiere una cierta mentalidad, paciencia, creatividad y mente abierta entre ellos.
Hemos puesto los siguientes tipos de prueba manual.
1. Prueba exploratoria
Las pruebas exploratorias se basan en permitir que el probador tenga la libertad de interactuar con una aplicación y reaccionar como mejor le parezca.
Los buenos evaluadores se adaptan y descubren lo que se necesita en lugar de seguir procedimientos de prueba predefinidos. Sin embargo, algunos líderes de opinión en la industria de pruebas de software interpretan las pruebas exploratorias como diseño de prueba y ejecución de prueba al mismo tiempo.
Para maximizar los resultados de las pruebas exploratorias, se deben proporcionar parámetros específicos a los probadores, por ejemplo, qué partes de una aplicación probar, cuánto tiempo probar, etc.
Una buena prueba exploratoria es una actividad planificada, pero no programada.
Ventajas
Un beneficio importante es que la preparación no tiene que ser exhaustiva, aunque todavía es necesaria. Cuando se ejecuta correctamente, las pruebas exploratorias son fluidas sin documentación ni casos de prueba. Lo hace muy efectivo para encontrar errores únicos y verificar la funcionalidad.
Las pruebas exploratorias son útiles en situaciones de pruebas complejas cuando se sabe poco sobre una aplicación o se necesita más información para escribir pruebas con guiones.
Inconvenientes
La falta de planificación antes de ejecutar pruebas exploratorias conducirá a resultados ineficientes e improductivos. Por el contrario, las pruebas exploratorias no deben ser programadas. Significa que lograr el equilibrio entre los dos es difícil.
Las pruebas exploratorias también dependen en gran medida de la habilidad y la mentalidad de los evaluadores. Un buen probador exploratorio requiere muchas habilidades;:
- pensamiento lateral,
- pensamiento crítico,
- habilidades de investigación,
- habilidades para contar historias,
- buena comunicación y
- habilidades técnicas.
2. Prueba de regresión manual
La prueba de regresión manual es un método de verificación, que se realiza manualmente. Se utiliza para confirmar que una actualización reciente, corrección de errores o cambio de código no ha afectado negativamente a las funciones existentes.
Utiliza todos o algunos de los casos de prueba ya ejecutados que se vuelven a ejecutar para garantizar que la funcionalidad existente funcione correctamente y no se hayan introducido nuevos errores.
Pros
La prueba de regresión es una necesidad en todos los ciclos de lanzamiento.
Cuando se hace correctamente, puede mejorar y mantener la calidad. Idealmente, debe realizarse después de cada confirmación de código. Esto garantiza la necesidad de retroceder solo una confirmación para solucionar un problema, pero esto no siempre es práctico.
Contras
Cuando se implementan cambios constantes en una aplicación, las pruebas de regresión manual son muy ineficientes.
3. Ejecución de caso de prueba
Los casos de prueba ayudan a guiar al probador a través de una secuencia de pasos para validar si la aplicación funciona según lo previsto.
Un buen caso de prueba requiere buenas habilidades de escritura, atención al detalle y una buena comprensión de la aplicación.
La ejecución del caso de prueba es el proceso de ejecutar el código y comparar los resultados esperados y reales. Los casos de prueba se asignan a los probadores para ejecutar las pruebas, crear el informe de errores e informar el estado de cada uno.
Pros
A los evaluadores les gusta el proceso paso a paso de los casos de prueba, aunque puede ser muy repetitivo. Un buen caso de prueba es reutilizable. Esto debe tenerse en cuenta al escribirlos para ahorrar tiempo a largo plazo.
Los casos de prueba proporcionan documentación completa para el área que están probando.
Contras
Si los casos de prueba están mal escritos o no son claros, causará confusión o errores, lo que significará resultados inexactos o la necesidad de volver a realizar la prueba.
Pruebas automatizadas
La prueba automatizada es un proceso en el que se utiliza una herramienta de automatización para ejecutar casos de prueba preescritos. El objetivo de las pruebas automatizadas es simplificar y aumentar la eficiencia en el proceso de prueba.
Las tareas repetitivas, como probar procesos de inicio de sesión o formularios de registro, son buenos ejemplos de cuándo utilizar pruebas automatizadas.
El uso de pruebas automatizadas es indudablemente más rápido que las pruebas manuales.
En términos de ejecución de pruebas, aumentará la productividad y reducirá el tiempo de prueba para la mayoría de las aplicaciones o sitios web. Aunque los costes de instalación son altos, las pruebas automatizadas pueden ahorrar dinero a largo plazo.
Las tareas repetitivas son ineficientes cuando se realizan manualmente, especialmente cuando se repiten. También hay una mayor probabilidad de error humano. Las pruebas automatizadas pueden erradicar esto, dependiendo de la calidad y el alcance de los casos de prueba.
Sin embargo, hay ciertas situaciones de prueba en las que las pruebas automatizadas no funcionarán, como:
- interfaz de usuario,
- documentación,
- instalación,
- compatibilidad y
- recuperación.
Incluso si eliges automatizar, se necesitarás alguna forma de prueba manual.
Los costes iniciales de configuración (compra de herramientas de automatización, capacitación, mantenimiento de scripts de prueba) son elevados. Además, si tu aplicación o sitio web cambian regularmente, el coste y el tiempo asociados con el mantenimiento del script aumentarán considerablemente.
Hemos puesto los siguientes tipos de pruebas automatizadas.
1. Examen de la unidad
La prueba de unidad es probar unidades individuales o componentes de una aplicación. El objetivo es garantizar el funcionamiento de cada unidad tal como se diseñó.
Por lo general, lo llevan a cabo los desarrolladores, no los probadores, ya que requiere un conocimiento detallado del diseño y el código interno del programa.
Pros
Cuando ocurre un fallo en una prueba unitaria, es causado por un error en el código o un problema con la prueba unitaria real. De cualquier manera, es fácil identificar el problema y lo suficientemente temprano en el ciclo de desarrollo para solucionarlo.
Las pruebas unitarias aseguran que el código funcione correctamente a medida que crece la base del código. Esto simplifica el código para hacerlo más legible y menos complejo. Al verificar cada unidad, la integración en una aplicación es más simple.
Las pruebas unitarias también proporcionan documentación garantizada para una aplicación. Esto es útil para otros desarrolladores que necesitan averiguar qué funcionalidad proporciona una unidad en particular.
Contras
Las buenas pruebas unitarias son complejas de escribir.
Puede significar que es probable que el código de prueba sea al menos tan defectuoso como el código que está probando. Este escenario es el mismo para las pruebas unitarias manuales y automatizadas.
Es casi imposible evaluar cada ruta de ejecución en todas las aplicaciones excepto las más básicas. Un sistema completo de control de versiones es esencial para registrar los cambios en caso de que alguien necesite consultar las versiones anteriores.
2. Prueba de API
La prueba de las interfaces de programación de aplicaciones (API) significa verificar las API directamente.
Una API es una característica que permite que una aplicación interactúe y se comunique con otras aplicaciones. Determina si las API cumplen con las expectativas de funcionalidad, confiabilidad, rendimiento y seguridad. Estas pruebas implican enviar llamadas a una API, recibir una salida y registrar una respuesta.
Pros
Si una API no se prueba correctamente, puede causar problemas no solo a la aplicación principal sino también a las otras aplicaciones con las que se integra. Las pruebas de API proporcionan una verificación vital para garantizar que esta funcionalidad funcione correctamente.
Contras
Configurar un entorno de prueba para pruebas de API puede ser complejo. Además, es necesario un buen nivel de conocimiento de codificación para los casos de prueba de API.
3. Pruebas de regresión automatizadas
Por naturaleza, las pruebas de regresión requieren una repetición constante. Se puede realizar manualmente o utilizando un método automatizado.
La definición es la misma que la prueba de regresión manual. Es un método de verificación, pero está automatizado en lugar de realizarse manualmente.
Pros
- Mejora la calidad del producto.
- Detecta cualquier efecto secundario de actualizaciones, correcciones de errores y cambios de código
Contras
- Configurar pruebas de regresión automatizadas es costoso
- Alto esfuerzo de mantenimiento
- Puede causar sus propios efectos secundarios.
¿Quién ejecutará las pruebas?
Ya se trate de pruebas internas, de crowdsourced y/o externalizadas, decidir quién ejecutará tus pruebas es una parte crucial de tu estrategia.
Las pruebas de software no te darán buenos resultados a menos que elijas a la persona adecuada para realizarlas.
Dentro de este apartado, distinguimos los siguientes tipos de pruebas.
Pruebas beta
Las pruebas beta son un tipo informal de pruebas realizadas por los usuarios finales.
Se realiza en entornos del mundo real, generalmente en la etapa de prueba final cuando la aplicación se considera estable.
Normalmente se lanza una versión beta a un número limitado de usuarios finales. Tienen la tarea de usarlo y compartir sus comentarios con los desarrolladores para que puedan hacer los cambios necesarios.
Ventajas
El objetivo principal de las pruebas beta es garantizar que no haya fallos importantes en la aplicación.
Proporciona una validación final antes del lanzamiento. También proporciona comentarios únicos de los usuarios finales, lo que brinda a los desarrolladores la oportunidad de realizar mejoras adicionales antes de lanzar a todos los usuarios.
La prueba beta es una forma rentable de probar una aplicación que genera buena voluntad entre el desarrollador y el usuario final.
Inconvenientes
La gestión de las pruebas beta es un problema. Otros tipos de pruebas tienen parámetros más claros y están más estructurados, mientras que las pruebas beta se prueban en el mundo real, por lo que hay una falta de control.
Seleccionar los probadores beta correctos y hacer que acepten llevar a cabo las pruebas beta puede ser un desafío. Algunos usuarios serán más receptivos que otros y algunos pueden aceptar participar solo para acercarse a la prueba.
Pruebas de crowdsourced
Las empresas de pruebas de crowdsourcing ofrecen una gran comunidad de probadores profesionales en diferentes ubicaciones con acceso a múltiples dispositivos.
Los probadores tienen como objetivo encontrar errores, documentar pasos reproducibles y proporcionar informes de errores. El concepto es simple: el poder colectivo de más cabezas es mejor que uno.
Las compañías de pruebas de crowdsourcing actúan como un agente entre el cliente y la multitud al administrar el proyecto de prueba y los probadores antes de evaluar y presentar los resultados al cliente para la acción.
Ventajas
En un momento en que existe una presión incesante para desarrollar y lanzar aplicaciones más rápido, las pruebas de crowdsourcing son atractivas.
La multitud puede entregar resultados de prueba más rápido que los probadores internos simplemente porque son más.
Las pruebas de crowdsourcing son una opción rentable en comparación con el control de calidad interno o las pruebas automatizadas. El poder colectivo y la diversidad de la multitud ofrece una perspectiva diferente, que conduce a mejores resultados.
Inconvenientes
Los evaluadores internos suelen tener un mejor conocimiento de dominio, empresa y producto que los evaluadores de crowdsourcing. Dependiendo de tu aplicación o sitio web, esto puede o no importar.
Pruebas internas
Las pruebas internas son cuando utilizas probadores internos para tus necesidades de prueba.
Ventajas
El uso de probadores internos hace que exista un buen conocimiento de la empresa, del dominio y del producto sin que se necesite una capacitación adicional. Además, los probadores internos trabajan directamente con el líder y los desarrolladores, lo que a menudo puede hacer que la comunicación sea más rápida y fácil.
Inconvenientes
Para la mayoría de las organizaciones, los requisitos de prueba difieren durante todo el año. Esto significa que a menudo hay una brecha en los recursos, ya sea que no sea suficiente o que sea demasiada. Mantener y agregar a un equipo de pruebas internas es más costoso que usar opciones subcontratadas.
Pruebas subcontratadas
Las pruebas subcontratadas son las realizadas por una compañía independiente o un grupo de evaluadores fuera de la organización.
Ventajas
Las pruebas subcontratadas significan que tiene acceso a un grupo más grande de probadores. Más ojos a menudo significarán resultados de mejor calidad.
El outsourcing también se escala más eficientemente que las opciones internas. Puede ser una opción rentable en comparación con agregar a tu equipo interno de control de calidad.
Inconvenientes
El uso de recursos externos fuera de tu organización pondrá un mayor énfasis en la comunicación. Diferentes horarios, barreras de idioma y problemas de zonas horarias pueden ralentizar el proceso de prueba. El líder de control de calidad puede sentir menos control en comparación con la gestión interna de tu propio equipo de control de calidad.
¿Qué debe probarse?
Antes de realizar las pruebas de software debemos tener claro qué deben probar. Aquí distinguimos las siguientes pruebas.
Prueba de caja negra
La prueba de caja negra trata el software como una «caja negra», examinando la funcionalidad sin ningún conocimiento de implementación interna y sin ver el código fuente. Los evaluadores solo saben lo que se supone que debe hacer el software, no la lógica de cómo lo hace.
Pros
Las pruebas de caja negra ofrecen pruebas imparciales porque el diseñador y el probador trabajan de forma independiente. El probador no necesita conocer ningún lenguaje de programación específico para probar la confiabilidad y funcionalidad de una aplicación o sitio web.
Las pruebas de caja negra se realizan desde el punto de vista del usuario final en lugar de desde el punto de vista del desarrollador. Los casos de prueba se pueden diseñar inmediatamente después de completar las especificaciones.
Contras
No es posible probar todas las secuencias de entrada posibles porque consume demasiado tiempo y eventualmente dejaría muchas rutas de programa sin probar. Las pruebas de recuadro negro no están destinadas a probar segmentos complejos de código.
Prueba de caja blanca
La prueba de caja blanca es lo opuesto a la prueba de caja negra. Prueba la estructura interna de una aplicación para probar el código en sí, a diferencia de la funcionalidad expuesta al usuario final.
Este tipo de prueba es utilizada tanto por desarrolladores como por evaluadores. Les ayuda a comprender qué línea de código se ejecuta realmente y cuál no.
Pros
La transparencia de la estructura de codificación interna es útil para comprender el tipo de datos de entrada que se necesitan para realizar pruebas de manera efectiva.
Las pruebas de caja blanca cubren todas las rutas de código posibles que pueden motivar a los desarrolladores a escribir un código mejor. Los casos de prueba se pueden automatizar fácilmente con una gran cantidad de herramientas disponibles para hacer esto.
Contras
La prueba de caja blanca es un procedimiento complejo y costoso que requiere una combinación de amplios conocimientos de programación y una comprensión profunda de la estructura interna del código. La complejidad se prolonga si se trata de una aplicación grande. Se requieren actualizaciones del script de prueba cuando la implementación cambia con demasiada frecuencia.
La necesidad de crear una gama completa de entradas para probar cada ruta y condición hace que las pruebas de caja blanca sean extremadamente lentas. Significa que algunas condiciones pueden no haber sido probadas ya que no es realista probar cada una.
¿Cuándo deberías usar diferentes tipos de pruebas?
Por último, debes conocer cuándo utilizar los distintos tipos de pruebas según la siguiente clasificación.
Pruebas de accesibilidad
Las pruebas de accesibilidad se realizan para garantizar que una aplicación sea utilizable para personas con discapacidades. Esto incluye impedimentos visuales, daltonismo, habilidades motoras deficientes, dificultades de aprendizaje, dificultades de alfabetización, sordera y discapacidades auditivas.
La accesibilidad al sitio web se puede medir usando W3C (conocido como Pautas de Accesibilidad al Contenido en la Web).
Pros
Muchas personas tienen problemas de discapacidad que afectan su uso del software. Para evitar aislar a los usuarios, una aplicación debe ser accesible.
La legislación sobre accesibilidad existe en muchos países. Si una solicitud no cumple, existe el riesgo de sanciones financieras y / o acciones legales.
Contras
La prueba de software es un proceso complejo ya sea automatizado, manual o una combinación de ambos. Aunque hay muchas herramientas de automatización disponibles, no necesariamente ayudan en cada situación.
Es un área difícil reemplazar la intuición humana y el razonamiento que proporcionan los controles humanos manuales.
Las pruebas de accesibilidad aún están en su infancia, lo que causa inconsistencia. En el futuro, habrá una forma más estándar y consistente de probar la accesibilidad de una aplicación.
Pruebas de compatibilidad
Las pruebas de compatibilidad ratifican si es posible ejecutar una aplicación en distintos entornos, incluidos red, hardware, sistema operativo o red.
Pros
Las pruebas de compatibilidad ayudan a garantizar la satisfacción del cliente, ya que verifica si una aplicación funciona como se espera en múltiples plataformas.
Todas las aplicaciones deben ser compatibles con la cantidad máxima de hardware, software, sistema operativo, plataformas, etc. El tiempo y el coste involucrados en responder las quejas de los usuarios pueden ser elevado. También puede tener un efecto adverso en la reputación de una aplicación.
Contras
Las pruebas de compatibilidad conducirán a un aumento en los costes y el tiempo de prueba. Esto se debe al mantenimiento de diferentes tipos de sistemas de hardware y software, así como a la necesidad de agregar potencialmente a la plantilla de su equipo de control de calidad.
Es común que se produzcan retrasos en las pruebas, lo que puede dar lugar a ciclos de entrega más largos. La realización de este tipo de prueba lleva mucho tiempo porque debe realizarse en los distintos entornos.
Pruebas Funcionales
Las pruebas funcionales son un paso esencial para evaluar el rendimiento de una aplicación antes de que se lance.
Se refiere a la prueba de una acción o función específica del código. Estos generalmente se encuentran en la documentación de requisitos de código, aunque algunas metodologías de desarrollo funcionan a partir de casos de uso o historias de usuarios.
Las pruebas funcionales tienden a responder la pregunta de «¿puede hacer esto el usuario?» o «¿funciona esta característica en particular?».
Pros
Las pruebas funcionales se realizan en condiciones cercanas a las que experimenta el cliente. Esto funciona mejor cuando hay los mismos sistemas operativos, navegadores, bases de datos, etc.
La liberación de aplicaciones con serias deficiencias funcionales puede crear consecuencias desastrosas. Las pruebas funcionales son una de las formas más efectivas para evitar esto.
Contras
Las pruebas funcionales se limitan a probar qué tan bien una aplicación hace lo que se supone que hace posible perder errores fuera de este alcance. Cuanto más específicas sean las especificaciones del usuario, mejores serán las pruebas funcionales. En última instancia, la efectividad de las pruebas funcionales se basa en esto.
Prueba de GUI
El objetivo de las pruebas de la GUI (interfaz gráfica de usuario) es garantizar que la GUI funcione correctamente. La prueba de GUI incluye comprobaciones como el tamaño del botón, el campo de entrada, la alineación del texto, la legibilidad, etc.
Pros
Las pruebas de GUI son buenas para encontrar errores de regresión causados por actualizaciones de aplicaciones. Si bien es repetitivo y requiere mucho tiempo, las pruebas de GUI en sí mismas a menudo son fáciles de realizar.
Contras
La automatización de las pruebas de GUI acelerará la entrega y mejorará la cobertura de las pruebas, pero no siempre es posible o eficiente hacerlo.
La interacción humana a menudo es necesaria para problemas como el choque de colores, la legibilidad, etc. Las pruebas manuales de GUI son muy repetitivas, por lo que existe un mayor riesgo de errores.
Prueba de carga
Una vez que el ciclo de desarrollo está casi completo, se realizan pruebas de carga para verificar cómo se comporta una aplicación bajo las demandas reales de los usuarios finales.
La prueba de carga generalmente se realiza utilizando herramientas de prueba automatizadas que simulan el uso en el mundo real. Tiene la intención de encontrar problemas que impidan que el software funcione bajo cargas de trabajo pesadas.
Pros
La prueba de carga proporciona una estimación de la capacidad máxima a la que una aplicación puede funcionar antes de que se vea afectado el rendimiento.
También detecta errores de funcionalidad que ocurren bajo diferentes variaciones de carga, lo que puede proporcionar información valiosa sobre los cuellos de botella de rendimiento.
Las pruebas de carga mejorarán la escalabilidad de una aplicación.
Contras
Si la prueba de carga no se realiza en múltiples dispositivos y combinaciones de sistemas operativos, puede causar resultados inconsistentes.
Aplicar carga a una aplicación para probar su capacidad bajo una prueba controlada puede no reflejar lo que podría suceder en una situación del mundo real.
Pruebas de localización
Las pruebas de localización verifican la calidad de una versión localizada de una aplicación para una cultura o localidad en particular.
Cuando una aplicación se personaliza para un país extranjero o se presenta en un idioma diferente, las pruebas de localización aseguran que sea precisa. Predomina en tres áreas: lingüística, cosmética y funcional.
¿La traducción afecta negativamente a una marca o mensaje? ¿Los cambios crean problemas de alineación o espaciado para la interfaz de usuario? ¿La funcionalidad se ve afectada por las preferencias regionales?
Pros
Las pruebas de localización mejorarán la calidad de una aplicación. Lanzarlo a diferentes mercados puede proporcionar una ventaja competitiva, pero presenta sus propios desafíos. Las pruebas de localización van más allá de la traducción. Tiene que probar las diferencias culturales y la experiencia del usuario.
Cuando se realiza correctamente, las pruebas de localización reducirán los costes de soporte y aumentarán la satisfacción del usuario.
Contras
Lanzar una solicitud a un país o cultura diferente puede ser una tarea laboriosa. No hay atajos. La prueba de localización no es un simple ejercicio de traducción, requiere un conocimiento experto de la cultura local, la lingüística y las preferencias.
Dependiendo de las diferencias de ubicación y hora local, coordinar las pruebas de localización puede ser un desafío y llevar mucho tiempo.
Pruebas no funcionales
Las pruebas no funcionales implican pruebas que pueden no estar relacionadas con una función específica o acción del usuario final, como pruebas de carga o pruebas de seguridad. Determinará el punto de ruptura. El punto en el que los elementos no funcionales conducen a una ejecución inestable.
Pros
Las pruebas no funcionales cubren pruebas como los tiempos de carga, que pueden no estar cubiertos en las pruebas funcionales. Debido a las pruebas que cubre, una aplicación por defecto será más segura y funcionará mejor.
Contras
Cada vez que se actualiza una aplicación, se deben realizar pruebas no funcionales. Puede requerir varias herramientas y suele ser costoso.
Pruebas de penetración
La prueba de penetración es un tipo de prueba de seguridad. Se realiza para probar la seguridad de una aplicación y sus entornos (hardware, sistema operativo, red, etc.) cuando están sujetos a ataques por parte de un intruso externo o interno.
Un intruso se define como un hacker o programa malicioso. Las pruebas de penetración fuerzan un ataque o lo hacen usando una debilidad para obtener acceso a una aplicación. Utiliza los mismos métodos y herramientas que usaría un hacker, pero la intención es identificar vulnerabilidades para que puedan repararse antes de que un hacker real o un programa malicioso las explote.
Pros
Cada pirata informático es diferente, pero tienen un objetivo común: engañar a las personas para que les faciliten accesos no deseados. Las pruebas de penetración pueden descubrir exactamente cuáles son estas circunstancias y ayudar a solucionarlas.
También identifica vulnerabilidades de alto riesgo que existen debido a una acumulación de debilidades más pequeñas. Estas pequeñas debilidades podrían estar relacionadas con el software, el código o, más comúnmente, causadas por negligencia involuntaria de los empleados.
Las pruebas de penetración son difíciles de automatizar porque es más fácil para los evaluadores humanos detectar los tipos de debilidades que los atacantes humanos pueden aprovechar.
Contras
Las pruebas de penetración son probadores que intentan entrar en una aplicación. Aunque los beneficios son evidentes, los probadores no dejan de ser piratas informáticos. Esto crea un problema de confianza obvio que puede ser muy complejo de administrar.
Otra desventaja potencial es la naturaleza poco realista de las condiciones de prueba y la falta de sorpresa por parte del personal interno. Una violación de la aplicación en la vida real siempre será inesperada, lo cual es muy difícil de replicar. Una posible solución es realizar pruebas no anunciadas que solo son conocidas por personal interno seleccionado.
QAOps
QAOps es un marco para ayudar a más empresas a convertirse en organizaciones centradas en la calidad.
Esto se logra mediante la implementación de los tres pilares de QAOps que le permiten cambiar su perspectiva sobre cómo se ve típicamente el QA en una organización: desde una perspectiva de operaciones puramente de software hasta cómo QA puede ayudarlo con sus objetivos de crecimiento y mejorar la experiencia de sus clientes.
Los tres pilares de QAOps son:
Mezclar
La prueba se trata de gestionar el riesgo. Una forma importante de hacerlo es obtener varias fuentes de información de alta calidad para ayudarte a tomar mejores decisiones.
En un contexto de control de calidad, este principio se trata de utilizar diferentes tipos de pruebas (esto incluye pruebas manuales y automatizadas) para ayudarte a tomar mejores decisiones sobre tu enfoque.
Con estas actividades, como con las pruebas, no hay solo una forma de alcanzar tu objetivo y en algunos casos aumentará su riesgo al apegarse a una estrategia y no incorporar otras fuentes de información.
Optimizar
La mayoría de los equipos se centran en crear y lanzar software lo más rápido posible. Con ello se pretende que las empresas ofrezcan rápidamente productos al mercado con lo que se incrementará su ciclo de retroalimentación y se mejorarán sus productos. Para eso es necesario analizar de forma estricta cada uno de los elementos de su proceso de control de calidad.
Además, algunos de los equipos de desarrollo de alto rendimiento han cambiado la estructura de su equipo para quitarle la carga de responsabilidad únicamente al probador. En cambio, integran la calidad al comienzo de su proceso para alentar la colaboración en toda la organización y ahorrar tiempo a largo plazo.
Crecer
En la mayoría de las organizaciones, el control de calidad generalmente se ve como un centro de costes, sin embargo, el control de calidad puede verse como un motor de crecimiento para tu empresa.
Los equipos han incorporado los objetivos de crecimiento de la organización en sus actividades de control de calidad para priorizar las tareas de manera efectiva y dar forma a su estrategia interna.
Como conclusión, podemos decir que no hay un tipo de prueba que se ajuste a todos los requisitos de prueba. Las principales organizaciones combinan diferentes enfoques de prueba en diferentes etapas de su ciclo de desarrollo para lograr los mejores resultados.