Pruebas estáticas y pruebas dinámicas: diferencia entre estas dos importantes técnicas de prueba

static testing dynamic testing difference between these two important testing techniques

La prueba es Verificación y validación . Todos sabemos que se necesitan 2 V para completar las pruebas.

En el artículo de hoy, arrojaremos algo de luz sobre Prueba estática . También se llama Verificación. Aprenderemos todo al respecto y pondremos especial énfasis en esto porque Prueba dinámica a menudo recibe la máxima atención y tiene innumerables artículos que lo detallan.

Sin embargo, ninguna discusión sobre las pruebas estáticas estaría completa sin una explicación de lo que significa su contraparte, las pruebas dinámicas. La prueba dinámica es validación, la otra 'V'.

Las pruebas dinámicas son cuando se trabaja con el sistema real (no con algún artefacto o modelo que represente el sistema), proporcionando una entrada, recibiendo salida y comparando la salida con el comportamiento esperado. Es un trabajo práctico con el sistema con la intención de encontrar errores.

Durante este proceso, entenderemos cómo los siguientes dos conceptos erróneos comunes sobre las pruebas no son ciertos:

1. La prueba es una actividad que llega al final
2. Lo realizan solo testers y el resto no tienen nada que hacer

Comencemos con una referencia rápida al modelo v :

• Sobre el lado izquierdo del modelo V, tenemos actividades que no son realizadas por el equipo de QA.
• Sobre el lado derecho , tenemos algunos de ellos que son atendidos por el equipo de desarrollo, algunos por los probadores y otros por los usuarios.

Empecemos con - Recopilación de requisitos . Lo lleva a cabo el analista de negocios y otros administradores de nivel superior; el documento de salida para esta fase es el documento de requisitos comerciales, BRD.

qué descargador de videos mp4 es compatible con youtube

La siguiente etapa es la Diseño de sistemas . El diseño del sistema es una fase en la que los requisitos comerciales se traducen en requisitos funcionales, en el FRD (documento de requisitos funcionales).

Cuando se lleva a cabo la traducción, el equipo de desarrollo (que es el actor principal en este paso) revisará el documento BRD paso a paso, página por página y línea por línea. Aunque el objetivo principal es consumir los requisitos comerciales por el bien de la traducción, el documento BRD se está revisando a su vez.

Un ejemplo: Digamos que este es el BRD para un sitio bancario que tiene una gran seguridad. Hay una sección en el BRD que habla sobre las reglas de contraseña para los distintos usuarios que crean una cuenta en el sitio de banca en línea. Una de las reglas es: Un usuario no puede usar una contraseña que usa para otras cuentas.

Esto no es posible. Porque, un sitio puede simplemente sugerir cómo el usuario debe establecer las credenciales de inicio de sesión, pero no hay forma de que se pueda imponer esta restricción. Por lo tanto, este requisito no es factible; en otras palabras, no se puede lograr a través del software.

Consideremos ahora los siguientes puntos basados ​​en este ejemplo:

1. ¿Cómo se determina que este requisito no se puede construir y, por lo tanto, no se puede probar (en otras palabras, no es factible)? ¿Tenemos el sitio del banco y luego establecemos el nombre de usuario y la contraseña, y luego nos damos cuenta de que esto no es posible? No, simplemente basamos esto en nuestra revisión del BRD y, por supuesto, en un sentido comercial común.
2. ¿Estamos probando este requisito? Seguro, pero puramente basado en el sentido conceptual teórico, pero no en el AUT (Aplicación bajo prueba) real.
3. ¿Cuál es la forma física de esta prueba? -Una lectura simple o una revisión formal del BRD o un análisis de viabilidad aún más formal de los requisitos comerciales.

Volviendo a nuestros conceptos erróneos:

4. ¿Quién está realizando esta revisión del BRD? - Principalmente el equipo de desarrollo y otros equipos técnicos que son responsables de crear el producto. No probadores.
5. ¿Continúa esta revisión al final de la creación del producto? No, en la etapa inicial del desarrollo del proyecto. Por lo tanto, no solo el final.

Técnicas de prueba estática:

En resumen, las pruebas estáticas son la parte de verificación de las pruebas de software que siguen los métodos de:

• Revisiones de documentos
• Tutoriales
• Inspección
• Análisis de viabilidad o cualquier otra forma de análisis para determinar si el software es lo que debería ser o no
• Revisión de código

Para citar el CSTE CBOK, 'La verificación responde a la pregunta:' ¿Creamos el sistema correcto? ' mientras que las validaciones abordan, '¿Creamos el sistema correctamente?'

Las siguientes son todas las actividades de prueba estáticas que ocurren en el lado izquierdo del modelo V.

Nota: Esta información se puede extrapolar para proyectos que sigan cualquier metodología de desarrollo, ya que los pasos serán más o menos similares.

En el lado derecho del modelo V está la validación.

Técnicas de prueba dinámica:

• Examen de la unidad
• Pruebas de integración
• Prueba del sistema

Las fases de Unidad, integración, sistema y UAT tienen que ver con la creación de pruebas que se realizarán en el AUT durante las distintas etapas de su desarrollo. Aunque las pruebas están destinadas a validar diferentes tipos de requisitos, todas son pruebas de todos modos.

Por lo tanto, cualquier forma de prueba en la que tengamos una prueba que deba ejecutarse en un AUT y su salida sea necesaria para determinar el resultado de la prueba (exitosa o no), es validación.

Ahora, ¿estaría bien generalizar que en el lado derecho (RHS) del modelo V no hay verificación alguna? La respuesta es no.

Todas las pruebas que se crean en cada etapa del RHS se revisan varias veces durante la etapa de creación / finalización de la prueba. El proceso detallado de revisión de la documentación de prueba se encuentra en https://www.softwaretestinghelp.com/test-documentation-reviews/

En el RHS:

• Los desarrolladores revisan las pruebas y el código en las etapas de prueba de Unidad / Integración.
• Las pruebas del sistema se someten a una revisión por pares durante su documentación y, una vez finalizadas, el equipo de desarrollo y el analista empresarial las revisan.
• Las pruebas de UAT se someten a una revisión por parte del equipo de control de calidad y de los usuarios antes de que comience la UAT.

Conclusión

En conclusión, las pruebas estáticas son una técnica de prueba importante que toma la forma de revisión de requisitos comerciales, revisión de requisitos funcionales, revisiones de diseño, recorridos de código y revisión de documentación de prueba. Es una actividad continua y no solo realizada por probadores.

Validación, la parte de prueba dinámica es más práctica y ocurre en el producto en sí y no en un artefacto o una representación del producto. Un proceso mucho más formal de identificación de casos / condiciones de prueba, consideraciones de cobertura, ejecución e informes de defectos marcan los métodos de prueba dinámicos.

Sobre el autor: Este artículo fue escrito por Swati S., miembro del equipo de STH.

Comparta sus comentarios, preguntas y experiencias sobre el tema de las pruebas estáticas y dinámicas.

Lectura recomendada

• Diferencia entre pruebas de escritorio, cliente-servidor y pruebas web
• Técnicas de estimación ágil: una estimación verdadera en un proyecto ágil
• Prueba de caja negra: un tutorial detallado con ejemplos y técnicas
• ¿Qué son las pruebas de conformidad (pruebas de conformidad)?
• ¿Cuál es la diferencia entre las pruebas SIT y UAT?
• Pruebas alfa y beta (una guía completa)
• Diferencias clave entre las pruebas de caja negra y las pruebas de caja blanca
• Las diferencias entre pruebas unitarias, pruebas de integración y pruebas funcionales