El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

El Manual de la Calidad Software
Segunda edición
En esta segunda edición del Manual de la Calidad Software de Panel Sistemas, hemos
querido de nuevo recopilar nuestro mejor conocimiento sobre las buenas prácticas en la
actividad de SQA.
Para ello, hemos escogido los mejores artículos y opiniones que nuestros expertos han
compartido a través del blog de Panel, blog.panel.es, a lo largo de este año 2015. Es
muy recomendable complementar esta edición 2015 con la anterior de 2014: contará así
con el más amplio repositorio documental sobre Aseguramiento de la Calidad de
Software del mercado.
Esperamos que lo disfrute y se convierta en su “segundo” libro de cabecera sobre SQA.
2015 - 2016. Panel Sistemas Informáticos. Todos los derechos reservados.
2015 Panel Sistemas. Página 2

INTRODUCCIÓN: SQA, una cuestión de Cultura, Procesos y Herramientas
PARTE I- Cultura y SQA
Capítulo #1 - Lean Management: Cultura, cambio y liderazgo
Capítulo #2 - Calidad y más Calidad...pero ¿y la entrega de Valor?
Capítulo #3 - Navegar y disfrutar en equipo
Capítulo #4 - One2change, el cambio está en cada uno de nosotros
PARTE II - Procesos y SQA
Capítulo #5 - Algo pasa con CMMi
Capítulo #6 - Entre anomalía, defecto o fallo anda el juego
Capítulo #7 - Los 7 ejes de la calidad del código fuente
Capítulo #8 - ¿Cuáles son los tipos de pruebas software?
Capítulo #9 - El modelo de Testing en capas de cebolla
Capítulo #10 - ¿Cuánto nos pica un bug?
Capítulo #11 - Agile Testing en proyectos grandes y complejos
Capítulo #12 - Razones para practicar la Integración Continua
Capítulo #13 - DevOps, hacia la Calidad Continua del software
Capítulo #14 - ¿Qué es DevOps 101?
Capítulo #15 - ¿Cómo probar aplicando Entrega Continua?
Capitulo #16 - Estrategias de integración entre productos software
PARTE III - Herramientas y SQA
Capítulo #17 - Gestión del Ciclo de Vida con Apache Maven
Capítulo #18 - Nexus, gestión de artefactos y otras especies.
Capítulo #19 - Git, Control de Versiones
Capítulo #20 - ¿Qué es Ansible, y por qué?
Capítulo #21 - Testing automático para websites responsive
Capítulo #22 - DevOps en las nubes y con Contenedores
AGRADECIMIENTOS
Índice
ÍNDICE

SQA, una cuestión de Cultura, Procesos y
Herramientas
La fabricación de Software ha cambiado. Hemos evolucionado desde un proceso de
creación de software basado en modelos de ciclo de vida secuenciales hacia ciclos de vida
ágiles en los que hay una presentación rápida, iterativa e incremental de producto
terminado, con numerosos beneficios directos para el proyecto y para el usuario final.
En este nuevo escenario, asegurar la Calidad del producto final y entregar el Valor que
Introducción: SQA, una cuestión de Cultura, Procesos y Herramientas

espera tu Cliente, es el objetivo principal. Aplicando prácticas saludables sobre escenarios
como Devops, Integración Continua o Automatización, es posible favorecer el
aseguramiento de la Calidad del producto desde el inicio, y maximizar el valor de lo que
entregamos.
Pero para ello, es necesario cambiar la Cultura, los Procesos y las Herramientas en la
construcción de software, hacia un modelo que en Panel Sistemas llamamos fabricación
ecoLÓGICA de software.
En otras palabras, es necesario revitalizar el Ciclo de Vida en la
creación de software, por este orden: Cultura, Proceso y
Herramienta.
Cambios en la Cultura producen avances más rápidamente en la
organización, que solamente cambios en los procesos o las
herramientas.

Cuando hablamos de cambiar la Cultura en la construcción de software, es necesario que
en el nuevo modelo las personas adopten los cambios, asuman los objetivos, y entiendan
su nueva función. Por tanto, es muy importante una buena estrategia de Comunicación y
Formación, de difusión de conocimientos y buenas prácticas, y de medidas de avance y
mejora continua.
Así en la primera Parte de este Manual, recopilamos algunos interesantes artículos sobre
técnicas de facilitación, acompañamiento y mentoring en la integración y adaptación de
modelos Scrum, Kanban o Lean Management en equipos y organizaciones, facilitando el
cambio Cultural que requiere el nuevo modelo de fabricación ecoLÓGICA de software.
En segundo lugar, la metodología, los procedimientos y las buenas prácticas en tus
proyectos deberían de trabajar para ti, y no tú para ellos. Por esta razón, los procesos de
Creación de Software deben adoptar un enfoque global e integrado, con una visión
completa del proceso, cercano al negocio e involucrando a todas las personas de la
Organización.
La Parte II de este Manual la dedicamos precisamente a entender algunas metodologías
más globales como CMMi, otras más específicas sobre modelos y tipos de pruebas
software, y otras buenas prácticas como DevOps, Agile Testing o Integración Continua.
Todas ellas mejoran sin duda los resultados y ofrecen mayores garantías de calidad en el
producto entregado.
Por último, las herramientas sustentan el Ciclo de Vida del software a lo largo de todas
sus etapas. Cambiar nuestra Cultura y nuestros Procesos obliga necesariamente a
cambiar las herramientas, y para ello es recomendable realizar una selección estratégica
de las mismas, alineándolas con nuestra metodología y nuestra cultura, e integrando
cada área del proceso de creación de software con una inversión equilibrada en tiempo y
coste.
La tercera parte de este Manual recopila nuestro análisis de algunas reconocidas
herramientas que, bajo nuestra propia experiencia, pueden aportar mucho valor en el
nuevo modelo de fabricación ecoLÓGICA de software.
Introducción: SQA, una cuestión de Cultura, Procesos y Herramientas

En definitiva, como decíamos al principio, los modelos de
fabricación de software han cambiado, y las organizaciones
deben estar preparadas para ofrecer a sus clientes soluciones
realistas y adaptadas a pequeños y grandes proyectos, que
buscan obtener de forma satisfactoria el Valor que esperan y
rentabilizar su Inversión lo antes posible.

PARTE I
CULTURA Y SQA
"Las personas deben adoptar los cambios, asumir los objetivos y
entender su nueva función"
PARTE I - Cultura y SQA

Capítulo #1
Lean Management: Cultura, cambio y liderazgo
Hace unas semanas tuvimos la oportunidad de escuchar durante unas sesiones
formativas en Panel Sistemas a nuestros compañeros de Thinking with You (@_twy_) en
un curso sobre Lean Management, que yo definiría como una experiencia “religiosa” :-),
enriquecedora, motivadora y ¡aguijoneadora de conciencias!
Para empezar, Lean no es una metodología de trabajo, sino una filosofía, una forma de
pensar focalizada en un objetivo claro: aumentar la productividad y producción, con
CALIDAD. Pero lo que a veces olvidamos (con mucha frecuencia) es tener bien
identificado el pilar básico para el que hacemos las cosas, que no es otro que el CLIENTE.
“Los objetivos de negocio se centran en lo que los clientes
quieren, no en lo que nosotros pensamos que necesitan” (sic).
Esta tarea de análisis es imprescindible para que nuestras actividades estén orientadas a
un fin concreto y encarriladas al máximo rendimiento, con el mínimo desperdicio: hacer

MÁS, con MENOS. No obstante ya nos lo
avisaron: Lean requiere paciencia, y para lograr
los objetivos es necesario aplicar cambios que
nos ayuden a estar cada día un poco más cerca
de nuestro objetivo. ¡Bienvenido a la calle de los
cambios!
Y este cambio de mentalidad requiere dedicación
y tiempo de una serie de “actores” que han de
evidenciar, analizar, comunicar y ejecutar cada
uno de los cambios identificados a realizar (El
cambio Kotter)… y sin un apoyo expreso de la
dirección, es imposible llevarlo a efecto. Parece
obvio, pero evidenciar algo que no funciona y
que requiere materia gris y acción para cambiar, debe ir más allá de las “sensaciones” y
se debe constatar mediante cuadros de mando o mediciones que nos señalen dónde no
funcionan las cosas y dónde se ha de aplicar un proceso iterativo para obtener una mejora
continua hacia el camino de la perfección.
¿Qué me llevo personalmente del curso? Muchas cosas Por ejemplo, fue muy
revelador que, en uno de los ejercicios durante el curso, la gente que participábamos
teníamos distintas visiones (y muy enriquecedoras!) de Panel como compañía. Nos
dimos cuenta de que unificar una Cultura en la organización es muy necesario, pero
también complicado, y de nuevo se requiere del liderazgo de la Dirección para
conseguirlo, poco a poco. Para mí, cursos como éste ya suponen de por sí un cambio
cultural. También me llevo mucho enriquecimiento personal y profesional. Te das cuenta
de que todo suma, de que hay ser más reflexivo y escuchar al de al lado. Y que hay que
estar más abierto al cambio, pues por pequeño que éste sea puedes conseguir resultados
objetivos y medibles.
¿Y si empezamos cambiando ésto … por esto otro?
Capítulo #1 - Lean Management: Cultura, cambio y liderazgo

Y en la práctica, ¿en qué creo que puedo aplicar
lo que hemos aprendido? Pues creo que
empezaré con pequeños cambios. El primero de
ellos, poner más foco en el Cliente: escucharle,
establecer una relación de mayor confianza y
darle realmente el valor que necesita de manera
continua y permanente, eliminando el
desperdicio. Aportar valor al cliente debería ser
nuestro único objetivo. El segundo: Gemba
Walk, una pieza clave en el proceso de mejora
continua que consiste en “pasear” por nuestras
líneas de trabajo, y de nuestros usuarios (el
Cliente), para tomar contacto con la realidad de la
producción, conocer de primera mano sus
problemas y comprenderlos en profundidad.
En definitiva, todo esto es posible si existe un apoyo expreso de la dirección como
decíamos, si la cultura de la empresa facilita estas tareas (gracias al curso
@PanelSistemas) y si existe un equipo motivado detrás que juegue los roles adecuados.
El “chapuzón Lean” que nos han dado, ha servido para despejar unas cuantas dudas y
desperezarnos. Entre todos, haremos el camino. Como reza kanban: “Comienza donde
estés“.
Referencias
Artículo original: http://blog.panel.es/index.php/lean-management-cultura-cambio-y-
liderazgo/

Capítulo #2
Calidad y más Calidad…pero ¿y la entrega de
Valor?
(Reflexiones de lo que Marketing es a la Calidad, y viceversa.)
Aunque parezcan actividades antagónicas, las disciplinas de Marketing y Calidad están
más vinculadas de lo que parece. Doy fe de ello.
De hecho deberíamos aplicar muchos de los principios del Marketing a la Calidad. Por
ejemplo: entendemos por calidad cumplir con los requisitos del cliente, cumplir con sus
expectativas. Y para ello, los instrumentos que nos proporcionan las metodologías de
Calidad nos permiten “verificar” que se cumple con la calidad esperada.
Pero los que trabajamos en Marketing sabemos que cumplir con la satisfacción del cliente
es algo más subjetivo, y menos medible. Realmente es una ecuación entre la percepción
del cliente con el producto que le entregamos y lo que él esperaba.
“Calidad es la entrega satisfactoria del valor esperado” decía nuestro compañero Miguel
Ángel Nicolao en este post sobre Innovación Rentable – Masa K. Maeda. Y de eso se

