Sunteți pe pagina 1din 35

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA


DIRECCIÓN DE POSGRADO

“DEVOPS – PRUEBAS CONTINUAS”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE


DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.

POSTULANTE : Lizeth Salazar Soto


TUTOR : Msc. Richard Félix López Fulguera

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

Figura 1: Pruebas Continuas - tareas involucradas .............................................................. 17


Figura 2: Proceso de las pruebas continuas ......................................................................... 30
Figura 3: Pruebas automatizadas versus Pruebas continuas ............................................... 32

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

1.1. Pruebas en el desarrollo de software

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:

1. Los riesgos comerciales asociados a un determinado software y el software candidato


a ser liberado están bien definidos.

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.

4. La automatización de las pruebas nos ayuda a evaluar continuamente el estado de la


aplicación frente a estos riesgos definidos.

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.

1.2. Las pruebas continuas no son una herramienta

Las pruebas continuas no representan simplemente más automatización de pruebas. Más


bien, es la reevaluación de las prácticas de calidad del software, impulsada por el costo de
calidad de una organización y equilibrada para obtener velocidad y la agilidad. En última
instancia, las pruebas continuas pueden proporcionar una evaluación cuantitativa del riesgo
y producir tareas accionables que ayudarán a mitigar estos riesgos antes de pasar a la
siguiente etapa del SDLC.

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

2.1. Objetivo General

• Por tanto, el objetivo de las pruebas continuas es proporcionar comentarios rápidos y


continuos sobre el nivel de riesgo empresarial en la última versión o software
candidato a ser liberado.

2.2. Objetivos Específicos

• 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.

• Además, cuando los equipos ejecutan continuamente un amplio conjunto de pruebas


continuas a lo largo del SDLC, acumulan métricas con respecto a la calidad del
proceso, así como el estado del software. Las métricas resultantes se pueden utilizar
para volver a examinar y optimizar el proceso en sí, incluida la efectividad de esas

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

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

● Método Bibliográfico, debido a que se realizará la lectura y compilación de


información de internet relacionados al tema de estudio.

● Método Analítico, debido a que se procederá a revisar y analizar documentos


relacionados al tema de estudio.

4. EL VALOR DE LAS PRUEBAS CONTINUAS

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.

4.1. ¿Qué es un Riesgo de Negocio?

En términos de software, un riesgo de negocio es cualquier falla de la aplicación que


perjudica la experiencia esperada del usuario final (o del cliente) y, en última instancia,
erosiona la confianza en el negocio. Un riesgo de negocio de software puede manifestarse
como un evento principal, como una interrupción del sistema de reservaciones que ahuyenta
a los viajeros de vacaciones, lo que perjudica el valor de marca. O podría tratarse de una
serie de contratiempos en la experiencia del usuario que finalmente llevan a los clientes a
competir, lo que afecta directamente los ingresos o la base de suscriptores.

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.

4.2. El valor comercial de las pruebas continuas

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.

Cuando las pruebas continuas son ejecutadas correctamente, claramente se pueden


identificar 4 beneficios comerciales:

1. Las pruebas continuas definen riesgos comerciales claramente delineados asociados


con cada aplicación en la organización, incluidos los estándares de medición para
evaluar el nivel de riesgo. Orienta a los equipos comerciales y técnicos para cerrar en
colaboración la brecha entre el riesgo empresarial y las actividades de desarrollo.

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.

3. Las pruebas continuas permiten a los managers tomar mejores decisiones de


compromiso. Desde la perspectiva del negocio, lograr una ventaja competitiva
diferenciable al ser el primero en llegar al mercado con un software innovador
impulsa el valor para el accionista. Sin embargo, el desarrollo de software es una
tarea compleja. Como resultado, los managers se enfrentan constantemente con

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.

4. Cuando los equipos ejecutan continuamente un amplio conjunto de pruebas a través


de "sensores" colocados a lo largo del SDLC, recopilan métricas sobre la calidad del
proceso y el estado del software. Las medidas resultantes se pueden usar para volver
a examinar y optimizar el proceso en sí, incluida la eficacia de las pruebas. Esta
información se puede utilizar para establecer un ciclo de retroalimentación que ayude
a los equipos a mejorar el proceso de forma incremental. La medición frecuente, los
circuitos de retroalimentación ajustados y la mejora continua son todos los principios
clave de DevOps.

