Pruebas técnicas (capacidad y vulnerabilidad) sobre aplicaciones
El objetivo del plan de pruebas es documentar cada requerimiento de prueba y cómo estas pruebas serán realizadas. para el caso particular las pruebas de capacidad y vulnerabilidad. lo primero que se debe hacer es realizar la identificación del requerimiento de pruebas, esto es asignar un código de prueba, identificar el proceso/ sub-proceso de negocio en que se enmarca la prueba, definir la fecha de creación, el autor y el área de trabajo donde se define y ejecuta. todo lo anterior, con el fin de contextualizar al auditorio que recibirá el resultado de la prueba, como un auditor, un supervisor, etc.
Seguidamente se recomienda realizar una descripción del proceso a probar, identificar el diagrama de arquitectura de la aplicación, diagrama de arquitectura de la solución o servicio tecnológico y el diagrama de interfaces.
La planeación y ejecución de las pruebas de capacidad y vulnerabilidad deben articularse con las demás actividades y pruebas del proyecto y compromisos de la infraestructura tecnológica “ambientes no productivos”, para tal fin se debe tener en consideración los cronogramas de proyectos y procesos que se vean comprometidos, como pruebas funcionales, capacitaciones, paralelos, desarrollos, contrataciones, etc.
Premisas para el inicio de las Pruebas al Software
Se debe contar con un ambiente que permita realizar las pruebas, este ambiente debe encontrarse congelado. Debe estar garantizada la disponibilidad de tiempo del responsable del software a probar, para realizar reuniones de presentación, entregas parciales, comités de pruebas y definición de posibles cambios. Hay que disponer de documentación actualizada y debidamente aprobada. Es de tener en cuenta que cualquier actualización de la documentación deberá ser comunicada formalmente al gerente del proyecto.
Alcance de las pruebas técnicas (capacidad y vulnerabilidad) sobre aplicaciones:
Las Pruebas de Capacidad pueden ser: 1) Pruebas de carga: Con la participación o simulación de usuarios concurrentes en el uso de la aplicación, identificando tiempos de respuesta de aplicación, Base de Datos y otros componentes del servicio. Objetivo identificar restricciones dentro de los componentes del servicio. 2) Prueba de estrés: Se simula la concurrencia de usuarios hasta encontrar falla en el sistema, identificando límites de capacidad. 3) Prueba de estabilidad: Se simula la concurrencia alta de usuarios sin llegar a punto de falla en el sistema, se hace persistente la demanda de peticiones, durante un periodo determinado y se identifica la capacidad del sistema para soportar la persistencia de carga. Y 4) Pruebas de picos: Se simula la concurrencia alta de usuarios sin llegar a punto de falla en el sistema, se reduce la cantidad de concurrencia, nuevamente se simula la concurrencia alta de usuarios sin llegar a punto de falla en el sistema, se repite durante un periodo determinado de tiempo los pasos anteriores y se identifica la capacidad del sistema para soportar los picos de carga.
Con el fin de focalizar las pruebas, se dispone de estadísticas de volumetría de transacciones.
Las Pruebas de Vulnerabilidad son: 1) Pruebas de Vulnerabilidad a todos los servicios e integraciones y al host que contenga los servicios. 2) Aseguramiento de la transmisión, las carpetas compartidas, FTP, etc. 3) Sitios Web (Portal). Y 4) Pruebas a los servidores (sistema operativo).
Documentación requerida.
A partir de los demás proceso y actividades del proyecto, es posible obtener documentos de casos de uso, manual de usuario, manual de instalación, pruebas unitarias, certificación de pruebas técnicas, documento de casos de prueba; elementos que permitirán una mayor y mejor comprensión de las funcionalidades. Por otro lado, se debe apropiar la información disponible en el diagrama de arquitectura de la aplicación, diagrama de arquitectura de la solución o servicio tecnológico, el diagrama de interfaces y los modelos entidad relación; de esta actividad depende la oportunidad con la que se identifique y diagnostique las desviaciones encontradas en las pruebas.
Otros factores que controlar
Es necesario definir y controlar los usuarios permisos y roles necesarios para la prueba; hacer identificación de riesgos durante la prueba. Definir un plan de mitigación de riesgos; definir planes para prevenir o mitigar cada riesgo detectado (tanto los riesgos del proyecto como los del producto) y resolverlos en caso de que ocurran. Dentro de los riesgos posibles a ser gestionados se tienen: falta del recurso humano para la ejecución de la prueba (Líder técnico, Funcional), disponibilidad del soporte técnico, disponibilidad del ambiente de pruebas, disponibilidad del soporte técnico por parte de proveedores, falta de integración de los procesos internos que intervienen.
Se hace necesario definir un cronograma del proyecto de pruebas; definiendo actividades, estimado en horas, fecha estimada de inicio, fecha estimada final, fecha terminación de la prueba y responsable.
Finalmente se hace necesario definir los criterios de finalización de la prueba y criterios de devolución - suspensión o cancelación.
No hay comentarios:
Publicar un comentario