trata: la calidad técnica, la calidad objetiva, es la que se puede medir, y la que responde a
las especificaciones de producción. Pero la verdadera dimensión de la “calidad” es la
subjetiva, la percibida. Y esto, sinceramente, es mucho más que el mero cumplimiento
estricto de los requisitos del cliente.
La calidad debe ser algo más: es precisamente “no cumplir” con
las expectativas del cliente, sino ir más allá. Es ofrecerle un valor
adicional que no ha pedido, pero que una vez obtenido lo
reconoce como esperado.
Realmente, la principal diferencia entre ambas disciplinas, Calidad y Marketing, es la
PERSPECTIVA. Como decíamos, en la primera la calidad se define desde una perspectiva
de la producción. En la segunda, desde una perspectiva de valor. Ambas son
indispensables para asegurar la satisfacción final del cliente. Sin embargo, parece obvio
que la calidad técnica debe siempre estar implícita a nuestra marca, sea cual sea el
segmento al que nos dirigimos y sea lo que sea lo que vendemos. Por ejemplo, el Sr.
Masa K Maeda afirma que la calidad es una propiedad intrínseca que se debe trabajar
desde el principio porque no se puede añadir al final, ni siquiera con un proceso de
inspección QA final.
Cumplir con los requisitos del producto que nos pide el cliente SE
DA POR HECHO en Marketing. Es la única garantía para
mantener nuestra credibilidad y reputación en el mercado.
Y por cierto: recuerda que tu competencia tiene los mismos “sellos” de Calidad que tú.
En definitiva, hay que convencer a los equipos de que trabajar con calidad consiste en
proporcionar al cliente “algo más” que él perciba como beneficio adicional. En software
podríamos hablar de seguridad, de procesos de bajo consumo, de mantenibilidad, de

control de la deuda técnica, de aseguramiento del uso futuro del software…O un
producto/servicio perfectamente alineado con sus objetivos de negocio.
¡Piensa cuál podría ser ese beneficio tangible o intangible para tu cliente, y persíguelo!
Imagen del blog: http://www.consultorinternet.com/
El arte está en conseguir primero identificar ese valor que quiere el cliente (aunque él no
lo sepa), asegurarte de que es el valor que espera, y desarrollarlo generando ese valor
con un beneficio para la Organización. Esta es al final la función del Marketing.
No es tan difícil. Pero desde luego hay que cambiar nuestra Cultura, y mejorar nuestras
formas de trabajar, nuestros métodos, nuestros procesos. Por este orden. Al menos en IT
nos es muy útil apoyarnos en estándares o buenas prácticas que facilitan la entrega
satisfactoria de ese valor: CMMi, Scrum, Kanban… De hecho, la combinación de estas
nuevas prácticas en nuestros proyectos está siendo para nosotros “EL CAMINO HACIA LA
EXCELENCIA” con mayúsculas y su explicación bien merecería otro post.

Es fundamental asegurarse de que la aplicación de estas
metodologías y procesos añaden valor percibido al cliente,
porque si no, sólo suponen costes que no implican Valor. Y esto sí
es alinear la calidad con tu negocio.
En definitiva, ciertos procesos (¿de Calidad?) que se desarrollan de forma rutinaria en
muchas empresas no aportan valor al cliente y pueden ser eliminados. El juicio sobre la
calidad del servicio/producto lo hace el cliente, no nuestros procesos internos. Por eso,
mis procesos de calidad deben estar continuamente adaptándose a las expectativas de mi
cliente, de mi negocio. Quizá mi cliente valore otros “servicios” adicionales que yo antes
no tenía en cuenta, y no valore los que me empeño en prestar.
¿Os suena? es la famosa Cadena de
Valor de Michael Porter, y su aplicación gráfica
en Lean Manufacturing a través del
método Stream Value Mapping, un modelo que
no parece fácil de aplicar pero que permite
identificar fuentes de ventaja competitiva en
aquellas actividades de la empresa generadoras
de valor, eliminando desperdicios. Gracias a un
“amigo” por esta referencia.
Referencias
Artículo original: http://blog.panel.es/index.php/calidad-y-mas-calidad-pero-y-la-
entrega-de-valor/

Capítulo #3
#SQA: Navegar y disfrutar en equipo
Conclusión: sin trabajo en equipo, respeto, rutina, información y algo de alegría es muy
difícil que un barco llegue a puerto, incluso en un “caso de uso” tan benévolo como la
navegación fluvial. Un destino cercano puede resultar inalcanzable si no es también un
objetivo común, al igual que en el desarrollo de software. Comprobado de primera mano.
Así, tras alquilar con cierta ligereza un crucero fluvial en Francia, nos encontramos con que
todo un barco de 13,5 metros de eslora era nuestro durante una semana. Nuestro,
nuestro. Es decir, nosotros éramos patrón, tripulación y pasaje a la vez.

Nuestro barco, Le Magnificat
Como buenos novatos pedimos explicaciones sobre el manejo de la embarcación, la
normativa de navegación pero, sobre todo, que nos expliquen cómo se pasan las
exclusas. Las escuetas explicaciones estuvieron a la altura del típico arranque (“kick off”)
de los proyectos software.
Bien, lo primero hay que organizarse:
Provisiones y equipo de emergencia – (Infraestructura).
Reparto de tareas. Todos queremos ser el piloto, pero hay muchas más cosas
que hacer – (Roles).
Libro y ruta de navegación – (Plan, “backlog”).
Cultura ¿cornamusa?, maniobras (atracar, soltar amarras y no quedarse en
tierra, etc.) y rutinas – (Aseguramiento).
En un par de horas ya nos sentimos cómodos. El resto de la semana nos dedicaremos a
navegar por los ríos Mayenne y Oudon. Tendremos nuestros momentos de tensión
(¿riesgo?), trabajo en equipo, turismo, convivencia y mucho disfrute e incluso, reflexión.
Una gran experiencia.
De entre mis reflexiones quiero compartir con vosotros lo rentable que resulta construir

sobre unas bases adecuadas. También en la construcción de software. Así, perseverando
en interiorizar que “la Calidad es una propiedad intrínseca que sucede antes de terminar el
producto“, pondremos rumbo hacia maximizar resultados, hasta conseguir que un crucero
fluvial sea una experiencia memorable.
Collage crucero fluvial Francia
¿Cómo podemos orientarnos hacia maximizar resultados?
Pensando a nivel de sistema, ecualizado, integrando.
Podemos aplicar diversas técnicas o metodologías, pero la clave es pensar en el conjunto
y buscar el equilibrio: ecualizar. Todos llegamos a ser patrón, tripulante y pasajero con el
objetivo común de disfrutar cada segundo.
Las exclusas hay que pasarlas con cuidado, poniendo atención y en equipo, pero son muy
reconfortantes. En la construcción de software las denominamos “Quality Gates” y una
forma de visualizarlas es mediante el cuadro de mandos de SonarQube. Una auténtica
medida de avance y cumplimiento.

Esta experiencia también ayuda a establecer claramente la diferencia entre marinero de
agua dulce y lobo de mar (con respeto y a mucha honra ;-). Ciertamente, hay diversos
grados de complejidad pero comparten los fundamentos y valores.
¡Enrólate en el equipo de Calidad Software intrínseca! Será una
experiencia memorable y … puede que también salgáis en el
periódico
Referencias
Artículo original: http://blog.panel.es/index.php/sqa-navegar-y-disfrutar-en-equipo/

Capítulo #4
#one2change – El cambio está en cada uno de
nosotros
A principios de diciembre se celebró la Conferencia Agile Spain (CAS). Hablamos de una
emblemática conferencia apta todos los interesados en el desarrollo de productos
software que habilita un sináptico punto de encuentro. Si quieres, el descubrimiento
personal y profesional está garantizado.
En este artículo quiero contaros mis impresiones en esta mi primera CAS. Se ha tratado de
una conferencia grande, rica, con una organización notable y muy buen ambiente. La
agenda estaba divida en 6 “tracks” (desarrollando personas, mejorando software,
creando equipos, entregando producto, transformando organizaciones y una serie de
talleres), además, cada día empezaba y acababa con una “keynote”. Mucha tela.
También se habilitó un panel gigante con los valores y principios del Manifiesto Ágil. Una
interesante iniciativa que en su parte central ofrecía un espacio para firmas, de forma que
nos ayude a recordar su importancia como cimientos del agilismo.

Manifiesto ágil CAS2015 #one2change
En cuanto a los contenidos, el espacio web creado para la ocasión – CAS2015 en Agile-
spain.org – sigue enriqueciéndose cada día. Resulta un sitio de visita obligada por sus
referencias a los contenidos de las distintas charlas, incluidas las grabaciones gracias a la
cortesía de los ponentes y la inestimable labor técnica de Autentia. Es una valiosa mina.
Mi recomendación es:
aprovechad la oportunidad
asomaos a todas estas ventanas.
cotillead todas las charlas CAS2015.
¡Qué decir de las personas! Como bien señalan en este mismo espacio web, la CAS “es un
punto de encuentro con amigos, compañeros y otros profesionales para compartir
aprendizajes y encontrar sinergias de colaboración que nos permitan avanzar juntos y
continuar evolucionando.” Confirmado. Si todavía no has podido experimentarlo de
primera mano, no intentes imaginártelo, acude al próximo evento, meetup, open space,
café … lo que sea. Superará todas tus expectativas.

Centrándome en mi CAS2015
Acudí con idea de aplicar como criterio de priorización los contenidos del track
“Entregando producto” (me debo de estar haciendo mayor) y las charlas en las que no
conociera al ponente. Os cuento.
Eugenio Moliní asumió el reto de la “keynote” inaugural titulada “Vocación y
Vulnerabilidad de un Agente de Transformación”. En la presentación de Eugenio, Vanesa
Tejada señaló que pensó en él por el impacto personal que le había causado en un taller
anterior y el efecto que tuvieron estas palabras en mi caso fue: escudos abajo, atención al
máximo.
Como resultado, la charla de Eugenio me arrasó. Me atravesó, encendió velas en zonas
profundas de mi espíritu en las que las tinieblas ya se estaban acomodando y me provocó
un serio proceso de reflexión. Sinceramente, si al final de esta charla se hubiera
suspendido la CAS2015, lo hubiera dado por bueno.
La premisa básica en la Teoría del
Cambio:
“Las personas cambian cuando
quieren (y punto).”
Por Eugenio Moliní.
CAS2015 Keynote Eugenio Molini

Sigamos, ponte cómodo y, por favor, recuerda que “Entregando Producto” era mi
mantra.
Apertura Entregando Productos – Aritz Suescun
Aritz nos plantea: “Os habéis fijado que todo empieza de forma mágica con el
Product Backlog.” ¿Qué pasa antes del Product Backlog? ¿De dónde viene esa
información? El descubrimiento llama a nuestra puerta.
Además, nos muestra su admiración por los responsables de producto (Product
owners), “unos auténticos superhéroes”. ¿Serán como Superman?, con
superpoderes desde la cuna, o ¿Serán como Batman?, gente normal que con
entrenamiento y herramientas consigue destacar como superhéroe.
Para los que no somos Superman, nos presenta su kit de herramientas para los
responsables de producto (que irá repitiéndose en otras charlas … buena
señal).
Herramientas para el Product Owner superhéroe – CAS2015
El Síndrome de Niggle, la orientación a Objetos y la Familia de Juan Carlos I –
Jorge Uriarte

