EVALUACIÓN DE SISTEMAS QA

Principios para la calidad del software. Parte I

Jesús De La Fuente V.

EVALUACIÓN DE SISTEMAS QA

Instituto IACC

23/08/2021

Desarrollo

1.- Considerando los elementos descritos en el problema a continuación detallo plan de trabajo para análisis de errores y plan de prueba para “La Casa Del Software”.

Tomando en cuenta que la empresa esta presentando fallas en los programas (software) de control de Recursos Humanos debemos aplicar una “Verificación” donde es necesario definir:

• Requerimientos funcionales.
• Requerimientos no funcionales.
• Historias de usuario ( incluyendo casos de uso)

Además, debemos aplicar una “Validación” que debe contener los siguientes puntos:

• Alcance del software.
• Reglas y términos del negocio.
• Entornos de ejecución del software (Requisitos mínimos de equipo como: sistema operativo, Red etc.)

2.- Para el plan de pruebas existen varios elementos a considerar para establecer un correcto plan, los cuales detallaré a continuación:

• Niveles:  Corresponde a la “profundidad” de las pruebas realizadas en el software, estas se dividen en :

• Pruebas de componente.
• Pruebas de integración.
• Pruebas de sistema.
• Pruebas de aceptación (1)

• Objetivos: Definir el resultado del proyecto y su utilización.
• Calendario de ejecución:  corresponde a la planificación para la ejecución de procedimientos de prueba.
• Actividades de preparación: Cuales serán las pruebas escogidas y que necesitaremos para realizar las pruebas.
• Factores de estimación: Cuanto nos demoraremos en realizar todas las pruebas estimando una cantidad de tiempo razonable entre cada una de las pruebas.
• Criterios de Entrada y Salida: Cuando iniciar las pruebas, de acuerdo con el entorno, Herramientas, Código y Datos de prueba ( para los criterios de entrada) y Cuando detener las pruebas, Medidas de exhaustividad, Estimación de defectos, Coste, Riesgos y Calendarios para los criterios de Salida.

3.- Para las estrategias de pruebas considere la utilización de pruebas analíticas en primera instancia pues debemos establecer los requisitos y riesgos del software actual. Debemos diseñar las pruebas con un usuario conocedor del negocio para priorizar y enfocar las pruebas en los errores. Luego utilizaría una estrategia dirigida, considerando al usuario experto en el dominio del negocio para considerar y diferenciar el comportamiento esperado versus el mostrado por la herramienta.

Y, por último, utilizaría una estrategia reactiva, donde una vez obtenido el feedback de las estrategias analíticas y dirigidas, probaría la herramienta para validar los eventos que ocurren durante la ejecución de la misma.

4.- En mi experiencia, para realizar pruebas de un software que se encuentra en ambiente productivo, es necesario tener un “clon” o copia de el mismo diseño y versión del sistema, pero en un ambiente seguro y controlado como por ejemplo un ambiente “Testing” o TST, y además de un ambiente de “Desarrollo” que permita realizar pruebas funcionales y no funcionales, llevando al software a limites de carga y de funcionamiento.

En estos ambientes de pruebas es posible ejecutar múltiples tipos de prueba como también adicionar software que nos permitan “romper” nuestro código, estresando el sistema y permitiendo dilucidar errores e inconvenientes ya sea en tiempo de pruebas como en tiempo de ejecución.

Para estas pruebas en ambientes “testing” es posible utilizar softwares simples como “Sonarqube” que analizan nuestro código y evidencian potenciales problemas de Frameworks, librerías y demases. Por otro lado, si tenemos integraciones ya sea a servidores intermedios o a través de “Apis” es posible utilizar clientes como “Postman” que permite consultar directo a una api y ver la respuesta de esta. En definitiva en el mercado se encuentran múltiples herramientas y suites de las mismas que aúnan diferentes herramientas que permiten asegurar la calidad de nuestros entregables. ( Jmeter, Hp LoadRunner, Wget, Fiddler etc.) que en sus múltiples combinaciones permiten probar nuestros desarrollos.

...