4.3. Re-evaluando el costo de la calidad

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:

● Servicios de taxi → Uber

● Musica & Media → iTunes

● 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.

5. DEFINIR LAS EXPECTATIVAS DEL NEGOCIO

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.

● La capacitación debe garantizar que los desarrolladores entiendan realmente lo que


se espera y cómo se traduce al nivel técnico, es decir, cómo se desarrolla y prueba la
aplicación.

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.

Este enfoque agudo en la validación de requerimientos o historias de usuarios puede


agravarse aún más por los tiempos definidos en metodologías de desarrollo ágiles o más
iterativas.

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?

5.2. ¿Qué se necesita para reducir esta brecha?

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:

● Política: el elemento principal es una definición de la expectativa comercial: a lo que


nos referimos como una "política".

● Requerimientos no funcionales: cada política está respaldada por una serie de


requerimientos no funcionales. Mientras que los requerimientos funcionales definen lo
que el sistema debería hacer, los requerimientos no funcionales describen cómo
debe comportarse el sistema en general.

Los requisitos no funcionales podrían incluir flexibilidad de la aplicación, accesibilidad,


disponibilidad, confiabilidad y capacidad de prueba, por nombrar solo algunos. La
política tiene una relación uno a muchos con requisitos no funcionales. En otras
palabras, se podrían necesitar múltiples requerimientos no funcionales para evaluar
la exposición a un riesgo comercial específico que se define en una política.

● KPIs (Key Performance Indicator - Indicadores clave de rendimiento) y criterios


de aceptación: Una vez que se establecen los requerimientos no funcionales, el

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.

● Medición y monitoreo automáticos: Una política y sus requerimientos no


funcionales sin un método automatizado para medir y monitorear sólo pueden
considerarse una guía.

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.

5.3. Expectativas del negocio

Después de evaluar si el software candidato satisface las expectativas comerciales en un


momento dado, veamos de cerca cómo diseñar mejor y promulgar políticas para satisfacer
esas expectativas.

La clave para cualquier manager de desarrollo de software es garantizar que el equipo


realmente entienda el impacto comercial de la aplicación en la que está trabajando, así como
también los posibles riesgos comerciales asociados con la falla de la aplicación.

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.

5.3.1. Importancia de tener respaldo de un gerente ejecutivo

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.

5.3.2. Comunicar el impacto de la falla

Después de que se evalúa y cuantifica el verdadero impacto comercial, el gerente


patrocinador ejecutivo necesita comunicar esto a los desarrolladores e ingenieros de calidad.
Es importante centrarse en el impacto real de la falla en lugar del impacto teórico de la falla.
Las historias tangibles son clave para lograr este propósito. Además, es inestimable que el
ejecutivo comunique esto personalmente al equipo, poniendo un nombre y una cara a los
riesgos e inquietudes. Una cosa es leer sobre el potencial de riesgo en un manual de
capacitación; Otra cosa es hacer que la gerencia ejecutiva pase por aquí para resaltar su
importancia. Esto verdaderamente humaniza el impacto del fracaso empresarial.

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:

● ¿Por qué no cumpliremos con las expectativas asociadas con la política?

● ¿Hay algo mal en términos de recursos?

● ¿Hay algo mal en términos de herramientas?

● ¿Subestimamos el nivel de esfuerzo?

● ¿Nos faltan pasos críticos del proceso?

● ¿Algunos pasos del proceso no están entregando el resultado esperado?

5.3.4. Capacitación sobre las expectativas comerciales

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.

El primer aspecto de la capacitación efectiva es proporcionar un lugar formal para delinear


las políticas y la capacitación sobre cómo cumplir con las expectativas contenidas en esas
políticas. Los nuevos hábitos eventualmente se volverán una segunda naturaleza para los
miembros de su equipo a largo plazo a medida que pasa el tiempo. Esto es esperado; sin
embargo, cuando los miembros principales del equipo estén asesorando a otros nuevos,
inevitablemente se pasarán por alto los conceptos centrales. Para garantizar que las nuevas
contrataciones reciban el mismo nivel de capacitación que se brindó cuando se introdujo la
política por primera vez, la capacitación debe ser un proceso formal y continuo.