Se trata de una llamada de reflexión sobre el nivel de abstracción a aplicar en el
diseño de un producto. Equilibrar entre el nivel de detalle y el avance del
producto, diseñar de forma iterativa. Para ilustrar su punto de vista, se apoyó
en el síndrome de Niggle y en el trabajo del pintor Antonio López. ¿Eterno
dilema?
How to bet in Montecarlo and end up with some money in your pocket – Pablo
Domingo de la Orden.
Buenas noticias, es posible trabajar en la predictibilidad, afinar nuestra
respuesta a cuándo terminaremos un producto o cuánto costará … aunque …
“todos los modelos fallan porque la realidad es mucho más compleja, el valor
está en las conversaciones”. Una sesión muy interesante, densa por obligación
pero que nos presenta el método Monte Carlo, la entrada a la madriguera del
país de la simulación.
"Plans based on averages are wrong on average"
No es posible esconder la complejidad de los datos en la
media
Si la grabación llega a estar disponible, os la recomiendo porque es una buena
forma de bautizarse. En todo caso, es necesario trabajarse la predictivilidad
para sacarle rendimiento.
El arte de decir que no [pdf] – Carlos Hernández (Quaderno.io)
Me gustó -mucho- la claridad y convicción con la que Carlos nos transmitió su
mensaje. Fue reventando una a una todas las tentaciones que los constructores
de producto van a ir encontrándose en su camino: “con esta funcionalidad se
disparará el interés de los usuarios”, “solo os llevará una jornada”, “este cliente
está a punto de abandonar”, “podemos hacer que sea opcional”, “no tenemos
nada más planificado”, “todo el mundo lo quiere”, “nuestro competidor ya lo

tiene”, “si no lo hacemos, lo hará otro”, “el jefe lo quiere”, “esta es LA
funcionalidad”.
En conclusión, Carlos nos señala que decir “no” es un ejercicio de
responsabilidad para con el futuro de nuestro producto. Su propuesta: “Es mejor
que el cliente se adapte al usuario antes que el producto se adapte a los
clientes”.
En el resumen de su charla nos lo indica: En esta pequeña charla te contaré
porqué el desarrollo de un buen producto está ligado a la frecuencia de uso de
la palabra “no”. No un “quizás”. No un “más adelante”. Un simple “no”.
El Big Data también es ágil (o debería) – Juan Tomás García
En sesión corta, Juan Tomás nos puso al día en Big Data y nos contagió su
entusiasmo por las posibilidades de esta disciplina. Inicialmente nos recordó
que los procesos de analítica de datos tradicionales siguen metodologías
secuenciales que resultan demasiado lentas entregando resultados y
demasiado pesadas para modificarlas y adaptarlas a las cambiantes
necesidades de negocio.
Afortunadamente, gracias a los marcos ágiles, la filosofía Lean y las nuevas
tecnologías en Big Data se han podido implementar nuevas formas de hacer
análisis que permiten un diálogo productivo entre datos y negocio. El foco está
en contener el “Time to answer”, trabajando el Big Data con Productos Mínimos
Viables (MVP), midiendo y pivotando.
Para terminar, un viaje relámpago por las tecnologías Big Data, desde
MapReduce y Apache Hadoop hasta su todopoderoso equipo fantástico: la
arquitectura Kappa, formada por Kafka + Spark + NOSql + Scala.
Design Thinking: the power to accept every challenge – Mariana Ivanova
(SAP)

¿Cómo conectar con la esencia de un problema? ¿Cómo dinamizar la
innovación en producto? Mariana nos cuenta que su particular periplo en
búsqueda de respuestas se ha consolidado en la aplicación de la metodología
Design Thinking en equipos multidisciplinares.
Dedicamos la sesión a recorrer las cinco etapas de este proceso no lineal:
Empatiza, Define, Idea, Prototipa, Testea. Estas son algunas de las píldoras que
nos regaló:
Empatiza: ponte en los zapatos de los demás, pregunta 5 veces ¿por qué?
– Libro: Interviewing Users de Steve Portigal
Define: buscamos establer el Punto de Vista (POV – Point-of-View). Un punto
de vista bien definido se enfoca en un problema específico. “Storytelling” es
una interesante herramienta para ello, nos señala.
“Before start working hard,
make sure you are working on the right thing”.
by Marvin Liao
Idea: Empezamos a buscar soluciones, numerosas y variadas. Nos detalla la
“tormenta de ideas inversa” como una técnica particularmente interesante.
– Pista: Artículo sobre "The power of bad ideas by Steve Portigal".
Prototipa: “Lo mejor para adquirir experiencia es experimentar”, por ello,
hagamos prototipos de forma rápida y barata, que nos permita fallar de forma
temprana y frecuente (pero no mortal, ni siempre). Pisamos territorio ya
visitado en este blog: Pretotipa y prueba.
- Caso práctico: "Dark horse prototype" (Stanford Univ.). Prototipamos sin
descartar ninguna opción, así incluso el peor caballo (“the dark horse”) tiene
opciones de ganar.

Hablamos de p_e_r_s_e_v_e_r_a_n_c_i_a, solo te diré que James Dyson (el de
las aspiradoras sin bolsa) realizó 5.127 prototipos.
Prueba: No te conviertas en un vendedor de tu idea, busca y escucha
opiniones.
– Libro: The Mom test de Rob Fitzpatrick, buscando el “product market fit”.
Estamos ante un proceso iterativo e incremental. Como deberemos pasar
varias veces por estas etapas y superar grandes dosis de frustración, mejor que
busquemos el niño que todos llevamos dentro
“Do not fall in love with the process,
fall in love with the problem
and no power can stop you from changing the world”
by Mariana Ivanova
Persuading the business guys – Gerardo Ponte
Una valiosa sesión en la que Gerardo nos comparte la experiencia que han
vivido en el banco BBVA para conseguir la inmersión de los equipos de negocio
en las dinámicas propias de los marcos de trabajo ágiles (Scrum en su caso).
El recorrido fue exhaustivo y clarificador: por qué los modelos en cascada son
confortables para los “chicos de negocio” y qué aspectos de los marcos ágiles
ofrecen oportunidades para reducir fricción y potenciar el sentido de propiedad
del producto. La importancia de buscar contextos de trabajo comunes, cuidar los
miedos y trabajar – intensamente- en el descubrimiento (han aplicado Design
Thinking, Story Mapping, Storytelling, Productos mínimos viables, etc).
El punto en el que han visto más problemas y resistencias es formalizando la
etapa de Definición. En su caso, el intento de utilizar el lenguaje Gherkin fue un
absoluto fracaso. En consecuencia el equipo se reorganizó y definió un proceso

para establecer los criterios de aceptación, consiguiendo una mejora
espectacular al aplicarlo a las historias de usuario. Pista: Inspirarse en el The
three amigos de la Scrum Alliance.
Economía del Software y dependencias: dilemas del software desacoplado –
Luis Artola y Guillermo Gutiérrez
Considero que esta fue mi charla estrella, al margen de la “keynote” de
Eugenio Moliní. La parte técnica de la charla fue una reflexión sobre el impacto
de las dependencias del software en su rentabilidad, relevante.
Destacado: la Inversión de Control como contramedida a las dependencias, las
arquitecturas hexagonales y recordar los seis principios olvidados del diseño
Orientado a Objetos, extended S.O.L.I.D.
El premio gordo vino de la necesidad de esta fantástico descubrimiento (Luis y
Guillermo) de tener su suelo bajo control. Su trabajo de cimentación intelectual
produjo una introducción de oro puro sobre Economía del Software para torpes.
En cuestiones de economía no es necesario inventarnos nada, aprendamos
este contexto (“business mindset”), es necesario para entablar conversaciones
productivas con las áreas de negocio y construir relaciones de confianza.
Economics of Software economics (collage)
La gente de negocio se centra en los
costes visibles,
pero los costes son menos
importantes que
el valor, el riesgo o la deuda.
Todo se acaba

Y con esto se terminó mi asistencia a charlas del track “Entregando Producto”. Muy
intenso, con una clara línea que lleva a trabajar en el acercamiento hacia las áreas de
negocio (“Business mindset”) y a avanzar juntos en el descubrimiento del mercado. Se
quedan en el tintero tres “keynotes”, otras charlas y talleres (gracias Diego Rojas por
reconducirme al taller con Tim Ingarfield). Eso sí, me ratifico en que todo el que quiera,
con el conjunto de contenidos generados por la CAS2015 puede estar muy ocupado hasta
que llegue la CAS2016. Sin duda
Para terminar, una vez más quiero agradecer a @JTuregano por animarme a asistir y a
@Danipise los buenos ratos que pasamos. La CAS volvió a Madrid por suerte para mi y ha
sido una inolvidable experiencia ¡un novato felíz!
El slogan de la CAS2015 ha sido #one2change
y expresa el mensaje fundamental:
– El cambio está en cada uno de nosotros –
Referencias
Artículo original: http://blog.panel.es/index.php/one2change-una-de-cas-2015-madrid/

PARTE II
PROCESOS Y SQA
"La metodología, los procedimientos y las buenas prácticas en
tus proyectos deberían de trabajar para ti, y no tú para ellos".
PARTE II - Procesos y SQA

Capítulo #5
Algo pasa con CMMi
Agilismo, Conocimiento, Seguridad, Innovación… ¡Lo quiero TODO! ¿Qué le está pasando
a CMMi? La respuesta a esta pregunta la encontramos el pasado día 2 de Diciembre, en
la IX Semana del CMMi y la Mejora de la Calidad TIC, un evento que se celebra
anualmente en Madrid organizado por Caelum y dirigido por Ramiro Carballo, y en el cual
tuvimos el placer de participar. Sí, sí…. tenía pendiente de redactar este post.
El resumen de lo que se presentó en esta Jornada lo dice muy claramente Caelum en la
agenda del programa:
“Un modelo con más de 20 años que se diseñó para cubrir la
necesidad del Departamento de Defensa de los Estados Unidos en
materia de software, se adapta a los nuevos tiempos.”

Nuevo logo CMMi-DEV para Panel Sistemas
Una conclusión que quedó perfectamente reforzada en cada una de las ponencias que
escuchamos durante la mañana, incluida la nuestra, y que está enmarcada en la iniciativa
CMMi NeXT Gen, toda una declaración de intenciones.
Empecemos por la gran importancia que se le está dando a la CiberSeguridad en el
modelo CMMi. En este sentido, hay en marcha varias iniciativas como la incorporación de
prácticas de codificación segura del software, en colaboración con Siemens y Oracle.
Recomiendan 4 nuevas áreas de proceso para el modelo CMMi-DEV e incluyen guías de
codificación en Java teniendo en cuenta aspectos seguros. También nos presentaron
el nuevo modelo CERT- RMM (Resilience Management Model), para gestionar la
capacidad de la organización a la hora de asumir situaciones límites (disrupciones)
y continuar operando el negocio. Nada menos que 26 áreas de proceso en 4
categorías (Ingeniería, Gestión de Empresa, Gestión de la Operación, Gestión de los
Procesos).
Agilismo y CMMi. Qué gran tema :-). Pues bien, aunque al principio ambas metodologías
pueden parecer incompatibles, no lo son. Ambas persiguen un objetivo común, aunque
basan sus esfuerzos en competencias distintas para alcanzarlo. Por eso realmente creo
que el éxito está en integrarlas, no en combinarlas, creando así un mayor valor añadido al
proyecto. La clave está en ser realistas y ofrecer soluciones pragmáticas que realmente
funcionen – para el producto y para el cliente.
Sobre ello precisamente giró el contenido de nuestra ponencia. Miguel Ángel Nicolao, CIO
en @PanelSistemas, contó muy entretenida y brillantemente cómo en Panel (una
empresa CMMi-DEV nivel 3 y CMMi -SVC nivel 2) hemos cruzado el precipicio hacia el
Agilismo. Hablamos de muchas historias de éxito, y “algunas” de fracaso, pero sobre todo
compartimos muchas reflexiones y lecciones aprendidas en el día a día de los equipos y de
los proyectos, que dan para escribir otro post!.

