El proceso de prueba se clasifica en dos tipos: prueba estática y prueba dinámica . Las pruebas estáticas son diferentes de las pruebas dinámicas en el sentido de que las pruebas estáticas no implican la ejecución del programa o el software. Sin embargo, las pruebas dinámicas se realizan ejecutando el código del producto de software.
Por definición, la prueba estática es una técnica de prueba humana que no implica ejecutar o ejecutar el programa o producto de software. En cambio, implica verificar o monitorear el software en cada fase del ciclo de vida de desarrollo de software (SDLC) con los requisitos o estándares mencionados en las especificaciones de requisitos de software (SRS) del producto de software.
¿Por qué se requieren pruebas estáticas?
- Detección de errores/fallas en etapas anteriores:
mientras se crea un software, uno no puede depender únicamente de las pruebas dinámicas, ya que descubre los errores o fallas del producto de software en una etapa posterior, lo que podría costarle al desarrollador mucho tiempo y esfuerzo para depurarlo. . - Mayor tamaño del software:
a medida que aumenta el tamaño del producto de software, se vuelve difícil manejarlo a medida que disminuye la eficiencia de la cobertura del código. Es por eso que se requieren pruebas estáticas, ya que ayudan a eliminar errores o fallas antes en el software. - Las pruebas dinámicas requieren mucho tiempo:
aunque las pruebas dinámicas descubren el error y brindan algunos detalles sobre el error, sin embargo, aún requiere tiempo y esfuerzo corregir el error, ya que comprende detectar la falla desde el caso de prueba hasta la causa raíz, haciendo es un proceso difícil en conjunto. - Las pruebas dinámicas son costosas:
como se mencionó anteriormente, las pruebas dinámicas requieren casos de prueba y hacerlo en sí mismo es costoso porque los casos de prueba primero deben crearse, luego ejecutarse y validarse y también deben mantenerse, lo que resulta en mucho trabajo para los evaluadores.
Beneficios de las pruebas estáticas:
- Disminución del costo de SDLC: dado que
los errores se identifican en etapas anteriores de SDLC, se requieren menos esfuerzos y tiempo para modificar el producto y resolverlos, lo que reduce el costo total de SDLC. - Mayor calidad del producto:
cuando se detectan fallas en el software, se corrigen en ese momento, lo que conduce a una mayor calidad del producto. - Se rastrea la ubicación exacta del error:
en las pruebas estáticas, se puede rastrear la ubicación exacta del error, mientras que lo mismo no es posible fácilmente en el caso de las pruebas dinámicas. - Evaluación y comentarios inmediatos: la
evaluación del producto se realiza con frecuencia, lo que hace que el producto sea de mejor calidad, ya que se reciben comentarios inmediatos durante cada fase mientras se desarrolla el producto. - Mayor eficacia de las pruebas dinámicas:
a medida que el código se vuelve más limpio y mejor después de las pruebas estáticas, se requieren menos esfuerzos y tiempo para crear y mantener casos de prueba de buena calidad, lo que hace que las pruebas dinámicas sean más efectivas.
Tipos de pruebas estáticas:
1. Inspección de software:
El proceso de inspección se realiza en las primeras etapas del SLDC y se aplica a una parte específica del producto como SRS, código, diseño del producto. etc. Se trata de examinar manualmente los diversos componentes del producto en las primeras etapas. El proceso de inspección de software consta de seis fases que son las siguientes:
- Planificación de la reunión de inspección:
- Esta fase se enfoca en identificar el producto a inspeccionar y el objetivo de esta inspección.
- En esta fase se asigna un moderador, que gestiona todo el proceso de inspección.
- El moderador asignado verifica si el producto está listo para la inspección o no. El moderador también selecciona el equipo de inspección y les asigna sus funciones.
- El moderador también programa la reunión de inspección y distribuye el material requerido al equipo de inspección.
- Visión general –
- En esta fase, el equipo de inspección recibe toda la información de fondo para la reunión de inspección.
- El autor, que es el codificador o diseñador responsable de desarrollar el producto, presenta su lógica y razonamiento para el producto, incluidas las funciones del producto, su propósito previsto y el enfoque o concepto utilizado durante su desarrollo.
- Se asegura que cada miembro del equipo de inspección haya entendido y esté familiarizado con los objetivos y propósito de la reunión de inspección que se llevará a cabo.
- Preparación individual por miembros –
- En esta fase, los miembros del equipo de inspección se preparan individualmente para la reunión de inspección estudiando el material proporcionado en las fases anteriores.
- Los miembros del equipo identifican los posibles errores o fallas en el producto y los registran en un registro. El registro finalmente se envía al moderador. Luego, el moderador compila todos los registros recibidos de los miembros y envía una copia al autor.
- El inspector – quien es la persona responsable de verificar e identificar errores e inconsistencias en los documentos o programas, revisa el producto y registra los problemas encontrados en el mismo (tanto generales como específicos del área). El inspector registra los problemas o problemas en un registro junto con el tiempo dedicado a la preparación.
- El moderador revisa los registros para verificar si el equipo está listo y preparado para la reunión de inspección o no.
- Finalmente, el moderador envía todos los registros compilados al autor.
- Reunión de Inspección –
- Esta fase implica la discusión del autor sobre las cuestiones planteadas por los miembros del equipo en el registro compilado.
- Los miembros llegan a una decisión sobre si el problema planteado es un error o no.
- El moderador concluye la reunión y proporciona un resumen de la reunión, que es una lista de errores encontrados en el producto y que debe resolver el autor.
- Reelaboración –
- El autor realiza la reelaboración de acuerdo con la lista resumida presentada por el moderador en la fase anterior.
- El autor corrige todos los errores e informa al moderador.
- Hacer un seguimiento –
- El moderador comprueba si todos los errores se han resuelto o no. Luego, el moderador prepara un informe. Si se corrigen y corrigen todos los errores, el moderador publica el documento.
- De lo contrario, los problemas no resueltos se agregan al informe y se programa otra reunión de inspección.
2. Tutoriales estructurados:
este tipo de prueba estática es menos formal y de naturaleza no tan rigurosa. Tiene un proceso más simple en comparación con el proceso de inspección. Implica los siguientes cuatro pasos:
- Organización:
este paso implica la asignación de roles y responsabilidades al equipo seleccionado para los recorridos estructurales. El equipo puede estar formado por los siguientes miembros:- Coordinador: organiza y coordina con todos los miembros las actividades relacionadas con el recorrido.
- Presentador: presenta el elemento que se va a inspeccionar.
- Escriba: anota todos los problemas y sugerencias presentados por los miembros.
- Probador: encuentra los defectos o errores en el artículo que se va a inspeccionar.
- Mantenimiento Oracle: se centra en el mantenimiento futuro del producto.
- Portador de estándares: evalúa la conformidad con los estándares y las directrices.
- Representante del usuario: representa las necesidades y preocupaciones del usuario.
- Preparación –
- En este paso, el enfoque se encuentra en la preparación para los recorridos estructurales que podrían incluir pensar en casos de prueba básicos que serían necesarios para probar el producto.
- Tutorial –
- El tutorial lo realiza un probador que llega a la reunión con un pequeño conjunto de casos de prueba.
- El probador ejecuta mentalmente los casos de prueba y los resultados se anotan en un papel o en un medio de presentación.
- Reelaboración y Seguimiento –
- Este paso es similar al de las dos últimas fases del proceso de inspección.
- Si no se detectan errores, se aprueba el lanzamiento del producto. De lo contrario, los errores se resuelven y, nuevamente, se realiza un recorrido estructurado.
3. Revisiones técnicas:
Es una técnica de nivel superior en comparación con la técnica de inspección o recorrido porque también implica la gestión. Esta técnica se utiliza para valorar y evaluar el producto comprobando su conformidad con los estándares, directrices y especificaciones de desarrollo.
No tiene un proceso definido y la mayor parte del trabajo lo lleva a cabo el moderador, como se explica a continuación:
- El moderador recopila y distribuye el material y la documentación a todos los miembros del equipo.
- Moderator también prepara un conjunto de indicadores para evaluar el producto con respecto a las especificaciones y normas y directrices ya establecidas:
- consistencia
- documentación
- adhesión a las normas
- lo completo
- definición del problema y requisitos
- Los resultados se registran en un documento que incluye tanto defectos como sugerencias.
- Finalmente, se resuelven los defectos y se tienen en cuenta las sugerencias para mejorar el producto.