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.