Pasarela de Holzarte
Alrededor de este tema también destacamos la intervención de Theodora Bozheva
(Berriprocess) y su ponencia ¿Cómo aligerar CMMI con KANBAN?. Se trata de cómo
obtener la esencia de CMMI a través de Kanban, construyendo procesos sostenibles que
permitan conseguir el objetivo del proyecto: aumento de la visibilidad y de la
comunicación, creación de valor, eliminación del desperdicio, motivación del equipo.
Fundamental.
Y cerramos este capítulo de Agilismo con la aplicación práctica que Ramiro nos ofreció de
las métricas para monitorizar proyectos ágiles subcontratados (adquisición de software):
Bar chart of velocity, para medir la velocidad de entrega por puntos de historia; Sprint
burn-down; Story points entregados por sprint; Defectos entregados acumulados; Trabajo
en progreso, etc.
Sobre la Gestión del Conocimiento, fue muy interesante la experiencia de Babel Sistemas
con su Centro de Mantenimiento de Aplicaciones, en el que uno de sus pilares básicos es
la Gestión del Conocimiento aplicada, basada en los modelos de Nonaka y Takeuchi:
cómo pasar del conocimiento tácito al conocimiento explícito. Todo ello en un ambiente de
conocimiento accesible y medible a través de herramientas como un CM welcome
package, wikis, base de datos de lecciones aprendidas y compartidas, y herramientas

colaborativas. Al hilo de esto, también es interesante la colaboración que nos presentó
Ramiro entre el SEI y el EDM (Enterprise Data Management Council): el nuevo
modelo DMM – Data Management Maturity, para mejorar la gestión de activos de
información críticos.
Y por último, Innovación. En esta categoría incluyo otras cosas que me parecieron
interesantes, ¿innovadoras?, del modelo. La primera, el aprovechamiento de
las sinergias en procesos comunes de la Gestión de Servicios ISO 20000 y CMMI-SVC, y la
experiencia de “aprender a remar al unísono” que nos contó Unisys usando CMMI-DEV y
CMMI-SVC para afrontar la diversidad de proyectos que abordan. Y por último, otras
novedades curiosas en el modelo CMMi: la generación de un entorno de innovación
durante el proceso Scampi; la iniciativa formativa CMMi Master (300 horas de
formación), y la posibilidad para las empresas de un Action Plan Reappraisal (APR) en el
proceso Scampi, que suscitó un intenso debate con opiniones encontradas.
En definitiva: creo que esta Jornada reflejó claramente lo que nos viene sucediendo a las
organizaciones acreditadas en este modelo en los últimos años. Las tripulaciones están
cansadas, y en algunos casos frustradas, de la disciplina marinera :-). Aparece la
fascinación con las experiencias ágiles, y también inquietudes sobre otros aspectos a
considerar en el desarrollo de software, como es la ciberseguridad.

Pero en muchos casos, Scrum y su delimitación en temas como QA, arquitectura,
seguridad, requisitos o gestión de la contratación hace que los clientes no quieran ni oír
hablar de ello. Por eso tras un satisfactorio recorrido por el mundo CMMi, algunas
organizaciones necesitamos encontrar una pasarela similar a la de Holzarte.
¿Qué hacer? Bueno, ya lo dice el propio CMMI Institute:
Adáptate. Evoluciona. Acelera. Quedarse quieto no es una
opción.
Referencias
Artículo original: http://blog.panel.es/index.php/algo-pasa-con-cmmi/

Capítulo #6
Entre anomalía, defecto o fallo anda el juego
¿Cual es la diferencia entre un defecto y un fallo en un sistema informático? Para la mayor
parte de nosotros (como usuarios), no hay ninguna diferencia: “Apunta este fallo, esto no
hace lo que yo quería”.
Sin embargo, si estamos utilizando un software garantizado no debemos colocar todas
nuestras decepciones en la bandeja de “un fallo: me lo deben”. No hay garantía que lo
resista. Por ello, es necesario diseccionar la situación para poder catalogar correctamente
sus causas y consecuencias.
Ya empezamos. Bien, ¿Qué es un <fallo> en un sistema software?
Puesto que tenemos todo un instituto internacional especializado en la certificación de
profesionales de Pruebas Software, el “ISTQB”, veamos cómo lo definen: fallo es la
“desviación del componente o del sistema respecto de prestación, servicio o resultado
esperado.”
Es decir, nos señalan que un fallo es la incapacidad de un sistema software o de un

componente para realizar las funciones solicitadas dentro de unos márgenes de
rendimiento requeridos. Vamos, que el sistema software tiene un comportamiento
decepcionante.
Como el sistema software ha fallado, ¡Que lo arreglen!. En primera instancia, cualquier
decepción en el comportamiento del sistema la catalogamos como anomalía. Debemos
tomarlo como el punto de entrada para cualquier forma de gestión de la Calidad del
Software que utilicemos.
Entonces, ¿Qué es una <anomalía>?
Formalmente, anomalía es “cualquier condición que se desvíe de las expectativas
basadas en las especificaciones de requisitos, documentos de diseño, documentos de
usuario, estándares, etc., o de la percepción o experiencia de alguien. Las anomalías
pueden ser encontradas durante, aunque no se limitan sólo a, revisiones, proceso de
pruebas, análisis, compilación, o uso de productos de software o documentación
aplicable. [IEEE 1044]”
[Según el instituto internacional dedicado a la certificación de profesionales de Pruebas
Software (ISTQB)].
Anomalía:
Cualquier condición del sistema software que se desvíe de nuestras expectativas.
Nada más y nada menos.
Tranquilidad. Es cierto que estamos decepcionados y la calidad del producto se resiente,
pero todavía no sabemos en qué momento la construcción del producto software y
nuestras expectativas se desconectaron. Aunque es claro que la detección temprana de
anomalías ahorra dinero y decepciones, la caza de brujas tiene que esperar.
Habitualmente las anomalías son tratadas como incidentes. Su tratamiento nos llevará
hacia catalogar la causa de nuestra decepción como defecto, nueva funcionalidad o como
un sueño imposible.

El sueño de E.T.
Entonces, ¿Qué es un <defecto>?
Volviendo a tirar de formalismo ISTQB, un defecto es una “imperfección en un
componente o sistema que puede causar que el componente o sistema falle en
desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de
datos incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en
el componente o sistema.” [Según el instituto internacional dedicado a la certificación de
profesionales de Pruebas Software (ISTQB)].
Atentos, hablan de que se “falle en desempeñar las funciones requeridas”. En los
defectos, nos quedamos sin espacio para nuestros sueños y empieza a funcionar la
garantía de la garantía.
Un defecto es lo mismo que una falta (“fault”), problema o “bug”. Catalogando los tipos
de defectos podremos elaborar la Taxonomia de “bugs” sobre la que apoyar nuestro
sistema de gestión de incidentes (“defect management tool”). Cada defecto que se
introduce en el software es como resultado de un error.
¡Ajá, mi garantía! Entonces, ¿Qué es un <error> en el software?

Igual no te lo imaginas, el ISTQB establece que un error es una “acción humana que
produce un resultado incorrecto. [Según IEEE 610]”. Centrándolo en la construcción de
software, un error es un fallo, mala concepción (“misconception”) o mala compresión
(“misunderstanding”) por parte del desarrollador de software.
Nota: Léase desarrollador software en sentido de involucrado en el proceso de
construcción software, es decir, incluye ingenieros software, programadores, analistas,
ingenieros de pruebas, etc.
Ya tenemos la secuencia de los hechos:
el error humano cometido inyecta
un defecto en el software que, ocasionalmente,
se observa como una anomalía a causa de un comportamiento
incorrecto,
no acorde a lo especificado,
que finalmente provoca el fallo del sistema software.
En esta secuencia hemos dejado al margen el conjunto de anomalías motivadas porque el
sistema no satisface las expectativas -no expresadas- del cliente. Su gestión requiere de
una absoluta vocación por el descubrimiento y la detección temprana, de forma que la
adaptación a las expectativas del cliente se haga con el menor desperdicio posible.
Si queréis profundizar en cómo coordinar estas actividades en vuestro ciclo de contrucción
de software, te invitamos a ponerte en contacto con nosotros para conversar sobre cómo
desde el Aseguramiento de la Calidad Software (SQA) se puede impulsar la “entrega
satisfactoria del valor esperado”, como máxima expresión de la Calidad adecuada al
propósito.

Panel Servicios SQA
Referencias
Artículo original: http://blog.panel.es/index.php/softwareqa-entre-anomalia-defecto-o-
fallo-anda-el-juego/

Capítulo #7
Los 7 ejes de la calidad del código fuente
Analizar sistemáticamente la salud de nuestros desarrollos software y sintetizarla en los 7
ejes de la Calidad Software es el leitmotiv del producto SonarQube™, proyecto de código
abierto distribuido bajo licencia LGPL v3. La silueta de su cuadro de mandos (“dashboard”)
es ya imborrrable en las retinas de muchos equipos de desarrollo.
¿Cuales son los 7 ejes sonar de la Calidad Software?
el Código duplicado,
la adherencia a Estándares de codificación,
las Pruebas Unitarias,
la Complejidad del código,
las Evidencias de Fallos Potenciales,
el nivel de Comentarios,
y la valoración sobre Diseño y Arquitectura.

Unas líneas de trabajo (de análisis) que arrancan desde la versión 2.0 de sonar, allá por los
albores del año 2010. Con el tiempo este enfoque ha ganado en cuerpo, aromas y
matices – como los buenos vinos – hasta consolidar un excelente maridaje con el método
SQALE (“Software Quality Assessment based on Lifecycle Expectations”), reconocido
archienemigo de la deuda técnica.
En este artículo no vamos a desarrollar los detalles del conocido método SQALE, pero al
menos queremos reseñar que está pensado para ser automatizado, construido alrededor
del control de la deuda técnica (lo que supuso un valioso cambio de paradigma) e
impulsado por Jean-Louis Letouzey, al hilo de una investigación interna realizada en la
empresa inspearit. Volveremos, es una valiosa píldora cultural.
Siguiendo con los cuadros de mando (“dashboards”) para gestionar la calidad del
software conforme a los siete ejes técnicos citados, el punto fuerte de SonarQube™ es su
capacidad para integrar la gestión de diversas herramientas de análisis de código fuente.
Si cambiamos de perspectiva, a la gente de SonarSource les gusta llamarlos “los siete
pecados del desarrollador”:
1. Tener líneas de código duplicado (“Duplicated code”).
2. No respetar los estándares de codificación y las mejores prácticas establecidas
(“Coding standards”).
3. Tener una cobertura baja (o nula) de pruebas unitarias, especialmente en
partes complejas del programa (“Unit tests”).
4. Tener componentes complejos y/o una mala distribución de la complejidad
entre los componentes (“Complex code”).
5. Dejar fallos potenciales sin analizar (“Potential bugs”).
6. Falta de comentarios en el código fuente, especialmente en las APIs públicas
(“Comments”).
7. Tener el temido diseño spaghetti, con multitud de dependencias cíclicas
(“Design and architecture”).
¡Cuidado! No emocionarse, por favor mantengan en todo momento los brazos dentro del
vagón… ni utilizen “selfie-sticks”.

