ultimate guide risk based testing
La guía definitiva para las pruebas basadas en riesgos, la gestión de riesgos y su enfoque con ejemplos:
¿Qué son las pruebas basadas en riesgos?
Las pruebas basadas en riesgos consisten en realizar pruebas o diseñar y ejecutar los escenarios, de modo que los principales riesgos comerciales que tendrán un impacto negativo en el negocio, según lo identificado por el cliente, se descubran en su producto o característica al principio del ciclo de vida y se mitigado mediante la implementación de medidas de mitigación.
=> Haga clic aquí para ver la serie completa de tutoriales del plan de prueba
El impacto negativo puede incluir impacto en los costos, cliente insatisfecho, mala experiencia del usuario e incluso hasta el punto de perder clientes.
En otras palabras, el enfoque RBT es garantizar que las pruebas se realicen de tal manera que incluso si un usuario encuentra un error en la producción, eso no le impide usar el software o no afecta el negocio de manera seria.
La RBT se realiza en función de los riesgos del producto. RBT debe averiguar con mucha anticipación cuál es el riesgo de falla de una característica o funcionalidad en particular en la producción y su impacto en el negocio en términos de costo y otros daños mediante el uso de una técnica de priorización para los casos de prueba.
Por lo tanto, las pruebas basadas en riesgos utilizan el principio de priorizando las pruebas de las características, módulos y funcionalidades de un producto o software. La priorización se basa en el riesgo de la probabilidad de falla de esa característica o funcionalidad en la producción y su impacto en los clientes.
Lo que vas a aprender:
- Pruebas basadas en riesgos y su relevancia para Agile y DevOps
- Gestión de riesgos durante la planificación de pruebas
- Gestión de riesgos en la fase de ejecución de la prueba (con ejemplo)
Pruebas basadas en riesgos y su relevancia para Agile y DevOps
Trescientas horas dedicadas al desarrollo de software pueden volverse inútiles en solo 30 segundos con un solo defecto identificado en producción.
Esto, a su vez, puede arruinar el propósito de todo el producto sin otra opción que simplemente retirarlo del mercado. Y esa es la importancia y la necesidad de 'pruebas de calidad'.
Con el rápido crecimiento de la tecnología, el software está alojado en la nube y admite múltiples sistemas operativos, múltiples plataformas, infraestructuras de TI complejas, etc., los usuarios finales se están volviendo cada vez más exigentes con las características y opciones y nunca comprometen la satisfacción del cliente. .
Hoy en día, la 'calidad' se está convirtiendo en un factor crucial en la entrega de software, donde se están produciendo mejoras continuas para mejorar la calidad a fin de mantener contentos a los clientes.
A menudo notamos que es un problema común para casi todos los probadores estar bajo una tremenda presión que su ventana de prueba se aprieta y, por lo general, se les entrega la compilación para que la prueben en el último minuto. No hay suficiente tiempo y recursos para que ejecuten todas las pruebas que han diseñado y la cobertura de automatización no siempre es del 100% y tiene sus propios desafíos.
No se puede perder el plazo de entrega y, al mismo tiempo, la calidad tampoco puede verse comprometida. Cualquiera que sea el plan B, agregar recursos de prueba adicionales sacando de los otros equipos, no está funcionando, Plan C, dejar de hacer todas las otras actividades y desviar el esfuerzo solo a esto, no está realmente ayudando. Sin embargo, gran parte de la adición de recursos de prueba, al final, no está funcionando.
No hay otra opción que realizar pruebas limitadas e importantes dentro del tiempo y los recursos disponibles.
Entonces, ¿cómo decidimos qué prueba es importante en esta etapa? Cualquier cosa que un Tester considere importante puede no ser realmente importante para los clientes. ¿Desde qué perspectiva se decide la importancia de la característica o una funcionalidad? ¿Quién decidirá cuáles son las pruebas importantes? Y siguen surgiendo muchas otras preguntas.
Para responder a todas estas preguntas y manejar la situación anterior de manera efectiva, un enfoque de prueba llamado 'Pruebas basadas en riesgos' , llamado brevemente 'RBT' , comenzó a existir, donde el equipo ha planeado e identificado claramente los escenarios de prueba en función de los criterios de 'Riesgo del proyecto'.
Aunque el equipo de control de calidad tiene una imagen clara de las pruebas importantes, RBT es un método comprobado para identificar las pruebas cruciales e importantes desde la perspectiva del cliente y del negocio a través de un 'Análisis de riesgo' procedimiento .
Entonces, ahora en contra de la forma tradicional de simplemente identificar los defectos en el software, el enfoque y el objetivo de QA ha cambiado con el tiempo debido al cambio en la tecnología, aumento en la competencia en el mercado para lanzar un software de calidad, introducción de 'Automatice todo' y, en su totalidad, la introducción de la práctica Agile y DevOps de entregar el software en un período de pocas horas.
Por lo tanto, la tendencia actual del 'principio de prueba' no es simplemente 'identificar los defectos', sino también,
#1) Concéntrese en el área del producto donde hay un alto impacto en el negocio debido a fallas o alta probabilidad de fallas en la producción.
#2) Concentrándose en identificando los defectos temprano y permitir que un equipo lo arregle lo antes posible y, por lo tanto, permitir que el software / producto o característica 'Fallar rapido'.
#3) El aspecto más importante del servicio del equipo de control de calidad ahora es centrarse en el cliente para aportar valor al cliente aumentando el enfoque en 'Experiencia del cliente de principio a fin'.
Enfoque de prueba basado en riesgos
Siempre es como prepararse para un examen, que no se puede decir que las pruebas sean suficientes y que no haya más defectos en el software, incluso si diseñan y ejecutan un amplio número de pruebas.
Hay un punto en el que la estabilidad del software no va a estar doblemente asegurada aumentando el número de casos de prueba solo. En este momento, no se trata solo de centrarse en la cantidad de pruebas, sino en lo que realmente espera el cliente del lanzamiento.
Por lo tanto, es esencial lograr un equilibrio en la optimización de las pruebas para obtener el máximo beneficio con el esfuerzo razonable de las pruebas. Y esto es más importante cuando los plazos de prueba son muy ajustados y no hay suficientes recursos disponibles para llevar a cabo las pruebas suficientes.
Por lo tanto, en este caso, el enfoque RBT juega un papel clave en la optimización del esfuerzo de control de calidad y maximización del beneficio de las pruebas con el mínimo riesgo comercial.
Entonces, si nos enfocamos en el aspecto anterior, entonces el trabajo de un QA será mucho más aliviado. No tienen que quemar sus fines de semana en la oficina, probando continuamente el software y preocupándose por todos los defectos S4 (Severidad 4) y P4 (Prioridad 4) que surgen de las pruebas.
Bueno, 4 se considera la menor prioridad y gravedad de los defectos en las pruebas. Pueden invertir mejor su tiempo en otros aspectos útiles del proyecto.
Para resumir los impulsores clave del enfoque de 'pruebas basadas en riesgos':
- Para permitir probar 'lo que quieren los clientes' desde una perspectiva empresarial.
- Cumplir con el cronograma con la calidad esperada.
- Optimizar el esfuerzo de QA.
¿Cuándo utilizamos el enfoque RBT?
Esto se utiliza en los siguientes escenarios:
- El enfoque RBT se puede utilizar siempre que exista una limitación o restricción en el tiempo, el costo y los recursos de un proyecto y siempre que sea necesario optimizar los recursos.
- El enfoque RBT se utiliza cuando el programa es más complejo y adapta nueva tecnología y, por lo tanto, implica muchos desafíos.
- Cuando el programa es un proyecto de I + D y es de un primer tipo y hay una serie de incógnitas y riesgos en el proyecto.
Ejemplo de enfoque RBT
En la industria de TI se utilizan varios enfoques de análisis basados en riesgos para superar los riesgos que enfrenta la producción y su impacto.
A continuación se muestra uno de esos enfoques:
Este enfoque de RBT incluye identificar las 'funcionalidades vitales o características clave' del producto y evaluar los riesgos a los que se exponen cada una de estas funcionalidades en la producción e implementar las medidas de mitigación adecuadas para reducir o mitigar el riesgo.
Por lo tanto, el enfoque RBT incluye probar las funcionalidades que tienen la probabilidad de falla y el mayor impacto en el negocio. Los tipos de fallas pueden ser operativas o comerciales, técnicas, externas, etc.
Formas de realizar análisis de riesgos
No existe un proceso o plantilla estándar definido como tal para llevar a cabo el análisis de riesgo en las pruebas de software para todas y cada una de las características de un producto. Varias organizaciones utilizan su propio enfoque para los métodos de análisis de riesgos.
El análisis de riesgos se puede llevar a cabo en varios elementos del proyecto para identificar los riesgos e implementar un enfoque RBT para el análisis. Esos elementos incluyen,
- Características
- Funcionalidades
- Historias de usuarios
- Requisitos
- Casos de uso
- Casos de prueba
En este caso, centrémonos solo en los casos de prueba para comprender la implementación del enfoque de pruebas basadas en riesgos.
Procedimiento de análisis de riesgos
El análisis de riesgos incluye la participación de las partes interesadas relevantes del programa tanto de la ‘ Equipo técnico y equipo comercial ' , que incluye propietario del producto, gerentes de producto, analistas comerciales, arquitectos, probadores y representantes de clientes.
Se organizarían sesiones de lluvia de ideas con estas partes interesadas para llevar a cabo la discusión para identificar la importancia de cada característica de un producto y priorizarlas en función del riesgo de falla y su impacto en los usuarios finales en la producción.
Varios 'documentos del proyecto', como el documento de requisitos, los documentos de especificaciones técnicas, los documentos de arquitectura y diseño, el documento de proceso empresarial, el documento de caso de uso, etc., se convertirán en la entrada para la sesión de lluvia de ideas.
El conocimiento de las partes interesadas sobre el producto y el producto existente en el mercado también será un factor de entrada para la discusión.
Pocas otras fuentes de insumos también pueden incluir,
- Recopilar aportaciones sobre la funcionalidad más utilizada.
- Entradas de consultar a un experto en el dominio.
- Datos de la versión anterior del producto o producto similar en el mercado.
Durante el lluvia de ideas sesión, se identifican los riesgos relacionados con cada una de estas características. Los tipos de riesgos pueden ser operativos, técnicos o comerciales. Las pruebas y escenarios relacionados con ellos se ponderan y los valores de riesgo se evalúan en función de la probabilidad de ocurrencia del riesgo y el impacto del riesgo.
La 'probabilidad de que ocurra un riesgo' puede deberse a:
- Falta de comprensión de la función por parte del equipo de desarrollo de productos.
- Arquitectura y diseño inadecuados.
- Tiempo insuficiente para diseñar.
- Incompetencia del equipo.
- Recursos inadecuados: personas, herramientas y tecnología.
El 'Impacto del riesgo' es el efecto de la falla para los usuarios y la empresa si ocurre. El impacto podría ser,
- Impacto en los costos, que resulta en una pérdida.
- Impacto comercial que da como resultado la pérdida de negocios o la pérdida de participación de mercado, Procedimientos legales, Pérdida de licencia.
- Impacto en la calidad, que resulta en un lanzamiento de producto deficiente o incompetente.
- Mala experiencia de usuario, que resulta en insatisfacción y pérdida de un cliente.
El área de enfoque para evaluar el riesgo de una característica o producto puede ser,
- Área de negocio criticidad de la funcionalidad.
- Características más utilizadas y funcionalidad importante.
- Áreas propensas a defectos
- Funcionalidad que soporta el impacto de la seguridad y la protección.
- Área de Diseño y Arquitectura Complejos.
- Cambios realizados en versiones anteriores.
Metodología de análisis de riesgos
Entendamos ahora en detalle la 'metodología de prueba basada en riesgos'.
El enfoque de prueba basado en el riesgo utiliza el RIESGO como criterio en todas las fases de prueba del ciclo de prueba, es decir, planificación de pruebas , diseño de prueba, implementación de prueba, ejecución de pruebas e informes de prueba. Idealmente, se pueden diseñar numerosas combinaciones posibles de escenarios de prueba.
Por lo tanto, el enfoque RBT incluye una clasificación de las pruebas en función de la gravedad de los riesgos para descubrir el área de falla más defectuosa o riesgosa, lo que causa un alto impacto en el negocio.
El principal objetivo del análisis de riesgos es distinguir entre los 'Alto valor' elementos como características del producto, funcionalidades, requisitos, historias de usuarios , y casos de prueba, y ' Bajo valor' unos y, por lo tanto, más adelante para centrarse más en los casos de prueba de 'valor alto', centrándose menos en los casos de prueba de 'valor bajo'. Este es el paso inicial del análisis de riesgos antes de comenzar las pruebas basadas en riesgos.
La tarea principal de categorización o agrupación de casos de prueba en valor alto y valor bajo y asignar el valor de prioridad a cada uno de estos casos de prueba incluye los siguientes pasos:
Paso # 1) Usando una cuadrícula de 3X3
El análisis de riesgo se realiza utilizando una cuadrícula de 3X3, donde cada funcionalidad, no funcionalidad y sus casos de prueba relacionados son evaluados por un equipo de partes interesadas para su 'Probabilidaddel fracaso 'e' Impacto del fracaso '.
La probabilidad de falla de cada funcionalidad en la producción generalmente es accedida por un grupo de 'Expertos Técnicos' y se clasifican como 'Probable fallar, bastante probable e improbable' a lo largo del eje vertical de la cuadrícula.
descargar audio de alta calidad de youtube
De manera similar, el 'Impacto de fallas' de estas características y funcionalidades en la producción lo experimenta el cliente final, si no se prueba, es evaluado por un grupo de ‘ Business Specialists 'y se clasifican en las categorías' Menores, Visibles e Interrupción 'a lo largo del eje horizontal de la cuadrícula.
Paso # 2) Probabilidad e impacto del fracaso
Todos los casos de prueba se colocan en los cuadrantes de la cuadrícula de 3 X 3 según los valores identificados de probabilidad de falla e impacto de falla que se muestran como puntos en la siguiente imagen.
Obviamente, una alta probabilidad de falla y un alto impacto de falla (interrupción) se agrupan en la esquina superior derecha de la cuadrícula, lo cual es de gran importancia y, por lo tanto, se identifica que las pruebas de 'valor alto' y las pruebas de 'valor bajo' se agrupan en el esquina inferior izquierda que es de menor importancia o nula para el cliente, donde se puede dar un enfoque menor a estas características o casos de prueba.
Paso 3) Prueba de la cuadrícula de prioridad
Con base en el posicionamiento anterior de los casos de prueba en la cuadrícula, las pruebas se priorizan y etiquetan con prioridades 1, 2, 3, 4 y 5 y se marcan en cada una de ellas. Las pruebas más importantes se colocan en un 1S tLa cuadrícula que se asigna con prioridad 1 y las menos importantes de manera similar se clasifican como 2, 3, 4 y 5.
Finalmente, todos los casos de prueba se ordenan según sus números de prioridad y se seleccionan para su ejecución en el orden de prioridad. Los de alta prioridad se seleccionan para su ejecución en primer lugar y los de baja prioridad se ejecutan más tarde o se eliminan del ámbito.
Paso # 4) Detalles de la prueba
El siguiente paso es decidir el nivel de detalles de las pruebas para el alcance definido de las pruebas. La profundidad del alcance de las pruebas se puede decidir en función de la clasificación anterior según la siguiente cuadrícula.
Las pruebas de alta prioridad con clasificación 1 se prueban 'más exhaustivamente' y, en consecuencia, se implementan expertos para probar estas características de alta criticidad y sus casos de prueba relacionados. De manera similar, pruebe casos con prioridad 2, 3 y 4. Se puede tomar una decisión para eliminar el alcance de las características y pruebas de prioridad 5 en función del tiempo y los recursos disponibles.
Por lo tanto, el enfoque del nivel de detalle de las pruebas de priorizar las características y sus casos de prueba no solo ayuda a los probadores a identificar las 'pruebas de alto valor', sino que también los guía para decidir su 'nivel de detalle de las pruebas' en función de estas clasificaciones de prioridad y les ayuda a realizar mejores pruebas y reduce el costo de las pruebas mediante el proceso de optimización.
¿Qué importancia tiene RBT para Agile y DevOps?
Ahora, después de comprender el enfoque de las pruebas basadas en el riesgo de llevar a cabo las pruebas en función de la priorización de las pruebas en función del 'Riesgo de falla' de una función en particular y su 'Impacto en el cliente' en vivo, obviamente se plantearía la pregunta de la relevancia del enfoque de pruebas basadas en riesgos en prácticas ágiles y DevOps.
'Automatizar todo', 'Probar todo', 'Probar continuamente', 'Probar repetidamente' son los conceptos clave de estas prácticas.
Cada vez, cuando hay un cambio en el código o hay un lanzamiento, todas las pruebas diseñadas se ejecutan a través de la Integración continua (CI) / Entrega continua (CD) pipeline rápida y repetidamente, independientemente de su priorización.
Entonces, ¿cuál es la relación entre RBT y DevOps? ¿Dónde encajaría RBT y se volvería relevante en Agile y DevOps?
#1) Sí, como dije anteriormente, no es que todas las industrias y todos los productos tengan una cobertura de automatización del 100% para sus ejecuciones de prueba. Por lo tanto, si el equipo tiene que elegir la priorización para la ejecución de la prueba a partir de la elección de los casos de prueba manuales y le gustaría ahorrar la energía y el esfuerzo de los recursos de prueba para otras actividades, entonces RBT es la mejor opción.
El enfoque basado en riesgos también es una mejor apuesta para ejecutar pruebas automatizadas con alta prioridad y realizar pruebas lo antes posible.
#2) El equipo de garantía de calidad puede adoptar el enfoque RBT de manera más eficaz durante el análisis de requisitos para analizar los requisitos y proporcionar un informe anticipado de los riesgos probables de los productos y las características para que el equipo del programa pueda tomar las acciones apropiadas de manera proactiva para mitigarlo.
#3) El enfoque RBT se puede utilizar de forma eficaz en el diseño de casos de prueba y escenarios basados en Alto riesgo para que se pueda prestar más atención a las características y funcionalidades de alto riesgo.
#4) La identificación de las áreas de 'alto riesgo' permite al equipo de control de calidad enfocar su esfuerzo de prueba en esas áreas para probar 'más a fondo' utilizando 'probadores altamente calificados'.
#5) 'Fail Fast', como todos sabemos, es el concepto de 'Agile' y 'DevOps', para el cual el enfoque RBT ayuda a identificar las áreas de 'alto riesgo' en el software, identificar los defectos temprano y permitirles fallar rápidamente y fallar primero y deje que el equipo lo arregle.
#6) El objetivo final de Agile / DevOps es el 'enfoque en el cliente' y, por lo tanto, el enfoque RBT permite que el control de calidad se centre en la experiencia del cliente y no solo en la búsqueda de defectos.
Beneficios del enfoque de pruebas basadas en riesgos
Ya entendimos el propósito y el uso del enfoque RBT de analizar los requisitos, diseñar y ejecutar los escenarios de prueba. Hay varios beneficios de RBT.
Podemos consolidar y enumerar los beneficios de las pruebas basadas en riesgos como:
- Ayuda a un uso más eficiente y optimizado de los recursos de prueba.
- Ayuda a facilitar el trabajo de control de calidad, las pruebas, el diseño y desarrollo de pruebas y las actividades de preparación de pruebas mediante la priorización.
- Ayuda a administrar mejor los recursos de control de calidad al asignar los recursos clave a áreas de alto enfoque.
- Ayuda en la utilización eficaz de los recursos y desvía su tiempo y energía hacia cosas mejores en el proyecto.
- Ayuda al equipo de control de calidad a planificar los esfuerzos de prueba basados en la evaluación de riesgos y la identificación de áreas volátiles y de alto riesgo.
- Ayuda al equipo a optimizar las pruebas a realizar en función de la importancia y, por lo tanto, a eliminar el alcance de las pruebas de bajo valor de acuerdo con las partes interesadas.
- En general, ayuda en la reducción de costos a través de actividades de prueba optimizadas y reducidas.
- El enfoque RBT permite al equipo de control de calidad probar primero las áreas de alto riesgo y permite que el producto 'falle rápidamente' y se repare rápidamente.
- El enfoque RBT ayuda a aportar claridad en la ' Cobertura de prueba ' y el 'alcance de la prueba' para todo el grupo de partes interesadas.
- El equipo puede aumentar su enfoque en las áreas de alto riesgo y mantener menos atención en el área de bajo riesgo.
- RBT permite al Equipo decidir con mucha anticipación la implementación de la forma más efectiva de mitigación de los riesgos del producto.
- RBT ayuda a evitar el efecto de la implementación inapropiada de mitigaciones.
- Las pruebas basadas en riesgos permiten al equipo tomar las medidas adecuadas para mitigar o planificar contingencias o posicionar cualquier solución para superar la falla o reducir su impacto si el riesgo ocurre en Live.
- RBT ayuda a minimizar el riesgo residual en el lanzamiento.
- Ayuda a lograr la 'Calidad mejorada' a través de defectos de producción menos costosos.
- En última instancia, ayuda a 'Mejorar la experiencia del cliente' y 'Cliente satisfecho'.
A continuación, aprenderemos cómo gestionar los riesgos en las fases de planificación de pruebas y ejecución de pruebas del ciclo de vida de las pruebas de software.
Gestión de riesgos durante la planificación de pruebas
Cómo gestionar los riesgos durante la fase de planificación de pruebas:
La vida está llena de riesgos, al igual que un proyecto de software. Cualquier cosa puede salir mal en cualquier momento. Siempre estamos alerta para hacer las cosas bien, pero ¿qué tal si nos aseguramos de que nada salga mal y de que, cuando suceda, sepamos exactamente qué hacer? Ingrese a la gestión de riesgos: esta es una parte de un proyecto de prueba de software que nos prepara para prevenir, comprender, encontrar y superar los riesgos.
Un riesgo es simplemente un problema que es probable que ocurra y cuando ocurre, causará una pérdida.
La pérdida puede ser cualquier cosa: dinero, tiempo, esfuerzo o un compromiso en la calidad. La pérdida nunca es buena. No importa cuánto le demos, no es positivo y nunca lo será. Por lo tanto Gestión de riesgos es una parte integral de los proyectos de software para asegurarnos de que manejamos los riesgos y previene / reduce las pérdidas.
Pruebas basadas en riesgos : Dado que somos una comunidad de QA, permítanos ser específicos a los riesgos y el proceso relacionado con ellos en nuestro mundo QA exclusivamente. Los riesgos se evalúan y gestionan aproximadamente en 2 fases de nuestra Ciclo de vida de la prueba de software . STLC se puede clasificar en 3 fases: planificación de pruebas, diseño de pruebas y ejecución de pruebas.
El proceso de Gestión de Riesgos ocurre dos veces, durante:
- Planificación de pruebas
- Diseño de caso de prueba (final) o, a veces, en la fase de ejecución de prueba
Es obligatorio en el caso 1, pero en el caso 2 es más una situación de 'necesidad'.
Serie de artículos de dos partes:
Aunque el proceso subyacente es el mismo, el tipos de riesgos abordados en estas dos áreas son completamente diferentes. Para hacerles justicia individualmente, los vamos a manejar de manera diferente como una serie de dos partes.
Esta sección va a tratar sobre 'Gestión de riesgos durante la planificación de pruebas”.
Proceso de gestión de riesgos
El proceso genérico de Gestión de Riesgos consta de 3 etapas importantes:
- Identificación de riesgo
- Análisis de impacto de riesgo
- Mitigación de riesgos
Prueba de riesgos y ejemplos de mitigación:
# 1) Identificación de riesgos
Como se dice, el primer paso para resolver un problema es identificarlo. Esta etapa implica hacer una lista de todo lo que potencialmente podría surgir e interrumpir el flujo normal de eventos.
El resultado principal de este paso es una lista de riesgos.
Este paso de prueba basado en el riesgo suele estar dirigido por el líder / gerente / representante de QA. Sin embargo, el líder por sí solo no podrá generar la lista completa; la información de todo el equipo de control de calidad tiene un gran impacto. Podemos decir que esta es una actividad colectiva liderada por el líder de QA.
Además, los riesgos que se identifican durante la fase de planificación de la prueba tienen una orientación más 'gerencial', es decir, vamos a ver cualquier cosa que pueda afectar el cronograma, el esfuerzo, el presupuesto, los cambios de infraestructura, etc. del proyecto de control de calidad. El enfoque aquí es no la AUT, sino la forma en que continuará la fase de garantía de calidad.
Riesgos durante la planificación de pruebas: ejemplos de pruebas basadas en riesgos
La siguiente es una lista de muestra de los riesgos que pueden aparecer durante la fase de planificación de la prueba. Tenga en cuenta que el AUT y su funcionalidad no es el foco aquí.
- El calendario de pruebas es ajustado. Si el inicio de la prueba se retrasa debido a tareas de diseño, la prueba no se puede extender más allá de la fecha de inicio programada de UAT.
- No hay suficientes recursos, los recursos se incorporan demasiado tarde (el proceso demora alrededor de 15 días).
- Los defectos se encuentran en una etapa tardía del ciclo o en un ciclo tardío; Los defectos descubiertos tarde probablemente se deban a especificaciones poco claras y su resolución requiere mucho tiempo.
- Alcance no definido completamente definido
- Desastres naturales
- No disponibilidad de Independiente Entorno de prueba y accesibilidad
- Pruebas retrasadas debido a nuevos problemas
En este punto, puede optar por ser tan minucioso como desee, dependiendo de la cantidad de tiempo disponible.
Una vez que se enumeran todos los riesgos, pasamos a la Evaluación de riesgos / Análisis de impacto de riesgos.
# 2) Evaluación de riesgos / Análisis de impacto de riesgos
¿Su análisis de riesgo es algo como esto? :)
Análisis de riesgos en las pruebas de software : Todos los riesgos se cuantifican y priorizan en este paso. La probabilidad de cada riesgo (la posibilidad de ocurrencia) y el impacto (cantidad de pérdida que causaría cuando este riesgo se materialice) se determinan sistemáticamente.
Alto medio bajo , se asignan valores tanto a la probabilidad como al impacto de cada riesgo. Los riesgos con 'alta' probabilidad y 'alto' impacto se tratan primero y luego sigue el orden.
Tabla de análisis de impacto de riesgo:
Siguiendo estos pasos, la tabla de análisis de impacto de riesgo para los riesgos enumerados anteriormente se vería así (todos los valores son hipotéticos y solo para fines de comprensión):
Riesgo | Probabilidad | Impacto |
---|---|---|
7. Pruebas retrasadas debido a nuevos problemas | Medio | Alto |
1. El calendario de pruebas es ajustado. Si el inicio de la prueba se retrasa debido a tareas de diseño, la prueba no se puede extender más allá de la fecha de inicio programada de UAT. | Alto | Alto |
2. No hay suficientes recursos, los recursos se embarcan demasiado tarde (el proceso demora alrededor de 15 días). | Medio | Alto |
3. Los defectos se encuentran en una etapa tardía del ciclo o en un ciclo tardío; Los defectos descubiertos tarde probablemente se deban a especificaciones poco claras y su resolución requiere mucho tiempo. | Medio | Alto |
4. Alcance no definido completamente definido | Medio | Medio |
5. Desastres naturales | Bajo | Medio |
6. No disponibilidad del entorno de prueba independiente y accesibilidad | Medio | Alto |
# 3) Mitigación de riesgos
El paso final de este proceso de pruebas basadas en riesgos (RBT) es encontrar soluciones para planificar cómo manejar cada una de estas situaciones. Estos planes pueden diferir de una empresa a otra, de un proyecto a otro e incluso de una persona a otra.
Técnicas de mitigación de riesgos:
A continuación, se muestra un ejemplo de en qué se transforma la tabla de riesgos cuando se completa esta fase:
Riesgo | Prob. | Impacto | Plan de mitigación |
---|---|---|---|
Pruebas retrasadas debido a nuevos problemas | Medio | Alto | Durante las pruebas, es muy probable que se identifiquen algunos defectos 'nuevos' y que se conviertan en un problema que llevará tiempo resolver. Hay defectos que pueden surgir durante las pruebas debido a especificaciones poco claras del documento. Estos defectos pueden dar lugar a un problema que necesitará tiempo para resolverse. Si estos problemas se convierten en obstáculos, tendrá un gran impacto en el cronograma general del proyecto. Si se descubren nuevos defectos, se implementan los procedimientos de gestión de defectos y gestión de problemas para proporcionar una resolución inmediata. |
CALENDARIO El calendario de pruebas es ajustado. Si el inicio de la prueba se retrasa debido a tareas de diseño, la prueba no se puede extender más allá de la fecha de inicio programada de UAT. | Alto | Alto | • El equipo de pruebas puede controlar las tareas de preparación (por adelantado) y la comunicación temprana con las partes involucradas. • Se ha agregado algún colchón al cronograma para contingencias, aunque no tanto como recomiendan las mejores prácticas. |
RECURSOS No hay suficientes recursos, los recursos se embarcan demasiado tarde (el proceso demora alrededor de 15 días. | Medio | Alto | Los días festivos y las vacaciones se han estimado y se han incorporado al programa; las desviaciones de la estimación podrían derivar en retrasos en las pruebas. |
DEFECTOS Los defectos se encuentran en una etapa tardía del ciclo o en un ciclo tardío; Los defectos descubiertos tarde probablemente se deban a especificaciones poco claras y su resolución requiere mucho tiempo. | Medio | Alto | Se cuenta con un plan de gestión de defectos para garantizar una comunicación rápida y la resolución de problemas. |
ALCANCE Alcance completamente definido | Medio | Medio | El alcance está bien definido pero los cambios en la funcionalidad aún no están finalizados o siguen cambiando. |
Desastres naturales | Bajo | Medio | Los equipos y las responsabilidades se han distribuido a dos áreas geográficas diferentes. En un evento catastrófico en una de las áreas, habrá recursos en las otras áreas necesarios para continuar (aunque a un ritmo más lento) las actividades de prueba. |
No disponibilidad del entorno de prueba independiente y accesibilidad | Medio | Alto | Debido a la falta de disponibilidad del entorno, la programación se ve afectada y provocará un retraso en el inicio de la ejecución de la prueba. |
Algunos puntos a tener en cuenta:
- Cuanto antes comience la gestión de riesgos en una fase de planificación del proyecto de garantía de calidad, mejor.
- De los 3 pasos, La identificación de riesgos es la más importante . Si algo no está en la lista y no se considera para otros pasos, el riesgo no se maneja.
- Trate de encontrar un marco de tiempo ideal para esta actividad. Recuerde, demasiada planificación deja muy poco tiempo para hacer.
- Además, después del proceso de gestión de riesgos, si surge una nueva situación, el plan de gestión de riesgos puede modificarse o actualizarse para reflejar la condición más actual.
- Información histórica puede ser muy útil para el éxito de este proceso.
Conclusión
Esto nos lleva al final de la gestión de riesgos en la fase de planificación de pruebas. Aunque los pasos y principios subyacentes son similares, el proceso de gestión de riesgos está más concentrado hacia el AUT cuando ocurre en la fase de diseño / ejecución de la prueba.
En nuestra próxima sección, cubriremos: Gestión de riesgos en la fase de ejecución de pruebas.
Gestión de riesgos en la fase de ejecución de la prueba (con ejemplo)
En nuestro viaje hacia la comprensión del proceso de gestión de riesgos, hablamos sobre cómo funciona exclusivamente en el Fase de planificación de pruebas de pruebas basadas en riesgos . También entendimos el proceso genérico que involucra: identificación de riesgos, evaluación de riesgos y plan de mitigación de riesgos.
cómo solicitar un ascenso en la evaluación del desempeño
Cómo gestionar el riesgo en la fase de diseño o ejecución de la prueba:
Hay otra forma de Gestión de riesgos (también denominado a veces, Pruebas basadas en riesgos ) que se produce durante la fase de diseño o ejecución de la prueba, según la situación. Ahora bien, ¿de qué situación estamos hablando? Tratemos de entender eso primero.
Todos sabemos que nuestro trabajo de prueba es reactivo. Sin requisitos (o alcance definido), no podemos realizar un análisis de viabilidad y escribir escenarios de prueba o planificar actividades de prueba.
De manera similar, cuando el código no está listo, no tenemos nada que probar, sin importar cuánto trabajo de preparación podríamos haber estado listos en términos de casos de prueba, datos de prueba, etc. Además, la prueba es el único paso que queda antes de que el producto salga. En Vivo.
Gestión de riesgos: con especial atención a la AUT
Entendamos esto mejor con un ejemplo:
Si las pruebas debían comenzar en dicha fecha, el 1 de eneroS ty tuvo que continuar hasta el 14 de eneroth- cuando se realizan las pruebas, la fecha de lanzamiento del producto generalmente se fija de inmediato. Digamos, 15 de enerothpor simplicidad. Ahora, en un mundo perfecto, las cosas saldrían exactamente según lo planeado. Pero todos conocemos la realidad.
En este caso, supongamos que, por alguna razón, las pruebas no comenzaron hasta el 7 de enero.th, lo que significa que perdimos la mitad de nuestro tiempo de prueba. Pero necesitamos 14 días para probar el producto a fondo. Sin embargo, podríamos adelantar la fecha de puesta en funcionamiento en 7 días; esto generalmente no es una opción. Porque se promete que el producto llegará al mercado en una fecha determinada y cualquier retraso no es bueno para el negocio.
Entonces, por lo general, los equipos de prueba tenemos que absorber los retrasos, compensar de alguna manera, trabajar con el tiempo disponible y asegurarnos de que el producto se pruebe bien. Trabajo duro, ¿no?
Aquí es donde se vuelve a emplear el proceso de Gestión de Riesgos.
- Ahora si los retrasos se anticipan con anticipación incluso antes de que comience la prueba, el proceso tiene lugar en la fase de diseño de la prueba.
- Si los retrasos ocurren durante un Fase de ejecución de la prueba que comenzó normalmente, el proceso se sigue durante la fase de ejecución de la prueba.
- Los pasos y el método son los mismos sin importar en qué etapa ocurra.
Cual es el proceso
La gestión de riesgos se lleva a cabo para determinar qué áreas de la AUT (Aplicación bajo prueba) necesitan un enfoque máximo. Por lo general, estas son las áreas funcionales (módulos o componentes) que son críticas para el éxito del producto final y son las más propensas a fallar.
Leer también=> El análisis de modos y efectos de falla (FMEA) es una técnica de gestión de riesgos
¿Quién lo realiza?
Dado que se trata del AUT, el conocimiento al respecto no es solo del QA sino de todos los demás equipos - Dev, BA, Client, Project management, etc. Por lo tanto, es un esfuerzo colectivo, impulsado por el equipo de testing.
¿Cómo se realizan las pruebas de bases de riesgo?
Paso 1) Identificación de riesgo
Identificar todas las áreas funcionales de la AUT. Esto simplemente incluirá hacer una lista.
Paso 2) Evaluación de riesgos
Todos los riesgos se cuantifican y priorizan en este paso. Cuantificar es simplemente, asignar un número a cada riesgo en la lista que dará una indicación de la prioridad con la que se debe abordar.
Se decide la probabilidad de cada riesgo (la posibilidad de que ocurra) y el impacto (cantidad de pérdida que causaría cuando este riesgo se materialice).
El método típico es asignar las calificaciones. Por ejemplo, La probabilidad puede tomar valores del 1 al 5. 1 es la probabilidad de que ocurra ser baja (no es probable que suceda) y 5 es alta (lo más seguro es que ocurra).
Del mismo modo, a Impact también se le puede asignar una calificación de 1 a 5. 1 es de bajo impacto (incluso si este riesgo se materializa, la pérdida es mínima) y 5 es de alto impacto (grandes pérdidas cuando ocurre).
Paso 3)
Haga un formato de tabla y circule a todos los representantes del equipo: Dev, BA, Cliente, PM, QA y cualquier otra persona relevante.
Etapa 4)
Indique a cada equipo que complete los valores según su calificación de probabilidad e impacto.
Dado que los valores de probabilidad e impacto son numéricos, facilitará el cálculo del valor del “Factor de riesgo”.
Factor de riesgo = Probabilidad X Impacto. Cuanto mayor sea el factor de riesgo, más grave será el problema.
Un ejemplo:
Tenga en cuenta que en este punto, esto es simplemente el resultado de la calificación de un equipo. Para un proyecto en el que están involucrados 5 equipos diferentes, el equipo de QA terminaría con 5 mesas diferentes.
Paso # 5)
Tome un promedio de los valores de los factores de riesgo. Por ejemplo, si hay 5 equipos, para cada módulo, sume todos los valores de los factores de riesgo y divídalos por 5. Estos son los valores finales que vamos a tratar. Diga, estos son los factores de riesgo promediados:
Cuanto mayor sea el factor de riesgo, más debe probarse ese módulo.
Por lo tanto, los módulos 5 y 2 son los más cruciales para el éxito del negocio. Comparte los resultados con todos los equipos.
Paso # 6)
Plan de mitigación de riesgos : Ahora, este es el paso que cambia de Proyecto a Proyecto. Hemos identificado que los módulos 5 y 2 son los que más necesitan concentrarse.
Ejemplosdel plan podría ser:
- Los módulos 5 y 2 se probarán a fondo asegurándose de que se prueben todos los casos de prueba relacionados con ellos. Los otros módulos se probarán de forma exploratoria.
- Los módulos 5 y 2 se probarán primero y luego, según el tiempo disponible, se ocuparán los demás.
Una vez elaborado el plan, todos los equipos llegan a un acuerdo y lo siguen para probar el producto teniendo en cuenta el factor de riesgo.
¡Eso es!
Algunos puntos importantes a tener en cuenta:
- Dado que esta es una actividad colectiva que requiere la opinión de todos en consideración ; las posibilidades de que sea precisa y eficaz son mayores.
- Este es no es un método formal y no tiene que ser parte de todos los proyectos de control de calidad.
- A veces, incluso si el equipo elige no dibujar tablas y asignar valores, una simple sesión de lluvia de ideas con todos los presentes puede dar al equipo de control de calidad una buena dirección sobre cómo proceder.
- los aportes del equipo de desarrollo es muy importante porque son ellos quienes crean el producto, por lo que sabrán qué podría funcionar y qué podría necesitar verificación adicional. Asegúrese de estar atento a eso.
- Aunque hay varios pasos en el proceso, no se necesita una cantidad considerable de tiempo para realizarlos . Especialmente, si todos los equipos pueden sentarse juntos y trabajar simultáneamente.
- Recuerde este proceso y su resultado es solo la alternativa . Obtener todo el tiempo previsto para las pruebas es la mejor manera de realizar la actividad de control de calidad.
Conclusión
El enfoque de las pruebas basadas en riesgos indica claramente que el enfoque del evaluador no es solo seguir explorando los defectos, independientemente de la gravedad y la prioridad. Ahora las cosas han cambiado y los probadores deben trabajar de manera inteligente y deben comprender la clara 'necesidad del cliente y los deseos del usuario'.
Deben estudiar el producto a fondo y comprender cuál es la característica más utilizada en la producción, cuál es la ruta más crítica para la generación de ingresos y cómo proteger y salvaguardar a los clientes de los problemas de producción y las amenazas comerciales.
Por lo tanto, el enfoque RBT claramente educa a los 3 probadores de que solo probar todo o realizar pruebas exhaustivas no significa que las pruebas estén completas o que no haya defectos en el producto. Probar de manera efectiva en un tiempo estipulado y garantizar que los impactos comerciales importantes y críticos se anulen y eso es bastante importante para el evaluador.
Por lo tanto, las pruebas basadas en riesgos son la herramienta más eficiente para que el equipo de garantía de calidad oriente a las partes interesadas del proyecto en función de los riesgos del proyecto. El enfoque RBT ayuda al equipo de QA en la identificación continua de riesgos y su resolución que podrían poner en peligro el logro de las metas y objetivos generales del proyecto y ayuda a lograr el objetivo final del QA Group.
PD Las palabras QA y Testing se han utilizado indistintamente en todo el documento.
Sobre el Autor: Este artículo está escrito por varios miembros del equipo de STH: Gayathri Subrahmanyam y Swati S.
Gayathri es una PYME de pruebas de software con más de dos décadas de experiencia en pruebas de software y ha adoptado ampliamente el enfoque de 'pruebas basadas en riesgos' como parte de la industrialización de pruebas en varios compromisos y se ha dado cuenta de los beneficios de la optimización de recursos de prueba y las pruebas de calidad.
¿Las pruebas basadas en riesgos fueron un desafío para usted? ¿Tiene algún dato interesante que agregar a nuestro tutorial? ¡Siéntete libre de expresar tus pensamientos en la sección de comentarios a continuación!
=> Visite aquí para ver la serie completa de tutoriales del plan de prueba
Lectura recomendada
- Proceso de integración continuo: cómo mejorar la calidad del software y reducir el riesgo
- Análisis de modos y efectos de falla (FMEA): cómo analizar los riesgos para obtener una mejor calidad de software y clientes satisfechos.
- La guía definitiva para las pruebas basadas en riesgos: gestión de riesgos en las pruebas de software
- Las 10 mejores herramientas y técnicas de evaluación y gestión de riesgos
- Tipos de riesgos en proyectos de software
- Algunas preguntas interesantes de la entrevista sobre pruebas de software
- Elegir las pruebas de software como carrera
- Comentarios y revisiones del curso de pruebas de software