Para garantizar la calidad del producto de información en medicina, seguros, banca y otras industrias, junto con otros métodos de prueba, es importante utilizar pruebas basadas en el riesgo. Para la verificación, se seleccionan las áreas más riesgosas del software que se está creando. Esto nos permite anticipar escenarios negativos e implementar con éxito los objetivos comerciales del cliente.
En el artículo, diremos cómo en SimbirSoft trabajamos con los riesgos (usando el sistema de adquisición de Internet y otros proyectos como ejemplo) y qué métodos de evaluación y gestión de riesgos usamos en los proyectos de los clientes.
Riesgos al inicio del proyecto.
Para comenzar, damos un ejemplo de nuestra práctica en el desarrollo del sector bancario.
Propuesta del cliente: centrarse en la versión web del banco para particulares.
El riesgo que identificamos: una posible pérdida de audiencia debido a la baja demanda de la versión web para individuos, en contraste con el banco cliente móvil.
Nuestros argumentos: estadísticas de las preferencias de los usuarios basadas en revisiones y distribución de la audiencia por versiones móviles y web.
Conclusiones: para los individuos, la versión móvil es más conveniente, ya que el teléfono está siempre a mano. Las operaciones son rápidas, el sistema de autorización le permite acceder a todos los servicios convenientes. En este caso, es importante el acceso rápido a un conjunto limitado de las funciones más populares.
Para las personas jurídicas, la integridad de las funciones proporcionadas, la capacidad de cargar, imprimir y trabajar con una gran cantidad de información son importantes. Para esto, la versión web es más conveniente.
Nuestra solución: centrarnos en el banco de clientes móviles para particulares.
Al comienzo de trabajar con un proyecto, es importante elegir la estrategia de prueba correctamente. Veamos ejemplos de por qué es importante y cómo elegirlo.
La estrategia de prueba debe cumplir con los objetivos comerciales
Tarde o temprano, todas las empresas se enfrentan a la necesidad de organizar el proceso de prueba y llegan a comprender que desarrollar su estrategia es una etapa importante en el desarrollo de software. A veces, a través de su propia experiencia amarga. Es especialmente peligroso subestimar el papel de las pruebas y la selección de estrategias en el desarrollo de proyectos a gran escala. El proceso de prueba debe seleccionarse de acuerdo con los objetivos comerciales y los detalles del proyecto, de lo contrario no dará resultados positivos ni en un mes ni en un año.
Por ejemplo, considere probar aplicaciones móviles y web para un banco. Al comienzo del proyecto, seleccionamos una estrategia basada en los requisitos con un bajo nivel de detalle. Utilizamos listas de verificación para reducir el tiempo de prueba y apoyar la base de la prueba. Con el crecimiento de la funcionalidad, la adición de adquisición, sms-autorización y notificación, sistemas más complejos, las listas de verificación ya no hacen frente a su tarea. Con el tiempo, cada vez más especialistas en control de calidad se unieron al equipo, fue necesario transmitir información y coordinar sus acciones. Con la complicación del producto, cualquier cambio podría afectar las funciones relacionadas, es decir, el riesgo de regresión aumentó. La necesidad de automatización de las pruebas de regresión se estaba gestando, por lo que cambiamos a casos de prueba.
Conclusión: dependiendo del proyecto, sus detalles o etapa de desarrollo, la estrategia de prueba cambia.
La estrategia debe seleccionarse para los objetivos del proyecto a fin de garantizar la mejor calidad del producto. Ella responde las preguntas "qué", "dónde" y "cuándo" se evaluarán. En cualquier momento, usted sabe en qué momento se encuentra y de dónde vendrá en el futuro, de acuerdo con la estrategia.
Un objetivo comercial puede ser garantizar la seguridad de los datos del cliente, así como el software en sí en la etapa de producción. La seguridad comienza con el proceso de desarrollo y continúa durante la fase de prueba.
Por ejemplo, en uno de los proyectos, creamos un entorno seguro para el desarrollo y las pruebas, implementamos una infraestructura que cumplió con todos los requisitos y ayudó a proteger los datos. Solicitamos tokens certificados y unidades flash basadas en nombres para que cada especialista en control de calidad acceda a la infraestructura de prueba. Por lo tanto, garantizamos el objetivo comercial del proyecto en seguridad de software y mantuvimos la confidencialidad de los datos del cliente y del usuario.
Debido a la estrategia de prueba, se puede poner énfasis en aspectos realmente importantes para un proyecto en particular. Es lógico que el lanzamiento de un juego móvil o un sistema CRM bancario complejo requiera diferentes enfoques para las pruebas.
Estrategia de prueba bancaria
En nuestra práctica, en SimbirSoft utilizamos toda la gama de metodologías de desarrollo, pero las tecnologías flexibles siempre siguen siendo nuestra prioridad. E incluso cuando, por varias razones, no es posible usarlas, el equipo adopta las mejores prácticas y las aplica en el trabajo diario. Las pruebas se convierten en una parte integral de todo el proceso y se fusionan con el flujo de trabajo general. En este caso, es responsable no solo de la calidad del producto, sino incluso de la calidad de todo el proceso de trabajo.
¿Qué tecnologías utilizamos?
- planificación flexible y preparación de lanzamientos internos;
- preparación de la historia del usuario;
- celebración de manifestaciones;
- realización de retrospectivas.
Con toda su fuerza, la estrategia de prueba se revela en proyectos con lógica empresarial compleja. Por ejemplo, software para soporte de información de bancos, la construcción de un sistema de adquisición de Internet, una plataforma de negociación automatizada. En tales proyectos, es importante aplicar una estrategia de prueba adecuada, ya que el precio de algunos errores puede conducir a pérdidas reales y afectar en gran medida la reputación de la empresa.
Además, los objetivos principales de las pruebas (búsqueda de defectos y verificación de software para el cumplimiento) pueden agregarse adicionalmente. Por ejemplo, es importante que los bancos implementen rápidamente los nuevos requisitos del Banco Central. Esto significa que las pruebas oportunas con la calidad requerida para tareas críticas se agregarán al objetivo principal.
Recientemente, en un proyecto bancario, nos enfrentamos a un cambio en la ley federal: un aumento en la tasa del IVA del 18% al 20%. Se realizó una gran cantidad de trabajo preliminar para adaptarse al cambio de legislación, ya que el cambio se refería no solo al reemplazo de formularios, interfaces, sino también a la alteración de la lógica de varias fórmulas de cálculo. Era necesario asegurar la visualización correcta en muchas plataformas. Además, en la función de pago diferido, era necesario tener en cuenta el período de transición con tasas de 18% y 20%.
Ahora hablaremos con más detalle sobre cómo desarrollamos nuestra estrategia y por qué a menudo elegimos las pruebas basadas en el riesgo.
Ventajas de las pruebas basadas en el riesgo
Hay varias estrategias de prueba que se seleccionan para fines específicos:
- basado en los requisitos;
- metódico
- estrategias reactivas;
- Estrategias de asesoramiento.
En el caso de trabajar con proyectos con lógica empresarial compleja, es necesario determinar requisitos estrictos en el diseño de sistemas en los que se basan las pruebas. Una herramienta adecuada es la prueba basada en requisitos.
Un tipo de estrategia basada en requisitos son las pruebas basadas en riesgos. Además, las partes de la funcionalidad del sistema que están más expuestas a los riesgos se prueban primero. El riesgo es una posible consecuencia negativa de un mal funcionamiento del sistema. La consecuencia es un riesgo en presencia de dos componentes, como la oportunidad y la negatividad.
Hay dos tipos de riesgos:
1. Riesgo del productoSe puede administrar y no administrar. En el ejemplo anterior, nos enfrentamos a un riesgo manejable: el rápido crecimiento y la complejidad de la funcionalidad, lo que aumentó la probabilidad de regresión. Aquí resolvimos el problema al tener una base de prueba comprensible y una automatización posterior. El riesgo que no podemos afectar es la dependencia de los sistemas externos y su falla en el proceso de integración. Aquí presentamos las medidas que reducirán su impacto en nuestro sistema. Por ejemplo, usando copias de seguridad, manejando casos excepcionales, mostrando advertencias para el usuario.
2. Riesgo del proyectoPor ejemplo, en un proyecto, nos enfrentamos con el hecho de que el cliente no había trabajado previamente con un equipo distribuido y, por lo tanto, el flujo de trabajo utilizado no cumplía con los requisitos y creaba problemas de comunicación adicionales: falta de comprensión, duplicación de tareas, desempeño de tareas mutuamente excluyentes, etc. Acordamos la reestructuración y la mejora del proceso: revisamos el flujo de trabajo, presentamos a todos los miembros del equipo, realizamos manifestaciones, presentaciones y retrospectivas. Como resultado, el trabajo fue en la dirección correcta.
El enfoque basado en el riesgo le permite componer una cierta cantidad de riesgos, por un corto tiempo para probar los riesgos con alta prioridad y proporcionar al cliente métricas sobre qué tan bien fueron probados, mostrando la cantidad de casos planificados y completados y la cantidad de defectos.
La implementación de un enfoque basado en el riesgo en un proyecto se lleva a cabo en cuatro etapas:
Identificación de riesgos : en esta etapa, debe identificar los riesgos y obtener una lista de ellos.
Evaluación de riesgos : aquí analizamos la lista y la clasificamos por prioridad.
Mitigación de riesgos : en esta etapa determinamos qué tan profundamente probaremos los riesgos.
Gestión de riesgos : aquí decidimos cómo seguiremos trabajando con ellos y los revisaremos, identificaremos nuevos riesgos.
Los riesgos son identificados y evaluados por un grupo de partes interesadas durante las sesiones de lluvia de ideas. El equipo debe incluir analistas de negocios o proveedores de conocimiento sobre el sistema por parte del cliente, desarrolladores, gerente o gerente de proyecto, arquitectos, especialistas en control de calidad. Involucramos a especialistas en seguridad de la información, empleados que trabajan directamente con el sistema actual y analistas de negocios inmersos en procesos para identificar y evaluar riesgos.
Considere el enfoque basado en el riesgo mediante el ejemplo de probar el sistema de adquisición de Internet.
Trabajar con riesgos (en el ejemplo de un sistema de adquisición de Internet)
Destacamos los siguientes requisitos:
D1.Proporcionar 1000 conexiones simultáneas al sistema por segundo.
D2 Seguridad de la transacción.
D3 El acceso a la transacción debe estar disponible solo para la persona que realiza la transacción.
D4 Proporcionar y respaldar el estándar SET (Transacción electrónica segura).
Como riesgo de producto, podemos distinguir:
RP1. Sistema bloqueado con conexiones simultáneas.
RP2. Usando inyección SQL durante la transacción.
RP3. Acceso a la transacción de otra persona al cambiar los parámetros en la URL.
RP4. Pérdida de datos cuando se pierde la conexión con el banco en el momento de la transacción.
RP5. El uso de certificados no válidos al proporcionar el sistema SET (Transacción electrónica segura).
Como riesgos organizacionales:
RO1. La caída del sistema desarrollado debido a la inaccesibilidad de los sistemas externos.
RO2. La presencia de casos difíciles de reproducir que no se pueden detectar en un entorno de prueba.
Por lo tanto, cada riesgo se deriva lógicamente de los requisitos que están en el sistema, pero no se limita a ellos. Los riesgos complementan los requisitos e identifican casos adicionales que pueden surgir al trabajar con el sistema.
Los riesgos pueden reducirse o compensarse según los objetivos del proyecto y los requisitos del sistema. Se acepta que el riesgo está cubierto por el caso de prueba al menos una vez:
1. Para cada riesgo de producto, se prepara
un conjunto de casos de prueba RP1-RP4 con la condición de que cada requisito y cada riesgo deben estar cubiertos por al menos un caso de prueba. Dependiendo de los propósitos de la prueba, el conjunto de casos de prueba se expande a un cierto nivel de detalle.
2. Para cada riesgo organizacional, se prepara
una lista de actividades que pueden reducir el impacto del riesgo en el producto que se está desarrollando.
Evaluación de riesgos y técnicas de gestión
Existen varios métodos para evaluar y gestionar los riesgos: métodos ligeros (PRAM, PRISMA) y más formales (FMEA, FTA).
Con el modelo FMEA, el equipo del proyecto identifica todos los procesos, componentes, módulos del sistema en los que puede ocurrir una falla o error del sistema que puede conducir a la degradación de la calidad del producto. Durante la lluvia de ideas, los riesgos del sistema están determinados por tres indicadores: gravedad, prioridad, probabilidad. Luego, se calcula el Número de prioridad de riesgo para cada riesgo y, según los indicadores, se establece la profundidad de la prueba.
Con el modelo FTA, todas las causas que pueden conducir a defectos en los procesos comerciales del sistema se determinan por etapas. El análisis va del nivel más alto al más bajo. La diferencia entre FMEA y FTA es que el primer enfoque se centra en la funcionalidad del sistema, y el segundo en los procesos comerciales.
Además de estos enfoques formales y pesados, hay otros más flexibles e informales. Por ejemplo, los métodos PRAM (Análisis pragmático y gestión de riesgos) y PRISMA (Gestión de riesgos de productos). Combinan con éxito y fácilmente estrategias basadas en riesgos y requisitos. Básicamente, estos enfoques utilizan especificaciones de requisitos como entrada, pero las partes interesadas también pueden participar.
Los métodos de análisis de riesgo ligero son muy similares a los formales. Se centran en riesgos técnicos o comerciales, sopesando la probabilidad de ocurrencia del riesgo y los factores que afectan esta probabilidad.
Sin embargo, los únicos dos factores utilizados por estos métodos son la probabilidad de riesgo y su impacto. Además, estos enfoques utilizan juicios y escalas cualitativos simplificados para tomar decisiones.
Nuestros equipos utilizan métodos ligeros flexibles y adaptan los enfoques PRAM y PRISMA a sus objetivos.
Cómo trabajamos con pruebas basadas en riesgos
Por ejemplo, en uno de los proyectos, identificamos los riesgos del proyecto y del producto que pueden funcionar. Para hacer esto, los analistas, los desarrolladores y el control de calidad participan en el análisis, un representante del equipo.
Se forma una tabla de riesgos con los productos. Determinan la evaluación de la probabilidad de que ocurra un riesgo y su posible impacto en el sistema en una escala de cinco puntos. En la tabla 1 - la influencia más fuerte, 5 - la más débil. También para probabilidad 1 - alta probabilidad, 5 - baja probabilidad.
Cómo continuamos trabajando con los riesgos del producto
Además, para cada uno de ellos, la cobertura de riesgo del producto se rastrea con casos de prueba.
Seleccionamos los siguientes controles:
TC1. Verificación de carga con más de 1000 conexiones al sistema
TC2. Prueba de carga con 1000 conexiones del sistema
TC3. Ingrese inyección SQL durante la transacción
TC4. Ingrese la inyección SQL en la página de transacción exitosa, sustituyendo otros datos
TC5. Introducción de scripts XSS (Cross-Site Scripting) en los campos disponibles para entrada al realizar una transacción
TC6. Simulación de una conexión a Internet desconectada durante una transacción.
TC7. Salir de una sesión de transacción en el paso de verificación
TC8. Validación de certificados vencidos durante la transacción
Por lo tanto, las verificaciones de prioridad son TC2, TC4, TC5.
TC6 y TC8 tienen un alto impacto, pero menos probabilidad, por lo que la prioridad de verificarlos es menor, pero también se requieren verificaciones.
TC7 no se aplica a ninguno de los requisitos, pero extiende la prueba para un escenario negativo, que es posible con un funcionamiento estable del sistema.
Cómo continuamos trabajando con los riesgos del proyecto
También determinamos acciones para los riesgos del proyecto, mediante las cuales asignamos medidas y decisiones adicionales.
En riesgo "RO2. La presencia de casos difíciles de reproducir que no se pueden detectar en el entorno de prueba ”, puede tomar lo siguiente:
- Prepare un stand de preproducción, lo más cerca posible del entorno real de la aplicación, junto con todos los sistemas externos;
- escribir scripts de prueba de extremo a extremo que pasan por todos los sistemas adyacentes y proporcionan verificación de transacciones;
- después de realizar todas las verificaciones de prioridad, utilice las técnicas de adivinación de errores de acuerdo con los requisitos básicos del sistema y los scripts para verificaciones adicionales en el rol de un "pirata informático del sistema".
Plan de emergencia
Es importante tener un plan de acción en caso de que uno de los riesgos del producto o proyecto funcione. A veces puede guardar la configuración de un sistema de copia de seguridad del proyecto. No siempre es posible reducir el riesgo a un nivel mínimo, pero debería ser posible reducir al menos sus consecuencias. Nuestra publicación
"Christmas Story" fue sobre este tema: cómo puede funcionar un riesgo, cuya probabilidad tiende a cero.
Por ejemplo, debemos eliminar por completo la pérdida de datos durante una transacción, pero considerar todos los casos demasiado laboriosos. Por lo tanto, debe tener formas de manejar tales casos. Una de las opciones de seguridad es el desarrollo de registros más detallados. Esto proporcionará un punto de reversión permanente a la acción anterior si algo salió mal durante la transacción.
Conclusión
Las pruebas basadas en el riesgo le permiten cubrir las áreas más riesgosas con casos de prueba, reduciendo así su impacto y la probabilidad de ser desencadenadas. Esta es la estrategia más ganadora para sistemas con lógica empresarial compleja y alto costo de error. La solución es adecuada para el sector bancario, compañías de seguros, complejos sistemas CRM internos de perfil médico. Con un enfoque basado en el riesgo, también trabajamos con los riesgos del proyecto, lo que mejora el proceso general de pruebas y gestión de proyectos.