Antes de lanzarnos a una irracional caza de brujas
es preciso estudiar qué ejes son más relevantes
para nosotros y en qué medida. Por ejemplo,
deberemos evitar hipocresías como lipotimias por
una baja adherencia a estándares de codificación
que nadie ha definido.
Todo tiene un coste, tanto hacer algo como no
hacerlo, así que lo más sensato (y rentable) es
estudiar la situación, establecer un objetivo y un plan de trabajo paulatino. Como
explicamos durante el evento organizado por @PanelSistemas sobre fabricación
ecoLÓGICA de software, integrando acciones de mejora continua en los ciclos de
desarrollo se obtienen unos elevados Retornos de Inversión (ROI).
El resultado merece el esfuerzo. Para que lo podáis valorar vosotros mismos os incluimos
la refencia a un par de instancias SonarQube™ (enjoyadas a tope):
Dashboard Sonar EXOplatform
Sonar: Un producto exhaustivo y gratuito. ¿No será otro
unicornio más?

Efectivamente, además de la valiosa aportación funcional del producto SonarQube™
consideramos relevante que el modelo de negocio de su fabricante (SonarSource) debe
ser compatible con vuestros umbrales de rentabilidad. La descripción del producto que
realizan nos parece de por sí reveladora de su estrategia “™”:
SonarQube™ software (previously known as “Sonar”) is an open source project hosted at
Codehaus. Download and install your own copy. Version: 5.1.1 (Jun 5, 2015) distributed
under license LGPL v3.
El modelo de negocio se basa en recortar funcionalidades de la versión gratuita
(“Community”) e incorporarlas en forma de extensiones (“plug-in”) en las diversas
ediciones comerciales. Es bastante fácil plantarse en los 50.000 EUR anuales,
perfectamente razonables en un proyecto de 50 personas que quieran disponer de estos
cuadros de mando “para currar”.
Por último, como bien señalaba Allard Buijze: Sin perder de vista que las métricas son una
excelente ayuda, sigue siendo necesario que los equipos de trabajo analicen, entiendan y
ponderen los resultados. Por desgracia, ni siquiera unas métricas excelentes garantizan
un proyecto software exitoso. Siempre será necesario combinar un buen proceso de
trabajo, una adecuada gestión del proyecto, arquitectos centrados y un equipo de
interesados implicado para asegurar la debida entrega de valor a nuestros clientes.
En todo caso, nada que no pueda arreglar un experto como bien se explican en este
divertido vídeo (7 minutos, en inglés con subtítulos): “The expert”. (Gracias Cosme)
Referencias
Artículo original: http://blog.panel.es/index.php/softwareqa-los-7-ejes-de-la-calidad-del-
codigo-fuente/

Capítulo #8
¿Cuáles son los tipos de pruebas software?
Un conjunto de actividades de pruebas suele orientase a comprobar determinados
aspectos de un sistema software (o de una parte del mismo). Continuando así con nuestro
anterior artículo sobre el modelo de cebolla para los Niveles de Pruebas Software, y
siguiendo las directrices del ISTQB, acotaremos los Tipos de Pruebas Software en función
del objetivo en que se centran.
En primer lugar tenemos las Pruebas Funcionales. Típicamente encontraremos el
comportamiento del sistema, subsistema o componente software descrito en
especificaciones de requisitos o casos de uso, aunque también puede no estar
documentado (“que funcione como el sistema al que sustituye”) . Es decir, con las
funciones establecemos “lo que el sistema hace”.
Estas pruebas se definen a partir de funciones o características (como decimos, bien
descritas en documentos o bien interpretadas por los probadores) y su interoperabilidad
con sistemas específicos, pudiendo ejecutarse en todos los niveles de pruebas
(componentes, integración, sistema, etc).

Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el
comportamiento externo del sistema. Las Pruebas de Seguridad o las Pruebas de
Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas
funcionales.
En segundo lugar figuran las Pruebas no
Funcionales que incluyen las pruebas de:
Rendimiento, Carga, Estrés, Usabilidad,
Mantenibilidad, Fiabilidad o Portabilidad, entre
otras. Por tanto se centran en características del
software que establecen “cómo trabaja el
sistema“.
Estas pruebas también pueden ejecutarse en todos los niveles de pruebas. Las
características no funcionales del software se pueden medir de diversas maneras, por
ejemplo, por medio de tiempos de respuesta en el caso de pruebas de rendimiento o por
número máximo de sesiones en pruebas de estrés.
Puesto que las Pruebas no Funcionales normalmente consideran el comportamiento
externo del sistema, en la mayoría de los casos se utilizan técnicas de Pruebas de Caja
Negra.
A continuación, en tercer lugar, tenemos las Pruebas Estructurales. Nuevamente pueden
ejecutarse en todos los niveles de pruebas (ya sabéis: componentes, integración,
sistema, etc.) y encajan muy bien si hemos utilizado técnicas de especificación de la
estructura o arquitectura del Software. Es posible aplicar técnicas estáticas de análisis de
código.
Para expresar el alcance con un conjunto de pruebas (“test suite”) que ha cubierto la
estructura o arquitectura en cuestión, se utiliza el concepto de Cobertura (“Coverage”),
normalmente en forma de porcentaje.
Es especialmente habitual utilizar herramientas de apoyo para calcular la cobertura del
código en el caso de Pruebas de Componentes o en Pruebas de Integración de

Componentes (por ejemplo, trazando la jerarquía de llamadas entre elementos). Puesto
que indagamos en el comportamiento interno, estas pruebas se denominan también
Pruebas de Caja Blanca (“white-box testing”).
Finalmente, el cuarto tipo de pruebas que nos
presenta el ISTQB son las pruebas derivadas de
la realización de cambios: las Pruebas de
Regresión y las Re-pruebas.
Una vez que un defecto ha sido corregido, toca
volver a probar el software para confirmar que el
defecto ha sido eliminado. Son pruebas repetidas o Re-Pruebas.
Las Pruebas de Regresión consisten en volver a probar un componente, tras haber
sido modificado, para descubrir cualquier defecto introducido, o no cubierto previamente,
como consecuencia de los cambios. Los defectos pueden encontrarse tanto en el software
que se ha cambiado como en algún otro componente. Se ejecutan cuando se cambia el
software o su entorno. El criterio para decidir la extensión de estas Pruebas de Regresión
está basado en el riesgo de no encontrar defectos en el software que anteriormente
estaba funcionando correctamente.
Las Pruebas de Regresión se realizan sobre un componente ya probado, para verificar que
no presenta nuevos defectos cuando se realiza una modificación después de dichas
pruebas.
Este tipo de pruebas deben ser repetibles si han de usarse para pruebas de confirmación
(o aseguramiento) y regresión (como Sondas de Disponibilidad, por ejemplo). Los
conjuntos de pruebas de regresión (“Regression test suites“) suelen ser bastante estables
por lo que son muy buenos candidatos para actividades de automatización de pruebas.
Quizá ya no os sorprenda que estas pruebas también puedan ejecutarse en todos los
niveles de pruebas e incluyen casos de prueba de los tipos vistos anteriormente: Pruebas
Funcionales, No Funcionales y Estructurales.

Ahora que ya tenemos una buena imagen de los
tipos de pruebas que podemos incorporar para
asegurar la Calidad del Software (SQA), es más
fácil que entendamos que se trata de una
actividad que requiere una elevada capacidad de
adaptación de las cargas de trabajo, así como de
una suficiente especialización. Por ello, en
@PanelSistemas hemos consolidado nuestra
orientación hacia modelos de factoría, os lo
contamos en nuestro artículo: “el Testing bajo
modelos de factoría“.
¿Echas en falta algún tipo de prueba software? ¡Pruébanos!
Referencias
Algunas referencias sobre este tema que os proponemos son:
Descarga del Syllabus del ISTQB (2011, International Software Testing
Qualification Boards).
Espacio web para estudio de la certificación ISTQB.
Artículo sobre Niveles de Pruebas representados visualmente con un Modelo de
Capas de Cebolla: Software Testing Levels Onion Mode
Artículo original: http://blog.panel.es/index.php/software-qa-cuales-son-los-tipos-de-
pruebas-software/

Capítulo #9
Software testing levels onion model
Según avanzamos por el proceso de fabricación de software, nos apoyaremos en pruebas
a diversos niveles para mantener la confianza en el producto final. A continuación os
presentamos estos Niveles de Pruebas Software utilizando un modelo de representación
en capas, porque …
Las cebollas están hechas de capas sucesivas, siendo cada capa
más potente e intensa que la anterior. Además, las cebollas -a
veces- nos hacen llorar.
Las actividades de construcción de software y las de pruebas deben de convivir
armoniosamente. Una concepción aislada del “Testing” no es productiva. Por tanto, se
requieren planteamientos de pruebas acordes a los diversos ciclos de vida de desarrollo.
(Mapping SW V-model and ISTQB Testing levels)

Así en un ciclo de vida del tipo modelo en V o
secuencial, típicamente buscaremos relacionar
los niveles de construcción con los niveles de
pruebas de componentes, integración, sistema y
aceptación.
Si por el contrario optamos por modelos de
construcción iterativos (o incrementales), como los modelos de desarrollo ágil por
ejemplo, aplicaremos al resultado de cada iteración niveles de pruebas (componentes,
integración, sistema y aceptación) acordes a su tamaño y alcance. La naturaleza
incremental del proceso nos llevará de forma natural a potenciar aspectos como regresión
o automatización a todos los niveles (por pura supervivencia ;).
El modelo de capas de cebolla para los Niveles de Pruebas (según
ISTQB) que hemos elaborado para vosotros permite visualizar el
volumen potencial de cada nivel, su interdependencia y su
criticidad (o sabor).
La capa más externa nos presenta las Pruebas Unitarias. Suelen ser unas pruebas
relativamente pequeñas y numerosas. Se tiende a envolver con ellas buena parte de los
objetos, clases o módulos construidos. Se pueden incluir pruebas funcionales y no
funcionales, lanzándose típicamente con acceso al código en construcción y con el apoyo
de entornos de desarrollo. Suele dar lugar a la detección de defectos que son corregidos
rápidamente por el desarrollador.
El siguiente nivel, Pruebas de Componentes, es muy similar al de Pruebas Unitarias. La
complejidad de los elementos a probar nos marca si existe diferencia entre ellas y el
aislamiento del resto de elementos a probar nos marca la frontera con la siguiente capa.
Llegamos a una capa más sabrosa, el nivel de Pruebas de Integración. Estas pruebas
suelen ser realizadas por el equipo de desarrollo y permiten comprobar que los

componentes del software interactúan correctamente, entre sí y con otras partes del
sistema (como sistemas operativos, sistemas de archivos o hardware). El foco de las
pruebas es la interacción. Saltan las primeras chispas.
Avanzamos, el nivel de Pruebas de Sistema es la siguiente capa de nuestra cebolla. Cosa
seria, algunas lágrimas están casi garantizadas. El comportamiento global del producto
construido hasta el momento será la referencia. que concretaremos en un Plan de
Pruebas para este nivel (si queremos acabar las pruebas algún día). Cualquier aspecto de
interés deberá ser retado: riesgos, requisitos, casos de uso, interacciones,
configuraciones, rendimientos, comentarios del cliente en whatsapp, etc. Además, esta
actividad la suele realizar un equipo de pruebas independiente que, típicamente, utiliza un
entorno de pruebas que sea lo más similar posible al entorno de producción.
¡Ya tenemos un SISTEMA funcionando!
Llega el momento de la verdad. Estamos en el corazón de nuestro modelo y aquí nos
esperan las experiencias más intensas. Toca mirar cara a cara a los usuarios del sistema,
buscamos su confianza. El nivel de Pruebas de Aceptación nos revelará si cumplimos con
sus expectativas, ¿será dulce o amargo este último bocado?
Las habituales implicaciones contractuales derivadas del resultado de las Pruebas de
Aceptación han dado lugar a una amplia variedad de matices en la forma de