En segundo lugar, la capacitación también debe incluir un repositorio que centralice el


acceso a toda la información pertinente, y que proporcione información objetiva y en tiempo
real sobre si las actividades cumplen con las expectativas. La forma menos disruptiva de
ayudar a los miembros del equipo a asegurarse de que están en el camino correcto es con
un sistema de notificación basado en excepciones. Si los desarrolladores realizan las

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.

6. UNA PLATAFORMA PARA EVALUAR LOS RIESGOS COMERCIALES

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.

7. PRUEBAS CONTINUAS: ¿QUÉ ESTÁ INVOLUCRADO?

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 comience la transformación de las pruebas automatizadas a las pruebas


continuas, los siguientes elementos son necesarios para lograr una evaluación en tiempo
real de los riesgos comerciales.

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

FUENTE: LIBRO “CONTINUOS TESTING”, PAG. 38

7.1. Evaluación de riesgos: ¿El software está listo para ser liberado?

Uno de los aspectos más importantes de la evaluación de riesgos asociados con el

desarrollo de software se pasa por alto: si el software es la interfaz para su empresa, los

desarrolladores que escriben y prueban el código toman decisiones comerciales en nombre

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

release. Además, la evaluación de riesgos también jugará un papel importante en las

iniciativas de mejora para los ciclos de desarrollo posteriores.

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

aplicación pública que gestiona transacciones financieras o minoristas.

Se recomienda una política de referencia de la compañía para las expectativas de seguridad,

confiabilidad, rendimiento, mantenibilidad, disponibilidad, legal, etc. como punto de partida

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.

La aceleración SDLC requiere automatización. La automatización requiere instrucciones

legibles por máquina que permiten la ejecución de acciones prescritas (en un punto

específico en el tiempo). Cuantos más metadatos puede proporcionar un equipo en torno a la

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

defectos, la construcción de pruebas, la ejecución de pruebas y el mantenimiento.

7.1.1. Deuda Técnica

El concepto de deuda técnica ha ganado popularidad en los últimos años. Su medición se ha

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

no utilizado, código duplicado, código no cubierto por pruebas automatizadas y código

incompleto. La medición uniforme de la deuda técnica es una gran herramienta para la

comparación de proyectos y debe ser un elemento central del tablero de un profesional.

7.1.2. Tareas de mitigación de riesgos

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

trabajos principales: implementar requerimientos comerciales (o historias de usuarios) y

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

pares hasta la construcción o el mantenimiento de una prueba de componentes. Si una tarea

de mitigación de riesgos se genera manualmente a petición de un administrador o

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.

7.1.3. Optimización del Code Coverage

El Code Coverage siempre es un tema polémico. Existen diferentes técnicas de Code


Coverage que son adecuadas dependiendo de los diferentes objetivos de mitigación de
riesgos. Afortunadamente, existen pautas para ayudar a determinar qué métrica de Code
Coverage o técnica seleccionar y estandarizar.

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.

7.1.4. Evaluación de la calidad de pruebas

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.

7.2. Análisis de Políticas

El análisis de políticas a través de una plataforma de pruebas de desarrollo es clave para


impulsar el desarrollo y probar los resultados del proceso. El objetivo principal del análisis de
procesos es garantizar que las políticas cumplan con las cambiantes demandas
empresariales y de cumplimiento de la organización.

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).

El análisis de políticas a través de una plataforma de pruebas de desarrollo es la solución a


este problema omnipresente. Con una interfaz central donde un manager o líder grupal
define e implementa las prácticas de calidad "cómo", "cuándo" y "por qué" se implementan y
aplican, la administración puede adaptar el proceso a las cambiantes condiciones del
mercado, entornos normativos cambiantes o demandas de los clientes. El resultado: los
objetivos y expectativas de gestión se traducen en acciones ejecutables y supervisables que
reducen el riesgo comercial.

Los principales objetivos comerciales del análisis de políticas son:

● Exponer tendencias asociadas con patrones peligrosos en el código.

● Áreas donde los riesgos pueden ser aislados dentro de una etapa.

● Identificar actividades de mayor riesgo donde las prácticas de prevención de defectos


