validation testing ultimate guide
Explore la importancia de las pruebas de validación:
Lo que vas a aprender:
- ¿Qué son las pruebas de validación?
- Diferencia entre verificación y validación
- Etapas involucradas
- Ejemplos de casos de prueba de validación o protocolo
- Conclusión
- Lectura recomendada
¿Qué son las pruebas de validación?
Las pruebas de validación son el proceso de asegurar si el software probado y desarrollado satisface las necesidades del cliente / usuario. La lógica o los escenarios de requisitos comerciales deben probarse en detalle. Todas las funcionalidades críticas de una aplicación deben probarse aquí.
Como evaluador, siempre es importante saber cómo verificar la lógica empresarial o los escenarios que se le ofrecen. Uno de esos métodos que ayuda en la evaluación detallada de las funcionalidades es el proceso de validación.
Siempre que se le solicite realizar una prueba de validación, asume una gran responsabilidad, ya que debe probar todos los requisitos comerciales críticos en función de las necesidades del usuario. No debería faltar ni una sola vez los requisitos solicitados por el usuario. Por lo tanto, es muy importante un conocimiento profundo de las pruebas de validación.
Como evaluador, debe evaluar si los resultados de la ejecución de la prueba cumplen con lo mencionado en el documento de requisitos. Cualquier desviación debe informarse de inmediato y, por lo tanto, esa desviación se denomina error.
Se utilizan herramientas como HP Quality Center, Selenium, Appium, etc. para realizar la prueba de validación y podemos almacenar los resultados de la prueba allí. Un plan de prueba adecuado, ejecuciones de ejecución de prueba, informes de defectos, informes y métricas son los entregables importantes que se deben enviar.
Desde la perspectiva de una empresa, la prueba de validación en simple se lleva a cabo mediante los siguientes pasos:
- Reúne los requisitos comerciales para las pruebas de validación del usuario final.
- Prepare el plan de negocios y envíelo para su aprobación al sitio / partes interesadas involucradas.
- Una vez aprobado el plan, comienza a escribir los casos de prueba necesarios y los envía para su aprobación.
- Una vez aprobado, comienza a completar las pruebas con el software y el entorno requeridos y envía los entregables según lo solicite el cliente.
- Tras la aprobación de los entregables, el cliente realiza las pruebas de UAT.
- Después de eso, el software pasa a producción.
mejor software de clonación de disco duro windows 10
Exploremos ahora más sobre la validación en detalle.
Diferencia entre verificación y validación
Entendamos estos con un ejemplo de forma sencilla.
Ejemplo:
Requisito del cliente:
La inyección propuesta no debe pesar más de 2 cms.
Prueba de verificación:
- Verifique si la inyección es la inyección que no pesa más de 2 cm utilizando la lista de verificación, revisión y diseño.
Prueba de validación:
- Compruebe si la inyección no pesa más de 2 cm mediante pruebas manuales o automáticas.
- Debe verificar todos y cada uno de los escenarios posibles relacionados con el peso de inyección utilizando cualquier método de prueba adecuado (métodos funcionales y no funcionales).
- Consultar medidas inferiores a 2 cm y superiores a 2 cms.
| Verificación | Validación |
|---|---|
| El proceso solo verifica el diseño, el código y el programa. | Debe evaluar todo el producto, incluido el código. |
| Revisiones, recorridos, inspecciones y verificación de escritorio involucrados. | Están involucrados métodos de prueba funcionales y no funcionales. Se realiza un control en profundidad del producto. |
| Comprueba el software con la especificación. | Comprueba si el software satisface las necesidades del usuario. |
Etapas involucradas
- Calificación de diseño: Esto incluye la creación del plan de prueba en función de los requisitos comerciales. Todas las especificaciones deben mencionarse claramente.
- Calificación de instalación: Esto incluye la instalación de software según los requisitos.
- Calificación operativa: Esto incluye la fase de prueba basada en la especificación de requisitos del usuario.
Esto puede incluir Prueba de funcionalidad:
-
- Examen de la unidad - Caja negra, caja blanca, caja gris.
- Pruebas de integración - De arriba hacia abajo, de abajo hacia arriba, Big bang.
- Prueba del sistema - Pruebas de cordura, humo y regresión.
- Calificación de desempeño: UAT (prueba de aceptación del usuario) – Pruebas alfa y beta.
- Producción
Calificación de diseño
La calificación del diseño simplemente significa que debe preparar el diseño del software de tal manera que cumpla con las especificaciones del usuario. Principalmente necesitas obtener el Documento de especificación de requisitos de usuario (URS) del cliente para proceder con el diseño.
Estrategia de prueba:
Este documento constituye la base para preparar el plan de prueba. Por lo general, lo prepara el líder del equipo o el gerente del proyecto. Describe cómo vamos a proceder para probar y lograr el objetivo deseado.
Para incorporar todos los procedimientos, se debe diseñar un plan adecuado y ser aprobado por las partes interesadas. Entonces, háganos saber los componentes del plan de prueba.
En algunos proyectos, el plan de prueba y la estrategia de prueba se pueden incorporar como un solo documento. También se preparan documentos de estrategia separados para un proyecto complejo (principalmente en técnica de automatización).
Componentes del plan de pruebas de validación:
- Descripción del proyecto
- Entender los requisitos
- Alcance de la prueba
- Niveles de prueba y calendario de pruebas
- Ejecutar la creación del plan
- Requisitos de hardware, software y personal
- Funciones y responsabilidades
- Supuestos y dependencias
- Riesgos y mitigación
- Informe y métricas
Descripción del proyecto: Aquí debe aclarar toda la descripción de la aplicación que se le otorgó para la prueba. Debe incluir todas las funcionalidades de la aplicación.
Comprensión de los requisitos: Al obtener el USR, debe mencionar los requisitos entendidos por su parte. También puede plantear aclaraciones si las hubiera. Este es el criterio base o de prueba para las pruebas.
Alcance de la prueba: El alcance debe incluir los módulos en detalle junto con las características a un alto nivel. Debe decirle al cliente cuáles son todos los requisitos que cubriría en sus pruebas.
Desde una perspectiva empresarial, se puede solicitar la realización de pruebas de validación para los requisitos críticos de una aplicación. Simplemente significa que dices qué se cubrirá y qué no .
Niveles de prueba y calendario de pruebas: Debe mencionar cuántas rondas de pruebas deben realizarse. El esfuerzo general para el proyecto de prueba se estima utilizando las técnicas de estimación estándar como la estimación de Test Case Point (TCP), etc.
Como su nombre indica calendario de pruebas describe cómo se llevarán a cabo las pruebas. También debe indicar cómo y cuándo se llevarán a cabo la aprobación y las revisiones.
Ejemplo:
El diseño de una página web es el proyecto considerado.
Los niveles de prueba incluyen:
Nivel 1: Prueba de humo
Nivel 2: Examen de la unidad
Nivel 3: Pruebas de integración
Nivel 3: Prueba del sistema
Nivel 3: Test de aceptación
Calendario de pruebas:
- Envío del plan - Día 1
- Diseño de casos de prueba - Dia 2
- Ejecución en seco y corrección de errores - Día 4
- Revisar- Dia 5
- Carrera formal - Día 6
- Entregables enviados para aprobación - Día 8
- Informes - Día 10
Ejecutar la creación del plan: El plan de ejecución marca el número de ejecuciones necesarias para la prueba. Cada carrera que realice fuera del sitio será anotada por el equipo en el sitio.
Por ejemplo, cuando usas el Herramienta profesional HP Quick Test para la ejecución, el número de ejecuciones se mostrará en la pestaña Ejecuciones del plan de prueba.
Requisitos de hardware, software y personal:
- Requisitos de hardware y software como los dispositivos, versiones de navegador, IOS, herramientas de prueba necesarias para el proyecto.
- Dotación de personal significa designar a las personas necesarias para realizar las pruebas. Puedes mencionar el recuento de equipos aquí.
- En caso de que necesite miembros de prueba adicionales, puede solicitarlo en el sitio según el alcance de la prueba. Simplemente, cuando aumenta el número de casos de prueba, implica que necesita más miembros del equipo para ejecutarlos.
Funciones y responsabilidades: Esto implica asignar tareas a los roles relacionados responsables de llevar a cabo los distintos niveles de prueba.
Por ejemplo,
Una aplicación debe ser probada por un equipo compuesto por 4 miembros para ejecutar 4 protocolos de validación y puede delegar las responsabilidades de la siguiente manera:
- Cable de prueba: Diseño de plan de prueba
- Miembro del equipo 1: Diseño y ejecución de protocolos 1,2.
- Miembro del equipo 2: Diseño y ejecución de protocolos 3,4.
- Miembro del equipo: Elaboración de informes, revisión y métricas.
Supuestos y dependencias: Esto significa que las suposiciones hechas durante el diseño y las dependencias identificadas para las pruebas se incluirán aquí.
Riesgos y mitigación: Riesgos relacionados con la planificación de la prueba, como la disponibilidad de los entornos deseados, la construcción, etc. junto con los planes de mitigación y contingencia.
Informe y métricas: Los factores que se utilizaron para las pruebas y los informes a las partes interesadas deben mencionarse aquí.
A continuación, se proporciona un ejemplo de una aplicación móvil:
Calificación de instalación
- La calificación de la instalación contiene detalles como cuáles y cuántos entornos de prueba se usarían, qué nivel de acceso se requiere para los probadores en cada entorno junto con los datos de prueba requeridos. Puede incluir compatibilidad con el navegador, herramientas necesarias para la ejecución, dispositivos necesarios para la prueba, etc. El sistema que se está desarrollando debe instalarse de acuerdo con los requisitos del usuario.
- Es posible que se requieran datos de prueba para probar algunas aplicaciones y deben ser proporcionados por la persona adecuada. Es un requisito previo vital.
- Algunas aplicaciones pueden requerir una base de datos. Tenemos que mantener todos los datos necesarios para las pruebas listos en una base de datos para validar las especificaciones.
Por ejemplo, Una nueva aplicación dice que 'abc' debe probarse en el móvil (Android 4.3.1) y el navegador (Chrome 54), en tal caso, tenemos que realizar un seguimiento de lo siguiente:
- Verifique si se otorga la autorización adecuada para verificar el sitio de la aplicación 'abc'.
- Vea si los dispositivos utilizados para probar la aplicación como dispositivos móviles (android / ios), navegador Chrome, Internet Explorer con la versión requerida, están disponibles.
- Compruebe si están instalados correctamente con las versiones especificadas (por ejemplo: Chrome 54, versión de Android 4.3.1).
- Asegúrese de que se pueda acceder a la aplicación tanto en el navegador como en el móvil.
Calificación operacional
La calificación operativa asegura que cada módulo y submódulo diseñado para la aplicación bajo prueba funcione correctamente como se espera en el entorno deseado.
Una prueba de validación, en general, se lleva a cabo en la siguiente jerarquía.
Las pruebas funcionales juegan un papel importante en las pruebas de validación. Simplemente significa que debe validar la funcionalidad de la aplicación según todos y cada uno de los requisitos críticos mencionados. Esto allana el camino para mapear los requisitos mencionados en el documento de Especificaciones funcionales y garantiza que el producto cumpla con todos los requisitos mencionados.
Pruebas funcionales y sus tipos
Como el nombre sugiere, La prueba funcional consiste en probar las funciones, es decir, lo que tiene que hacer el software. Las funcionalidades del software se definirán en el documento de especificación de requisitos.
Echemos un vistazo rápido a sus tipos.
# 1) Prueba unitaria:
La prueba unitaria consiste en probar las unidades / módulos / componentes / métodos individuales del sistema dado. La validación de campo, control de diseño, diseño, etc., se prueban con diferentes entradas después de la codificación. Cada línea del código debe validarse para los casos de prueba de unidades individuales.
Las pruebas unitarias las realizan los propios desarrolladores. El costo de corregir errores es menor aquí en comparación con los otros niveles de prueba.
convertidor de youtube a mp4 en línea gratis sin descarga
Ejemplo:
Al evaluar un bucle del código para una función, la elección de género es un ejemplo de prueba unitaria.
# 2) Prueba de caja negra:
Probar el comportamiento de una aplicación para las funcionalidades deseadas frente a los requisitos sin enfocar los detalles internos del sistema se llama prueba de caja negra. Por lo general, lo realiza un equipo de prueba independiente o los usuarios finales de la aplicación.
La aplicación se prueba con entradas relevantes y se prueba para validar si el sistema se comporta como se desea. Esto se puede utilizar para probar tanto los requisitos funcionales como los no funcionales.
# 3) Prueba de caja blanca:
Prueba de caja blanca no es más que una verificación detallada del código del programa por código. Todo el funcionamiento de la aplicación depende del código escrito, por lo que es necesario probar el código con mucho cuidado. Debe verificar cada unidad y su integración como un módulo completo paso a paso.
Un evaluador con conocimientos de programación es un criterio imprescindible aquí. Esto descubre claramente si hay alguna desviación en el flujo de trabajo de la aplicación. Es útil tanto para los desarrolladores como para los probadores.
# 4) Prueba de caja gris:
La prueba de caja gris es una combinación de pruebas de caja blanca y caja negra. Aquí se conoce el conocimiento parcial sobre la estructura o el código de la unidad a probar.
Pruebas de integración y sus tipos
Los componentes individuales del software que ya se prueban en las pruebas unitarias se integran y prueban juntos para probar sus funcionalidades en su conjunto, a fin de garantizar el flujo de datos a través de los módulos.
Esto lo hacen los propios desarrolladores o un equipo de pruebas independiente. Esto se puede hacer después de probar dos o más unidades.
Enfoque de arriba hacia abajo:
En este enfoque, las unidades superiores se prueban primero y luego las unidades de nivel inferior se prueban una por una paso a paso. Los talones de prueba que se pueden utilizar son necesarios para simular las unidades de nivel inferior que pueden no estar disponibles durante las fases iniciales.
Enfoque de abajo hacia arriba:
En este enfoque, las unidades inferiores se prueban primero, se integran y luego se prueban las unidades de nivel superior. Los talones de prueba que se pueden utilizar son necesarios para simular las unidades de nivel superior que pueden no estar disponibles durante las fases iniciales.
Pruebas de sistemas y sus tipos
La prueba del sistema / software completo se denomina prueba del sistema. El sistema se prueba completamente contra las especificaciones de requisitos funcionales. Las pruebas del sistema se realizan en función de los requisitos funcionales y no funcionales. Generalmente, se prefiere la prueba de caja negra para este tipo de prueba.
# 1) Prueba de humo:
Cuando los constructores dan la compilación para probar inicialmente, tenemos que probar la compilación a fondo. A esto se le llama prueba de humo. Necesitamos indicar si la compilación es capaz de realizar más pruebas o no.
Para realizar la validación, necesita una compilación adecuada. Por lo tanto, la prueba de humo la realiza en primer lugar el equipo de prueba. El flujo de trabajo de la aplicación probada debe probarse con los casos de prueba o sin ellos. El caso de prueba que cubre todo el flujo es útil para esta prueba.
# 2) Prueba de cordura:
En las pruebas de cordura se prueban las principales funcionalidades de los módulos de la aplicación bajo prueba. Al probar un sitio web que tiene 3 pestañas, es decir, creación de perfil, educación, inicio de sesión, etc., en IRCTC , las principales funcionalidades de todas estas pestañas deben comprobarse sin profundizar mucho más.
Los menús, submenús y pestañas deben probarse en todos los módulos. Es un subconjunto de las pruebas de regresión, ya que las pruebas se realizan solo del flujo principal y no en profundidad.
# 3) Prueba de regresión:
Para cada lanzamiento del proyecto, el equipo de desarrollo puede introducir ciertos cambios. Validar si los nuevos cambios introducidos no han afectado el flujo de trabajo del sistema se denomina prueba de regresión. Aquí solo deben probarse ciertos casos de prueba pertenecientes a los nuevos requisitos.
Calificación de desempeño
UAT (prueba de aceptación del usuario):
Esta es la última fase de prueba que se realiza para garantizar que el sistema se comporta como se requiere en correspondencia con los requisitos especificados. Esto lo hace el cliente. Una vez que el cliente certifica y aprueba las pruebas del sistema, el producto puede implementarse.
Pruebas alfa y beta:
Los desarrolladores realizan las pruebas alfa de la aplicación antes de su lanzamiento en el sitio de desarrollo de software. Implica pruebas de caja en blanco y negro. Las pruebas beta se realizan en el lado del cliente después de que se desarrolla e implementa el producto.
Ejemplos de casos de prueba de validación o protocolo
Con mi experiencia, he escrito este protocolo para iniciar sesión en Gmail.
La verificación en profundidad de la funcionalidad de inicio de sesión cubierta es lo que realmente es la validación. Pero me gustaría mencionar que el estilo de las columnas de oraciones utilizadas puede diferir completamente y depender de los requisitos del cliente.
=> Descargar ejemplos de casos de prueba de validación: Caso de prueba de inicio de sesión de Gmail
Conclusión
Bueno, la validación se trata de analizar en detalle las funcionalidades de un producto. Como probador de validación, siempre debe recordar informar las desviaciones en ese momento para obtener resultados óptimos en las pruebas.
herramientas utilizadas por el analista empresarial para la recopilación de requisitos
Cada caso de prueba que se escriba debe ser nítido, conciso y comprensible incluso para el hombre común. El probador de validación debe asegurarse de que se esté desarrollando el producto correcto en función de los requisitos especificados.
Como guía para las pruebas de validación, he cubierto el proceso asociado con la validación.
Calificación de diseño que involucra el plan de validación, Calificación de instalación que se refiere a la instalación de hardware-software, Calificación de operación que involucra la prueba del sistema completo, Calificación de desempeño que involucra la prueba de aceptación del usuario que otorga la autorización para la producción.
¡Espero que este artículo haya enriquecido sus conocimientos sobre el concepto de pruebas de validación!
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Pruebas alfa y beta (una guía completa)
- Diferencias clave entre las pruebas de caja negra y las pruebas de caja blanca
- Pruebas funcionales versus pruebas no funcionales
- Descarga del libro electrónico Testing Primer
- Guía completa de pruebas de verificación de compilación (pruebas de BVT)
- ¿Qué es la prueba del sistema? Una guía definitiva para principiantes
- Guía de pruebas de seguridad de aplicaciones web