materializarlas: pruebas de aceptación de usuario, pruebas de aceptación operativa o
pruebas de cumplimiento regulatorio son algunos ejemplo.
Es más, si se realizan en casa del fabricante se denominan pruebas Alpha (todavía queda
un atisbo de sospecha) mientras que, si son en casa del comprador, se denominan
pruebas Beta (¡por fin!).
Gracias al modelo de Niveles de Pruebas Software presentado,
podemos visualizar cómo organizarnos para llegar hasta la
esencia de toda actividad de fabricación de software, la
satisfacción de las expectativas del cliente[1].
En todo caso, quizás os hayáis preguntado: PERO, ¿cómo se sabe si estamos
construyendo el producto correctamente? (es decir, conforme a sus especificaciones) o
¿estamos satisfaciendo las expectativas del cliente? Estas inquietudes, que nos
acompañan durante todo el ciclo de vida, nos permiten introducir un último concepto:
Los Tipos de Pruebas. ¿Los conocéis?
Algunas referencias interesantes sobre este tema, que hemos consultado, son:
1. Descarga del Syllabus del ISTQB [2] (2011, International Software Testing
Qualification Boards).
2. Espacio web para estudio de la certificación ISTQB. [3]
3. Blog Pruebas del Software, por Javier Zapata S. [4]
4. Herramientas para pruebas software [5] (entre otros) en el blog de Javier
Garzás.
5. Creating the onion model [6], artículo de Mike Clayton.

Referencias
1. Innovación rentable – Masa K Maeda (blog.panel.es)
2. Syllabus del ISTQB (2011, International Software Testing Qualification Boards).
3. Estudio de la certificación ISTQB.
4. Blog Pruebas del Software, por Javier Zapata S.
5. Herramientas para pruebas software (entre otros) en el blog de Javier Garzás.
6. Creating the onion model, artículo de Mike Clayton.
Artículo original: http://blog.panel.es/index.php/software-qa-software-testing-levels-
onion-model/

Capítulo #10
¿Cuánto nos pica un bug?
En aquellos negocios en los que las Tecnologías de la Información son críticas para la
operación, disponer de una medida clara sobre cuánto daño nos ha hecho un problema en
producción es un formidable reto. Si preguntamos a las partes interesadas (los míticos
“stakeholders“), todos coinciden en su importancia pero discrepan drásticamente en su
implementación.
¿Por qué es tan difícil cuantificar el efecto de los problemas
software? ¿Es más difícil establecer el impacto de un error
software que cuantificar cuánto pica una guindilla?
Desde 1912, gracias a Wilbur Scoville y su Examen Organoléptico Scoville, tenemos una
escala que nos permite saber cuánto nos va a picar una guidilla o chile. La medida se
estableció en unidades … Scoville (SHU, del inglés “Scoville Heat Units”) que indicaban
cuántas veces había que diluir el extracto del chile en agua azucarada hasta que era
indetectable por un jurado.

Escala Scoville SHU
En la actualidad se recurre a medir con precisión la cantidad de capsaicina (componente
químico culpable del picor) mediante técnicas de laboratorio: mejora continua. Por cierto,
la capsaicina no es soluble en agua … así que si necesitas aliviar el picor de un chile, mejor
con leche.
¿Y qué pasa con el picor de una incidencia en los sistemas de información?
¿Cómo lo medimos?
Para poder contestar se necesita método, deberemos obtener nuestro “extracto de chile”
equivalente para medir su pungencia.
Así, aplicando prácticas como la Integración Continua de software dispondremos de
mecanismos para establecer relaciones de causa – efecto sobre los comportamientos de
nuestros sistemas TI y podremos alinearlos con los elementos incorporados en la Gestión
de Activos. Nos vamos acercando.
¿Qué nos aporta la Gestión de Activos software? Nos introduce en la dimensión
“economía”. Nos cuantifica el valor aportado por los diversos elementos de configuración,
de forma que podemos establecer cuándo nuestra incidencia queda suficientemente

diluida como para ser indetectable. Si lo queremos ver en términos de dinero, equivale a
compensar el picor reconociendo una pérdida en euros (por ejemplo).
Mientras recorremos este camino, la detección temprana de anomalías es una auténtica
vía rápida hacia el aseguramiento del valor esperado. Por ejemplo, si monitorizamos el
“proceso de registro de nuevos clientes en la tienda online”, el valor añadido de este
sensor emana del beneficio directo generado por este proceso. Os lo contamos con más
detalle en nuestro artículo sobre Sondas automáticas de disponibilidad software.
Estas son las bases que proponemos desde Panel Sistemas para caminar hacia un método
que culmine en una escala estándar de escozor software: las SHU, del inglés “Software
Hurt Units”
Scoville nos demostró hace mucho tiempo que si se quiere, se puede medir. Inciativas
como el proyecto europeo Iceberg, participado por Deiser, son un clara señal de que se
quiere y se puede. Nuestra particular contribución en este ámbito de la Calidad Software
está publicada en forma de estudio para el cálculo del retorno de la inversión en pruebas
software (“ROI on Testing Investment”).
Para terminar, si en vuestra empresa habéis conseguido consolidar una escala (que no
sea el número de llamadas en el Centro de Atención a Usuarios o los decibelios de los
gritos del área de Operaciones) os animo a compartirlo con todos nosotros, porque …
… ¿Cuánto os pica un bug?
Referencias
Artículo original: http://blog.panel.es/index.php/softwareqa-cuanto-nos-pica-un-bug/

Capítulo #11
Aplicar Agile Testing en proyectos grandes y
complejos
En este artículo compartimos nuestras conclusiones para la aplicación de prácticas Agile
Testing en grandes proyectos. Agile Testing es un sabor más de los fundamentos de la
filosofía Agile, en el que la esencia de las funciones de Testing no cambia; sólo los
métodos y roles para lograr un mismo objetivo: contribuir a asegurar la calidad desde el
inicio.
Según su definición, el Agile Testing involucra a todo el equipo de desarrollo ágil de forma
temprana, continua y sostenible. Se trabaja con una perspectiva de aportar calidad (valor)
desde el principio, probando y analizando código (o especificaciones) desde que están
disponibles y suficientemente estables.
Así, nuestra interpretación de algunos de los principios del Manifiesto Ágil (“Agile
Manifesto”, 2001) para escenarios de Certificación y Testing clásico es:

Los cambios en los requerimientos no son excepcionales.
Entrega temprana y continua de Software con valor.
La comunicación directa es la forma más efectiva.
El Cliente está integrado en el equipo de delivery.
Ciclos de vida de los entregables cortos.
Aproximación al producto final por iteración.
Sin embargo, una de las principales críticas que se hacen a las prácticas Agile Testing es
que no son aplicables en proyectos grandes o complejos (o que no producen los mismos
resultados). Por ejemplo, en entornos tradicionales, el grupo de Testing suele ser una
unidad independiente dentro del ciclo de vida, tanto en función como en dependencia
organizativa. Por contra, una concepción orientada a Agile Testing requiere una mayor
integración de las pruebas en las fases de Desarrollo, con serios retos de cultura y
organización en la composición de equipos de trabajo grandes o con roles pre-
establecidos.
Es por ello que para proyectos de desarrollo de software complejos y con cierto peso de
los inevitables sistemas legacy, se está consolidando el recurrir a metodologías
enriquecidas mediante la adaptación de prácticas Agile.
En particular destacamos el esfuerzo de Ericsson AB con Streamline Development (SD)
(libro, 2007), una metodología iterativa en la que los requisitos se establecen bajo un
modelo de matriz de taxonomías o de anatomías, junto con la premisa de que todos los
equipos tienen responsabilidad end to end en el proyecto … ambicioso sin duda. O como
la que nos recomendaba Javier Garzás en este artículo del 2012: Feature Driven
Development (FDD), una meta-metodología que incluye también un ciclo de vida iterativo
e incremental como Scrum, pero orientada a equipos grandes, que contempla por
ejemplo la figura del jefe de proyecto y una fase de arquitectura.
Esta deriva quedó patente durante las sesiones de la ” IX Semana del CMMi y la Mejora
de la Calidad TIC”, organizadas por Caelum y que podéis consultar en este brillante
resumen: “Algo pasa con CMMi…”

En cualquier caso, antes de incorporar prácticas de Agile Testing en nuestro proyecto, hay
que cuidar algunos aspectos habitualmente ya delicados en un proceso de desarrollo y
pruebas tradicional (secuencial):
Eliminar ambigüedades y clarificar suposiciones en los requisitos, de forma
recurrente y permanente. Como al volumen de requisitos sumamos la mayor
velocidad en la entrega de valor, se requerirá de un gran esmero en su gestión
para no alimentar la tendencia a generar deuda técnica de estos proyectos.
Apoyar al usuario en la formulación de los tests de Aceptación, contribuyendo
en lo posible a descubrir requerimientos nuevos, desde el conocimiento
funcional de los equipos de Pruebas. (¿He oído conversación BDD?)
Dar más apoyo a Desarrollo en la definición, localización y cierre de una
incidencia.
Cuidar los ratios de automatización, especialmente en las regresiones. Con las
pruebas de regresión buscamos asegurar calidad y precisión sobre el
comportamiento del sistema. En particular, recomendamos automatizar las
pruebas de aceptación que aseguren al cliente las funcionalidades clave
deseadas.
Consideramos un factor clave de éxito en Agile Testing saber
ecualizar el esfuerzo en automatización de pruebas.
Visualmente podemos recurrir, por ejemplo, a los cuadrantes de Agile Testing para
ayudarnos a definir nuestras estrategias de pruebas.

Agile Testing Quadrants
Sin embargo, no todo es tan fácil. En @PanelSistemas sabemos por
experiencia que existen algunos factores de riesgo que es necesario mimar en la
aplicación de este tipo de metodologías sobre grandes sistemas:
Gestión de la anatomía de requisitos. Conviene prestar especial cuidado a la
definición detallada de la matriz de requisitos cuando se necesita establecer
interdependencias entre componentes o subsistemas.
Estabilidad de requisitos. Un clásico. Al manejarse un mayor volumen de
requisitos es más complejo controlar el alcance de los cambios y su gestión.
Además, en proyectos de larga duración (meses/años), acompasar los ciclos de
requisios adquiere carácter crítico.
Visión global de la Arquitectura. Aplicando ciclos iterativos debemos velar por
asegurar el alineamiento con la visión global de la funcionalidad y de la
arquitectura del sistema. Si se pierde la visión integrada del sistema, se
incrementa el riesgo de carencias de arquitectura.
Peso de los Legacy. Suele ser complejo aplicar ciertas prácticas Ágiles, como la
Integración Continua (IC), en los sistemas heredados (“Legacy”) con los que
deben convivir estos proyectos. Por tanto, deberemos controlar la proporción
de sistemas Legacy para poder aspirar a mantener un ritmo sostenible de Agile

Testing.
Valor de los Planes de Prueba. Si llegaran a combinarse los riesgos de requisitos
(tanto en anatomía como en estabildiad), los riesgos de visión integrada del
sistema o carencias de Arquitectura y un alto peso de los sistemas Legacy, la
conclusión más directa es que tendremos graves problemas en la definición de
los Planes de Prueba y la predictibilidad de sus resultados. Trabajemos primero
en paliar estos riesgos.
“Si hay que probar, se prueba. Pero, probar ‘pa ná’ es
tontería".
Priorización de la actividad. Los beneficios de establecer una organización con
un fuerte foco en la visión extremo a extremo (“e2e”) conllevan una intensidad
equivalente en la gestión de prioridades y expectativas. En caso contrario es
fácil caer en dinámicas en las que todo pasa a ser urgente, todo el mundo está
muy ocupado y el valor añadido pasa a negativo (¡Sí! ¡Desperdicio!).
Gestión de equipos. Al potenciar la versatilidad de los equipos, fomentando
“células autogestionadas” de tamaño reducido, hemos constatado que la
rotación de personas es un riesgo con un alcance potencial más delicado que en
una visión tradicional.
Automatizar es necesario. En automatización -en general- el riesgo principal
nace de una inadecuada estrategia. Incorporar prácticas de Agile Testing
conduce de forma natural a no cuestionarse la necesidad de automatizar
(pruebas). Sin embargo, una estrategia de pruebas equivocada puede llevarnos
a escenarios en los que el esfuerzo de mantenimiento de las pruebas sea
excesivo, arriesgando así el retorno de esta inversión (ROI).
Elegir adecuadamente los niveles de pruebas sobre los que se
invierte en automatización de pruebas es determinante.
“Por favor, no realicen esta actividad en sus casas,

