“Diferencia entre la estrategia de prueba y el plan de prueba”, primero necesitamos ver su definición individual. Pruebas de software
La estrategia de prueba es un documento de alto nivel que define el enfoque para las pruebas de software. Básicamente, se deriva del documento de requisitos comerciales. La estrategia de prueba es desarrollada por el gerente de proyecto o analista de negocios. Es un tipo de documento estático que establece los estándares para las pruebas, por lo que no se actualiza con frecuencia.
El plan de prueba se deriva de SRS (Especificación de requisitos de software), que es preparado por el jefe de prueba o el gerente. El objetivo principal del plan de prueba es incluir todos los detalles relacionados con la prueba, como qué probar, cuándo realizar la prueba, cómo realizar la prueba y quién será el evaluador. El plan de prueba a menudo no se actualiza, pero si hay alguna característica nueva o se introduce un cambio, entonces debe actualizarse en consecuencia.
- ¿Cuál debe ser mi puntaje en KCET para obtener un puesto en CSE en RV college?
- ¿Puede alguien ayudarme con la preparación del GRE?
- Cómo obtener de 700 a 800 puntos en SHSAT
- ¿Puedo alcanzar un rango de tres dígitos si comienzo para IIT JEE 2018 ahora?
- Si alguien obtuvo AWA 3.0 en GRE, ¿debe volver a realizar la prueba?
Ahora, vamos a hacer una lista de puntos que se incluyen en ambos respectivamente.
La estrategia de prueba contiene:
1. Alcance y objetivo: el objetivo de la empresa y la cantidad de alcance de las pruebas se define en la estrategia de prueba.
2. Problemas de negocios: ¿cuánto es el presupuesto del proyecto, cuánto tiempo se requiere para las pruebas, cuántos recursos se necesitan, etc.? Son la parte de los problemas de negocios que deben considerarse antes de que comience la prueba real.
3. Método de prueba: qué tipo de prueba se necesita (rendimiento, carga, estrés, etc. funcional) y si la prueba es solo manual o automatizada o ambos son algunos de los puntos cruciales que definen el método de prueba.
4. Entregables de prueba: ¿Cuáles son los documentos requeridos por el equipo de prueba, cómo se mantendría el registro de los ciclos de prueba, etc., se incluirán aquí?
5. Enfoque de seguimiento de defectos: qué herramienta se utilizará para rastrear los defectos y cómo se comunicará el equipo de pruebas con el equipo de desarrollo y cómo se decidirá el flujo de defectos en este punto de la estrategia de prueba.
6. Capacitación: si se introduce alguna herramienta compleja o nueva en el negocio, es útil que los miembros del equipo reciban la capacitación adecuada. Aquí se define qué tipo de capacitación y la persona responsable para conducir dicha capacitación.
7. Automatización: si el proyecto o la empresa necesita pruebas de automatización, el lenguaje de script, la herramienta utilizada, los informes y el código actualizado se planifican en la estrategia de prueba.
8. Riesgos: Nadie puede anticipar todos los riesgos de antemano, pero se pueden evitar los riesgos obvios y también se puede incluir una solución (si se produce un riesgo) en el documento para obtener ayuda en el futuro.
El plan de prueba contiene:
1. ID del plan de prueba: esta es una ID única que define el plan de prueba. Puede ser un número o nombre o combinación de ambos, según la conveniencia.
2. Entorno de prueba: esta sección define qué tipo de entorno se necesita para que la prueba se lleve a cabo. Por ejemplo, en las pruebas de dispositivos, generalmente se realiza una configuración virtual para probar las llamadas de emergencia.
3. Funciones a probar / No probadas: Esto tendrá todos los detalles sobre las funciones que el probador necesita probar y cuáles son las funciones que no se probaron (puede ser porque aún no se implementó o no se probó para esa versión en particular) .
4. Criterios de entrada / salida: Estos son los términos que definen cuándo iniciar o detener la prueba. Los estándares se definirán según la estrategia de prueba y serán seguidos por los evaluadores en el plan de prueba.
5. Estado: ya sea que un caso de prueba se haya aprobado o no, o no haya sido probado, todos estos resultados de prueba se incluyen en el plan de prueba con una razón adecuada.
6. Tipos de pruebas: los tipos de pruebas requeridos, como regresión, funcional, no funcional, estrés, etc., son definidos y luego ejecutados por el comprobador respectivo.
7. Introducción de Breves: algunas veces también se incluye una breve introducción, de modo que si algún miembro nuevo se une al equipo, debe tener una idea de cómo funcionan las cosas.
Básicamente, el plan de prueba es la estrategia de prueba y la logística de prueba (herramientas utilizadas, configuración del entorno, etc.). La estrategia define qué enfoque debería estar allí para las pruebas y el plan tiene todos los detalles sobre cómo se ejecutarán esos enfoques de manera adecuada y planificada. Ambos van de la mano. El plan de prueba tendrá todos los nombres de los evaluadores que probaron un script en particular y también mantiene los números de ciclo, de modo que si alguna característica falla en este ciclo, se puede consultar el ciclo anterior para ver si esa característica en particular se pasó o falló, de esta manera es fácil obtener la raíz del problema y, por lo tanto, se vuelve fácil de resolver.
La estrategia de prueba no debe modificarse con mucha frecuencia porque establece algunos estándares para el plan de prueba y si las normas se modifican con frecuencia, se vuelve difícil seguir un plan en particular y el cambio de plan con frecuencia afectará la calidad de la prueba. A veces, cuando se modifican los requisitos pequeños, solo necesitamos actualizar el plan de prueba, pero la estrategia de prueba sigue siendo la misma.