deben ser aumentadas o aplicadas.

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.

Esta centralización de las expectativas de gestión no solo establece el punto de referencia


necesario para analizar el riesgo, sino que también proporciona el control requerido para
mejorar continuamente el proceso de entrega del software.

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.

Una plataforma de pruebas de desarrollo ayuda a la organización a mantener las


expectativas comerciales bajo control, asegurando que haya pruebas efectivas alineadas con
los requerimientos del negocio. Al permitir que los metadatos ampliados se asocien con un
requerimiento, una aplicación, un componente o una iteración, la plataforma de pruebas de
desarrollo también optimizará la priorización de las tareas.

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.

7.4. Análisis Avanzado

7.4.1. Prevención de defectos con análisis estático

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.

7.4.2. Cambio de análisis de impacto

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:

● ¿Debo modificar o eliminar la prueba anterior?

● ¿Necesito una nueva prueba?

● ¿Cómo han afectado los cambios a otras secciones de la aplicación?

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.

7.4.3. Alcance y priorización

Dado el alcance, la iteración o el lanzamiento de un proyecto de software, algunas pruebas


son ciertamente más valiosas y oportunas que otras. Las técnicas de análisis avanzadas no
solo ayudan a los equipos a identificar estas pruebas de mayor prioridad, sino que también
les ayudan a seleccionar el conjunto adecuado de pruebas para las distintas entregas en
calendario.

El análisis avanzado también debe entregar una lista priorizada de pruebas de regresión que
necesitan revisión o mantenimiento.

Aprovechar este tipo de análisis y actuar en la lista priorizada para la creación o el


mantenimiento de pruebas puede evitar eficazmente que los defectos se propaguen a
procesos posteriores, donde la detección de defectos es más difícil y costosa. Aquí hay dos
factores principales para la entrega de tareas: los límites del alcance y la política que define
los riesgos comerciales asociados con la aplicación.

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.

Aunque el código dentro del componente de transacción podría no estar cambiando, es


necesario hacer pruebas sobre este componente para verificar la correctitud en el
funcionamiento del mismo.

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.

Independientemente de la metodología que mejor se adapte a los objetivos de su negocio y


a la cultura de desarrollo deseada, se requiere un proceso que genere consistencia para el
éxito a largo plazo.

Los algoritmos de optimización de pruebas lo ayudan a determinar qué pruebas debe


ejecutar absolutamente en comparación con cuáles pruebas son de menor prioridad dado el
alcance del cambio. Lo ideal es contar con una guía inteligente sobre la manera más
eficiente de mitigar los mayores riesgos asociados con su aplicación. La optimización de las
pruebas no solo garantizan que el conjunto de pruebas esté validando el comportamiento
correcto de la aplicación, sino que también evalúa cada prueba en sí misma en cuanto a su
efectividad y facilidad de mantenimiento.

7.5.1. Administración de optimización de pruebas

La gestión de optimización de pruebas requiere que se establezca y mantenga un flujo de


trabajo uniforme asociado a las políticas definidas al comienzo de un proyecto o iteración.
Una plataforma de pruebas de desarrollo debe proporcionar la administración granular de
colas combinadas con el flujo de trabajo de las tareas y la medición del cumplimiento de las
mismas. Para lograr esto:

● El alcance de las tareas debe poder medirse en diferentes niveles de granularidad,


que incluyen el individuo, el equipo, la iteración y el proyecto.

● Las colas de ejecución de pruebas deben permitir la priorización de las ejecuciones


de pruebas en función de la gravedad y el riesgo comercial asociado con los
requerimientos.

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.

7.5.2. Construcción y Capacidad de Pruebas

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.

● Determinista y significativo: las pruebas deben ser limpias y deterministas. El pase


y la falla tienen un significado inequívoco. Cada prueba debe hacer exactamente lo
que usted quiere que haga, ni más ni menos. Las pruebas solo deben fallar cuando
se detecta un problema real que le preocupa. Además, la falla debería ser obvia y
comunicar claramente lo que salió mal.

● Se puede mantener dentro de un proceso: una prueba que no está sincronizada


con el código genera errores incorrectos (falsos positivos) o pasa por alto problemas
reales (falsos negativos). Un proceso automatizado para desarrollar artefactos de
prueba es tan importante como la construcción de nuevas pruebas.

