Tipos de pruebas basadas en lo que detectan (Pruebas estáticas)

 

¡Hola!

Continuando con el tema de Tipos de pruebas de software el día de hoy daré comienzo al tópico tipos de pruebas basadas en lo que detectan, estas son las pruebas estáticas (la cuales detectan defectos) y las pruebas dinámicas (las cuales detectan fallas). En esta primera parte trataré las pruebas estáticas y sus elementos.

Para iniciar vamos a definir las pruebas estáticas estas son técnicas de pruebas de software las cuales consisten en la revisión de la documentación del producto de software, dígase la especificación de los requerimientos, diagramas o incluso el código fuente sin ser ejecutado. Su objetivo es verificar y validar que dichos documentos cumplan con lo establecido previamente.

Estas pruebas se dividen en dos tipos:

El Análisis estático el cual se enfoca en detectar defectos en el código fuente del producto de software evaluando el cumplimiento de normas o estándares, las buenas prácticas, la estructura de datos y flujo de control, puede llevarse a cabo con un editor de código como Sublime Text o Visual Studio Code.

Las Revisiones, por otro lado, se centran en los productos de trabajo, es decir, la documentación que se genera a lo largo del ciclo de vida del software, con el objetivo de identificar inconsistencias en estos, se evalúa si obedecen a lo solicitado.

Estas últimas pueden ser formales e informales:

Las revisiones formales: Siguen un proceso definido en cuál se genera documentación, dependiendo del nivel de formalidad de la revisión, antes, durante y posteriormente a su ejecución, además de esto cuentan con roles definidos.

Revisiones informales: No siguen un proceso claro o especifico y no requieren de documentación.

Una buena práctica sería elegir el tipo de revisión basándonos en el contexto del sistema a desarrollar, el capital humano disponible, cuáles roles serán requeridos y los aspectos técnicos.

Pero ¿Cuáles son esos roles?, pues los roles en las revisiones pueden ser:

Autor: Es la persona que creo en producto o elemento bajo prueba.

Escriba: Es quien se encarga de anotar lo discutido durante las revisiones.

Revisores: Son las personas encargadas de realizar las revisiones, es decir, son quienes principalmente evalúan los productos.

Líder: Es quien se encarga de dirigir las revisiones y es la persona responsable de estas.

Facilitador: Su función es moderar la reunión de revisión.

Director: Es la persona encargada de la planificación y el control de la revisión.

Estos roles se incluyen dependiendo del nivel de formalidad de la revisión, según esto las revisiones pueden ser:

Informal: Como se mencionó anteriormente no cuentan con documentación, además de esto, no requieren de una reunión, se puede llevar a cabo entre colegas, en ocasiones se utilizan listas de comprobación, pero no es un requerimiento.

Guiada: En este tipo de revisiones el autor del producto es quien dirige la revisión, requieren de un escriba, la preparación previa a la revisión no es necesaria y al igual que en las revisiones informales las listas de comprobación no son obligatorias.

Técnica: Se realizan entre pares técnicos, es decir, con la ayuda de expertos que puedan ayudar a mejorar el producto de trabajo, en caso de llevar a cabo una reunión, se debe contar con preparación individual antes de esta, en este tipo de revisión se requieren los roles de facilitador, autor y escriba.

Inspecciones: Están en el nivel más alta de formalidad, los resultados de estas se documentan, necesita de preparación individual previa a la reunión de revisión, cuenta con roles definidos los cuales son autor, director, facilitador, escriba, revisores y líder de revisión y las listas de comprobación son obligatorias.

 

¡Pero espere aún hay más! También contamos con técnicas de revisión, estas son:

 

Ad Hoc: El producto software se entrega a los revisores sin guía o preparación previa sobre cómo proceder con el producto ni qué buscar, también se conoce como lectura sin Checklists (Lista de comprobación). Los revisores estudian el producto de trabajo y a medida que van identificando los defectos los van documentando.

 

Basada en listas de comprobación: Esta técnica busca proporcionar un mayor soporte mediante preguntas que los revisores deben de responder mientras leen el producto de trabajo. Es decir, esta técnica proporciona listas que ayudan entender qué tipo de faltas buscar. Estas listas suelen ser productos basados en la experiencia de quien o quienes la crean.

 

Basada escenarios: Se basa en el uso esperado del producto de trabajo descrito en un documento, su objetivo es proporcionar una guía al revisor (escenarios que pueden ser preguntas o de casos de uso) sobre cómo realizar la evaluación del producto del trabajo. Esta técnica permite limita la atención de la persona que realiza la revisión en la detección de defectos particulares definidos por la guía.

 Basada en roles: Los revisores evalúan el producto de trabajo desde el punto vista de los usuarios, ya sean expertos, inexpertos, adultos, niños, mayores, etc. O roles propios de la organización como un administrador de usuarios, administrador de sistemas o un probador del rendimiento.

Basada en perspectiva:  Establece que un producto debería revisarse bajo las perspectivas de los distintos participantes en un proyecto de desarrollo. Estas dependen del papel que los distintos participantes tienen en el proyecto. Para cada perspectiva se definen uno o varios escenarios en actividades repetibles que un revisor debe llevar a cabo y preguntas a las cuales debe dar respuestas.

El proceso de revisión cuenta con varias fases o etapas, las cuales son:

Planificación:  Durante esta actividad se define el alcance, se seleccionan los participantes, a los cuales se debe asignar roles y preparar el cronograma de la revisión

Inicio de la revisión: distribuir el material e informar a los participantes en la revisión.

Revisión Individual: Cada participante evalúa de manera particular el material proporcionado o los elementos bajo prueba y realiza anotaciones sobre los defectos encontrados.

Análisis e informe defectos:  En esta fase se comunican los defectos encontrados a las personas responsables, por ejemplo, el desarrollador o el analista del sistema. Se evalúa si son realmente defectos y en caso de serlo cual sería el impacto que tendrían en el sistema.

Corregir e informar: En esta fase se crean informes sobre lo encontrado, se recompilan métricas y se confirman los criterios de salida.

La prueba estática son una buena forma de encontrar defectos en etapas tempranas del ciclo de vida de desarrollo de software, recordemos, cuanto más lejos llegamos con un defecto más costoso será repararlo. Estas se complementan con las pruebas dinámicas las cuales serán tratadas en la segunda parte de este tópico.

Para redactar este artículo me basé en el contenido disponible en la plataforma full advanced referentes al capítulo tres de su curso fundamentos de pruebas de software. (https://www.fulladvanced.com)

Esto es todo por hoy, espero que este artículo te sea de utilidad y si es así te invito a compartirlo con tus colegas y amigos, cualquier duda u observación del tema déjala en la sección de comentarios será un placer responder.

 

¡Gracias por leer!