Descripción general de las pruebas de software
La prueba de software es la evaluación del software contra los requisitos recopilados de los usuarios y las especificaciones del sistema. Las pruebas se realizan a nivel de fase en el ciclo de vida del desarrollo de software o a nivel de módulo en el código del programa. Las pruebas de software se componen de validación y verificación.
Validación de software
La validación es el proceso de examinar si el software satisface o no los requisitos del usuario. Se lleva a cabo al final del SDLC. Si el software coincide con los requisitos para los que se creó, se valida.
- La validación garantiza que el producto en desarrollo se ajuste a los requisitos del usuario.
- La validación responde a la pregunta: "¿Estamos desarrollando el producto que intenta todo lo que el usuario necesita de este software?".
- La validación enfatiza los requisitos del usuario.
Verificación de software
La verificación es el proceso de confirmar si el software cumple con los requisitos comerciales y si se desarrolla siguiendo las especificaciones y metodologías adecuadas.
- La verificación garantiza que el producto que se está desarrollando cumple con las especificaciones de diseño.
- La verificación responde a la pregunta: "¿Estamos desarrollando este producto siguiendo firmemente todas las especificaciones de diseño?"
- Las verificaciones se concentran en el diseño y las especificaciones del sistema.
El objetivo de la prueba son:
Errors- Estos son errores de codificación reales cometidos por desarrolladores. Además, existe una diferencia en la salida del software y la salida deseada se considera un error.
Fault- Cuando existe un error, se produce una falla. Una falla, también conocida como error, es el resultado de un error que puede hacer que el sistema falle.
Failure - se dice que falla la incapacidad del sistema para realizar la tarea deseada. La falla ocurre cuando existe una falla en el sistema.
Pruebas manuales versus automatizadas
Las pruebas se pueden realizar manualmente o mediante una herramienta de prueba automatizada:
Manual- Esta prueba se realiza sin la ayuda de herramientas de prueba automatizadas. El probador de software prepara casos de prueba para diferentes secciones y niveles del código, ejecuta las pruebas e informa el resultado al administrador.
Las pruebas manuales consumen tiempo y recursos. El evaluador debe confirmar si se utilizan o no los casos de prueba correctos. La mayor parte de las pruebas implica pruebas manuales.
AutomatedEsta prueba es un procedimiento de prueba que se realiza con la ayuda de herramientas de prueba automatizadas. Las limitaciones de las pruebas manuales se pueden superar utilizando herramientas de prueba automatizadas.
Es necesario realizar una prueba para comprobar si se puede abrir una página web en Internet Explorer. Esto se puede hacer fácilmente con pruebas manuales. Pero para comprobar si el servidor web puede soportar la carga de 1 millón de usuarios, es bastante imposible probarlo manualmente.
Hay herramientas de software y hardware que ayudan al evaluador a realizar pruebas de carga, pruebas de estrés y pruebas de regresión.
Enfoques de prueba
Las pruebas se pueden realizar según dos enfoques:
- Prueba de funcionalidad
- Prueba de implementación
Cuando se prueba la funcionalidad sin tener en cuenta la implementación real, se conoce como prueba de caja negra. El otro lado se conoce como prueba de caja blanca, donde no solo se prueba la funcionalidad, sino que también se analiza la forma en que se implementa.
Las pruebas exhaustivas son el método mejor deseado para una prueba perfecta. Se prueba cada valor posible en el rango de los valores de entrada y salida. No es posible probar todos y cada uno de los valores en un escenario del mundo real si el rango de valores es grande.
Prueba de caja negra
Se lleva a cabo para probar la funcionalidad del programa. También se llama prueba 'conductual'. En este caso, el probador tiene un conjunto de valores de entrada y los respectivos resultados deseados. Al proporcionar la entrada, si la salida coincide con los resultados deseados, el programa se prueba 'bien' y, en caso contrario, es problemático.
En este método de prueba, el probador no conoce el diseño y la estructura del código, y los ingenieros de prueba y los usuarios finales realizan esta prueba en el software.
Técnicas de prueba de caja negra:
Equivalence class- La entrada se divide en clases similares. Si un elemento de una clase pasa la prueba, se supone que se pasa toda la clase.
Boundary values- La entrada se divide en valores finales superior e inferior. Si estos valores pasan la prueba, se supone que todos los valores intermedios también pueden pasar.
Cause-effect graphing- En los dos métodos anteriores, solo se prueba un valor de entrada a la vez. Causa (entrada) - Efecto (salida) es una técnica de prueba en la que las combinaciones de valores de entrada se prueban de forma sistemática.
Pair-wise Testing- El comportamiento del software depende de múltiples parámetros. En la prueba por pares, los múltiples parámetros se prueban por pares para sus diferentes valores.
State-based testing- El sistema cambia de estado al proporcionar la entrada. Estos sistemas se prueban en función de sus estados y entradas.
Prueba de caja blanca
Se lleva a cabo para probar el programa y su implementación, con el fin de mejorar la eficiencia o la estructura del código. También se conoce como prueba 'estructural'.
En este método de prueba, el probador conoce el diseño y la estructura del código. Los programadores del código realizan esta prueba en el código.
Las siguientes son algunas técnicas de prueba de caja blanca:
Control-flow testing- El propósito de las pruebas de flujo de control para configurar casos de prueba que cubran todas las declaraciones y condiciones de rama. Las condiciones de la rama se prueban para que sean verdaderas y falsas, de modo que se puedan cubrir todas las declaraciones.
Data-flow testing- Esta técnica de prueba hace hincapié en cubrir todas las variables de datos incluidas en el programa. Prueba dónde se declararon y definieron las variables y dónde se utilizaron o cambiaron.
Niveles de prueba
La prueba en sí misma puede definirse en varios niveles de SDLC. El proceso de prueba se ejecuta en paralelo al desarrollo de software. Antes de saltar a la siguiente etapa, se prueba, valida y verifica una etapa.
Las pruebas por separado se realizan solo para asegurarse de que no queden errores o problemas ocultos en el software. El software se prueba en varios niveles:
Examen de la unidad
Mientras codifica, el programador realiza algunas pruebas en esa unidad de programa para saber si está libre de errores. Las pruebas se realizan con un enfoque de prueba de caja blanca. Las pruebas unitarias ayudan a los desarrolladores a decidir que las unidades individuales del programa funcionan según los requisitos y no tienen errores.
Pruebas de integración
Incluso si las unidades de software funcionan bien individualmente, es necesario averiguar si las unidades, si se integran juntas, también funcionarían sin errores. Por ejemplo, paso de argumentos y actualización de datos, etc.
Prueba del sistema
El software se compila como producto y luego se prueba como un todo. Esto se puede lograr mediante una o más de las siguientes pruebas:
Functionality testing - Prueba todas las funcionalidades del software contra el requisito.
Performance testing- Esta prueba demuestra la eficacia del software. Prueba la eficacia y el tiempo medio que tarda el software en realizar la tarea deseada. Las pruebas de rendimiento se realizan mediante pruebas de carga y pruebas de estrés en las que el software se somete a una gran carga de usuarios y datos en diversas condiciones ambientales.
Security & Portability - Estas pruebas se realizan cuando el software está destinado a funcionar en varias plataformas y se accede por varias personas.
Test de aceptación
Cuando el software está listo para entregarse al cliente, debe pasar por la última fase de prueba en la que se prueba la interacción y respuesta del usuario. Esto es importante porque incluso si el software cumple con todos los requisitos del usuario y si al usuario no le gusta la forma en que aparece o funciona, puede ser rechazado.
Alpha testing- El propio equipo de desarrolladores realiza pruebas alfa utilizando el sistema como si se estuviera utilizando en un entorno de trabajo. Intentan averiguar cómo reaccionaría el usuario a alguna acción en el software y cómo debería responder el sistema a las entradas.
Beta testing- Una vez que el software se prueba internamente, se entrega a los usuarios para que lo utilicen en su entorno de producción solo con fines de prueba. Este no es todavía el producto entregado. Los desarrolladores esperan que los usuarios en esta etapa traigan problemas mínimos, que se omitieron para atender.
Pruebas de regresión
Siempre que un producto de software se actualiza con un nuevo código, característica o funcionalidad, se prueba minuciosamente para detectar si hay algún impacto negativo del código agregado. Esto se conoce como prueba de regresión.
Documentación de prueba
Los documentos de prueba se preparan en diferentes etapas:
Antes de la prueba
La prueba comienza con la generación de casos de prueba. Se necesitan los siguientes documentos como referencia:
SRS document - Documento de requisitos funcionales
Test Policy document - Describe hasta qué punto deben realizarse las pruebas antes de lanzar el producto.
Test Strategy document - Esto menciona aspectos detallados del equipo de prueba, matriz de responsabilidad y derechos / responsabilidad del gerente de prueba y el ingeniero de prueba.
Traceability Matrix document- Este es un documento SDLC, que está relacionado con el proceso de recopilación de requisitos. A medida que llegan nuevos requisitos, se agregan a esta matriz. Estas matrices ayudan a los evaluadores a conocer la fuente de los requisitos. Se pueden rastrear hacia adelante y hacia atrás.
Mientras se prueba
Es posible que se requieran los siguientes documentos mientras se inician y se realizan las pruebas:
Test Case document- Este documento contiene una lista de las pruebas que deben realizarse. Incluye plan de prueba de la unidad, plan de prueba de integración, plan de prueba del sistema y plan de prueba de aceptación.
Test description - Este documento es una descripción detallada de todos los casos de prueba y procedimientos para ejecutarlos.
Test case report - Este documento contiene un informe de caso de prueba como resultado de la prueba.
Test logs - Este documento contiene registros de prueba para cada informe de caso de prueba.
Después de la prueba
Los siguientes documentos se pueden generar después de la prueba:
Test summary- Este resumen de prueba es un análisis colectivo de todos los informes y registros de prueba. Resume y concluye si el software está listo para ser lanzado. El software se lanza bajo el sistema de control de versiones si está listo para ejecutarse.
Pruebas frente a control de calidad, garantía de calidad y auditoría
Necesitamos entender que las pruebas de software son diferentes del aseguramiento de la calidad del software, el control de calidad del software y la auditoría del software.
Software quality assurance- Son medios de seguimiento del proceso de desarrollo de software, mediante los cuales se asegura que todas las medidas se toman según los estándares de la organización. Esta supervisión se realiza para asegurarse de que se siguieron los métodos de desarrollo de software adecuados.
Software quality control- Este es un sistema para mantener la calidad del producto de software. Puede incluir aspectos funcionales y no funcionales del producto de software, que mejoran la buena voluntad de la organización. Este sistema garantiza que el cliente reciba un producto de calidad para sus necesidades y el producto certificado como "apto para su uso".
Software audit- Esta es una revisión del procedimiento utilizado por la organización para desarrollar el software. Un equipo de auditores, independiente del equipo de desarrollo, examina el proceso, el procedimiento, los requisitos y otros aspectos del software SDLC. El propósito de la auditoría de software es verificar que el software y su proceso de desarrollo cumplen con los estándares, reglas y regulaciones.