● 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

El acceso a datos de prueba realistas puede aumentar significativamente la eficacia de un


conjunto de pruebas. Los buenos datos de prueba y las prácticas de administración de datos
de prueba aumentarán la cobertura e impulsarán resultados más precisos. Sin embargo,
desarrollar o acceder a los datos de prueba puede ser un desafío considerable, en términos
de tiempo, esfuerzo y cumplimiento. Copiar datos de producción puede ser arriesgado (y
potencialmente ilegal). Pedir a los administradores de bases de datos que proporcionen los
datos necesarios generalmente está plagado de retrasos. Además, delegar esta tarea a dev /
QA mueve a los miembros del equipo más allá de sus competencias centrales, lo que podría
retrasar otros aspectos del proyecto para lo que podrían ser resultados imprecisos o
incompletos.

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:

● Sub-establecer o copiar datos de una base de datos de producción en un entorno por


etapas y emplear técnicas de limpieza para eliminar la privacidad de los datos o los
riesgos de seguridad.

● Aproveche la virtualización de servicios para capturar el tráfico de solicitudes y


respuestas y reutilizar los datos para escenarios posteriores. Dependiendo del origen
y el estado de los datos, es posible que se requieran técnicas de limpieza.

● 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.

● Actualiza las aserciones.

● Actualiza los datos de prueba.

● Actualizar los metadatos de la prueba.

7.6. Acceso a ambientes de pruebas

Con las tendencias convergentes de desarrollo paralelo e iterativo, el aumento de la


complejidad / interdependencia del sistema y DevOps, se ha vuelto extremadamente raro
que un equipo tenga acceso a todas las aplicaciones dependientes requeridas para ejecutar
una prueba completa. La capacidad de evaluar con precisión el riesgo de una versión
candidata para las aplicaciones compuestas actuales se está convirtiendo en una tarea
difícil.

Tiene equipos de desarrollo y prueba altamente distribuidos que necesitan acceso


simultáneo a pedido a un candidato a ser liberado, así como a sus innumerables API y
dependencias que deben estar presentes en el entorno de pruebas, para poder realizar
pruebas continuamente durante todo el ciclo de vida del software. El uso de una
infraestructura estándar convencional para construir entornos de pruebas completos que se
parecen mucho a la producción suele ser lento, técnicamente desafiante, costoso e inviable
debido a dependencias que no se pueden reproducir en el entorno de 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.

Al aprovechar la virtualización de servicios o la simulación para eliminar estas restricciones,


una organización puede obtener acceso completo (y control sobre) al ambiente de pruebas
permitiendo a las pruebas continuas realizarse tan temprano y a menudo como sea
necesario.

¿Quiere comenzar a probar el componente que acaba de construir, aunque no se haya


completado mucho más? ¿No tiene acceso las 24 horas, todos los días de la semana, a
todas las dependencias involucradas en sus esfuerzos de prueba, con todas las
configuraciones que necesita para sentirse seguro de que los resultados de sus pruebas son
verdaderamente predictivos del comportamiento en el mundo real? ¿Cansado de retrasar las
pruebas de rendimiento porque el acceso a un entorno realista es demasiado limitado (o
demasiado caro)? La virtualización de servicios puede eliminar todas estas restricciones.

Con Service Virtualization, las organizaciones pueden acceder a entornos de prueba


simulados que les permiten a los desarrolladores y QA realizar pruebas antes, de forma más
rápida y más completa. Las organizaciones que dependen de sistemas interconectados
deben poder validar los cambios del sistema de manera más efectiva, no solo por el
rendimiento y la confiabilidad, sino también para reducir los riesgos asociados con la
seguridad, la privacidad y la interrupción del negocio. La virtualización de servicios es el
eslabón perdido que permite a las organizaciones realizar pruebas y validar continuamente
los requisitos del negocio con el fin de llevar al mercado una funcionalidad de mayor calidad
de manera más rápida y económica.

29

8. PROCESO DE PRUEBAS CONTINUAS

Pruebas Continuas es el proceso en el que las integraciones de código creadas durante el


