Documente Academic
Documente Profesional
Documente Cultură
Cochabamba – Bolivia
2018
TABLA DE CONTENIDO
INTRODUCCIÓN .................................................................................................................................................................. 4
1. ANTECEDENTES ...................................................................................................................................................... 4
1.1. Pruebas en el desarrollo de software ................................................................................................ 4
1.2. Las pruebas continuas no son una herramienta ......................................................................... 5
2. OBJETIVOS ................................................................................................................................................................... 6
2.1. Objetivo General ............................................................................................................................................. 6
2.2. Objetivos Específicos .................................................................................................................................. 6
3. METODOLOGÍA .......................................................................................................................................................... 7
4. EL VALOR DE LAS PRUEBAS CONTINUAS .......................................................................................... 7
4.1. ¿Qué es un Riesgo de Negocio? ......................................................................................................... 7
4.2. El valor comercial de las pruebas continuas ................................................................................. 8
4.3. Re-evaluando el costo de la calidad .................................................................................................. 9
5. DEFINIR LAS EXPECTATIVAS DEL NEGOCIO ................................................................................ 10
5.1. Brecha entre las expectativas del negocio y la implementación técnica del
producto .............................................................................................................................................................................. 10
5.2. ¿Qué se necesita para reducir esta brecha? ............................................................................. 12
5.3. Expectativas del negocio ........................................................................................................................ 13
5.3.1. Importancia de tener respaldo de un gerente ejecutivo ........................................... 14
5.3.2. Comunicar el impacto de la falla............................................................................................. 14
5.3.3. Proveer visibilidad dentro del Proceso................................................................................ 15
5.3.4. Capacitación sobre las expectativas comerciales ....................................................... 15
6. UNA PLATAFORMA PARA EVALUAR LOS RIESGOS COMERCIALES ........................... 16
7. PRUEBAS CONTINUAS: ¿QUÉ ESTÁ INVOLUCRADO?............................................................ 16
7.1. Evaluación de riesgos: ¿El software está listo para ser liberado? ............................... 17
7.1.1. Deuda Técnica ................................................................................................................................... 18
7.1.2. Tareas de mitigación de riesgos ............................................................................................. 19
7.1.3. Optimización del Code Coverage .......................................................................................... 19
7.1.4. Evaluación de la calidad de pruebas ................................................................................... 20
7.2. Análisis de Políticas ................................................................................................................................... 20
7.3. Trazabilidad de Requerimientos ........................................................................................................ 22
7.4. Análisis Avanzado....................................................................................................................................... 22
7.4.1. Prevención de defectos con análisis estático ................................................................. 22
7.4.2. Cambio de análisis de impacto ................................................................................................ 23
1
7.4.3. Alcance y priorización ................................................................................................................... 24
7.5. Optimización de las pruebas ................................................................................................................ 25
7.5.1. Administración de optimización de pruebas .................................................................... 25
7.5.2. Construcción y Capacidad de Pruebas .............................................................................. 26
7.5.3. Manejo de Datos de Prueba...................................................................................................... 27
7.5.4. Mantenimiento.................................................................................................................................... 27
7.6. Acceso a ambientes de pruebas ....................................................................................................... 28
8. PROCESO DE PRUEBAS CONTINUAS ................................................................................................. 30
8.1. Pruebas automatizadas versus Pruebas continuas ............................................................... 31
9. CONCLUSIONES .................................................................................................................................................... 32
10. DICCIONARIO DE TÉRMINOS EN ESTE DOCUMENTO ....................................................... 33
11. REFERENCIAS BIBLIOGRÁFICAS ....................................................................................................... 34
2
TABLA DE FIGURAS
3
INTRODUCCIÓN
Cuando iniciaron los procesos ágiles y estos entraron con fuerza para ser usados por los
equipos de desarrollo de software en diferentes compañías; los Sprints e iteraciones hacían
que los equipos de desarrollo fueran más rápidos, sin embargo dejaron a los sub-equipos de
QA y Operaciones en una posición inadecuada, tratando de alcanzar y completar trabajo
realizado por los sub-equipos de desarrollo o disminuyendo al mínimo las prácticas de
calidad sobre los diferentes entregables, o retrasando a todo el equipo de desarrollo.
Por tanto, surgen las pruebas continuas en DevOps, que fomentan un enfoque sistemático
hacia la mejora del proceso, en lugar de acelerar el mismo sin control, o disminuyendo el
desarrollo sin omitir la calidad.
Las pruebas continuas van más allá de la automatización y abarcan todas las prácticas,
incluidas las herramientas y el cambio cultural, que ayudan a mitigar los riesgos antes de
pasar a las siguientes etapas del ciclo de vida de desarrollo de software.
1. ANTECEDENTES
Las empresas empiezan a acelerar el ciclo de vida del desarrollo de Software (SDLC), por
tanto, se hará más evidente los cuellos de botella en los procesos de desarrollo. Uno de los
cuellos de botella que limita la aceleración del proceso son las “Pruebas”. Las “Pruebas”
suelen ocurrir por lo general después que el código ha sido completado y antes de las fechas
de liberación del producto (Release Date). Por esta razón, muchas empresas y compañías
deciden realizar las pruebas después de que el producto ha sido liberado obligando a los
clientes a realizar pruebas de aceptación del producto. Esto constituye en deuda técnica
dentro del desarrollo de Software que se constituye en riesgo y complejidad para cada
liberación del software (Release).
Otro obstáculo en la aceleración del ciclo de vida del desarrollo de software es la carencia de
un proceso de calidad coordinado que dificulta a las empresas tomar una decisión para
liberar o no el software con la confianza de que cumple con todos los parámetros de calidad.
Los managers suelen preguntar si el equipo ha completado las pruebas para liberar o no el
software, sin embargo hoy en día, ésta puede ser considerada una pregunta errónea dentro
del proceso de desarrollo de software; esta pregunta está vinculada a un concepto de
4
“calidad del software” que está directamente relacionada con pruebas estáticas que
producen resultados múltiples e independientes de éxito (pass) o falla (fail); pero no es
exactamente la información necesaria para entender el impacto real para la experiencia del
usuario final. Para tal efecto, se debe realizar un análisis de riesgos que se torna en una
misión crítica dentro de las compañías para intentar acelerar el proceso de desarrollo de
software para poder ayudar a los managers tomar las decisiones apropiadas con respecto a
la liberación del software.
Por tanto, la pregunta real debería de ser “¿Tiene este software candidato a ser liberado un
nivel aceptable de riesgo?”. Sin embargo, esta pregunta no es simple de responder, y
conlleva muchas suposiciones que son críticas:
2. Se entiende claramente cómo medir cada uno de los riesgos del negocio que han
sido definidos.
3. Se establece una línea de base y umbrales para definir lo que constituye un nivel
aceptable de riesgo. Algunos riesgos del negocio pueden tener tolerancia cero y no
hay umbrales para la aceptación.
Esta es la razón por la que el concepto de “Pruebas Continuas” es tan crítico. Las pruebas
continuas encuentran un equilibrio entre todas las tareas del desarrollo de software y tienen
un enfoque de arriba hacia abajo centrado en salvaguardar la integridad de la experiencia del
usuario mientras protege al negocio de los impactos potenciales de las deficiencias de la
aplicación.
5
Cuando se trata de la calidad del software, nos enfrentamos a la necesidad de una
verdadera reingeniería de procesos. Las pruebas continuas no son una solución inmediata.
Al igual que con todas las iniciativas impulsadas por procesos, requiere la evolución de las
personas, el proceso y la tecnología. Debemos adaptarnos a la naturaleza creativa del
desarrollo de software como una disciplina, pero debemos enfrentar el hecho abrumador de
que el software impregna todos los aspectos del negocio, y la falla del software ahora
presenta el mayor riesgo para la organización.
2. OBJETIVOS
• Dado que las pruebas comienzan temprano y se ejecutan de manera continua, los
riesgos de la aplicación se exponen poco después de su introducción. Los equipos de
desarrollo pueden evitar que esos problemas avancen a la siguiente etapa del SDLC.
Esto reduce el tiempo y el esfuerzo que se necesitan para encontrar y corregir
defectos. Como resultado, es posible aumentar la velocidad y frecuencia con la que
se entrega el software de calidad (software que cumple con las expectativas de un
nivel de riesgo aceptable), así como disminuir la deuda técnica.
• Además, cuando los esfuerzos de calidad del software y las pruebas se alinean con
las expectativas del negocio, la ejecución de la prueba produce una lista priorizada de
tareas ejecutables (en lugar de un número potencialmente abrumador de resultados
que requieren una revisión manual). Esto ayuda a los equipos a enfocar sus
esfuerzos en las tareas de calidad que tendrán el mayor impacto, en función de los
objetivos y prioridades de su organización.
6
pruebas. Esta información se puede usar para establecer un circuito de
retroalimentación que ayude a los equipos a mejorar el proceso de manera
incremental. La medición frecuente, los circuitos de retroalimentación ajustados y la
mejora continua son principios clave de DevOps.
3. METODOLOGÍA
No se puede apreciar por completo el valor de las pruebas continuas sin entender el
concepto de riesgo comercial. Hemos mencionado el término “riesgo de negocio” algunas
veces hasta ahora; tomemos un momento para definirlo antes de continuar.
Los riesgos de negocio más comunes asociados con el software están ligados a la seguridad
de las aplicaciones, que es una iniciativa anual multimillonaria para las organizaciones de IT
(Information Technology). La pérdida de información personal o privada debido al robo de
datos, las violaciones de datos o los piratas informáticos no solo ataca al valor de la marca,
sino que también puede generar sanciones financieras.
7
Existen muchos otros riesgos que son una amenaza igualmente para el negocio, pero atraen
mucha menos atención. Por ejemplo, los riesgos pueden caer en categorías como la
flexibilidad de la aplicación, la accesibilidad, la disponibilidad, la confiabilidad y la capacidad
de prueba... por nombrar solo algunas. Debido a la naturaleza extremadamente variada del
desarrollo de software, los riesgos principales inevitablemente variarán entre organizaciones,
aplicaciones y liberación del software. Por ejemplo, la seguridad podría ser absolutamente
crítica en el contexto de una aplicación bancaria, pero se considera trivial en un servicio web
público que informa una observación meteorológica.
Dadas las expectativas comerciales en cada etapa del desarrollo de software, las pruebas
continuas brindan una evaluación cuantitativa del riesgo, así como también tareas
accionables que ayudan a mitigar los riesgos antes de que pasen a la siguiente etapa del
SDLC. El objetivo es eliminar actividades sin sentido y producir tareas de valor agregado que
impulsen a la organización de desarrollo hacia una publicación exitosa.
2. Las pruebas continuas establecen una red de seguridad que permite a los
desarrolladores de software traer nuevas características al mercado más rápido. Con
un conjunto de pruebas de confianza que garantiza la integridad de los componentes
y la funcionalidad de las aplicaciones relacionadas, los desarrolladores pueden
evaluar de inmediato el impacto de los cambios en los códigos. Esto no sólo acelera
la tasa de cambio, sino que también mitiga el riesgo de que los defectos del software
lleguen a los clientes.
8
decisiones de compensación para cumplir el objetivo comercial establecido. Al
proporcionar una comprensión del riesgo de liberación o entrega de software
(release), las pruebas continuas ayudan a optimizar el resultado del negocio.
Un motivador fundamental para la evolución hacia las Pruebas Continuas es que las
expectativas del negocio sobre la velocidad y confiabilidad de las versiones de software han
cambiado drásticamente, en gran medida porque el software se ha transformado de un
habilitador de procesos de negocios en un diferenciador competitivo.
Cada segmento de negocio se redefine, con un enfoque en una experiencia perfecta para el
usuario final y una mejor conectividad, por tanto en muchos casos se reinventa, con
software, como por ejemplo:
● Ventas → Amazon
En algunos casos, la industria crea e investiga el mercado y obtiene una visión de futuro y
desarrollo. En la mayoría de los casos, hemos visto cambios agresivos que entran en los
mercados y desafían el status quo. Por ejemplo, el ascenso meteórico en la popularidad de
Uber frente a un taxi común que brinda servicios.
Este cambio radical se centró en la experiencia del cliente también viene con expectativas
mucho mayores de la calidad del software. Hoy, las fallas de software se destacan en
titulares de noticias como fallas organizacionales con impactos arraigados a un nivel
ejecutivo y también en precios de acciones. Como fue el caso del problema de seguridad de
Facebook en el primer trimestre de este año 2018.
9
La conclusión es que debemos reevaluar el costo de la calidad para nuestras organizaciones
y proyectos individuales. Si su evaluación de costos de calidad expone una brecha en su
proceso de calidad, es una señal de que ahora es el momento de volver a evaluar la cultura
de su organización en lo que respecta a la construcción y pruebas de software. En la
mayoría de las organizaciones, el software de calidad es claramente la intención, pero la
cultura de la organización produce decisiones de compromiso que aumentan
significativamente el riesgo de exponer el software defectuoso al mercado.
Hoy en día, existe una brecha entre cómo la empresa define el riesgo y cómo el desarrollo
aborda estos riesgos en el software. Dada la creciente importancia del software, debemos
asegurarnos de que los esfuerzos del equipo de desarrollo y pruebas se centren en mitigar
los riesgos comerciales declarados de la organización. Esto se logra al expresar los objetivos
en políticas claramente definidas, de fácil acceso, medidas automáticas y gestionadas por
excepción.
5.1. Brecha entre las expectativas del negocio y la implementación técnica del
producto
No hay duda de que las preocupaciones diarias del CEO son diferentes a las
preocupaciones diarias de los desarrolladores e ingenieros de control de calidad. Sin
embargo, el equipo de desarrollo de software que escribe y prueba el código para las
aplicaciones orientadas al cliente en realidad podría tener un mayor impacto en la
satisfacción del cliente. Desafortunadamente, debido a la naturaleza técnica del equipo de
desarrollo, es muy probable que no exista un entendimiento real de las preocupaciones
comerciales del CEO y su equipo ejecutivo.
Cerrar esta brecha entre las expectativas del negocio y la implementación técnica no solo
reducirá el riesgo comercial, sino que también minimizará los impactos comerciales
negativos del software defectuoso. Cuando el desarrollo tiene una comprensión firme de las
expectativas del negocio y cómo traducirlas en la implementación técnica, los riesgos
comerciales se reducen significativamente.
Existen varios requisitos críticos para cerrar la brecha entre las expectativas del negocio y la
implementación técnica:
10
● Las expectativas o riesgos del negocio deben comunicarse claramente al equipo de
desarrollo como políticas. Una política convierte las expectativas en tareas
procesables y medibles. Esto ayuda a la organización a garantizar la coherencia del
proceso a la vez que se adapta ágilmente a las tendencias cambiantes del mercado,
los entornos normativos y las demandas de los clientes.
● Una infraestructura en tiempo real debe informar a los desarrolladores si cumplen las
expectativas. Para que esto funcione, las expectativas y/o los riesgos del negocio
deben correlacionarse con los requisitos no funcionales que se miden y monitorean
automáticamente. Si no está completamente automatizado y es completamente
discreto (administrado por excepción con impacto cero en la productividad),
simplemente no será factible, especialmente para los equipos que han adoptado
Agile y / o DevOps.
● Los ejecutivos deben tener claro que satisfacer estas expectativas no es negociable.
Los ejecutivos también deben ser capaces de monitorear automáticamente el
cumplimiento y evaluar el nivel de riesgo comercial para cada proyecto o software
candidato a ser liberado.
Con demasiada frecuencia, cuando el equipo está en pleno proceso de desarrollo y pruebas
de un software candidato a ser liberado, se centran en los aspectos técnicos específicos del
requisito funcional o la historia de usuario en el alcance. Lo que se pierde en la confusión es
una perspectiva integral de la experiencia del usuario. Por ejemplo, un equipo encargado de
implementar el inicio de sesión más seguro podría degradar inadvertidamente el rendimiento
de las aplicaciones en transacciones críticas. Sin un intento proactivo de alinear
consistentemente su trabajo con los requisitos comerciales claramente definidos, es probable
que el equipo corra rápido, pero no necesariamente en la dirección esperada. Si el trabajo
duro de los equipos de desarrollo y pruebas no produce el resultado comercial esperado, se
corre el riesgo de obstaculizar significativamente la productividad y desmoralizar al equipo.
11
Según un estudio, los equipos ágiles tienen un 38% de probabilidades de supervisar el
cumplimiento de los requerimientos de nivel del sistema (no funcionales). Comparado con los
equipos de cascada, que tienen un 58% de probabilidad de medir el cumplimiento de estos
requerimientos. Con esta información, podemos concluir que las limitaciones de tiempo de
las iteraciones cortas de desarrollo obligan a los equipos a enfocar sus recursos en la
validación de las historias de los usuarios en el alcance.
Cuando hacer que cada historia esté "completada" dentro de los plazos ya es un desafío, es
difícil justificar el gasto de tiempo validando si la aplicación satisface expectativas más
amplias a nivel del sistema. Y este problema seguramente aumentará a medida que
aumente la adopción de DevOps. Después de todo, si este nivel de verificación no es factible
cuando está trabajando en sprints de dos semanas, ¿cómo podría funcionar cuando
comience a liberar/entregar varias veces al día?
Si realmente se desea evaluar los riesgos comerciales asociados con un software candidato
a ser liberado, es esencial contar con una manera automática y discreta de evaluar
continuamente las expectativas comerciales generales en el contexto de una aplicación en
evolución. Este mecanismo debe basarse en expectativas comerciales claras y
convincentes, impulsadas por un fuerte patrocinio ejecutivo y respaldado por una
infraestructura de capacitación efectiva. Por tanto, tenemos los siguientes puntos:
12
equipo de negocio y desarrollo deben colaborarse para definir los indicadores clave
de rendimiento. Además, si la organización está explorando flujos de trabajo basados
en excepciones o nodos de decisión automatizados, los equipos deben trabajar
juntos para establecer los criterios de aceptación: criterios para activar una
notificación y/o detener el avance de una entrega.
Por ejemplo, una organización con una aplicación de compras móvil podría tener una política
asociada con la experiencia del cliente en relación con el rendimiento de la red. Bajo ciertas
condiciones de latencia, la empresa desea informar a sus usuarios que la degradación del
rendimiento es causada por problemas de red en lugar de la aplicación en sí. La
organización debería construir una política para el rendimiento. Luego, la organización
establecería el rendimiento esperado y establecería el criterio que debería desencadenar
una advertencia sobre el rendimiento de la red. El equipo de desarrollo necesitaría acceder a
un entorno de prueba que pudiera simular una amplia gama de condiciones de rendimiento
de la red y probar continuamente el software en evolución como parte del proceso de
integración continua.
Cuantificar el riesgo es un paso importante para lograr una razón de acción creíble y
convincente. Por ejemplo, esto podría implicar cuantificar el costo de una interrupción o
comprender el impacto en el valor de la marca en términos cuantificables. Con demasiada
frecuencia, el concepto de calidad del software se aborda de una manera "esponjosa" de
miedo, incertidumbre y duda, más que de impactos conocidos cuantificables. Con una
comprensión de las demandas del negocio, los equipos de desarrollo pueden enfocar sus
13
esfuerzos en los aspectos de la aplicación que son realmente más importantes para la
empresa.
La falta de patrocinio ejecutivo es el único punto de falla más grande en relación con las
iniciativas de calidad. Sin un gerente ejecutivo que establezca la importancia de las tareas o
actividades asociadas con la calidad, las prácticas de pruebas corren el riesgo de ser
consideradas desfavorables y decaen rápidamente. En otras palabras, terminas con pautas
en lugar de políticas. "Lávese las manos después de usar el baño" y "Mire a ambos lados
antes de cruzar la calle" son dos pautas: son excelentes sugerencias, pero a menos que
sean ordenadas y supervisadas, el cumplimiento será muy variable. La falta de una política
clara también se ve agravada por equipos de desarrollo altamente distribuidos o equipos que
utilizan terceros contribuyentes. Es muy fácil que las instrucciones que se concibieron como
requisitos se interpreten como pautas. Por ejemplo, "Deberías hacer una revisión del código
del mismo nivel" generalmente se entiende como "Hacer una revisión del código del mismo
nivel si crees que tienes tiempo" mientras que la intención es todo lo contrario.
El impacto del fracaso también debe detallarse en la descripción de una política. Por
ejemplo:
● "Se estima que una violación de datos costará a nuestra organización alrededor de $
250 por registro, sin incluir el impacto en la marca y el valor para el accionista”.
● "Un corte de producción equivale a una pérdida de ingresos de $ 66,000 por minuto".
14
5.3.3. Proveer visibilidad dentro del Proceso
El gerente patrocinador ejecutivo y los reportes directos deben tener suficiente información
sobre el cumplimiento de las políticas para poder identificar los problemas emergentes y
saber cuándo es apropiado intervenir y hacer preguntas. Para proporcionar este nivel de
visibilidad, una plataforma central debe agregar datos y emitir advertencias cuando no se
cumplen los criterios deseables. En última instancia, lo que el patrocinador ejecutivo necesita
es suficiente información para tomar decisiones óptimas sobre procesos y recursos. Por
ejemplo:
Asegurar que los desarrolladores comprendan las demandas del negocio y sentirse
obligados a satisfacerlos es una cosa; prepararlos para cumplir realmente esas expectativas
es otra. Es por eso que el entrenamiento es un componente crítico.
15
acciones esperadas (según lo definido por la política), entonces el sistema permanece
pasivo. Las notificaciones se generan sólo cuando los entregables no se alinean con las
definiciones de las políticas. El resultado es que los miembros experimentados del equipo
que entienden y ejecutan las políticas de la empresa tienen libertad para escribir códigos y
pruebas sin interrupción, mientras que aquellos que son nuevos en el equipo pueden ser
empujados suavemente en la dirección correcta.
Las pruebas continuas requieren una infraestructura para aplicar políticas consistentemente
entre individuos, equipos, proyectos y divisiones.
Una plataforma de pruebas de desarrollo traduce las políticas en tareas priorizadas para
mitigar los riesgos comerciales definidos. También proporciona a los gerentes información y
control sobre el proceso de creación de aplicaciones de calidad.
Si los esfuerzos de calidad del software han sido tradicionalmente un ejercicio con tiempos
reducidos, entonces no podemos esperar que la aceleración del SDLC produzca mejores
resultados desde una perspectiva de pruebas. Si las organizaciones desean acelerar las
versiones de software, deben volver a evaluar las prácticas de pruebas actuales para
mantener la calidad como un status quo. Sin embargo, para mejorar la calidad del software
junto con la aceleración de SDLC, las organizaciones deberán considerar realmente la
reingeniería del proceso de creación de software de calidad.
A medida que revisamos los elementos de las pruebas continuas, es difícil argumentar que
un elemento es más importante que el resto. Si presentamos nuestro caso lo suficientemente
bien, debería ser obvio que cada elemento es crítico para el éxito general del proceso. Sin
embargo, necesitamos un lugar para comenzar, y establecer una línea de base para medir el
riesgo es el lugar perfecto para comenzar y terminar.
16
FIGURA 1: PRUEBAS CONTINUAS - TAREAS INVOLUCRADAS
7.1. Evaluación de riesgos: ¿El software está listo para ser liberado?
desarrollo de software se pasa por alto: si el software es la interfaz para su empresa, los
de la empresa.
17
Evaluar el riesgo de proyecto por adelantado debería ser la línea de base con la que
medimos si hemos terminado las pruebas y permitimos que el SDLC continúe hacia el
La definición de riesgo no puede ser genérica. Debe ser relativo al negocio, el proyecto y,
potencialmente, las iteraciones en el alcance del candidato a ser liberado. Por ejemplo, una
aplicación interna que no es crítica no enfrentaría el mismo nivel de escrutinio que una
mínimo para cualquier esfuerzo de desarrollo. Sin embargo, cada equipo de proyecto
específico debería aumentar el requisito básico con políticas adicionales para evitar
amenazas que podrían ser exclusivas del equipo, la aplicación o el release del proyecto.
legibles por máquina que permiten la ejecución de acciones prescritas (en un punto
aplicación, los componentes, los requisitos y las tareas asociados con el lanzamiento, se
pueden realizar las actividades más rigurosas de elaboración posterior para la prevención de
convertido en el núcleo de la evaluación del SDLC y puede ser una medida eficaz a nivel
profesional.
18
Una plataforma de pruebas de desarrollo ayudará a prevenir y mitigar los tipos de deuda
técnica, como código mal escrito, código excesivamente complejo, código obsoleto, código
Todas las tareas de calidad solicitadas para el desarrollo deben estar correlacionadas al
100% con una política o una oportunidad para minimizar el riesgo. Un desarrollador tiene dos
reducir el riesgo comercial asociado con una posible falla de la aplicación. Desde una
perspectiva de calidad y evaluación, es crucial darse cuenta de que las iniciativas de calidad
generalmente fracasan cuando los beneficios asociados con una tarea de prueba no se
entienden claramente.
Una tarea de mitigación de riesgos puede ir desde la ejecución de una revisión de código de
automáticamente (como con el análisis de código estático), debe presentar una actividad de
desarrollo o prueba que esté claramente correlacionada con la reducción del riesgo.
Una vez que una técnica de Code Coverage (línea, enunciado, función, condición
modificada, decisión, ruta, componente, servicio, aplicación, etc.) se selecciona y se
19
correlaciona con una prueba, la Plataforma de pruebas de desarrollo generará reportes y
tareas que guiarán al desarrollador o ingeniero de calidad para optimizar el code coverage.
El análisis de Code Coverage es complicado porque no garantiza una mejor calidad. Sin
embargo, el análisis de Code Coverage ciertamente puede ayudar a tomar decisiones de
priorización asociadas con la asignación de recursos para pruebas. El análisis de Code
Coverage ofrece datos excelentes que deben usarse junto con otros "sensores" de SDLC.
Por ejemplo, los datos de Code Coverage junto con metadatos de componentes de
aplicaciones enriquecidos que perfilan riesgos pueden establecer parámetros para pruebas
exploratorias o condiciones de simulación ampliadas. El análisis de Code Coverage junto con
la complejidad ciclomática puede resaltar un punto de acceso a la aplicación que debe ser
investigado.
Los procesos y las pruebas tienen una cosa en común: con el tiempo, crecen en tamaño y
complejidad hasta que alcanzan un punto de quiebre cuando se consideran inmanejables.
Desafortunadamente, la racionalización de las pruebas se gestiona tradicionalmente como
un proceso por lotes entre releases. Gestionar de esta manera cede a decisiones
subóptimas porque el equipo se ve obligado a disputar con requerimientos, funciones o
códigos fuera del contexto del momento o la historia del usuario que los impulsó.
Las pruebas continuas requieren pruebas confiables. Cuando los resultados del conjunto de
pruebas se vuelven cuestionables, hay un rápido declive en cómo y cuándo los miembros del
equipo reaccionan ante fallas en las pruebas. Esto lleva a que el conjunto de pruebas pierda
sincronía con el código y la calidad de la aplicación queda fuera de control.
Con esto en mente, es tan importante evaluar la calidad de las pruebas. La automatización
de la evaluación de las pruebas es crítica para las pruebas continuas. Las pruebas se
encuentran en el núcleo de la evaluación de riesgos del software. Si estos monitores de
riesgo o sensores no son confiables, entonces debemos considerar que el proceso está
fuera de control.
20
La mayoría de las empresas u organizaciones tienen una política de desarrollo o SDLC que
es pasiva y reactiva. Se puede hacer referencia a esta política cuando se incorpore un nuevo
empleado o cuando un incidente drástico obligue a la administración a consultar, actualizar y
capacitar sobre la política. La naturaleza reactiva de cómo se expresan y miden las
expectativas de gestión plantea un riesgo comercial significativo. La falta de un mecanismo
de manejo coordinado también obstaculiza gravemente la productividad del equipo de
desarrollo (ya que no puede mejorar lo que no puede medir).
● Áreas donde los riesgos pueden ser aislados dentro de una etapa.
Con un análisis de políticas efectivo, la "política" ya no se relega a ser una medida reactiva
que documenta lo que se supone que ocurre; se promueve a ser el principal impulsor de la
mitigación de riesgos.
A medida que los entregables se convierten cada vez más en la "cara" del negocio, los
riesgos inherentes asociados con el fracaso de la aplicación exponen a la organización a
graves repercusiones financieras. Además, los grupos de interés empresariales exigen una
mayor visibilidad de los mecanismos de gobierno corporativo. Esto significa que simplemente
documentar políticas y procesos ya no es suficiente; también debemos demostrar que las
políticas se ejecutan realmente en la práctica.
21
7.3. Trazabilidad de Requerimientos
Todas las pruebas deben correlacionarse con un requerimiento comercial. Esto proporciona
una evaluación objetiva de qué requerimientos están funcionando según lo esperado, cuáles
requieren validación y cuáles están en riesgo. Esto es complicado porque la articulación de
un requerimiento, la generación o validación del código y la generación de una prueba que
valide su implementación adecuada requieren interacción humana. Debemos tener formas
de garantizar que los artefactos estén alineados con el verdadero objetivo comercial, y esto
requiere una revisión y aprobación por parte de los humanos.
Durante el "tiempo de cambio", las pruebas continuas son las que activan las alertas al
equipo del proyecto sobre los cambios que afectan los requerimientos comerciales, los
conjuntos de pruebas y los componentes de las aplicaciones periféricas. Además de la
verificación de cumplimiento satisfactorios, como la visibilidad en tiempo real del estado de la
calidad de cada requerimiento que ayuda a evitar sorpresas tardías y que amenazan al
calendario de entrega.
Es bien sabido que cuanto más tarde en el proceso de desarrollo se encuentre un defecto,
será más difícil, costoso y llevará mucho tiempo eliminarlo. Las tecnologías maduras de
análisis estático, administradas en el contexto de objetivos empresariales definidos,
mejorarán significativamente la calidad del software al prevenir los defectos de manera
temprana.
Escribir código sin un análisis estático es como escribir un trabajo de término o producir un
informe sin revisión ortográfica o verificación gramatical. Un número sorprendente de
defectos de software de alto riesgo se pueden prevenir al 100% mediante un análisis de
código estático completamente automático. Al evitar que se introduzcan defectos en primer
lugar, minimiza la cantidad de interrupciones y demoras causadas por el equipo que tiene
que diagnosticar y reparar errores. Además, mientras más defectos se eviten, menor será el
22
riesgo de que los defectos se deslicen en los procedimientos de prueba y lleguen al usuario
final, y requieran una cantidad significativa de recursos para la reproducción de defectos, la
reparación de defectos, la nueva prueba y la entrega de la aplicación actualizada. En última
instancia, las prácticas automáticas de prevención de defectos aumentan la velocidad, lo que
permite al equipo lograr más en una iteración.
A un nivel más técnico, este análisis automatizado para la prevención de defectos puede
involucrar una cantidad de tecnologías, incluido el análisis multivariante que expone patrones
maliciosos en el código, áreas de alto riesgo y / o áreas más vulnerables al riesgo. Todos
están impulsados por una política que define cómo se debe escribir y probar el código para
satisfacer las expectativas de la organización en términos de seguridad, confiabilidad,
desempeño y cumplimiento.
Los hallazgos de este análisis establecen una línea base que puede usarse como base para
la mejora continua.
Los enfoques puros de "prevención de defectos" pueden eliminar los defectos que provocan
bloqueos, comportamiento errático y degradación del rendimiento. Un enfoque centrado en la
seguridad puede aplicar la misma estrategia preventiva a las vulnerabilidades de seguridad,
evitando ataques, vulnerabilidades de puerta trasera, controles de seguridad débiles,
exposición de datos confidenciales y más.
Es bien sabido que es más probable que se introduzcan defectos cuando se modifica el
código asociado con bases de código más antiguas y más complejas.
Desde la perspectiva del riesgo, el código modificado equivale a código de riesgo. Sabemos
que cuando el código cambia, existen distintos impactos desde una perspectiva de prueba:
El objetivo es tener una visión única de los impactos del cambio desde la perspectiva del
proyecto, así como la perspectiva del contribuyente individual. De manera óptima, el análisis
de impacto de cambio se realiza tan cerca del momento del cambio como sea posible,
cuando el código y los requerimientos asociados todavía están frescos en la mente del
desarrollador o del evaluador.
23
Si los activos de prueba no están alineados con los requerimientos comerciales reales, las
pruebas continuas se volverán inmanejables rápidamente. Los equipos necesitarán pasar un
tiempo considerable clasificando las fallas informadas o, lo que es peor, pasarán por alto los
defectos que hubieran quedado expuestos por una construcción de prueba más precisa.
Ahora que los procesos de desarrollo son cada vez más iterativos (más ágiles), mantener las
pruebas automatizadas y los entornos de prueba asociados sincronizados con las
dependencias del sistema que evolucionan continuamente puede consumir considerables
recursos. Para mitigar este desafío, es útil tener una manera rápida, fácil y precisa para
actualizar las pruebas. Esto requiere métodos para evaluar cómo el cambio afecta los
artefactos existentes, así como también un medio para actualizar rápidamente esos
artefactos para reflejar los requisitos comerciales actuales.
El análisis avanzado también debe entregar una lista priorizada de pruebas de regresión que
necesitan revisión o mantenimiento.
Por ejemplo, el equipo podría estar trabajando en una aplicación compuesta en la que un
componente esté diseñado para recopilar y procesar tarjetas de pago para transacciones en
línea. El costo de calidad asociado con este componente puede ser colosal si la organización
tiene una brecha de seguridad.
24
7.5. Optimización de las pruebas
Para acelerar verdaderamente el SDLC, tenemos que ver las pruebas de forma muy
diferente. En la mayoría de las industrias, los procesos modernos de calidad se enfocan en
optimizar el proceso con el objetivo de prevenir defectos o errores.
Con el desarrollo de software, hemos evitado este enfoque, declarando que impediría la
creatividad de ingeniería o que los beneficios asociados con la actividad son bajos, dado el
valor de los recursos de ingeniería. Con una reevaluación del verdadero costo de la calidad
del software, muchas organizaciones tendrán que realizar cambios culturales importantes
para combatir las penalizaciones más altas por software defectuoso.
25
● Las colas de tareas deben ser visibles y priorizadas con la opción de alterar o
priorizar manualmente (esta debería ser la excepción, no la norma).
● Los informes sobre tareas antiguas deben estar disponibles para que los managers
los ayuden a determinar si el proceso está bajo control o fuera de control.
Con un conjunto de pruebas frágiles, las pruebas continuas simplemente no son factibles. Si
realmente desea automatizar la ejecución de un amplio conjunto de pruebas que abarque
unidades, componentes, integración, funcionalidades, rendimiento y pruebas de seguridad,
debe asegurarse de que su conjunto de pruebas esté a la altura de la tarea. ¿Cómo lograr
esto? Asegurándonos de que sus pruebas sean:
● Componente lógico: las pruebas deben tener componentes lógicos para que pueda
evaluar el impacto en el momento del cambio. Cuando las pruebas fallan y están
lógicamente correlacionadas con componentes, es mucho más fácil establecer
prioridad y asociar tareas al recurso correcto.
● Incremental: las pruebas se pueden construir una sobre la otra, sin afectar la
integridad del caso de prueba original o nuevo.
● Repetible: las pruebas se pueden ejecutar una y otra vez con cada compilación
incremental, integración o proceso de publicación.
● Flujo de trabajo prescriptivo basado en los resultados: cuando una prueba falla,
debe desencadenar un flujo de trabajo impulsado por el proceso que les permita a los
miembros del equipo saber qué se espera y cómo proceder. Esto generalmente
incluye una lista de tareas priorizadas.
26
7.5.3. Manejo de Datos de Prueba
Por lo tanto, el acceso rápido y fácil a datos de prueba realistas elimina un obstáculo
significativo. Los métodos principales para derivar datos de prueba son:
● Genere datos de prueba sintéticamente para varios escenarios que se requieren para
la prueba.
En todos los casos, es fundamental garantizar que los datos puedan reutilizarse y
compartirse entre múltiples equipos, proyectos, versiones y lanzamientos. La reutilización de
datos de prueba "seguros" puede aumentar significativamente la velocidad de construcción,
administración y mantenimiento de las pruebas.
7.5.4. Mantenimiento
Con demasiada frecuencia, encontramos que los equipos de desarrollo separan el tiempo
entre versiones para "limpiar" las suites de prueba. Esta tarea ad-hoc suele ser de baja
prioridad y es aplazada por solicitudes de características de clientes de alta urgencia,
defectos prioritarios y otros imperativos comerciales. La falta resultante de mantenimiento
continuo generalmente termina erosionando la confianza del equipo en el conjunto de
27
pruebas y generando una acumulación de decisiones de mantenimiento cada vez más
complejas.
El mantenimiento de las pruebas se debe realizar tan pronto como sea posible después de
que se implemente un nuevo requerimiento comercial (o, en el caso de las metodologías
similares a TDD, antes de que se implemente un requerimiento). El desafío es lograr el
equilibrio óptimo entre crear y mantener suites de prueba versus el alcance del cambio.
Los conjuntos de pruebas fuera de sincronización entran en una espiral descendente viciosa
que se acelera con el tiempo. Las pruebas de unidades, componentes e integración que
mantienen los desarrolladores son tradicionalmente los artefactos con mayor riesgo de
deterioro. El análisis avanzado del artefacto de prueba en sí mismo debe guiar a los
desarrolladores a mantener el conjunto de pruebas. Hay cinco actividades principales para el
mantenimiento, todas ellas impulsadas por el requerimiento comercial:
● Eliminar la prueba.
● Actualiza la prueba.
28
Para eliminar estas limitaciones, los equipos deben aprovechar tecnologías innovadoras de
clonación y simulación de sistemas para configurar, aprovisionar, escalar y reproducir
rápidamente entornos completos de desarrollo / prueba. Las pilas de aplicaciones que están
bajo su control (preparadas para la nube) pueden importarse y visualizarse a través de un
Entorno-como-Servicio (EaaS). La virtualización de servicios le permite simular el
comportamiento de aquellas dependencias con las que no puede crear fácilmente imágenes
(por ejemplo, servicios de terceros, regiones de SAP, mainframes, API aún no
implementadas, etc.) o aquellas que desea estabilizar para la cobertura de pruebas. Los
entornos de EaS se están volviendo más omnipresentes dentro de las organizaciones de
DevTest, sin embargo, la mayoría de las organizaciones recién ahora están descubriendo la
virtualización de servicios.
29
8. PROCESO DE PRUEBAS CONTINUAS
TESTING”
Cada vez que los desarrolladores integran su código, se ejecuta un ciclo de Integración
Continua. Si el proceso es exitoso, el binario creado a partir del proceso de integración
continua se probará automáticamente. Como se ilustra en la Figura 2, el binario se ejecuta
automáticamente a través de pruebas de integración. Si tiene éxito, sigue la prueba del
sistema. Si eso tiene éxito, sigue la prueba de regresión. Si la regresión tiene éxito, se
ejecutan las pruebas automáticas de aceptación del usuario (UAT). Del mismo modo, puede
agregar, eliminar o modificar cualquier prueba que necesite en esta canalización.
El proceso de Pruebas continuas garantiza que una vez que el código esté integrado, se
pruebe automáticamente.
30
8.1. Pruebas automatizadas versus Pruebas continuas
Las pruebas automatizadas son un proceso en el que el código del desarrollador se ejecuta
a través de herramientas de prueba alimentadas con scripts de prueba que ejecutan cada
prueba. No hay intervención humana en el proceso de prueba automatizado, aparte de
escribir los scripts de prueba.
Las pruebas continuas es un proceso donde la ejecución de las pruebas se ejecuta a través
de las herramientas de prueba automáticamente después de la integración del código. Como
antes, las herramientas de prueba están precargadas con los scripts de prueba. Tampoco
hay intervención humana en las pruebas continuas, salvo en el desarrollo del script.
La ventaja de las pruebas continuas frente a las pruebas de automatización es que una vez
que se ingresa el código en el repositorio de código fuente, comienza el proceso para
construir y validar, y la retroalimentación se obtiene rápidamente. No hay brecha en el
proceso donde el mecanismo de integración, prueba y retroalimentación aguarda la
intervención humana.
La diferencia entre las pruebas automatizadas y las pruebas continuas se puede explicar
mejor en la siguiente figura.
31
FIGURA 3: PRUEBAS AUTOMATIZADAS VERSUS PRUEBAS CONTINUAS
TESTING”
9. CONCLUSIONES
Actualmente, estamos en una nueva era de software. La empresa espera más, y los
procesos de software existentes no satisfacen las demandas de calidad y velocidad. Ha
llegado el momento de un verdadero cambio de proceso.
Entonces, ¿por qué invertir y aplicar pruebas continuas durante el proceso de desarrollo? A
continuación, algunas razones y respuestas:
32
software para lograr cada vez más interacciones centrales. El costo de la calidad es
la penalidad o riesgo incurrido por no entregar software de calidad, y esto es relativo.
En otras palabras, si una industria completa está entregando una experiencia de
usuario promedio a través del software, entonces el costo de la calidad del software
no es tan alto en ese mercado. Sin embargo, si una organización logra brindar una
experiencia de usuario excepcional, este podría ser un diferenciador competitivo
valioso.
La verdad innegable es que satisfacer las expectativas de sus clientes con un software de
calidad genera lealtad a la marca. Sin un proceso de calidad del software que esté bien
definido y se mejore continuamente, una organización se rezagará entre sus competidores y
la marca se saldrá del mercado.
Todas las industrias están bajo el fuego para ofrecer una experiencia de usuario excepcional
a través del software o enfrentar la extinción.
● Code Coverage - también conocido como Test Coverage: medida utilizada para
describir el grado en que el código fuente de un programa es ejecutado cuando se
ejecuta un conjunto de pruebas.
33
● SDLC - Software Development Life Cycle: proceso utilizado por la industria del
software para diseñar, desarrollar y probar softwares de alta calidad
● Software: los programas y otra información operativa utilizada por una computadora.
● Gene Kim, Jez Humble, Patrick Debois. The DevOps HandBook (Pag. 5-6, 149-151,
175-177, 354)
34