Introducción a los principios de pruebas de software
El principio de prueba de software es un proceso de prueba del resultado o salida de un producto con una salida esperada de un cliente. En otras palabras, podemos decir que la evaluación del sistema o componentes para encontrar los requisitos especificados. Ejecuta el proceso de identificación de lagunas, errores, cualquier defecto en el producto, la calidad del software que se está desarrollando, la integridad o la falta de requisitos para cumplir con los requisitos especificados.
Antes de pasar a los principios de prueba de software, veremos brevemente algunos conceptos de prueba de software como se discute a continuación:
Historial de pruebas de software
La prueba del producto comenzó en el año 1979 por Glenford J. Myers, quien introdujo el proceso de depuración de los productos. Su intención principal era trabajar en pruebas de rotura, que es un caso de prueba simple para detectar errores no descubiertos y separar actividades fundamentales de desarrollo, tales como depuración, errores, etc. de la comunidad de ingeniería de software.
¿Quién hace las pruebas?
En grandes industrias o empresas, habrá un equipo de partes interesadas asociadas del proyecto para llevar a cabo las pruebas basadas en el proceso. Analizarán el software en los requisitos dados.
Los siguientes son los profesionales que participan en un proceso de prueba en función de sus respectivas capacidades: -
- Probador de software
- Desarrollador de software
- Gerente de proyecto
- Usuario final
Existen diferentes tipos de roles que prueban el software o el producto en función de su experiencia y conocimiento, como Software Tester, Software Quality, Assurance Engineer, QA Analyst, etc.
Principios de prueba de software
La prueba de software es una tarea extremadamente desafiante. Los principios del software definen instrucciones para que los equipos de desarrollo encuentren los errores o efectos de un proyecto. Los siguientes son los siete principios fundamentales de las pruebas de software:
Principio 1: Las pruebas muestran la presencia de defectos
La prueba es un proceso que muestra la presencia de defectos en la aplicación. Muestra los defectos pero no puede probar que no hay defectos. Lo que significa que el equipo de prueba no puede decir que el producto está 100% libre de defectos. Reduce la cantidad de defectos no descubiertos en la aplicación. No puede suponer que la aplicación probada está 100% libre de errores, incluso cuando se realizan las pruebas. Por lo tanto, diseñe los casos de prueba necesarios para encontrar los defectos tanto como sea posible.
Principio 2: las pruebas exhaustivas son imposibles
Hay menos posibilidad de realizar pruebas con combinaciones de entradas, datos, escenarios de prueba y condiciones previas, ya que tomarán más tiempo probar el proceso. Por lo tanto, el equipo de prueba puede usar algunos efectos importantes de los criterios de prueba, como el riesgo y las prioridades, en lugar de realizar pruebas exhaustivas.
Por ejemplo, considere que hay 15 campos en una pantalla que contiene 5 valores posibles. Para probar todas las combinaciones, necesitaría 30 517 578 125 (5 15 ) pruebas. Pero, las escalas de tiempo del proyecto nunca permitirían probar una gran cantidad de combinaciones. Debido a esta razón, los efectos de prueba llamados riesgo y prioridades se utilizan para probar características importantes. Por lo tanto, el acceso y la gestión del riesgo se consideran las actividades más importantes y esenciales para las pruebas en cualquier proyecto.
Principio 3: Pruebas tempranas
En esta etapa, se llevarán a cabo actividades de prueba en el ciclo de vida de desarrollo de software o sistema para encontrar los defectos lo antes posible y centrarse en objetivos definidos. Los probadores pueden comenzar a probar los productos si tienen la disponibilidad de los requisitos o documentos del producto.
La principal ventaja de las pruebas iniciales es que los evaluadores pueden detectar fácilmente errores, errores y ayudar en cada nivel de desarrollo con menos costos y esfuerzos.
Si se encuentran errores en una etapa inicial del ciclo de vida del desarrollo, entonces será más fácil y más económico solucionarlo, y también el costo de la calidad será menor. De lo contrario, si se encuentran tarde, entonces debe cambiar todo el proceso del sistema. El equipo de pruebas tendrá una comprensión profunda del producto, ya que estuvieron involucrados desde el comienzo de la fase de recopilación y análisis de requisitos.
Principio 4: Agrupación de defectos
Esta fase incluye defectos relacionados con un pequeño número de módulos, que se rastrean durante las pruebas previas al lanzamiento. Significa que los módulos pequeños tendrán más defectos en el sistema. En la aplicación Principio de Pareto, las pruebas de software son aproximadamente 80:20; lo que significa que el 80% de los problemas se encuentran debido al 20% de los módulos.
La agrupación de defectos utiliza el conocimiento y la experiencia del equipo de prueba para reconocer los módulos potenciales para probar. Ese pronóstico puede ayudar a ahorrar tiempo y esfuerzo ya que el equipo solo necesita enfocarse en esas áreas "sensibles". Hay un pequeño inconveniente de esta fase cuando los evaluadores se centran en un área pequeña del equipo, pueden fallar en fallar los errores de otras áreas.
Principio 5: paradoja de los pesticidas
Esta fase se usa para revisar casos de prueba sistemáticamente y usa diferentes tipos de pruebas para encontrar más defectos del software o sistema. Si está ejecutando las mismas pruebas una y otra vez, entonces hay menos posibilidades de obtener nuevos errores descubiertos por estos casos de prueba.
No puede aplicar estas pruebas a todo el sistema, pero puede aplicarse a algunos módulos limitados. Los equipos de prueba a menudo revisan y actualizan los casos de prueba para cubrir diferentes tipos de secciones de los proyectos.
Principio 6: Las pruebas dependen del contexto
Las pruebas dependen básicamente del contenido, los proyectos y productos incluyen diferentes elementos, características y requisitos. En este enfoque, se pueden probar diferentes tipos de sitios de manera diferente y no se pueden aplicar los mismos casos de prueba para diferentes proyectos.
Por ejemplo, la seguridad y el software crítico se probarán de manera diferente a un sitio de comercio electrónico o una aplicación en la industria bancaria se probará más que el software de entretenimiento. Existen diferentes tipos de metodologías, técnicas y tipos de pruebas basadas en la naturaleza de una aplicación.
Principio 7: Ausencia de errores Falacia
Si hay una ausencia de errores en la aplicación, o si el sistema construido no se puede usar y no cumple con las expectativas del usuario, entonces encontrar y corregir defectos no ayudará. Si no hay errores en el software, entonces no debe considerar que el software está listo para ser utilizado; porque las pruebas deben realizarse junto con los requisitos correctos.
Conclusión: principios de prueba de software
Hasta ahora, ha visto que siete principios de las pruebas de software proporcionan una calidad de producto confiable al probar los productos. Estos principios se pueden aplicar para probar el proyecto y la codificación. El objetivo principal de este proceso del ciclo de vida es encontrar la corrección, integridad, calidad y detección de errores en el software.
Artículos recomendados
Esta ha sido una guía para los principios de pruebas de software. Aquí discutimos los conceptos, la historia y los 7 principios principales de las pruebas de software. También puede consultar nuestros otros artículos sugeridos para obtener más información:
- ¿Qué es el MVC?
- Prueba de preguntas de la entrevista
- ¿Qué son las pruebas de software?
- Carreras en pruebas de software