proceso de integración continua se envían a una serie de pruebas (integración, sistema,
rendimiento, regresión y aceptación del usuario, por nombrar algunas) y las pruebas se
ejecutan automáticamente. con cero participación humana.

FIGURA 2: PROCESO DE LAS PRUEBAS CONTINUAS

FUENTE: GUIA DE PLURALSIGHT - “EVERYTHING YOU NEED TO KNOW ABOUT CONTINUOUS

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.

Entonces, ¿cuál es la diferencia entre Pruebas automatizadas y Pruebas continuas? En las


pruebas automatizadas, el código se integra con la línea principal, luego se desarrollan los
scripts de prueba de automatización, y los binarios se prueban automáticamente contra estos
scripts utilizando los conjuntos de pruebas de automatización. En las pruebas continuas, los
scripts de prueba se escriben antes de que comience la codificación. Entonces, cuando el
código está integrado, las pruebas de automatización se ejecutan automáticamente una
detrás de otra, de ahí el término Prueba continua.

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

FUENTE: GUIA DE PLURALSIGHT - “EVERYTHING YOU NEED TO KNOW ABOUT CONTINUOUS

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:

● Los prospectos o futuros clientes están juzgando antes de interactuar con


ellos: los clientes actuales de hoy en día disfrutan de abundante acceso a la
información, con blogs, reseñas, reportes y comentarios de los clientes
universalmente accesibles desde una variedad de dispositivos. Antes de ponerse en
contacto con un cliente potencial, es probable que ya lo hayan investigado a usted (y
a sus competidores) y haya desarrollado un sesgo basado en su exploración no
guiada y su reputación en línea.

● Mayor costo de calidad: el costo de la calidad del software está en aumento y


seguirá aumentando ya que las empresas líderes en la industria confían en el

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.

10. DICCIONARIO DE TÉRMINOS EN ESTE DOCUMENTO

● API - Application Programming Interface: Conjunto de métodos de comunicación


claramente definidos entre varios componentes.

● 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.

● DevOps - (un compuesto recortado de "desarrollo" y "operaciones"): es una cultura y


práctica de ingeniería de software que apunta a unificar el desarrollo de software
(Dev) y la operación de software (Ops).

● EaaS - Encryption as a Service: es un modelo de suscripción que permite a los


clientes del servicio en la nube aprovechar la seguridad que ofrece el cifrado sin tener
que instalar y usar el cifrado por sí mismos.

● Manager: Persona responsable de controlar y administrar un proyecto de software.

● QA - Quality Assurance: forma de prevenir errores y defectos en los productos y


evitar problemas cuando se entregan soluciones o servicios a los clientes.

● Release: Entrega y puesta en producción de un proyecto de software

33

● SDLC - Software Development Life Cycle: proceso utilizado por la industria del
software para diseñar, desarrollar y probar softwares de alta calidad

● Service Virtualization: método para emular el comportamiento de componentes


específicos en aplicaciones heterogéneas basadas en componentes, como
aplicaciones impulsadas por API, aplicaciones basadas en la nube y arquitecturas
orientadas a servicios.

● Software: los programas y otra información operativa utilizada por una computadora.

● Sprint: período de tiempo durante el cual el trabajo específico debe completarse y


estar listo para su revisión.

● TDD - Test Driven Development:

11. REFERENCIAS BIBLIOGRÁFICAS

● Ariola, Wayne; Dunlop, Cynthia (2014). Continuous Testing

● Gene Kim, Jez Humble, Patrick Debois. The DevOps HandBook (Pag. 5-6, 149-151,
175-177, 354)

● Everything you need to know about continuous testing. Recuperado de:


https://www.pluralsight.com/guides/everything-you-need-to-know-about-continuous-
testing en fecha: 12 de agosto del 2018.

● Continuous Testing. Recuperado de:


https://en.wikipedia.org/wiki/Continuous_testing#Continuous_Testing_tools en fecha:
15 de agosto del 2018.

● Pruebas continuas para DevOps. Recuperado de:


https://alm.parasoft.com/hubfs/New_Pages/Whitepaper:%20Continuous%20Testing%
20for%20DevOps.pdf?submissionGuid=86bde237-f1f4-463d-9185-a2943b9cd1a3 en
fecha: 20 de agosto del 2018.

34

S-ar putea să vă placă și