Pruebe enfoques o métodos , es decir, formas o medios sobre cómo podemos probar la aplicación bajo prueba (AUT) de manera efectiva. ¿Comenzará a probar en paralelo con el desarrollo o solo después de que se complete el desarrollo? ¿Qué pasa con las pruebas a nivel de código? es decir, revisiones de código para garantizar que se sigan las mejores prácticas. ¿Serán solo revisiones o realmente ejecutará la aplicación para identificar defectos? ¿Qué tal utilizar alguna herramienta de automatización para facilitar el proceso? ¿O será híbrido? Como habrás adivinado, hay varios enfoques o métodos para probar una aplicación. En general, estos se dividen como se explica en este artículo.
Enfoque preventivo
” Prevenir es mejor que curar “, ¡Sí! Lo mismo se aplica a las pruebas de software. Las pruebas están diseñadas en una etapa temprana, es decir, encontrar infinitas formas de probar y romper su software antes de que salga a producción. Identifique o pronostique los riesgos temprano y planifique en consecuencia. Ser proactivo siempre paga: puede evitar ciertos tipos de defectos antes de que comience la ejecución real de la prueba.
- ¿Cuál es la diferencia entre la ingeniería de software y la informática?
- ¿Cuál es el mejor software para grabar la pantalla de su computadora para tutoriales?
- ¿Cuál es la próxima gran compañía tecnológica como Google, Facebook, Amazon, Apple, etc., a la que debe unirse un ingeniero de desarrollo de software?
- ¿Por qué siempre siento que mi código del último trimestre no estaba bien escrito?
- ¿Cuáles son los cursos más importantes en un plan de estudios de CS para un ingeniero de software?
Enfoque reactivo
Sensible – como en las pruebas se diseñan después de que se completa el desarrollo de software. Reacciona cuando se produce el problema (defecto). En otras palabras, trabaja más noches y fines de semana 🙂 podría resultar en una reevaluación del plan de prueba o actividades de prueba. Es costoso y se basa en una mentalidad de fracaso. Es como esperar hasta que hayas perdido el juego para estudiar cómo te derrotó tu oponente durante el juego ( reactivo ) en lugar de explorar a tu oponente mucho antes del juego, aprender sus fortalezas y debilidades y estar preparado para ganar el juego antes de que sea jugado ( preventivo ).
Prueba de caja negra (funcional)
¿Puedes ver lo que hay dentro de una caja negra cerrada? No, verdad? Del mismo modo , el método de caja negra trata el AUT como una caja negra (sin conocimiento de su estructura interna). Resultado: no nos preocupa cómo se mantiene / cambia la estructura interna de la aplicación hasta que la funcionalidad externa funciona como se espera (según los requisitos). Saber qué hace la aplicación es más importante que saber cómo lo hace. Este es el método de prueba más utilizado para las pruebas de Sistema y Aceptación, ya que no requiere profesionales con conocimientos de codificación y también proporciona una perspectiva externa del AUT (como usuario final que no tiene conocimiento del código real).
Por ejemplo , solo nos preocupa si el usuario puede ver televisión, cambiar canales y volumen, etc.
Prueba de caja blanca (estructural)
Es obvio, simplemente invierta el enfoque. Como se trata de un recuadro blanco >> podemos ver lo que contiene, es decir, la estructura interna, y usar ese conocimiento para expandir la cobertura para probar cada flujo posible a nivel de código. Por ejemplo: cobertura de estado de cuenta, cobertura de sucursal o cobertura de ruta . Requiere habilidades de programación y generalmente se prefiere solo para los niveles de prueba de Unidad e Integración. Puede llamarlo por diferentes nombres: Clear-box, Glass-box o Transparent-box hasta donde pueda ver el contenido interno de la caja :-).
Por ejemplo, nos preocupa si el circuito interno del televisor está diseñado correctamente.
Prueba de caja gris
Como habrás adivinado, un enfoque híbrido , es decir, aprovechando la fuerza de ambos, es la combinación de pruebas de caja blanca y caja negra. No está completo pero el probador aún tiene poco conocimiento sobre la estructura interna del AUT.
Pruebas estáticas (verificación)
Estático como en inmóvil, el código no se ejecuta. Más bien, el código, los requisitos, el diseño y otros documentos se revisan manualmente para encontrar errores (como fallas de código o código potencialmente malicioso) antes de que los casos de prueba se ejecuten realmente para verificar la funcionalidad. El beneficio: ¡ahorra esfuerzo al identificar errores antes! Existen diferentes técnicas aceptadas por la industria para la revisión, tales como revisiones informales, revisiones técnicas, recorridos, inspección y revisiones de códigos .
Pruebas dinámicas (validación)
Dinámico como en activo: el código se ejecuta. ¿Cómo? Al ejercitar los diferentes flujos funcionales o no funcionales del AUT en un entorno de tiempo de ejecución desde la interfaz de usuario (por ejemplo, página web). El objetivo: confirmar que el AUT está trabajando de acuerdo con los requisitos del cliente. Las pruebas dinámicas se realizan en todos los niveles de prueba y pueden ser pruebas de caja negra o caja blanca.
Nota : tanto las pruebas estáticas como las dinámicas se configuran para descubrir vulnerabilidades y errores de codificación dentro de AUT utilizando diferentes métodos.
Prueba manual
Espero que esto se explique por sí mismo. No se utilizan herramientas de automatización como Selenium o HPE UFT para probar el AUT. En cambio, los probadores diseñan los casos de prueba diseñados manualmente, es decir, verifican manualmente diferentes flujos funcionales / no funcionales. Se requiere conocimiento de negocios, dominio y aplicación para probar con éxito una aplicación. La ventaja : como no está programado, un probador puede seguir también pruebas ad-hoc mientras realiza la ejecución de la prueba (lo que resulta en más defectos :-)).
Pruebas automatizadas
¿No sería genial si la computadora puede ejecutar las pruebas en una aplicación por sí sola? ¡Sí! Software-testing-Software testing La prueba de automatización se refiere a un método de prueba en el que se utilizan herramientas como Selenium, UFT, JMeter, LoadRunner , etc. para escribir (o grabar y reproducir) los casos de prueba que luego puede ejecutar la computadora en en cualquier momento. La ventaja : por qué desperdiciar los esfuerzos manuales en pruebas que se repiten con frecuencia (es decir, pruebas de regresión). Además, las pruebas automatizadas se pueden ejecutar en diferentes máquinas con diferentes combinaciones de plataformas de sistema operativo, al mismo tiempo. La trampa : requiere habilidades de programación
Nota : La mayoría de los proyectos tendrán un enfoque híbrido utilizando pruebas manuales para pruebas funcionales y automatización para pruebas de regresión. De hecho, ambas técnicas de prueba son 100% necesarias y se complementan entre sí de múltiples maneras. Aunque las pruebas de automatización no pueden reemplazar a las pruebas manuales, el enfoque ahora se está desplazando hacia profesionales con experiencia en automatización manual +.
Como habrás adivinado, hay varios factores involucrados antes de decidir el método de prueba : tipo de aplicación, experiencia en recursos, limitaciones de presupuesto y tiempo, expectativas del cliente, riesgos del proyecto, etc.
Espero que tengas una idea justa sobre los diferentes enfoques / métodos de prueba .