llamen a un profesional.”
En cualquier caso, como señala Rubén González en el blog Think Big, “...en otros casos,
los métodos ágiles pueden servir de guía. Pero siempre que se apliquen de una forma
explícita, se deberían adaptar de acuerdo a los skills y a la naturaleza del equipo, y nunca
forzarlos de forma imperativa. Muchas veces se aplican métodos y prácticas ágiles
religiosamente, perdiendo de vista lo que es verdaderamente importante: llevar a cabo
una gestión adaptativa de la incertidumbre inherente al desarrollo de software, sea con
un método o sin él.”
No podemos estar más de acuerdo con esta afirmación :-).
En este artículo hemos intentado compartir con vosotros conclusiones relevantes de
nuestra experiencia en la aplicación de prácticas Agile Testing en grandes proyectos,
aunque sabemos que el tratamiento no ha sido exhaustivo. No os quepa duda, nuestros
expertos del Centro de Excelencia en SQA & Testing ya se han encargado de puntualizar:
“es un tema muy extenso (toca gestión de requerimientos, gestión de incertidumbre,
organización de equipos, estrategia de automatización, gestión de reporte, gestión de
prioridades, visión E2E, etcétera) como para comprimirlo en tan pocas palabras”.
Tenemos el compromiso de redimir esta deuda (¡a OGMA pongo por testigo…!).
Para terminar, ¿no os habéis preguntado dónde estará el Agile Test Manifesto? Estar
está, pero ¡en revisión!
Referencias
Artículo original: http://blog.panel.es/index.php/aplicar-agile-testing-en-proyectos-
grandes-y-complejos/

Capítulo #12
Razones para practicar la Integración Continua
El objetivo de los equipos de desarrollo actuales es planificar, codificar, probar y entregar
una pieza de software utilizable cada dos o tres semanas. Para conseguirlo,
automatizamos buena parte del proceso software mediante la Integración Continua (IC),
de manera que el equipo pueda repetir la entrega de código de forma iterativa, pero
descargando el trabajo pesado en un servidor de Integración Continua (“CI server”). Así es
como conseguimos entregar los grandes proyectos de desarrollo software.

El servidor de Integración Continua automatiza diversos pasos en el ciclo de vida del
software. No puede ayudarnos con los requistos de negocio o diseño, pero sí puede
encargarse del empaquetado, despliegue, inspección y pruebas software automáticas. Y
lo hace de forma incansable, sistemática, robusta y barata.
Al automatizar parte del proceso de producción de software, la
Integración Continua contribuye definitivamente a acelerar el
tiempo para llegar al mercado (“time-to-market”) en las
organizaciones basadas en Tecnologías de la Información (TI).
¿Cuáles son las organizaciones basadas en Tecnologías de la Información? Son aquellos
negocios en los que las Tecnologías de la Información son críticas para la operación.
Bancos, empresas de paquetería o canales de venta basados en Internet, por ejemplo,
están basados en TI. Mejorar sus cañerias TI significa mejorar sus comunicaciones
internas, su estrategia de marketing y sus costes de producción. Es decir, son compañías
que consiguen ventajas competitivas con el uso de la tecnología, sin que sea excluyente
el que vendan o no tecnología.
Gracias al impulso de iniciativas como Agile o eXtreme Programming, entre otras, los
servidores de Integración Continua disponibles son numerosos: Bamboo, CruiseControl,

Jenkins, Team Foundation Server o Solano por ejemplo.
Sin embargo, aplicar Integración Continua (IC) es un proceso doloroso y exigente que
requiere un CAMBIO EN LA CULTURA de construcción de software. Con constancia
finalmente conseguiremos reducir los tiempos de empaquetado, aumentar el número de
versiones en paralelo y la robustez de las entregas.
Bien, va a doler. Pero , ¿en qué podemos ayudarte?
En primera instancia toca verificar la Cultura del equipo de desarrollo.
Habitualmente es necesario generar un proceso de adaptación, de
enriquecimiento, en que se minimice la resistencia al cambio gracias a un
enfoque de mejora paulatina, basada en principios Lean.
Aplicando definición temprana.
Asegurando los canales de comunicación.
También trabajaremos en definir los Procesos que permitirán maximizar el
rendimiento obtenido:
Estableciendo las líneas de automatización.
Determinando las “causas” a controlar.
Definiendo políticas de ejecución.
Implementando los Radiadores de información (indicadores de
medición).
Por último, utilizar la suite de Herramientas más adecuada entre las distintas
alternativas tecnológicas será nuestra contribución final.

Integración Continua en el Antiguo Egipto
La Integración Continua es un medio, no un fin.
El objetivo sigue siendo maximizar el valor entregado.
Un espacio de reflexión interesante nos lo proporciona la frecuencia. Aunque hablamos de
Integración C-o-n-t-i-n-u-a, no se trata de una práctica que fuerce a un proceso de
integración diario. La frecuencia es una cuestión que está abierta y que deberá quedar
definida conforme a los objetivos que se quieran alcanzar. Por ello, en la Integración
Continua, el ritmo lo marcan las relaciones “Causa -> Efecto” a controlar.
No podemos terminar sin recopilar las razones, en forma de beneficios, que motivan la
aplicación de esta exigente práctica de la Ingeniería Software:
1. Reducción de riesgos tecnológicos gracias a un proceso de construcción
predecible, retroalimentado y transparente. Así, por ejemplo, podremos
predecir el tiempo de integración dado que es algo que se realiza de forma
continua.
2. Minimizar las anomalías en el producto final gracias al “feedback” temprano.
Al realizar pruebas automáticas frecuentes habilitamos una pronta detección y

corrección de anomalías.
3. Calidad desde el inicio y adaptación al cambio. Como es posible disponer de un
entorno de demostración con cualquier versión de la aplicación, es viable
mostrar los últimos cambios de forma frecuente. Así, buscamos la aceptación
por parte de los usuarios de las nuevas características añadidas al proyecto y
devolvemos información al equipo de trabajo rápidamente.
4. Responsabilidad y visibilidad. El ciclo de vida del producto software se vuelve
explícito, común, independiente y público. Así, todo el equipo dispone de
información precisa sobre el estado real del proyecto, lo que aligera las tareas
de seguimiento, fomenta el sentimiento de propiedad colectiva del código y
garantiza la transparencia del proceso.
Sin duda, un viaje intenso hacia un mundo maravilloso en el que deleitarnos observando
manadas de hermosos unicornios …
¡Vaya! ¡Un Unicornio Bug!
… ¿Será posible?
Referencias
Artículo original: http://blog.panel.es/index.php/software-qa-razones-para-practicar-la-
integracion-continua/

Capítulo #13
Software QA - DevOps: hacia la calidad continua
del software
DevOps representa un avance para la ingeniería de software equiparable a la aportación
del continuo espacio-tiempo en la física. Siendo el espacio-tiempo[1] “el modelo
matemático que combina el espacio y el tiempo en un único continuo como dos conceptos
inseparablemente relacionados”, podemos parafrasear para DevOps:
DevOps es el modelo informático que combina el desarrollo y la
operación del software en un único continuo como dos conceptos
inseparablemente relacionados.
¡Olé!. Este neologismo proviene de agrupar en un acrónimo los términos ingleses
Development (Desarrollo) y Operations (Operaciones).
Para seguir con el recorrido desde la física clásica de Newton a la física cuántica de
Einstein, partiremos de la concepción clásica de equipos de desarrollo de software

(centrados en la construcción) y de equipos de operaciones (centrados en la explotación
de los sistemas informáticos en producción) aislados entre sí. A continuación, nos
plantearemos incluir el tratamiento del tiempo como una dimensión más.
Así llegamos a la necesidad de considerar unificadamente la actividad de todos
los equipos de trabajo y el tiempo, ya que la diferencia entre componentes informáticos
(Hw/Sw) y temporales es relativa según el estado de movimiento del observador (cliente,
negocio, PMO, …).
DevOps = Dev + Ops²
La omnipresente presión por acelerar la obtención de resultados lleva de forma natural a
plantear procesos de trabajo ágiles y continuos: planificación, medición, desarrollo,
pruebas, despliegue, ejecución, operación, supervisión y optimización continuos.
Afortunadamente, ahora es viable plantear metodologías de desarrollo estandarizadas,
procesos de comunicación y documentación claros junto con plataformas probadas y
basadas en estándares, lo que contribuye a agilizar los ciclos de gestión y desarrollo de las
aplicaciones. Además, con ello se sustenta una mayor disponibilidad y seguridad de la
infraestructura IT.

En el lado práctico de la vida, DevOps va de conectar personas,
productos y procesos.
En definitiva, estamos hablando de conectar tecnología, negocio
y valor entregado.
En resumen, mediante la aplicación de los principios “lean” y “agile”[2] en el ciclo de vida
de entrega continua de producto se consigue cimentar la agilidad del negocio y el
alineamiento de las Tecnologías de la Información (TI). Sobre esta base podremos
acelerar el “Time-to-Market” (tiempo de comercialización), disparar nuestra capacidad de
innovación y ofrecer una experiencia de cliente diferenciada.
La actividad en torno a DevOps es frenética. Los fabricantes de herramientas de nicho
(los creadores de VirtualBox, Puppet[3], Vagrant o Ansible[4], por ejemplo) están siendo
asediados por los grandes fabricantes (IBM, HP, Oracle) en su ánimo de prevalecer como
suministradores predominantes.
Si queréis ampliar información, nuestras recomendaciones son:
La explicación (en inglés) de la gente de NewRelic sobre DevOps [5] está bien
estructurada y presentada.
Participar en el notable grupo Madrid DevOps [6], didáctico, ameno y abierto a
todos.
La serie de artículos sobre Puppet [7] (en español) de David Fernández ofrece
una rápida visión global (aunque son del 2010).
NewRelic DevOps toolset [8]: Extenso compendio de herramientas
categorizadas.
Completo Trabajo Fin de Grado de la UNIR: (pdf) “Mejores prácticas de
despliegue continuo para aplicaciones Symfony2ʺ [9] de Fernando Arconada
Orostegui.
Como ejemplo de la fuerte reacción de los fabricantes grandes, os propongo:
IBM DevOps [10].

Vale, vale … también la entrada en inglés de la Wikipedia para DevOps[11] (justita, pero
su “DevOps (a portmanteau of development and operations)” es ya un clásico en
internet).
En @PanelSistemas seguimos pugnando por entregar productos software de calidad de
forma continua, por ello creemos que DevOps es el eslabón perdido en la cadena de
entrega de valor mediante la fabricación de software[12].
Referencias
1. Espacio-tiempo Einstein (es.wikipedia.org)
2. Innovación rentable – Masa K Maeda (blog.panel.es)
3. Puppet Labs (puppetlabs.com)
4. Ansible (www.ansible.com)
5. NewRelic sobre DevOps
6. Grupo Madrid DevOps
7. Serie de artículos sobre Puppet
8. NewRelic DevOps toolset
9. Mejores prácticas de despliegue continuo para aplicaciones Symfony2
10. IBM DevOps
11. DevOps Wikipedia (en.wikipedia.org)
12. Calidad software: fabricación ecoLógica (blog.panel.es)
Artículo original: http://blog.panel.es/index.php/software-qa-devops-hacia-la-calidad-
continua-del-software/

