Las publicaciones periódicas especiales de EBSE se dividen en "cinco" capítulos. Este artículo es el "cuarto" capítulo de la serie. En el "capítulo (3)" anterior, se explicó el contenido del "paso dos, determinar el plan de mejora a través de la investigación sistemática" en combinación con prácticas de investigación específicas. Luego, en este capítulo (4), analizaremos en detalle el paso tres de EBSE: reflexión crítica sobre la evidencia y resolución de problemas actuales.
Análisis del proceso de prueba EBSE automotriz (2): un estudio de caso de ventajas y desafíos
6. Paso tres: reflexionar críticamente sobre la evidencia y utilizarla para abordar el problema en cuestión.
Value Stream Mapping (VSM) se utiliza como herramienta de análisis de procesos para evaluar fortalezas y debilidades. Esta herramienta se utiliza para buscar y eliminar residuos. Un flujo de valor captura todas las actividades (tanto con valor agregado como sin valor agregado) actualmente requeridas para llevar un producto a través de los principales pasos del proceso hasta el cliente (flujo del proceso de un extremo a otro). Las actividades con valor agregado son aquellas que agregan valor al producto (por ejemplo, asegurando la calidad de las características), y las actividades sin valor agregado se refieren al tiempo de espera. Los mayores retrasos o cuellos de botella en el flujo de valor (es decir, sin valor agregado) presentan las mayores oportunidades para mejorar la capacidad del proceso. La motivación detrás de elegir VSM fue porque es una herramienta eficiente a través de la cual podemos realizar el proceso de prueba para comprender el flujo de trabajo y centrarnos claramente en identificar los residuos desde una perspectiva de extremo a extremo. Permite a los directivos dar un paso atrás y repensar todo el proceso desde una perspectiva de creación de valor. Además, es natural para la industria automotriz y se acepta fácilmente como un método de mejora ya que se originó en el campo automotriz (por ejemplo, el Sistema de Desarrollo de Productos de Toyota).
El mapeo del flujo de valor se realiza en dos pasos. En el primer paso, se mapean las actividades actuales utilizando la notación de la Figura 3, distinguiendo entre actividades con valor agregado y sin valor agregado. Indique desperdicio e ineficiencia con señales de ráfaga. La ingeniería de software normalmente define siete tipos de desperdicio (ver Tabla 12). Posteriormente se traza un mapa del estado futuro que incorpora mejoras en los residuos identificados. La Figura 1 muestra cómo la información obtenida de la evaluación del proceso de prueba realizada en el estudio de caso se relaciona con las actividades del flujo de valor.
Figura 3: Representación del mapeo del flujo de valor
6.1 Mapa del estado actual
Realizamos un mapeo de actividades del proceso a través del cual visualizamos diversas actividades realizadas durante el proceso de prueba. Esta sección presenta el mapa actual del flujo de valor, que describe los residuos identificados en el VSM y las entrevistas. El valor creado por el proceso se determina para diferentes tamaños de equipo, como se muestra en la Tabla 10 (definición de valor) y la Tabla 11 (descripción general del valor en proceso).
Tabla 10: Definiciones de valores
Las actividades que no agregan valor se identifican en el flujo de valor actual del proceso de prueba para ver áreas de mejora, como se muestra en la Figura 4.
Mapa del estado actual del proceso de prueba, que revela los siete desperdicios definidos en el contexto del Desarrollo Lean de Software/Mapeo de Flujo de Valor. Los siete desechos identificados incluyen trabajo parcialmente completado, procesamiento adicional, traspasos, cambio de tareas, reaprendizaje, retrasos y defectos (numerados W1-W7) (consulte la Tabla 12 para las definiciones de desechos).
Estos desechos se identifican en diferentes actividades del proceso de prueba, lo que lleva a retrabajos, aumento del tiempo de espera o tiempo ineficiente invertido durante toda la actividad de prueba. La Figura 4 ilustra el proceso de prueba planificado y los residuos identificados. Sin embargo, los problemas que surgen durante otras actividades que afectan las pruebas (por ejemplo, gestión de requisitos, etc.) no se muestran en el diagrama de flujo actual. Las razones detrás de esto y su impacto negativo en las actividades de prueba se discutieron en la sección anterior.
Durante nuestras pruebas identificamos 12 áreas (1-12 mostradas en la Figura 4) donde se produjeron desechos. A continuación se presenta una descripción de los residuos que se producen en cada subproceso identificado en el diagrama de flujo actual.
Residuos identificados en el Subproceso 1: Los residuos observados en el Subproceso 1 son trabajos que se encuentran parcialmente terminados. El motivo de las pruebas incompletas es la falta de pruebas planificadas debido a la falta de definición de la prueba y a las pruebas realizadas apresuradamente (C1), lo que en última instancia conduce a pruebas de manera no estructurada con una cobertura de prueba baja. Esta situación se ve agravada por requisitos poco claros.
Figura 4: Diagrama de estado actual
Tabla 11: Valores
Tabla 12: Definiciones de residuos
Desperdicio identificado en el subproceso 2: En este proceso identificamos el desperdicio de "funciones extra" y "conmutaciones". Funciones adicionales que a veces se eliminan del sistema antes del lanzamiento, incluso si ya están implementadas, por ejemplo, debido a inestabilidad y requisitos poco claros (C03). Sin embargo, dichas características/funcionalidades también se prueban. Este desperdicio se produce en la forma en que se escriben los planes de prueba, en la programación posterior de las pruebas y en la asignación de recursos. Los requisitos poco claros también requieren un reaprendizaje (W3).
Desperdicio identificado en el subproceso 3: Como se identificó en el estudio de caso, un problema común en la organización del caso son las limitaciones de recursos (C04). El desperdicio que se produce aquí es la falta de disponibilidad de testers (W3: traspaso) y roles y responsabilidades poco claros como parte de la estructura organizacional, lo que impide la formación del equipo correcto, lo que lleva al cambio de tareas (W4).
Desperdicio identificado en el Subproceso 4: El trabajo no avanza y se retrasa debido al tiempo significativo requerido por el cliente y la organización de desarrollo para negociar la versión actual de los requisitos candidatos (W1: Trabajo parcialmente completado/W6). Se observa que este proceso se repite múltiples veces, involucrando múltiples interacciones con el cliente, ya que nadie tiene la misma visión del requerimiento que los demás (C03). Para escribir casos de prueba para requisitos, es necesario tener un conjunto de requisitos estable y detallado para diseñar y analizar pruebas para la próxima versión.
Desperdicio identificado en el subproceso 5: Los retrasos aquí nuevamente se presentan en forma de largas esperas (W06: Latencia) utilizadas para activar los requisitos de verificación (C03) para finalizar la lista de casos de prueba que se ejecutarán en la actividad de prueba. En ocasiones, los casos de prueba de versiones anteriores no se actualizan. Se necesitaría mucho tiempo y esfuerzo para reescribir (W5: reaprender) los requisitos de la versión anterior e incluir esos casos de prueba en la versión actual. La falta de automatización en la generación de casos de prueba también contribuye a este retraso, ya que las pruebas se vuelven a trabajar a menos que se automaticen (relacionado con las herramientas de prueba, C07).
Residuos identificados en el Subproceso 6: Como se analizó anteriormente en el Desafío C10, no siempre se mantiene la documentación sobre las pruebas. Los casos de prueba de versiones anteriores no siempre se actualizan en el repositorio de casos de prueba, lo que significa artefactos de prueba no documentados (W1: trabajo parcialmente completado). Algunos de estos artefactos de prueba faltantes pueden llevar la actividad de prueba a una situación crítica, lo que eventualmente provocará que se repita toda la prueba nuevamente.
Residuos en el área de subproceso 7: Algunos artículos requieren equipo de prueba para realizar pruebas. El equipo de prueba del cliente no está disponible para realizar pruebas a tiempo (W3: Entrega). Sin embargo, en algunos casos, este desperdicio se reduce ya que los entornos de prueba utilizados en versiones anteriores se conservan y mantienen para versiones posteriores del producto. Como se señaló en el Desafío C7, no existe una razón específica para esta omisión.
Residuos en el Área de Subproceso 8 : Todas las actividades de prueba realizadas en la organización del caso se gestionan utilizando diferentes herramientas, generalmente para ahorrar tiempo. Pero en la práctica estas herramientas no sirven para este propósito. En cambio, utilizar estas herramientas para gestionar y asignar artefactos de prueba consume más recursos y, en ocasiones, crea una redundancia que crea una complejidad innecesaria. No disponer de una herramienta unificada que pueda gestionar y organizar todas las actividades de ensayo en el sector de la automoción lo convierte en un reto (C7), generando un despilfarro denominado handovers (W3), que están relacionados con la disponibilidad de personal, equipos, etc.
Residuos en el Área de Subproceso 9: No se realizan pruebas como actividad paralela al desarrollo (C09). En última instancia, localizar los defectos consume tiempo y dinero, lo que parece ser una carga para los evaluadores y provoca enormes retrasos (W6). La mayoría de los equipos no utilizan actividades de verificación que respalden la detección temprana de defectos, como inspecciones y revisiones de códigos. Otro tipo de desperdicio que ocurre aquí (W4: Traspaso) puede deberse a la falta de disponibilidad de evaluadores y de capacitación para implementar pruebas utilizando técnicas de prueba específicas, como pruebas exploratorias o pruebas basadas en la experiencia. Las pruebas exploratorias y basadas en la experiencia se basan en la intuición y la habilidad del evaluador (ver C04). Aunque estas técnicas de prueba se consideran una fortaleza de las organizaciones de casos, actualmente solo existe un número limitado de evaluadores que son capaces de realizar tales actividades. Esto, a su vez, provoca retrasos en las pruebas cuando estos evaluadores experimentados abandonan o pasan a otro proyecto. Sin embargo, la documentación sobre cómo utilizar técnicas y herramientas de prueba no se actualiza continuamente (y a veces no está disponible), por lo que no se puede confiar en que las pruebas se realicen (C10).
(Para C01-C010, consulte el capítulo serial (2) de este tema especial)
Residuos en el Área de Subproceso 10: Los atributos de calidad que deben incluirse en la pieza de trabajo bajo prueba no se obtienen adecuadamente desde el inicio del proyecto (W1: Trabajo parcialmente completado), lo que resulta en una mala calidad del producto. Algunos encuestados creen que las pruebas son sólo para garantizar la calidad de las funciones básicas, por lo que no pueden garantizar la confiabilidad del sistema entregado (C08). Faltan los estándares de calidad necesarios para medir el nivel de calidad y poder comparar los resultados de las pruebas con versiones anteriores. El análisis de los resultados de las pruebas ayuda a redefinir las mejoras de calidad que deben implementarse en la próxima versión del producto. Algunos empleados también informaron de largos retrasos (W6: Retraso) ya que los desarrolladores tuvieron que esperar a que se solucionaran los errores después de que se informaran. Este tiempo de espera puede parecer largo cuando la persona responsable del código pasa a otro proyecto inmediatamente después de completar el trabajo en el proyecto anterior (ver C04). Este problema se puede resolver si las pruebas se realizan en paralelo con el desarrollo.
Residuos en el Área de Subproceso 11: Debido a la volatilidad de los requisitos (C3), las especificaciones de los requisitos no están bien documentadas, lo que lleva a una mala interpretación de los requisitos. El esfuerzo y los recursos invertidos en desarrollar y probar requisitos mal entendidos no sirven de nada (W3: Reaprender). Los requisitos necesarios se obtienen y desarrollan después de una serie de interacciones con el cliente, lo que conduce a retrabajos innecesarios y cambios de tareas (W5).
Residuos en el Área de Subproceso 12: Los defectos detectados en versiones anteriores en ocasiones no se solucionan (W1: Trabajo parcialmente realizado), lo cual es acordado por el cliente. Pero a medida que el sistema evoluciona, estos errores son difíciles de detectar en la próxima versión. La falta de actividades de validación y actividades tempranas de prevención de defectos (W7: Defectos) crearon confusión antes del lanzamiento, y algunos defectos no resueltos en la versión actual se dejaron para la próxima versión. Este proceso se repite varias veces para cada versión. A medida que crece la funcionalidad, quedan muchos errores sin corregir, que pueden ser difíciles de localizar en un sistema tan complejo.
La Tabla 13 proporciona un resumen de los residuos y su relación con los desafíos.
6.2 Mapa del estado futuro
De los resultados se desprende claramente que otros procesos, especialmente la recopilación de requisitos y la documentación, afectan las pruebas de forma negativa y generan mucho desperdicio. Descubrimos que los desperdicios más comunes, a saber, W3: Entrega y W1: Trabajo parcialmente completado, se produjeron debido a grandes retrasos que desencadenaron requisitos de prueba claros y estables. Los desafíos identificados durante las pruebas informaron una caída en la cobertura de las pruebas debido a la afluencia de requisitos y un aumento en la cantidad de fallas debido al retraso en las pruebas. Los errores que aparecen en la versión actual a veces no se solucionan ni se entregan, por lo que los mismos errores se repiten en la siguiente versión, pero resulta difícil y costoso rastrearlos y corregirlos. Por lo tanto, los métodos de prueba utilizados actualmente no son adecuados para el flujo continuo de requisitos, lo que indica la necesidad de pasar a nuevos métodos, que puedan gestionar y organizar los cambios mientras mejoran la calidad.
Tabla 13: Residuos
El VSM del estado futuro, que se muestra en la Figura 5, es de naturaleza ágil. El proceso que se muestra representa una iteración.
Recomendamos el uso de prácticas ágiles (SP6) y gestión de pruebas (SP7), que ayudan a utilizar el tiempo de los evaluadores de manera más eficiente a través de la paralelización del desarrollo y las pruebas, la detección temprana de fallas y una comunicación breve. Agile también ayuda a lograr una alta transparencia en términos de los requisitos de los evaluadores, ya que la planificación de pruebas se realiza para todas las iteraciones. Sin embargo, el plan de prueba se puede actualizar en detalle para cada iteración. En particular, las prácticas ágiles (SP6) enfatizan los requisitos pendientes y las estimaciones de recursos de iteración para mantenerlos precisos y flexibles. Al mismo tiempo, el plan de pruebas debe documentarse, ya que es un requisito previo para poder reutilizar los artefactos de prueba de manera eficiente y alinear las pruebas con las actividades de requisitos (presentadas en SP7) para cada iteración. Para obtener requisitos, se han considerado útiles las historias de usuarios (consulte SP1). Los niveles de abstracción pueden ser importantes porque cuando los requisitos se priorizan en un nivel de abstracción, las prioridades deben propagarse a otros niveles (consulte SP1).
(Para SP1-SP7, consulte el capítulo serializado (3) de este tema)
Se descubrió que un proceso de prueba flexible era una fortaleza del proyecto, especialmente en equipos pequeños. La mayoría de las veces, las pruebas se realizan de una manera que ofrece más funciones (valor: V1) que calidad. Sin embargo, se ha descubierto que algunas técnicas de prueba, como las pruebas exploratorias y basadas en la experiencia, que dependen enteramente de la competencia y las habilidades de los evaluadores, mejoran la calidad del proceso de prueba implementado en el ámbito del automóvil. Este estudio también reveló que los desafíos en términos de limitaciones de recursos, como las dificultades para encontrar profesionales con capacidad de prueba adecuada con los conocimientos y la experiencia para realizar pruebas específicas del dominio automotriz, actúan como barreras para la integración de la calidad. Los desperdicios identificados en este caso podrían ser grandes retrasos o falta de personal para realizar las actividades de prueba (W3, W4). Casi 6 de cada 8 proyectos de investigación carecen de evaluadores dedicados.
El uso de estándares/medidas de calidad (SP3) ayuda a lograr una visión común de las pruebas, por lo que la comunicación y el intercambio de conocimientos se vuelven más fáciles, lo cual es importante cuando las pruebas se realizan con un número pequeño de personas. Es posible que las metodologías de prueba ágiles no conduzcan automáticamente a una incorporación de calidad, pero con prácticas ágiles adecuadas, es posible (ver SP6). Las entrevistas con Scrum masters en este estudio muestran claramente que cuando se utiliza correctamente, la metodología Agile es una fortaleza que proporciona no sólo flexibilidad y agilidad sino también calidad.
Los desafíos relacionados con las limitaciones de tiempo y costos, las técnicas de prueba (C02) y las herramientas y entornos (C07) hacen que redactar buenas pruebas sea claramente un desafío. Las pruebas automatizadas ahorran tiempo y aumentan el valor y la rentabilidad de las pruebas. Como se documenta en SP4, se han propuesto múltiples herramientas y enfoques para automatizar diferentes tipos de pruebas, por lo que las opciones son variadas y cuál elegir también depende del análisis comparativo en un contexto determinado. Para mejorar aún más la situación, los equipos pueden intentar implementar otras técnicas de prueba, como las pruebas exploratorias, que ya se utilizan en algunos proyectos y pueden encontrar defectos de manera efectiva. Las pruebas exploratorias se mencionaron como una ventaja en la Sección 4.5.2 del Capítulo 2 de esta serie de temas . La automatización de las pruebas unitarias y las pruebas de regresión puede facilitar la reutilización de casos de prueba y agregar valor al producto final. En el desarrollo ágil (SP6), el desarrollo basado en pruebas facilita la automatización de las pruebas unitarias porque las pruebas automatizadas se escriben antes de que se escriban nuevas funciones. En la Sección 4.5.2 del Capítulo 2 de esta serie de funciones basadas en SLR se identifican y sugieren una variedad de herramientas para respaldar las pruebas , que ya se utilizan en la industria automotriz.
Figura 5: Mapa del estado futuro
De esta investigación es razonable decir que no se presta tanta atención a las pruebas como al desarrollo de código nuevo. De las entrevistas se desprende que las pruebas tienen una baja prioridad, lo que no favorece el intercambio y la transferencia de conocimientos en las pruebas. En este sentido, la gestión de competencias puede considerarse esencial para las actividades de prueba, que pueden mejorar las habilidades y el conocimiento en las pruebas a través de la transferencia y el intercambio de conocimientos (ver SP2). Además, pensamos que sería mejor si los evaluadores necesarios pudieran estimarse al comienzo del proyecto, asignarse de forma rotativa y compartir su conocimiento con varios equipos. Esto también les ayudará a aumentar el nivel de capacidad con cada iteración, mejorando así las pruebas.
Las propuestas de solución a las oportunidades identificadas se basan en SLR y entrevistas (teniendo en cuenta los valores y beneficios mencionados). La propuesta de solución no pudo validarse dentro del alcance de este estudio. Sin embargo, las recomendaciones se extraen de literatura revisada por pares que está validada en la industria y es muy consistente con las experiencias de las empresas encuestadas en este estudio que utilizan Agile. Además, se presentaron soluciones a los profesionales que brindaron comentarios. El proceso de estado futuro propuesto ya incorpora sus comentarios.
Para obtener más contenido, preste atención a "Análisis del proceso de prueba EBSE automotriz (5): Paso 4, evaluar y reflexionar sobre el proceso EBSE".