Capítulo #14
¿Qué es DevOps 101?
Tras el enigmático título de “DevOps 101“, Antonio Peña del grupo de Madrid DevOps
nos motivó para vencer el magnetismo fácil de las herramientas, conectándonos con el
mejor superconductor: la cultura.
La sesión la planteó como iniciática, a imagen de los cursos introductorios americanos, los
“101”. Así, buscando las bases, se hizo incidencia en la importancia de formarse una
opinión propia. ¿Cómo? conociendo el punto de vista de técnicos de referencia como Seth
Vargo o Katherine Daniels y probando, haciendo, compartiendo.
Diversas voces alertan del riesgo que supone convertir DevOps en un “palabro de
moda”, perdiendo su esencia por intentar consolidar su oportunidad de ocupar un sitio en
el olimpo de la tecnología y, sobre todo, en el pastel comercial. Comparto la
recomendación de Antonio por el artículo de Baron Schwartz: “The DevOps identity
crisis” y por el vídeo de Katherine: “DevOps Is Dead (Long Live DevOps)” (20 min., inglés)
DevOpsDays Minneapolis 2014 — Katherine Daniels, DevOps Is Dead (Long Live
DevOps) from devopsdays on Vimeo.

Todavía la comunidad interesada es informal, sin líderes claros, metodologías o credos.
Como dice Baron Schwartz en la entradilla de su artículo: “El por qué DevOps necesita un
manifesto después de todo, aunque puede que nunca lo consiga”.
Por ejemplo, Seth ha optado por escribir una lista con 10 mitos sobre DevOps, os copio el
décimo:
“Myth #10 – DevOps is just a fad like “Agile” or “mainframes”
Unlike Agile or mainframes, DevOps is not a development
methodology or technology; DevOps is an ideology. Is it a way to
facilitate organizational prosperity and growth while increasing
each individual employee’s happiness along the way. I do not
know about you, but that sounds pretty sweet to me. I hope
DevOps is not a fad.”
Por su parte, Katherine insiste en la importancia de la empatía y la responsabilidad como
motores, en la importancia de conseguir resultados y en la necesidad de subyugar las
herramientas a la cultura de la Calidad Software. Aboga por la evolución antes que la
revolución.
Pero no hay que irse tan lejos. En el turno de preguntas, la gente de Tuenti (¡qué gran
anfitrión!) nos contó su periplo hasta conseguir que la actividad de DevOps forme parte
natural del proceso de creación de producto, de entrega de valor. Tras dos años y medio,
ahora no necesitan “ponerse a hacer DevOps“. Lo han conseguido dando pasos
pequeños, con pequeñas victorias y pequeñas derrotas. ¿Su clave? “Nuestra clave ha
sido tener un equipo dedicado a crear la cultura y suministrar/facilitar las herramientas
para el despliegue de su trabajo (enablers) a los equipos de producto. Que cada equipo de
desarrollo afronte el despliegue por su cuenta y con sus mecanismos es muy ineficiente“.
Gracias.

Entonces, ¿qué es DevOps? ¿Y tú me lo preguntas? DevOps … eres tú … y tú, y tú.
Hablamos de comunicarse y colaborar por un objetivo común, de
compartir la cultura de primar el valor al cliente, de aplicar
empatía y responsabilidad, de romper los silos funcionales
(también conocidos como nidos de excusas), de preservar la
rentabilidad de las compañías, de hablar sin esconder los
problemas … para buscar soluciones.
Finalmente, queremos agradecer a los esforzados organizadores del grupo Madrid
DevOps su tenacidad y a Antonio, en particular, su firme convicción en enriquecerse
compartiendo :-). Podéis consultar su presentación de apoyo en esta sesión en
Madriddevops-january-2015-meeting.
¿DevOps es tu tesoro o el de todos?
Referencias
Artículo original: http://blog.panel.es/index.php/software-qa-que-es-devops-101/

Capítulo #15
¿Cómo probar aplicando Entrega Continua?
Diseccionar las exigencias de la Entrega Continua de software utilizando el Testing como
certero bisturí es el reto al que se enfrentó Peter Marshall en su sesión sobre “Continuous
Delivery, Testing challenges”. Este es nuestro resumen y conclusiones, sin duda, un gran
acierto del grupo de QA y Testing de software de Madrid, nuevamente.
“Continuous Delivery is about building Quality in !!”
La Entrega Continua es una de las prácticas de ingeniería software más exigentes,
podemos decir que está situada cerca de la cúspide en la pirámide trófica del software.

MadridQA_Continuous_Delivery_Start_n
¿Qué retos plantea para el testing la Entrega Continua?
La velocidad en la entrega. ¿Cómo hacemos para probarlo todo?
Enfatizamos la automatización. Tenemos procesos manuales ¿quién se
encarga de toda esa automatización?
¿Cómo hacemos las pruebas de regresión?
El punto de partida
El punto de partida que nos presenta es el clásico gran proyecto (cientos de personas,
decenas de equipos, meses de trabajo hasta La Entrega) sometido a la presión de
construir un nuevo producto de referencia.
Algunos de los problemas que debían resolver desde el punto de vista de las pruebas
eran:
La mayor parte del equipo de pruebas tenía sus bases en el desarrollo sofware
tradicional.
Cada equipo de pruebas, en cada fase, tenía que volver a analizar los

requisitos, ¡y así para 9 fases!
La configuración en cada entorno de pruebas era diferente.
Los gestores del equipo de pruebas se oponían al cambio.
Bucles de retroalimentación entre desarrollo y pruebas muy, muy largos.
“Very long feedback loops between dev. and test”
En su conjunto la organización estaba haciendo un esfuerzo enorme para cambiar de
cultura: de “gestionar muchas cosas simultáneamente” a “gestionar solo unas pocas
cosas a la vez“. No sin pelea (ni sangre).
Durante más de un año la lucha estuvo igualada. Desde los primeros intentos de buscar
ciclos de producción semanales (incluyendo Aceptación ¡guau!), finalmente se llegó al
consenso en ciclos de 4 semanas, pasando primero por pruebas de Integración y
Funcionales para acabar en las pruebas de Aceptación.
¡Duro con ello!
Pude intuir a Peter en plena acción: “esquiva,
baila, esquiva, derecha, gancho, cubre, esquiva,
¡abraza!“
¿Cómo conseguir el cambio?
Su receta para esta pelea es rocosa: enfoque en el equipo como conjunto (“Whole team
approach”):
Reduciendo el número de funcionalidades que se mueven por el proceso de

entrega.
Incluyendo en cada entrega (“build process”) tantas pruebas como sea posible.
Sacando a los probadores (“tester”) de pensar solo en documentación y casos
de prueba para elevar su perspectiva hacia el producto, siguiendo los principios
del “Context driven testing“.
Adelantando al máximo las fases de pruebas previstas para después de la
entrega.
Implicando a todo el equipo en las pruebas, todos pueden aportar ¡Organiza
una buena piñata de bugs! (“Bug bash“).
Invirtiendo intensamente en gestión de la configuración y provisión de entornos
(en su caso: Docker).
Acercando a los responsables del negocio a los equipos (¡hacer piña!).
Formación y entrenamiento en pensamiento Agile e ingeniería Lean.
Para convencer a los más reticentes les tocó tirar de educación, demostración y talleres
con grandes refentes del sector (Mark Collin, David Farley, Steve Smith y Tony Bruce), de
lujo. Pero, sobre todo, fue determinante el conseguir un firme respaldo por parte de la
dirección.
¿Cuál fue el resultado?
¡Éxito! Sin duda, tras 18 meses de transformación, reajustes de equipos/procesos y
“pruebas de vida”. Así nos resume el proyecto:
Hemos cambiado la cultura.
Hemos cambiado la percepción de lo que significa probar.
Hemos minimizado las pruebas tradicionales (diseño y ejecución de casos de
prueba). Con ello hemos disminuido el tamaño de los equipos de prueba,
reforzando los equipos de desarrollo.
Hemos implicado responsablemente en la calidad del resultado a todo el
mundo.
Funcionamos como un equipo, en lugar de como un conjunto de silos

distribuidos por la organización.
Los números cantan: software en producción cada 4 semanas, mayor productividad del
equipo y un importante descenso en los errores críticos (nos dió el dato exacto). Es decir,
entrega satisfactoria del valor esperado.
En suma:
Quality is the responsability of everybody!!
Fin de fiesta
La sesión se cerró con un divertido concurso, un interesante debate y un excelente
“networking”.
Os destaco:
Nos llevó 18 meses conseguir el equilibrio y el compromiso de todos. Sigue
funcionando.
¿Habéis aplicado Scrum o Kanban? De todo. Lo más importante es que todo

tiene que ser alcanzable en el ciclo. Hemos usado muy diversos ciclos.
Tener equipos multidisciplinares (“crossfunctional”) ha sido determinante para
poder involucrar a todos en diversos papeles.
Entrega continua es pruebas de regresión, lo lleva implícito.
¿Qué hacía el equipo de testers tras los ajustes? Hacían testing, siempre se
necesita que un ser humano interactue con la aplicacion.
Si queréis saber algo más sobre Peter, estas son sus coordenadas: @petemar5hall y Lean
Software Servicies (cuando publique esta presentación, la incluiremos encantados).
¿Alguien da más? ¡Claro! ¡ El Blog de @PanelSistemas !
Referencias
Artículo original: http://blog.panel.es/index.php/madqa-como-probar-aplicando-entrega-
continua/

Capítulo #16
Estrategias de integración entre productos
software
Pain or Gain?
La integración entre productos o aplicaciones software es un aspecto determinante sobre
su futuro y utilidad. Gracias a la integración podremos extender la funcionalidad
disponible, acceder a información nativa de otros sistemas e, incluso, aspirar a la
eternidad (o casi :-).
Las técnicas que podemos utilizar para solucionar nuestras necesidades de conexión entre
aplicaciones son conocidas y numerosas, sin embargo, resulta crítico elegir
adecuadamente la ESTRATEGIA de INTEGRACIÓN sobre la que apoyaremos nuestros
esfuerzos.
Capitulo #16 - Estrategias de integración entre productos software

Multitud de conexiones
Dado el estado de cambio permanente que caracteriza a los
sistemas informáticos, las actividades de integración entre
aplicaciones software pueden ser un auténtico pozo sin fondo.
Para el análisis de esta toma de decisión (DAR en términos CMMI) encontraremos
condicionantes relacionados con exigencias en cuanto a prestaciones, facilidades para
nuevas integraciones o portabilidad, por ejemplo. Como orientación, a continuación
resumimos las principales cuestiones a considerar:
Conexiones una a una: Para cada pareja de aplicaciones defino e implemento
una forma de conectarlas.
Conexiones mediante servicios de mensajes: Cada aplicación se conecta a los
canales de comunicación que le interesan e interactúa con ellos (lee / escribe).
Los conocemos como “Bus de integración” o “Bus de servicios de empresa”.
Conexiones en una sola dirección (la información solo se propaga de la
aplicación Origen a la aplicación Destino) frente a conexiones bidirecciones
(información de ida y vuelta).

El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à El manual de la calidad software - Panel Ssistemas - 2ªedicion2015

Similaire à El manual de la calidad software - Panel Ssistemas - 2ªedicion2015 (20)

Dernier

Dernier (20)

El manual de la calidad software - Panel Ssistemas - 2ªedicion2015