Título: La Calidad como estilo de vida

© 2018, Víctor Gómez Adán

© De los textos: Víctor Gómez Adán

© Ilustración de portada: Víctor Gómez Adán

2ª edición – N/A

Reservados todos los derechos. No se permite la reproducción total o parcial de

esta obra, ni su incorporación a un sistema informático, ni su transmisión en cualquier
forma o por cualquier medio (electrónico, mecánico, fotocopia, grabación u otros) sin
autorización previa y por escrito de los titulares del copyright. La infracción de dichos
derechos puede constituir un delito contra la propiedad intelectual.

2
A Daniel. No sabía que esa sonrisa, un beso y un abrazo pudiera ser la causa de la
felicidad infinita.

3
 ÍNDICE
1. Nociones básicas de la Calidad del Software
2. La esencia del Testing de manera rápida y breve.
3. Los módulos de HP Quality Center
4. El tester no es un desarrollador
5. La importancia de las pruebas de compatibilidad en dispositivos
móviles
6. La regla del Sprint +1 y el Testing Ágil.
7. Siempre es mejor la calidad que la cantidad
8. El Testing y su importancia en nuestras vidas.
9. El flujo de los defectos
10. El Testing no es solo cosa de Testers
11. Testing exploratorio en entornos hostiles de desarrollo.
12. Monitorizar una aplicación en Microsoft Azure
13. Desarrollo y Testing ágil
14. Habilitar los registros de diagnóstico de Azure
15. Pruebas de compatibilidad en diferentes navegadores con Coded UI
16. ¿Funciona realmente el Test-driven development (TDD)?
17. Apostar por Testing, garantía de futuro.
18. La importancia del otro Testing
19. Cuando el tester es transversal
20. Pruebas de carga sobre una aplicación web en Azure
21. Cuando el tester tiene la razón.
22. La importancia de un entorno estable de Testing
23. Diferencia entre falso positivo y falso negativo.
24. Utilizar Firebug para facilitar la vida del tester
25. Mejorar nuestro trabajo con un procedimiento de Testing
26. Automatizando lo automatizable
27. Dando valor a la batería de pruebas de regresión.
28. Pruebas exploratorias, antes que nada.
29. Repartir el trabajo de una manera eficiente.
30. El error de no pensar en el Testing
31. ¿Cómo reportas tus defectos?
32. Prestando nuestros casos de prueba
33. ¿Usamos correctamente el nombre de proceso de desarrollo?
34. Introducción al Testing metódico con Microsoft Test manager.
35. Especializarse o morir.
36. Utilizando las etiquetas de TFS y Test Manager 2013

4
 37. Planificando el sprint del equipo de Testing
38. La Calidad empieza en nosotros mismos
39. Introduciendo una regresión en todos los ciclos de desarrollo
40. Entrenando los sentidos con una metodología exploratoria
41. El peligro de no dimensionar bien el equipo de Testing
42. Realizando el Daily meeting con TFS
43. Cuando la cabeza no da para más.
44. Cuando la Juventud es un “problema”
45. Testing con TFS vol.1: Sacando partido al panel principal de TFS del
equipo.
46. Educar al equipo para que sea auto gestionable.
47. Ayudando a reconducir el camino de las empresas
48. Realización de una regresión en Producción
49. El equipo de trabajo en los meses de verano
50. Mi gran amigo DEV
51. El tablón como apoyo a nuestro trabajo
52. Automatizar con CodedUI
53. Pruebas de portabilidad
54. Cada día somos más exigentes
55. Pruebas en dispositivos móviles
56. Rotar en un equipo de trabajo
57. La dificultad de validar desarrollos externos
58. Pruebas en Responsive web Design
59. Pruebas con mapas de calor
60. Pruebas funcionales de SEO para web
61. Automatización con Selenium
62. Pruebas de interoperabilidad
63. Pruebas de Internacionalización de software
64. Habitualmente...
65. Nos crecen los enanos
66. Pruebas de Stress
67. Herramientas para el control de la calidad
68. El oficio de repartir felicidad
69. Split Testing
70. La importancia de las pruebas de aceptación
71. Cuatro tipos de pruebas básicas en el mundo del Testing
72. Pasos básicos para dar de alta un defecto
73. Introducción al aseguramiento de la calidad del software
74. ¿Se puede establecer un método para asegurar la calidad?
75. Los eslabones de la cadena

5
76. Implementando procesos organizativos en los proyectos
77. La teoría del Taylorismo
78. Alcatraz o como evitar las fugas de talento
79. A veces me siento como Alberto Chicote
80. Jira con Testlink y de aperitivo Sonarqube

6
 1. Nociones básicas de la Calidad del Software
La calidad del software es un todo en el ciclo de vida del mismo, sin ella no tendríamos
posibilidad de llevar a cabo muchas funciones básicas que hoy vemos como normales
pagar con la tarjeta de crédito en una tienda, por ejemplo.

Siempre que hablamos de calidad del software, hablamos de eficiencia, fiabilidad,

mantenibilidad, usabilidad, integridad y sobre todo de seguridad.

La calidad del software, para muchos de nosotros, es totalmente medible, siempre

variable y dependiente. No es lo mismo un software que se va a ejecutar una vez, que,
si se va a ejecutar a diario, varias veces, todo depende del tiempo de explotación.

Lo más importante es que el control de la calidad ha de llevarse a cabo durante todo

el ciclo de vida del software, tanto al principio, como una vez desarrollado y puesto en
producción.

Para obtener una calidad excelente, hay que utilizar algún tipo de metodología, de
las que podemos destacar, “Agile” o “Cascada”. De esta manera, podemos realizar un
control uniforme y estándar de lo que vamos a probar. Estas metodologías engloban el
análisis, la construcción de las pruebas, la verificación y al final la ejecución.

Así logramos un aumento de la productividad y así poder sacar el mayor rendimiento

a la hora de que el software tenga una calidad óptima.

Una vez que obtenemos una calidad excelente y la controlamos, tenemos que definir
unos parámetros de medición de la misma, sin esto perderemos el control.

Para definir el software que va a ser controlado hay que seleccionar una medida que
pueda ser aplicada al objeto de control, para cada software es necesario definir los
indicadores y sus magnitudes. Estas medidas pueden ser realizadas de manera manual
o con herramientas que nos ayuden a ello, como los Diagramas de Ishikawa.

Una vez que cumplamos estos requisitos comenzaremos a tener claro que es la
Calidad del software, cómo llevarla a cabo y cómo hacer que un software suba a
producción de manera óptima y sin errores.

2. La esencia del Testing de manera rápida y breve.

¿Qué es para mí el Testing?
Pues muy sencillo, para mí el Testing es una forma de vida. Una manera de que todos
vosotros utilicéis programas, aplicaciones o juegos de forma correcta, sin errores y que,
sin daros cuenta, sigáis con vuestras vidas normalmente sin percataros de pequeñas
cosas que podrían acabar con esta normalidad.

Gestos tan sencillos como acceder a vuestro banco desde vuestro móvil, a consultar
vuestro saldo, mientras vais en el autobús y que no pase nada, es un pequeño hecho
cotidiano que tiene un excelente trabajo detrás por los profesionales que nos dedicamos
al Testing.

7
 ¿Te imaginas hacer una transferencia a tu cuenta de ahorro y que ese dinero jamás
llegue a su destino o que quieras acceder a tu correo electrónico y el botón para hacer
login no funcione?

El Testing es la manera de confirmar que un software llega a tus manos 100%

funcional, 100% sin defectos y 100% seguro.

¿Qué pasos hay que seguir?

Para ello se realiza un proceso de trabajo complejo que empieza con la definición,
revisión y entendimiento de los requisitos (o historias de usuario en Agile, del que ya
hablaremos más adelante). Este paso continúa con la elaboración de unos complejos
casos de prueba que darán vida a nuestro trabajo y donde quedará constancia de los
pasos que hay que dar para probar toda esa funcionalidad descrita en el requisito.

Una vez que se han finalizado y aceptado, tenemos una batería de pruebas y
comenzará el verdadero Testing.

¡VAMOS A PROBAR!
Siguiendo los casos de prueba descritos, en los que nos hemos asegurado al 100% de
que están cubriendo todas las variantes y caminos que cumple esa funcionalidad,
comenzamos a realizar las pruebas en el software, completando paso a paso el caso
descrito y revisando todo en busca de errores.

El trabajo ahora se ramifica en dos, si no encontramos defectos, daremos el caso de

prueba como OK y adjuntaremos una captura de pantalla o una descripción del porqué
de ese OK por nuestra parte.

Si encontramos defectos, tendremos que decidir si el defecto es bloqueante (no

podemos seguir con el siguiente paso) y por lo tanto daremos por KO o fallado todo el
caso o si no es bloqueante, daremos por KO el paso, pero no al caso en su totalidad, ya
que habrá otros pasos que sí estarán OK.

Cuando hemos abierto estos defectos, la gente de desarrollo se pondrá a trabajar en

su solución y una vez que está disponible, haremos el llamado retesting.

El retesting es la manera de asegurarnos de que la corrección que ha realizado

desarrollo es completa, cubre y arregla el defecto que dimos de alta y nos deja dar por
OK el paso donde lo detectamos.

En caso afirmativo, cerraremos el defecto y damos por validado el paso y el caso en

su totalidad (siempre y cuando no existan otros defectos) y si no, seguiremos dejando
el caso en KO y devolveremos el defecto a desarrollo para que vuelva a trabajar en su
resolución.

8
 ¿Qué podemos sacar de todo esto?
Sobre todo, que el Testing es algo vital en nuestras vidas, algo que las empresas ni
pueden dejar de solicitar, de imponer y de llevar a la práctica. Es preferible recortar en
otro tipo de acciones que de gente que pruebe su software.

¿Qué os causa mejor impresión?, ¿una aplicación sin fallos, o una aplicación que nada
más entrar nos deje tirados y sin acceso? La respuesta es sencilla y todos la tenemos en
la cabeza, lo complicado es llevarla a cabo y convencer de ello.

Asegurar la Calidad de un software siempre nos dará alegrías, la garantía del buen
hacer, unas buenas opiniones y, sobre todo, que los usuarios estén contentos que, al
final, son siempre los que nos darán de comer y aportarán ese granito de arena, para
que, de boca a boca, para que el software sea conocido, esté altamente cualificado y
podamos estar orgulloso de él.

3. Los módulos de HP Quality Center

Quality Center es la herramienta que pone nuestra disposición HP para gestionar la
calidad.

Podemos utilizarlo como TCoE (centro de excelencia de pruebas de calidad) y además

es una plataforma en la que podemos unificar todo nuestro trabajo, estableciendo
procesos coherentes, repetibles y siempre mejorar y aplicar las mejoras prácticas para
la gestión de requisitos, pruebas, defectos y en algunos casos, componentes
empresariales.

En HP QC tenemos cuatro apartados o módulos muy importantes, vamos a verlas una

por una:

• Módulo de Requisitos:
En dicho módulo podremos realizar un seguimiento completo de los
requisitos, darlos de alta, gestionarlos, consultarlos y tener un repositorio
donde guardarlos y exportarlos a diferentes formatos.

Este módulo está diseñado en forma de árbol de carpetas, en donde

una carpeta principal contendrá diferentes requisitos. Es totalmente
configurable para acoplarse al proyecto en el que trabajemos.

• Módulo de Pruebas:
En este módulo nos encontramos tres submódulos, la de los recursos
de pruebas, la de los planes de pruebas y la del laboratorio de pruebas.

Recursos de pruebas: en él podemos encontrar todos los recursos que

necesitamos para la realización de las pruebas, la mayor parte de ellos
relacionados con pruebas automáticas.

9
 • Planes de pruebas:
Aquí realizaremos los planes de prueba que utilizaremos más
adelante, paso por paso, diseñándolos desde cero y adjuntándolos a uno
o varios de los requisitos que cubran. En esta sección también podremos
aplicar las configuraciones de pruebas en las cuales seleccionaremos o
escribiremos para que pruebas en particular ejecutaremos ese mismo
caso. La sección se divide en una serie de planes de prueba, con sus
respectivos casos de prueba y que dentro tendrán los pasos de prueba
necesarios.

Laboratorio de pruebas: aquí podremos dar de alta las baterías de

prueba que vamos a utilizar en un determinado Sprint o para un
determinado requisito. La sección está configurada como un árbol de
pruebas sencillo y que nos ayuda a ver nuestro trabajo con un simple
golpe de vista. Con el botón “ejecutar” podremos empezar a realizar
nuestras pruebas.

• Módulo de Defectos:
En este módulo daremos de alta los defectos encontrados en cada
ejecución (también se pueden dar de alta mientras estamos ejecutando).
También podremos hacer un seguimiento completo de los defectos, ver
los que ha abierto el equipo, en qué estado están o a quien están
asignados. Un complejo módulo que es el corazón central del trabajo de
Testing y que es donde, realmente trabaja todo el mundo y donde se
guarda el principal núcleo de información de cómo se está comportando
el software.

Estos son, de una manera muy resumida, los principales núcleos o

módulos de HP Quality Center. Más adelante los abordaremos con más
detalle y explicaremos cómo funcionan desde dentro y de qué manera se
pueden configurar, mejorar o modularizar para que se adapten al 100%
a nuestra forma de trabajar.

4. El tester no es un desarrollador
Libros como "How Google tests software" proponen que el Tester puro desaparezca,
que el tester sea un desarrollador que se preocupe por la Calidad, una afirmación en la
que no puedo estar más en desacuerdo.

Como tester puro que soy, tengo que decir que no estamos en peligro de extinción,
ni mucho menos, solo estamos pasando un periodo en el que no están las cosas muy
claras. Hay muchas tendencias innovadoras que, realmente, no están calando en ningún
sitio, defensores y detractores ponen las cartas sobre la mesa y se encierran en sus
metodologías y en sus ideas y no dejan escuchar ni abrir sus mentes. Las cosas son así
porque están escritas en la biblia de la metodología y no hay nadie que me saque de esa
idea, no escucho ni dejo escuchar.

El futuro no está en estas metodologías emergentes, de hecho, revisar y preguntar

10
en que empresa o centro de trabajo se está usando una metodología cerrada, que
cumpla 100% el libro y que funcione, os puedo dar una pista, en una y está en Japón, la
única en todo el mundo.

El verdadero funcionamiento tiene que residir en la mezcla, en capturar las mejores

opciones de cada metodología y ponerlas en práctica. O más sencillo, modificar la
metodología y adaptarla a lo que más convenga para nuestro proyecto, no al revés.

Una vez explicado este concepto, el cual dedicaré más tiempo, más adelante,
volvamos a lo que nos ataña, si el tester tiene que ser desarrollador o no. La respuesta
es clara: NO.

El tester tiene que tener conocimientos de desarrollo, SI, debe de tenerlos.

Un tester no tiene que ser desarrollador, primero, porque para ser bueno en algo no
hay que ser de todo. Pongo un ejemplo muy claro y que todos vamos a entender, el
mejor cardiólogo del mundo no sabe porque le duele el oído a un paciente, puede
intuirlo, pero para eso hay un experto otorrino que le dirá que le pasa. Es exactamente
el mismo caso, un tester ve que algo está fallando, puede intuir por qué, pero para eso
está el desarrollador que lo arreglará y sabe exactamente donde tocar. Más sencillo, un
desarrollador hace una nueva funcionalidad, la prueba, pero como es experto en
desarrollar y no en hacer pruebas, siempre saldrá algo que dejará subir a producción y
así afectar al usuario final.

Bien claro lo dice el refrán, que parece que a muchos se le ha olvidado: “aprendiz de
todo, maestro de nada”.

Los pasos que hay que tomar son muy claros y están definidos, solamente hay que
saber leer las pistas que nos van dando y ponerlas en práctica. Los tester tenemos que
tener un conocimiento de lenguajes de programación, básico, para que nos de pistas de
que falla y ser más exacto a la hora de dar de alta errores y los programadores no tienen
que ser Tester, solamente tienen que meterse en la cabeza que hay que programar con
más calidad, con más calma y sobre todo tratando de evitar errores tontos que es en
verdad donde se va mucho tiempo de las personas que están probando sus desarrollos.

Mi opinión es clara, ni tienen que desaparecer los Tester puros ni tienen que
desaparecer los desarrolladores puros, solamente tienen que unir sus caminos,
balancearse. Claro ejemplo de lo que no está pasando es la charla de Alberto Savoia en
el GTAC del 2011, si señoras y señores, en el 2011, en el que dejaba claro que el Tester
había muerto, pues…estamos a 2013 y muchos de nosotros seguimos siendo Tester
puros y duros y viviendo de ello. Las figuras del tester y del desarrollador no tienen que
ser la misma persona, simplemente, tienen que ser dos y ser un equipo, ayudarse,
apoyarse y sobretodo confiar el uno en el otro, uno tendrá grandes conocimientos de
lenguajes de programación y el otro tendrá grandes conocimientos para realizar las
pruebas pertinentes, de esta manera serán cada uno maestros en su terreno. Esto,
damas y caballeros, SI es el futuro.

11
 5. La importancia de las pruebas de compatibilidad en dispositivos
móviles
Los dispositivos móviles están ganando mucho terreno en los procesos del
aseguramiento de la Calidad del software. La creciente demanda de estos por parte de
los usuarios, ha logrado que las empresas se preocupen cada día más de tener sus
páginas webs y productos disponibles para acceder a través de cualquier teléfono móvil
o Tablet.

Desde hace unos años el comportamiento general de todos nosotros ha avanzado a

utilizar casi al 100% un dispositivo móvil y de relacionarnos a través de él, esto es
extremadamente importante a la hora de que las empresas se mantengan en alza y sigan
obteniendo importantes ingresos de su software y/o productos en el mercado.

Dentro de este espectacular cambio hay una tendencia a que el aseguramiento de la

Calidad de un software tenga un alto porcentaje destinado a estos canales y que cada
vez seamos más los profesionales del Testing los que tengamos que hacer pruebas de
compatibilidad en dispositivos móviles.

Las pruebas de compatibilidad en dispositivos móviles tienen que ser muy exigentes,
al igual que los usuarios que utilizan estos canales. Tienen que ser precisas, pacientes y
muy detalladas, sobre todo para asegurar la calidad en tres puntos: la rapidez de carga,
la precisión de los datos consultados y la sencillez de uso del software.

A día de hoy, cualquier tipo de error, de caída de datos, de fallo en la consulta, hará
que el usuario elija otro software de la competencia sin ni siquiera dar una segunda
oportunidad.

La verdadera complejidad de las pruebas de compatibilidad reside en el gran abanico

de dispositivos que hay en el mercado y los diferentes sistemas operativos que están en
funcionamiento.

La primera idea que hay que tener es que no se puede probar la aplicación en todos
los dispositivos móviles del mercado, sobre todo con la gran afluencia que hay de clones
que vienen de china que dificulta más, si se puede, esta tarea.

Para solucionar este problema, hay que hacer un estudio de mercado, cuales son los
dispositivos que más se utilizan, los que más compra la gente y en que dispositivos se
hacen los principales accesos a internet en todo el mundo, de esta manera iremos
descartando y filtrando poco a poco este amplio rango.

Una vez que tengamos estos datos en las manos, tendremos que filtrar por S.O. y cual
o cuales son los más utilizados, esto nos acotará más el rango, si seleccionamos los 3 o
4 primeros de la lista.

Cuando obtengamos todos, haremos un ejercicio de descarte y tendremos que

centrarnos en los dispositivos más restrictivos de cada gama intentando que tengan
diferentes versiones de S.O. Por ejemplo, si seleccionamos dispositivos de Apple, no

12
tendremos demasiado problema ya que los usuarios de este tipo de dispositivos tienen
una tasa muy elevada de actualización y prácticamente el 95% de ellos tienen las últimas
versiones de iOS.

Con el listado de dispositivos creado, ya podemos comenzar a realizar unas buenas

pruebas de Compatibilidad.

El siguiente paso es crear una batería completa de casos de prueba que cubra al 100%
la compatibilidad de la interfaz del software en todos los dispositivos seleccionados.
Estos casos tienen que cubrir las diferentes variantes que se obtendrán de los mismos,
como pantallas, resoluciones, comportamientos táctiles, fluidez, procesadores, tiempos
de carga o compatibilidad con el S.O.

Una manera de ayudarnos con estas pruebas es una herramienta de gestión de la

calidad, como Quality Center, Testlink o Test manager.

Con este tipo de programas podemos realizar los casos de prueba, asociándolos a
configuraciones de prueba por cada dispositivo y así obtener baterías de prueba
diferenciadas por cada uno de ellos. Así evitaremos la duplicidad de datos, de pruebas y
tener un mayor control de que falla o que funciona concretamente en cada móvil o
tablet.

En mi opinión, las pruebas de compatibilidad en dispositivos móviles se han vuelto

totalmente esenciales en las tareas de Testing de software y si todo sigue así, las
empresas tendrán que tener estrategias específicas y cada vez más, sacar al mercado
software exclusivo para este tipo de canales, si no, tendrán una perdida muy importante
de usuarios o clientes potenciales.

6. La regla del Sprint +1 y el Testing Ágil.

El Agile Testing es una manera de probar software siguiente los principios del
desarrollo de Software Ágil.

Las Pruebas Ágiles involucran a todos los miembros del equipo y utilizan la
experiencia del tester para garantizar la entrega del software con el valor de negocio
deseado por el cliente. Esta entrega se realiza a un ritmo sostenible y con entregas
frecuentes cada dos semanas, cumpliendo las principales reglas de esta metodología.

Estas pruebas no se realizan de manera separada ni en una fase posterior al

desarrollo, sino que se integran en él. Estas pruebas tienen que comenzar antes de la
codificación inicial.

Los tester aportan su experiencia en crear casos del comportamiento deseado que
quiere el cliente para su software y colaboran con el equipo de desarrollo para convertir
estos “casos” en especificaciones ejecutables (y si pudiera ser automáticas) que guíen al
equipo en la codificación.

Como siempre, las pruebas y el código se realizan de forma que al final del sprint

13
tenga el valor suficiente para subirlo a producción.
Lo que sí que hay que tener muy claro a la hora de realizar Agile Testing es que:
AUTOMATIZAR TODO ES IMPOSIBLE.

El coste de automatización es muy alto y el mantenimiento también, por lo tanto, nos

tenemos que centrar en cuáles son las funcionalidades críticas de la aplicación y las que
en caso de fallo pueden tener un impacto económico negativo.

Esto, no quiere decir que solo tengamos que automatizar estos puntos, pero sí que
es una manera de descartar y saber que es lo más importante y en caso de tener un
presupuesto ajustado, centrarnos en ello.

Cuando tengamos claro que partes vamos a automatizar, una idea muy buena es la
regla del Sprint +1, en la que una tarea del Backlog será la creación de scripts de pruebas
de regresión automatizados de las funcionalidades que se hayan implantado en el sprint
anterior.

La regla del Sprint +1 puede chocar con otro tipo de automatizaciones en proyectos
Agile, pero es una muy buena manera de mantener la aplicación con unas pruebas de
regresión automáticas y que el esfuerzo que se podría “perder” en hacer esas pruebas
de forma manual se lleve a la realización de otras pruebas u otros asuntos al comienzo
del sprint.

Estos pasos y reglas nos ayudarán a que el Testing en una metodología Agile se
convierta en un añadido en cada sprint y no un trabajo aparte y totalmente desintegrado
del mismo.

7. Siempre es mejor la calidad que la cantidad

Siempre me gustó la frase “es mejor la calidad que la cantidad”, se puede aplicar a
muchas situaciones de la vida y a muchos contextos.

En mi trabajo esta frase es una máxima que debería de llevarse a cabo siempre. Todas
las empresas lo tendrían que tener claro, sea cual sea su función o su terreno.

Si pensamos en empresas que desarrollan software, la aplicamos al contexto de que

es mejor ir poco a poco sacando a producción trozos con una calidad excelente que no
un producto completo con una calidad nefasta y que tengamos que realizar parche tras
parche para reparar esos defectos que no se han arreglado antes.

¿Qué supone algo así? Que el tiempo de desarrollo se ha acortado porque el producto
está en producción, pero el tiempo de “reparaciones” de ese desarrollo se puede alargar
muchísimo y al final es un coste de dinero que se suma al mantenimiento que hay que
realizar y a los evolutivos que tengamos que ir haciendo. Además, a esto, se suma el
descontento de los usuarios que utilizan este software.

Si cambiamos las tornas y vamos por el camino correcto, sacando pequeñas piezas
poco a poco y que cuenten con una gran calidad, tendremos un desarrollo

14
previsiblemente más largo pero que estará en producción en buenas condiciones y a
esto sumamos que los usuarios estén contentos y que podamos tener más usuarios
potenciales por la técnica del boca a boca.

Siempre hay que tener en cuenta que la parte de mantenimiento y de evolutivos

estará constante en ambas opciones y que para la realización de esta segunda opción
nos pueden ayudar las metodologías ágiles que aportarán un punto de vista diferente y
nos resolverá la papeleta de separar el software en trozos adecuados para los usuarios
y que aporten un valor por sí mismo.

Esta máxima, como ya dije al principio se puede aplicar a cada situación en la vida,
tanto personal como profesional y cuando piensas que la cantidad está por encima de
la calidad, se tienen el 99% de papeletas para fallar.

8. El Testing y su importancia en nuestras vidas.

¿Que sería del mundo sin personas dedicadas 100% a encontrar defectos en
cualquier cosa que utilizamos a diario?

El Testing, por mucho que cueste creerlo, es la piedra angular de absolutamente todo
y con todo me refiero a TODO.

¿Te imaginas encender la vitrocerámica sin que hubiera pasado el control de calidad?
Me apuesto lo que queráis a que el 99% de vosotros ni os acercabais al botón de
encendido. Como este, se pueden poner infinidad de ejemplos y más concretamente, a
lo que yo me dedico, la calidad del software.

Un software sin testear es una bomba de relojería, ni más ni menos. Una bomba que
nos puede estallar en cualquier momento y que nos puede ocasionar muchísimos
problemas, sobre todo económicos.

Existen varias reglas que no deberíamos saltarnos en los modelos actuales de trabajo:

• Jamás se debe de subir a producción un software que no sepamos seguro que

haya pasado, por lo menos, una serie de pruebas de sistema y de aceptación.

• El Tester no debe de estar separado del equipo de desarrollo. Ahora mismo, el

equipo de Testing y el de desarrollo son uno solo y tienen que tener la mayor
afinidad posible, comunicándose en todo momento. Eso sí, cada uno tiene que
dedicarse a lo suyo, el desarrollador no es un tester y el tester no es un
desarrollador, por mucho que se empeñen en justificar lo contrario.

• Si no está probado, no sube a producción. Ahí es donde tienes que jugarte el

cuello con quien sea y cuando sea, no seas el artífice de una mala subida que
llegue a los usuarios y repercuta en tu trabajo.

15
 • Se inflexible a la hora de realizar tus pruebas, no dejes de hacer lo básico: lectura
de análisis, casos de prueba, pruebas exploratorias, reporte de defectos,
retesting de defectos arreglados, pasar los casos de prueba, reportar y retestear
los bugs y validar.

• Si no tienes un entorno estable, no automatices. Acabaras desesperándote y

dedicándole el 90% de tu tiempo a reparar esos scripts que tanto trabajo te
cuesta hacer.

No creas que no hay más reglas básicas y que alguna de las anteriores no sea válida
para tu entorno de trabajo, eso es evidente, en cada sitio tienen diferentes maneras de
hacer las cosas y nos tenemos que amoldar a todas ellas, pero siempre hay que ser firme
con las convicciones de cada uno y sobre todo ponerlas en práctica.

Al fin y al cabo, el Testing es la parte más importante del software y todo el mundo
tiene que apostar por él en sus empresas, acabarán ahorrando tiempo y dinero.

9. El flujo de los defectos

Un flujo de defectos es indispensable para el buen funcionamiento de un proyecto.
Con ellos logramos que el defecto siga los pasos adecuados y podamos organizarnos de
una manera más sencilla.

¿Cómo hago un flujo de defectos?

Muy sencillo, existen herramientas de Calidad como Microsoft Test Manager y HP
Quality Center (además de otras gratuitas como RedMine, Jira o Mantis) que nos pueden
ayudar a la hora de crear un ciclo para nuestro proyecto.

Si no se dispone de estas herramientas, siempre se puede utilizar una Excel o como

último recurso el email (último recurso no, lo siguiente).

Lo primero que tenemos que hacer es comprobar como tenemos organizado el

proyecto, cuanta gente lo compone y cuáles son sus roles, a partir de ahí, podemos
empezar a crear nuestro flujo de defectos.

¿Qué estados debe de tener mi flujo de defectos?

Un flujo tiene que tener 5 estados básicos: “Abierto”, “Asignado”, “En Desarrollo”,
“Disponible” y “Finalizado”.

A partir de esos estados se pueden implementar todos los necesarios para nuestro
proyecto y nuestras necesidades, por ejemplo, si solo tenemos un tester y un equipo de
desarrollo, con este flujo estaríamos cubiertos, pero si hacemos también pruebas de
validación por un equipo de UAT, se nos queda corto y deberíamos de introducir más
estados, como el de “validado UAT”, “Aceptado QA” o “disponible UAT”, por ejemplo.

¿Me ayudará a ganar tiempo un flujo de defectos?

Depende, si se satura con demasiados estados y validaciones, puede ser que las

16
personas que forman tu equipo o equipos de trabajo no se acuerden de todos y acabe
siendo un cuello de botella, por ello hay que ser lo más óptimo posible, buscar la
sencillez sin perder ningún paso.
Si tu flujo es óptimo, sin duda ganaras tiempo a la hora de tener organizada tu lista
de defectos y el correspondiente Backlog, y de una sentada podrás ver como se está
desarrollando su finalización y si la calidad está mejorando. Si se ven menos “abiertos”
eso es que tu software crea menos fallos, si hay cantidad de abiertos, pero son iguales
o menores que los “finalizados”, eso quiere decir que tu equipo está generando muchos
bugs, pero son muy rápidos corrigiendo. Cada uno puede sacar sus conclusiones y
estadísticas, basándose en los estados.

Un flujo de defectos se tiene que crear entre todos, nadie puede imponerlo y cada
jefe de equipo tiene que aportar los estados en los que se sentirán cómodos. Por lo
tanto, mi recomendación es que se junten los jefes de equipo de desarrollo, de QA, de
UAT y si hubiera más, cada cabeza visible del mismo.

Basándome en mi experiencia profesional os puedo poner unos ejemplos de flujos

de defectos que han funcionado muy bien en varios de los proyectos en los que he
trabajado:

FLUJO 1:

• NUEVO: este estado (también puede ser borrador) podría utilizarse para que
el tester edite los datos del mismo antes de pasarlo al siguiente estado donde
se bloquearía la edición.
• ABIERTO: El tester abre el bug oficialmente y lo deja en el Backlog para
pasarlo al equipo de desarrollo o si hay una persona responsable del
producto, lo ponga el en el mismo.
• ASIGNADO: El defecto está asignado al desarrollador y es consciente de ello,
lo tiene en su Backlog personal y empezará a solucionarlo en breve.
• EN DESARROLLO: El defecto se está solucionando por parte del desarrollador.
• TERMINADO DESARROLLO: El defecto está preparado para probarlo, está
asignado al tester.
• VALIDADO QA: El defecto ya ha sido validado por QA y puede probarlo UAT.
• VALIDADO UAT: El defecto está validado por QA y listo para cerrarse.
• FINALIZADO O CERRADO: El defecto está solucionado y se cierra para dejarlo
a tipo de historial.

FLUJO 2:

• ABIERTO: El defecto está abierto y listo para validar.

• ACEPTADO: El bug es aceptado y pasará al desarrollador.
• EN DESARROLLO: El desarrollador realiza la solución del bug.
• TERMINADO DESARROLLO: El tester puede validarlo.
• OK QA: El tester ha dado su OK y está listo para validarlo.
• OK UAT: El defecto ha pasado la segunda validación y está listo para cerrarse.
• CERRADO: El defecto se cierra y queda como historial.

17
 FLUJO 3:

• ABIERTO: El defecto está abierto y listo para validar.

• EN DESARROLLO: El desarrollador realiza la solución del bug.
• TERMINADO DESARROLLO: El tester puede validarlo.
• OK QA: El tester ha dado su OK y está listo para validarlo.
• CERRADO: El defecto se cierra y queda como historial.

Como veis, cada uno de los flujos es válido para diferentes situaciones y proyectos,
dependiendo de las personas que componen los equipos y de la cantidad de pasos que
queramos aportar. Lo fundamental es que en estos flujos exista la figura del
desarrollador y del tester.

Desde mi punto de vista, depende del proyecto y como tengan en cuenta la Calidad
en el mismo, pero el Tester es la única persona que debería de cerrar un defecto, al fin
y al cabo, nosotros somos los que nos dedicamos a ello.

10. El Testing no es solo cosa de Testers

Cada día más, se ha ampliado el abanico del Testing dentro de los proyectos. Antes,
el tester era la pieza única en la que se realizaban las pruebas, pero ahora este abanico
se ha ampliado y diversificado a cada persona del equipo.

La pieza angular de la calidad del proyecto es el tester, pero ahora, desde desarrollo,
se están implementado pruebas unitarias y de integración que hacen ellos mismos,
probando sus desarrollos y evitando errores graves, como un error 500 o similar.

Las pruebas unitarias son una forma de probar el funcionamiento idóneo del código
desarrollado y asegurar que los módulos funcionen separadamente. Después, las
pruebas de integración, tienen la capacidad de asegurar el funcionamiento del sistema.

Trabajando con un buen flujo de QA, la idea es que el tester, al realizar los casos de
prueba puedan “proporcionar” estos datos a los desarrolladores y así ayudarles a
implementar este tipo de pruebas de desarrollo, así llegará más limpio el código al
departamento de QA y la validación podrá ser más afable y menos traumática en el caso
de que existan defectos.

Las pruebas unitarias deben de cumplir las siguientes reglas: Automatizables,

Completas, Repetibles o Reutilizables, Independientes y Profesionales.

La idea de las pruebas unitarias es que simplifican la integración con los demás
módulos, ya que se encontrarán errores tempranos y se podrán solucionar antes de
realizar la misma.

Lo más importante es no volverse loco a la hora de realizar pruebas unitarias, estas,

solo deberían de servir para comprobar que el código funciona correctamente, nada
más.

18
 Al igual que las pruebas de integración que solo sirven para comprobar que ese
código de ese módulo específico, funcione correctamente en conjunto con los demás
módulos que agrupan la aplicación.

Una vez que se han pasado las pruebas unitarias y las pruebas de integración, el tester
comenzará con sus pruebas de sistemas que serán mucho más “amigables”, ya que los
errores graves y pantallazos de error se han detectado en esta fase previa y ahorrará
tiempo para dedicarse a que la aplicación tenga la calidad que le corresponde.

Como siempre hemos hablado, la relación entre tester y desarrollador cada día es
más cercana y con este tipo de pruebas, más aún. El tester comparte sus conocimientos
y el desarrollador los recoge para que su código sea mucho mejor y de una mayor
calidad, ayudándose mutuamente y demostrando que la relación del gato y del ratón
cada vez está más alejada de la realidad.

11. Testing exploratorio en entornos hostiles de desarrollo.

Cuando nos encontramos en un entorno hostil de desarrollo, donde pasemos por
donde pasemos, el error está asegurado, hay subidas al entorno continuas, los
desarrolladores están trabajando constantemente provocando falsos positivos,
tenemos que remangarnos y realizar batidas constantes con pruebas exploratorias.

Estas pruebas nos ayudarán, entre otras cosas, a detectar errores rápidamente, a
saber, cómo funciona algún tipo de módulo de una aplicación en concreto o a ayudar a
la gente de desarrollo a que su desarrollo contenga menos errores.

El Testing exploratorio no es más que una libre interpretación de las pruebas de cara
al tester, que según sus conocimientos y su punto de vista realizará pruebas sin ceñirse
a ningún caso, organizándolos pasos a su manera y comprendiendo y aprendiendo el
verdadero funcionamiento de un módulo o aplicación a probar.

La calidad de estas pruebas dependerá de la destreza y de la experiencia que tenga

el tester. Además, si este ya tiene conocimientos anteriores de la aplicación, las pruebas
serán mucho más satisfactorias y se podrán encontrar un número mayor de defectos de
una sola vez.

¿Por qué es importante el Testing exploratorio en entornos hostiles?

Pues muy sencillo, por la cantidad de falsos positivos que nos podemos encontrar en
los casos de prueba. Si nos dedicamos a pasar los casos de prueba y el entorno no es
estable, la mayor parte de ellos fallarán y será un caos y una pérdida de tiempo
importante.

Con unos test exploratorios podremos detectar que falla y podemos volver a probar
rápidamente esa pantalla y ver si el defecto que habíamos encontrado ya no está
sucediendo.

¿Qué pautas se pueden tomar para hacer Testing exploratorio en un entorno hostil?
Una de las pautas más sencillas y recurrentes es definir unos rangos de tiempo que

19
se cuadren, si es posible, a las subidas de ese entorno, en el caso de que tengamos
subidas cada dos horas, adaptar ese Testing exploratorio a ese tiempo, así con la nueva
subida podremos comprobar que lo que fallaba, sigue fallando o ya está solucionado.

¿Lo que probemos se perderá?

La respuesta es no. Existen muchas herramientas que permiten tener una buena
documentación de estas pruebas, en base a grabaciones de vídeo, pasos realizados o
capturas de pantalla.

Una de las que mejor funciona es Test Manager, que tiene un módulo llamado
"exploratory Testing" que nos ayuda a realizar este tipo de pruebas. Con esta
herramienta, pulsando al "play" podremos grabar vídeo, hacer un pantallazo final, crear
pasos de prueba automáticamente en base a los click en pantalla y de esta manera crear
un caso de prueba que se puede automatizar fácilmente.

Otra herramienta que nos puede ayudar es Test Studio, más barato que el anterior y
también nos puede servir para documentar todas nuestras pruebas.

Como podemos ver, el Testing exploratorio es un tema recurrente en entornos de

prueba poco amigables para las pruebas tradicionales y nos serán de gran ayuda a que
podamos ver el funcionamiento de la aplicación a corto plazo, pudiendo avanzar en
nuestro trabajo sin tener que revisar los casos de prueba una y otra vez, encontrando
falsos positivos y perdiendo un tiempo muy valioso que podamos dedicar a otras tareas
profesionales.

12. Monitorizar una aplicación en Microsoft Azure

Cuando utilizamos Microsoft Azure podemos determinar el estado general de la
aplicación mediante unas herramientas y así comprobar que todo es correcto.

Estas herramientas varían dependiendo de si estamos utilizando almacenamiento o

base de datos SQL Azure, pero en rasgos generales son las siguientes:

• Management portal: Aquí podemos observar las instancias de los servicios y el

estado de la aplicación en Azure, es similar al portal de TFS de una aplicación.

La principal característica del Management portal de Azure es que se puede

monitorear el estado de las aplicaciones que tenemos subidas y podemos
determinar el estado general de su implementación. Está visión es a muy alto
nivel, ya que no nos aportan información en profundidad ni trazas suficientes
para depurar el error, pero ya tendremos una idea de por dónde van los tiros

Si observamos el listado de los servicios, podemos pulsar en cada uno de ellos

para ver el estado de la instancia.

• Azure Services Management REST API: Azure nos proporciona un API que se
utiliza para recuperar información a través de consola. Esta información es la
misma que se puede obtener desde el Management Portal, pero de esta manera,

20
 una app de terceros podría recopilar información y mostrarla en su propio portal,
incluso recuperarla y ponerla a disposición de los usuarios.

• Azure Diagnostics: posiblemente es la herramienta más potente de todas.

Podemos recopilar información del rendimiento, monitorizar, ver los logs y los
registros que deja nuestra aplicación, incluso también, la información de
seguimiento del servicio alojado en Azure.

La característica más importante de Azure Diagnostics es la posibilidad de

agregar diferentes contadores de rendimiento, pudiendo monitorizar de manera
rápida el rendimiento de cada zona de la aplicación. Además, podríamos ver los
archivos de registro, personalizarlos y realizar un seguimiento de cada uno.

Si se tiene una cuenta de Windows Storage como sitio de almacenamiento,

podemos programar copias periódicas de los logs de nuestra aplicación y poder
tener un historial de posibles errores para poder depurarlos fácilmente.

• Azure SQL Database Dynamic Management Views: En el caso de utilizar la base

de datos SQL de Azure, esta herramienta nos proporcionará información muy
útil de posibles problemas de rendimiento al utilizar SQL en Azure.

Con Azure SQL Database Dynamic Management Views podemos detector

problemas de rendimiento como consultas largas, planes de consulta poco
definidos o un gran número de llamadas a la base de datos. Para acceder a esta
herramienta hay que tener una conexión con el servidor de base de datos de
Azure SQL.

Con estas cuatro herramientas de Azure podremos monitorizar y realizar un

seguimiento bastante completo a nuestra aplicación. Es muy importante este
tipo de controles porque en la mayoría de los casos, que los usuarios utilicen o
no nuestro software depende de la rapidez y de la optimización del mismo.

Microsoft ha facilitado las cosas poniendo en nuestras manos un mes de

prueba para que podamos ver si su sistema se adecua a nuestra aplicación y si
nos sirve verdaderamente, os dejo la URL: http://azure.microsoft.com/es-
es/pricing/free-trial/

13. Desarrollo y Testing ágil

El Testing ágil es un conjunto de pruebas que implican a todos los miembros del
equipo. Para ello se siguen los principios del desarrollo ágil.

El núcleo central de estas pruebas es el tester, pero todos utilizan su conocimiento

garantizando la entrega con el valor de negocio deseado por el cliente.

21
 Este conocimiento es usado para realizar una guía de codificación, pruebas unitarias
y de integración o un historial completo de casos de prueba que permitan, de un vistazo,
tener una idea clara de la funcionalidad de una pantalla.

En un desarrollo ágil, las pruebas no son independientes, como en otras

metodologías, sino que están integradas en el ciclo de vida de la aplicación, aplicando el
punto de vista de todo es de todos. Los tester pueden aportar su experiencia para
realizar unos casos del comportamiento correcto de la aplicación, o como quisiera el
cliente final que funcionara, guiando, de esta manera a los desarrolladores por un
camino determinado. Esto se realiza gracias a que un tester siempre tiene un punto de
vista más amplio y puede ver más allá de lo que puede ser típico o normal.

Las pruebas, al igual que el desarrollo de la aplicación, se realizan de modo

incremental, aportando el valor suficiente de cada funcionalidad para ponerla en
producción.

El Testing ágil abarca todo tipo de pruebas, las realizadas por los tester y las realizadas
por los desarrolladores y se tienen que adaptar a los principios básicos: colaboración,
flexibilidad, simplicidad, transparencia y capacidad de respuesta.

El principio de estas pruebas comenzaría con las pruebas unitarias, que realizará el
desarrollador apoyándose en los casos de prueba que ha escrito previamente el tester,
probando el funcionamiento básico. Tras esas pruebas, una vez que se integra el módulo
con el resto, se realizan las pruebas de integración, comprobando el correcto
funcionamiento de ese módulo y el resto del bloque ya desplegado. Estas pruebas
estarían en el tejado del equipo de desarrollo, siempre apoyado por el tester. En la parte
del tester están las siguientes pruebas, que podrán ser exploratorias al principio y
después las de sistema que pasarán los casos de prueba. Una vez que se realizan estas
pruebas, se realizaran las pruebas de aceptación y las de regresión.

El principio fundamental del desarrollo ágil es que desarrolladores y tester son vistos
de la misma manera, cosa que no estoy de acuerdo, como ya expliqué anteriormente en
otro post. Lo que sí que estoy de acuerdo es que las líneas de trabajo no pueden ser dos,
sino que se unen.

La idea principal es contraria a lo que se realizaba anteriormente: los desarrolladores

intentan perfeccionar su código antes de entregárselo al tester, que luego se esfuerza
en encontrar todos los defectos posibles para devolvérselo y así continuamente hasta
que todo funcione correctamente. Con el Testing ágil la idea es probar pequeñas
funcionalidades e ir mejorando el código continuamente, sin esperas. Los
desarrolladores y los tester tienen que reunirse a diario para que los primeros vayan
soltando código y los segundos probar, de esta manera mientras que el desarrollador
está implementando lo siguiente, el tester ya lo ha probado y se lo ha devuelto en el
caso de que falle y así sucesivamente, cosa que facilitará el trabajo de ambos y los
defectos estarán mucho más acotados y controlados.

22
 Aunque el tester no sea un desarrollador y el desarrollador no sea un tester, sí que
hay que intentar pensar como ellos. Un tester que piense como un desarrollador podrá
ayudarse de esto para encontrar errores que antes no podría detectar y un desarrollador
que piense como un tester podrá depurar su código y tener mejor calidad. Esto no quiere
decir que ambos ejerzan un trabajo que no es el suyo, sino que amplíen su forma de
pensar, nada más.

Esta manera de trabajar abre nuevos caminos y permite que el trabajo no sea
monótono y aburrido, ya que, por un momento, puedes pensar con un rol que no es el
tuyo e intentar indagar por qué se ha realizado una funcionalidad de esa manera o se
ha codificado para realizar una función específica.

Esta manera de trabajar es simplemente un punto de vista diferente, una forma de

que la relación sea más “humana” y podamos hacer más equipo y por lo tanto trabajar
de una manera más cordial y optimista.

14. Habilitar los registros de diagnóstico de Azure

En el post anterior hable de como monitorizar una aplicación en Azure, ahora vamos
a ver como habilitar el registro de diagnóstico para ayudar a depurar la información que
pueda devolver una aplicación alojada en este servicio en la nube.

Hay dos herramientas de diagnósticos disponibles:

• Diagnóstico de sitio, que nos permitirá activar o desactivas las siguientes

funcionalidades:

1. Registro de errores detallado. Es una ampliación de información de

errores de HTTP (errores 400 por ejemplo). Nos ayudará a detectar un
código de error de manera más fácil y detallada, pudiendo indagar que es
lo que sucede.

2. Seguimiento de solicitudes de error. Esta herramienta ampliará el detalle

de la información sobre las solicitudes enviadas y los fallos que se puedan
devolver. Se incluye un rastro de componentes de IIS, donde se procesa
la solicitud y el tiempo empleado. Esta información es muy útil si se
quiere aumentar el rendimiento del sitio o aislar un error específico.

3. Servidor de registro: registra absolutamente todas las transacciones

HTTP de un sitio web utilizando el formato W3C. Esta herramienta es útil
para determinar métricas como el número de solicitudes tramitadas o si
estas solicitudes son de una IP determinada.

• Diagnóstico de aplicación, que nos permite capturar la información que produce

nuestra aplicación web. Estos datos se pueden utilizar con la clase

23
 “System.Diagnostics.Trace”.

Azure también registrará la información de los despliegues que se realicen. Esta

información es guardada de manera automática y no se puede configurar el registro.
Este registro es muy amplio y puede ser utilizado para trazar un error de despliegue o
porque está fallando una subida en concreto.

La herramienta de diagnósticos se puede habilitar desde la página “configurar” del

sitio web de Azure. Esta página está en el portal de administración.

Al habilitar esta herramienta se tienen que seleccionar los niveles de registro, el

registro en el sistema de archivos, el de almacenamiento de tablas o el almacenamiento
blob. Estos dos últimos proporcionan información adicional (identificador, ID y marca de
tiempo) mucho más detallada y completa.

Cuando habilitamos el diagnóstico, hay que seleccionar obligatoriamente el

almacenamiento, donde podemos seleccionar una cuenta de almacenamiento de Azure
y un contenedor para guardar toda la información recibida.

Cuando trabajamos con Azure (u otro sistema en la nube), es muy importante tener
toda la información posible por si existiese algún fallo, ya que si no podemos quedarnos
en blanco y ver que nuestra aplicación está fallando sin saber los motivos reales.
Activando esta herramienta, que nos proporciona el sistema en la nube de Microsoft,
podemos trazar todo tipo de errores, fallos o logs y ver exactamente cuál es nuestro
problema.

Las herramientas que nos da Microsoft con su servicio en la nube son muy potentes,
pero siempre debemos de trabajar con las capacidades y presupuesto que tengamos,
sobre todo a nivel de almacenamiento.

15. Pruebas de compatibilidad en diferentes navegadores con Coded UI

Con Coded UI podemos crear una amplia batería de pruebas de compatibilidad
automatizadas gracias a que podemos reproducirlo con otros navegadores, como
Mozilla Firefox e Google Chrome.

Realizar pruebas de compatibilidad en diferentes navegadores es muy importante,

ya que no todos se comportan de la misma manera y un módulo de nuestra aplicación
puede funcionar perfectamente en un navegador, pero puede que no arranque en otro,
por lo tanto, trabajando de esta manera podemos comprobar que absolutamente todos
nuestros módulos funcionan en un amplio abanico de navegadores y que podemos
llegar a diferentes tipos de usuario sin problema.

También podemos detectar errores de manera temprana y corregirlos antes de que

afecte a clientes potenciales.

A día de hoy, podemos utilizar Coded UI de manera fiable en Mozilla Firefox 26 y

Google Chrome 32, además de las conocidas versiones de IE 9 y posteriores.
24
 La grabación se tiene que realizar en Internet Explorer, ahora mismo los demás
navegadores no son compatibles para ello. Esto es una clara deficiencia de esta
tecnología, pero también es entendible que Microsoft no quiera dar ese paso, para que
se utilice su navegador por defecto. También se puede agregar la validación y el código
personalizado para configurar una serie de propiedades y podamos comprobar el código
utilizando Coded UI, extendiendo las pruebas al front-end y al back-end de la aplicación.

Cuando reproducimos las pruebas que hemos grabado anteriormente, si no se

especifica ningún navegador previamente, lo ejecutaremos con Internet Explorer
(claramente optimizado para estas funciones), pero si queremos utilizar otro, podemos
establecer la prioridad en la propiedad BrowserWindow.CurrentBrowser al principio del
código de la prueba (sustituyendo IE por FF o Chrome).

También podemos crear pruebas con dependencias con Selenium y reproducirlas

perfectamente, instalando: Selenium components for Coded UI Cross Browser Testing.

La versión óptima para que estas configuraciones con Selenium u otros navegadores
es Visual Studio Ultimate con Visual Studio 2012 Update 4, si no, algunas de las funciones
acabarán fallando, ya que está manera de trabajar es relativamente nueva.

Otros problemas que nos podemos encontrar es que Safari no es compatible y en

otros navegadores que no son Internet Explorer, las acciones de maximizar, minimizar y
restaurar tampoco.

Microsoft ha dado un gran paso dejando que otros navegadores y herramientas sean
compatibles con su tecnología, facilitando a los tester que puedan ampliar el abanico de
pruebas y que cada día sea más fácil utilizar Coded UI, pudiendo dejar de lado otras
herramientas de automatización que son más complejas que esta.

Si algún día, Microsoft deja que Coded UI y su Suite de Pruebas entre en otras
versiones de Visual Studio que no sean la Ultimate, habrá dado el paso definitivo para
que muchas empresas utilicen esta tecnología para automatizar las pruebas de sus
aplicaciones.

16. ¿Funciona realmente el Test-driven development (TDD)?

Empezaremos por explicar de forma sencilla que es Test-driven development.

TDD es una práctica de programación que se basa en escribir las pruebas primero y
después realizar el desarrollo.

Para realizar esta práctica se suelen utilizar pruebas unitarias y es tan sencillo como
que, al lanzar la prueba, esta falla. Tras ese fallo, se implementa el código para verificar
que esta prueba funciona perfectamente.

La idea de esta técnica es que el desarrollador pueda hacer un código limpio y que,

25
cuando todas las pruebas estén cubiertas y en OK, el software garantiza que se han
establecido todos los requisitos solicitados. Una vez que las pruebas están OK habrá que
refactorizar para eliminar código sobrante o duplicado.
Al parecer una de las principales ventajas es que no se necesitaría la utilización de
debugger y que, al avanzar en pequeños pasos, permite al programador centrarse en
tareas muy concretas y actuales para acabarla más satisfactoriamente. Otra ventaja es
que el código ya está cubierto desde el inicio por pruebas.

Las principales limitaciones que presenta el TDD es su utilización en GUIs, objetos

distribuidos y bases de datos.

Mi opinión está justo en medio de esta técnica, ni la defiendo ni la rechazo, la veo

que tiene ciertas ventajas a la hora de hacer un desarrollo más limpio, pero también veo
que ni es necesario tener un 100% de cobertura de pruebas unitarias y que cualquier
cambio en el código por mínimo que sea, romperían los test y habría que estarlos
manteniendo constantemente, duplicando el trabajo, y si los test están rotos, los bugs
florecerán como la espuma.

El programador tendrá un código limpio, facilidad para realizarlo y una ayuda extra
que le será muy útil, pero también basará el desarrollo en esas pruebas y quizá habrá
algo que se escapa, que surge más adelante (nunca jamás desde el inicio acaban saliendo
absolutamente todos los caminos posibles en una pantalla, somos humanos y siempre
hay que añadir algún caso de prueba posterior) y que puede romper la aplicación en
cualquier momento, personalmente yo pienso que el desarrollo debe decidir las pruebas
no al contrario, como bien explica la frase: “como puedo hacerlo más claro, no como
puedo hacerlo más testeable“. Al fin y al cabo, el TDD produce un sobre Testing y es
preferible, desde mi punto de vista, automatizar las pruebas de regresión.

Una ventaja del TDD es la seguridad que aporta, la cobertura total del código y que
todo está absolutamente probado, por lo tanto, todos los desarrollos que utilicen esta
técnica serán mucho más fiables y casi al 100% no fallarán.

Yo pienso que para un buen uso del TDD el desarrollador tiene que confiar
ciegamente en las pruebas, absolutamente tanto como para hacer una subida a
producción dependiendo exclusivamente del correcto resultado de estos test.

Desde el punto de vista de un tester, esta técnica no debería de gustar, primero

porque la persona que desarrolla realiza las pruebas. Un desarrollador que se lee un
requisito o especificación y lo interpreta incorrectamente, generará errores en todos sus
test, lo cual acabará siendo una pérdida de tiempo y de dinero.

El TDD necesita un tiempo de desarrollo mayor, esto afectará a los entregables, a los
usuarios, a los directivos que quieren ver resultados rápidamente…y quizá se realizaron
infinidad de test innecesarios que después desaparecerán al refactorizar el código, al fin
y al cabo, los test funcionales son los más importantes y los que deben de hacer que un
desarrollo pase o no a producción.

26
 Creo que la técnica de TDD debería de utilizarse en un pequeño reducto dentro de
una metodología ágil, nunca extendiendo todo el desarrollo a esta, el tester debería de
crear una batería de pruebas antes del desarrollo, el desarrollador basar sus pruebas
unitarias a estos casos de prueba y después basar el desarrollo a todo lo demás,
pasando, una vez finalizado, toda la batería de pruebas y completando el ciclo completo
de Testing habitual en la metodología en la que se base el proyecto. De esta manera el
desarrollador generará un código más limpio y a su vez será validado como siempre.

17. Apostar por Testing, garantía de futuro.

A día de hoy son cada vez más las empresas que deciden, y, sobre todo, quieren a un
tester en sus equipos de desarrollo, algo que hace un tiempo no era tan fácil de ver.

¿Por qué este cambio de tendencia? Muy fácil: el usuario cada día se hace más
especializado.

Ahora uno sabe exactamente lo que quiere y más si paga por ello y si ofrecemos un
mal producto, la opinión negativa saldrá hasta de debajo de las piedras. Buena "culpa"
de ello tienen las redes sociales y la repercusión que damos ahora mismo a estas,
pudiendo "destrozar" un producto en cuestión de horas.

Las empresas están cada vez más preocupadas de las redes sociales, de las opiniones,
del mundo digital en general y se aseguran de que lo que lanzan al mercado funciona
exactamente como debería, sin dejar cabos sueltos y la persona que se encarga de ese
correcto funcionamiento es, por supuesto, el tester.

La figura del tester está tomando una importancia increíble y es rara la empresa o
equipo de desarrollo donde no se encuentre y forme parte del ciclo de vida de la
aplicación.

Hay infinidad de ejemplos de empresas en las que encontramos un ciclo basándose

en pruebas, comenzando por las unitarias, de integración, de sistemas y acabando por
las de regresión, asegurándose que a cada paso que se da hay una o más pruebas
comprobando el correcto funcionamiento de su aplicación. Asegurándose de que al
usuario final le llega un producto de calidad.

Una empresa que trabaja de esta manera se está asegurando el éxito, obteniendo
además la satisfacción de que su aplicación es de una muy buena calidad, teniendo
opiniones muy positivas, haciendo que el boca a boca le garantice más ventas y por lo
tanto unos mayores ingresos.

La figura del tester, a pesar de que hace unos años no se consideraba tan importante,
es a día de hoy una profesión muy demandada, pudiendo ser decisiva en la vida de una
aplicación lanzada al mercado y que esta sea más o menos larga. Si el tester es
inexistente, la aplicación fracasará rotundamente y si hay una buena planificación de
Testing, la aplicación será de las mejores valoradas del mercado (siempre y cuando la

27
aplicación tenga una funcionalidad que atraiga a los usuarios. Los tester somos buenos,
pero no hacemos milagros).
En mi opinión, el Testing es garantía de éxito para la empresa y para los proyectos
que aborde. Si de verdad queremos que la repercusión empresarial sea importante, o
sea hace un buen conjunto de pruebas o lamentablemente, el fracaso está garantizado.

18. La importancia del otro Testing

Cuando vemos el mercado laboral, a veces, nos encontramos con que las empresas
no tienen del todo claro qué tipo de Testing necesitan, que tipo de Tester quieren en
sus equipos y sobre todo cual es el Testing que necesita su proyecto.

Dentro del Testing hay diferentes ramas o variantes, digamos que, especialidades.
Existen tester especialistas en pruebas manuales, automáticas, de seguridad, stress o
carga...por ejemplo, por lo tanto, un determinado rol de Testing no tiene por qué saber
realizar un tipo de pruebas.

Este tema es muy parecido a la diferencia entre el tester y el desarrollador, pero

ahora dentro del mundo del Testing. Una empresa no puede pretender que un tester
sepa realizar excelentemente pruebas de carga y también pruebas de seguridad, cada
rol tiene su campo y cada especialista ha de serlo, únicamente, de su parcela o terreno.

Un buen proyecto en el que se quiera garantizar la calidad del mismo tiene que tener
como mínimo una serie de pruebas que ya hemos visto en muchas ocasiones, pero,
además, deberían de realizarse unas buenas pruebas de seguridad y unas pruebas de
stress y de carga.

A día de hoy, muchos proyectos están concienciados con el Testing, pero aún son
reticentes a la seguridad, por ejemplo, y en muchas ocasiones, leyendo las noticias, nos
encontramos cada día con referencias a este tipo de problemas, muchos tendrán en
mente las fotos de famosas robadas o las listas de datos de clientes de PSN de Sony, por
poner algún ejemplo cercano.

En el tema de stress o carga, tenemos ejemplos cercanos como el concierto de los

Rolling Stones en Madrid, en los que los servidores de páginas como TicketMaster no
pudieron soportar la carga de usuarios y de acceso a su portal.

Nosotros, los que trabajamos en este mundo, tenemos que hacer fuerza para que,
cada vez más, tengamos este tipo de pruebas en nuestros proyectos, que cada día
podamos cubrirnos más las espaldas cuando pueda existir algún problema de este tipo
y que nuestro trabajo luzca como debe.

Imaginaros por un momento que el software que estamos probando funciona a la

perfección, tiene una tasa de errores por debajo del 2%, que tenemos las páginas limpias
y los usuarios están muy contentos con la aplicación, pero casualmente un día, hackean
la misma y todos sus datos quedan expuestos en Internet, vulnerándose su intimidad o
que un día necesitan entrar y de repente la página o aplicación se ha caído y no pueden
utilizarla... ¿qué ocurrirá? Pues lo más seguro es que al no encontrar nuestro servicio

28
activo, buscarán una alternativa y posiblemente perdamos un gran número de
clientes...y en el caso de vulnerabilidad de datos...no quiero ni hablar...casi seguro que
mucha parte de usuarios ya no accederán a nuestros servicios jamás. La empresa
perderá dinero y nuestra credibilidad bajará considerablemente.

Al final, personalmente, creo que no merece la pena que esto pase y siempre debería
de guardarse parte del presupuesto, para realizar, puntualmente, este tipo de pruebas,
cubrirnos en salud y, sobre todo, lo que siempre buscamos, la excelencia y la satisfacción
total de los usuarios finales.

19. Cuando el tester es transversal

Hoy, como en muchas cosas, uno tiene que intentar tener conocimientos de todo lo
que pueda, tiene que intentar empaparse de cualquier cosa que pueda y en nuestro
trabajo no podía ser menos.

Cuando tenemos un proyecto en el que hay varios equipos y en cada equipo tenemos
un tester (o varios) al final esa persona será especialista en exactamente lo que se dedica
ese equipo y dejará un poco de lado el resto.

Para evitar esto hay varias medidas que podemos tomar, una de ellas, que exista un
departamento de Testing en el que un grupo trabaje mano a mano indistintamente de
los equipos de desarrollo, cuando llega algo para probar, lo podrá coger cualquiera de
ellos.

Este método, desde mi punto de vista tiene un, pero, que la gente que pruebe será
"menos" especialista en una cierta zona de la aplicación y puede no tener toda la
información.

Otra medida que se puede tomar es que cada cierto tiempo, el tester se mueva de
equipo, hacer rotaciones, así no se cogerán malos hábitos, costumbres y se podrán tocar
todos los palos para probar. El, pero de esta "técnica" es la falta de "confianza" con el
equipo, el trastorno de estar cambiando contantemente de posición y el "jet lag" que
suponen estos cambios hasta que se acostumbra al tester a lo nuevo.

Para mí la mejor solución, aunque muchas empresas sean reticentes a nivel

económico, sobre todo, es que exista un tester transversal.

Cada equipo tiene su propio tester, que probará y será un experto en esa zona,
teniendo conocimientos de las otras zonas, pero mínimo. Como apoyo para estos tester,
existirá un tester transversal (o varios) que irán de equipo en equipo dependiendo de
las necesidades y de la carga de trabajo, apoyando a los tester "fijos" y ayudándoles en
su trabajo.

Estos tester tendrán toda la información global de la aplicación y podrán ayudar al

resto sin ningún problema. Cuando acaben con ese pico de trabajo puntual, irá a otro
equipo ayudando y gestionando el trabajo en base a la pila pendiente que tenga.

29
 De esta manera podremos tener un trabajo constante en todos los equipos de
desarrollo y se podrán apoyar unos a otros para que, entre otras cosas, no existan
diferencias de horarios, que unos equipos tengan menos trabajo y otros estén saturados
y no estén apoyados entre sí.

Al final, cada proyecto tendrá su propia filosofía y sus propias ideas para hacer Testing
de la mejor manera, pero creo que estas ideas se pueden aplicar siempre a
prácticamente todos nuestros grupos de trabajo.

20. Pruebas de carga sobre una aplicación web en Azure

Hace unas semanas comenzamos a realizar pruebas de carga en el proyecto en el que
actualmente trabajo y os quiero compartir las experiencias y pensamientos que he
sacado de todo esto.

Empecemos por el principio, ¿qué son las pruebas de carga?

Las pruebas de carga son el tipo de pruebas de rendimiento más sencillas. Estas se
realizan para comprobar cómo se comporta una aplicación en determinadas situaciones,
como una cantidad alta de peticiones de algún tipo. La mayoría de las veces tienden a
"simular" una serie de usuarios concurrentes que nos darán el comportamiento real de
nuestra aplicación una vez está puesta en producción.

¿Cuál es el primer paso?

El primer paso que debemos de dar para realizar unas pruebas de carga fiables es
saber el grado de madurez de nuestra aplicación. Es completamente absurdo el realizar
pruebas de carga antes de prácticamente haber terminado o en algún punto en el que
la aplicación está todavía verde, ya que los resultados no nos darán las métricas reales
y si nos basamos en métricas equivocadas, el rendimiento puede verse afectado
gravemente.

En este caso os voy a hablar de las pruebas de carga realizadas en un entorno

Microsoft y con herramientas de la misma compañía, más concretamente Visual Studio.

¿Qué es lo más eficiente económica y estructuralmente?

Lo más eficiente para la realización de las pruebas de carga es que se lancen en un
entorno desplegado, no desde nuestra propia red. Al ser un entorno de Microsoft, el
despliegue se realiza en Azure, por lo tanto, tendremos la ventaja de saber que el
rendimiento que obtenemos es casi calcado al que tengamos en producción. Otro punto
fuerte es que no tendremos que invertir en infraestructura física, ya que Azure nos
proporcionará el entorno en la nube para poder lanzar nuestras pruebas.

¿Cómo se realizan en Visual Studio?

Como estamos trabajando en un entorno de Microsoft, habitualmente estaremos
trabajando con Visual Studio, por lo tanto, lo más sencillo es realizar las pruebas de carga
a través de VS Load Testing, Las pruebas de carga las creamos con un simple proyecto
de web test en el que iremos grabando los pasos que queremos realizar y después

30
parametrizar en base a nuestras necesidades cada paso o prueba.
Una vez que tengamos nuestras pruebas configuradas, "grabadas" y parametrizadas,
tendremos que instalar unos "test agent" y un "test controller" que desembocaran en
un repositorio de resultados en el que poder consultar y recopilar todos los datos que
vamos generando.

Si lo que queremos es pasar las pruebas en Azure directamente y no pasarlas en un

entorno montado en Azure, tendremos que conectarnos a una cuenta en línea de Visual
Studio Team Explorer. Después seleccionaremos el proyecto de equipo donde queramos
ejecutar esas pruebas (añadiendo previamente el TFS al que conectarnos) y como último
paso ejecutar la prueba con Visual Studio Online.

Una vez que la prueba funcione y pase correctamente podremos ver con detalle el
informe de resultados y las gráficas que nos darán los datos exactos del funcionamiento
de nuestra aplicación:

Las pruebas de carga son una ayuda muy importante para determinar cómo se
comportará nuestra aplicación en la red con una serie de usuarios y sobre todo detectar
prematuramente un posible error de saturación que conlleve una caída del sistema que
nos pueda causar graves daños económicos y de imagen de cara al cliente final.

21. Cuando el tester tiene la razón.

Dentro de muchos proyectos, parece que el Testing es lo último, lo infravalorado, lo
que, si se hace, pues bien, y si no también... ¡QUE EQUIVOCACIÓN MÁS GRANDE!

El Testing, quieran o no ciertos gremios, es lo más importante y fundamental dentro

de un proyecto. Un tester es la persona que vela por la integridad, la calidad y el buen
hacer de un equipo y de todo un proyecto.

Me he encontrado a lo largo de mi carrera comentarios, infravaloraciones,

habladurías que no hacen más que estar equivocadas. Frases como "este es solo el
tester" o "no le hace falta un equipo muy potente, solo hace Testing" solo evidencian
que hay muy poca o nula información de lo importante que es nuestro trabajo dentro
de un equipo y de un proyecto.

La necesidad del Testing viene dada por la satisfacción del cliente, si se quiere que el
cliente final este feliz y no tengamos problema, hay que hacer probar de manera
organizada y bien estructurada, si no le damos importancia a las pruebas, al final el
cliente final estará descontento y en muchos casos incluso peligrará el proyecto
pudiendo llegar a ser cancelado.

La importancia del Testing viene dada por no infravalorar la opinión de la persona

que prueba. Si un tester dice que no se debería de subir o no pondría la mano en el
fuego por el correcto funcionamiento de una subida en concreto... ¡NO SUBAMOS! Al
final el asumir fallos o que una versión no funcione como debe solo nos traerá
problemas y dolores de cabeza.

31
 Seamos consecuentes y no infravaloremos su opinión, nos evitará muchos
quebraderos de cabeza.

El tester no siempre tendrá razón, pero jamás intentará perjudicar una subida o un
desarrollo. En la mayoría de los casos, ayudará a minimizar el impacto negativo y sobre
todo a que el proyecto tenga una calidad mucho mejor.

22. La importancia de un entorno estable de Testing

Cuando nos encontramos en un proyecto donde no se da importancia a los entornos
y no tenemos una estabilidad, la realización de las pruebas no es óptima y no podemos
garantizar al 100% nuestro trabajo.

Un entorno inestable reporta falsos negativos o también positivos, reporta errores

que al final no lo son, nos dificulta la tarea de acceder correctamente a ciertos módulos
de la aplicación y sobre todo hará que nuestras tareas se ralenticen o tengamos que
reprobar defectos que ocurren por la inestabilidad.

Una de las peores cosas que nos puede suceder (aparte de no poder acceder al
entorno) es que nos encontremos con falsos negativos o falsos positivos. Un falso
negativo es en realidad un defecto que no es defecto en sí, un defecto que nos sucede
por la inestabilidad del entorno, por incoherencia de datos o porque una subida del
equipo de desarrollo pueda haber estropeado el entorno y nos frene totalmente la
realización de pruebas. Un falso positivo nos puede ocurrir cuando creemos que está OK
y en realidad no es así, dándonos bastantes quebraderos de cabeza.

Otro grave problema de los falsos negativos o positivos es que, si llegamos a abrir
esos defectos y luego no ocurren, nos los devolverán los desarrolladores y perderemos
bastante tiempo en reprobar.

Para optimizar y garantizar nuestro trabajo al 100% necesitamos lo siguiente:

• Un entorno lo más parecido al de producción posible.

• Datos “reales” o en su defecto muy similares a los que podamos encontrarnos

en producción.

• Una base de datos con las mismas características que la de producción.

• Que el entorno sea únicamente de Testing, que no tenga interferencias de

desarrollo de ningún tipo.

Muchas veces un entorno inestable puede reportarnos la pérdida de muchas horas

de trabajo y, por lo tanto, que el visto bueno de la versión a desplegar se retrase por la
falta de validación.

32
 En muchos casos el entorno de pruebas es también un entorno de desarrollo, cosa
que jamás debería de suceder, ya que si por un casual, un check-in incorrecto es
propagado a este entorno y este se cae o deja de funcionar, las pruebas se verán puestas
en riesgo, además de que se necesitará una validación continua de todas las pantallas
ya que no sabremos exactamente qué es lo que se toca y lo que no.
Lo ideal para un entorno de Testing es tener versiones cerradas cada cierto tiempo.
Pongamos un ejemplo trabajando con PBI’s:

• Desarrollo termina una serie de tareas y hace check-in en su entorno. Así

constantemente con varias de estas tareas hasta completar un PBI o varios. El
equipo de Testing sigue realizando pruebas con su propia versión, en su propio
entorno, de momento inalterable.

• Una vez que Testing da el OK a esa versión, esta se sube al siguiente entorno o a
Producción. La validación finaliza y se puede garantizar que esa versión en
concreto está OK y es 100% funcional.

• Una vez que Testing ha dado el visto bueno, avisará al equipo de desarrollo para
que suba esa nueva versión para poder probarla en el entorno de Testing.
Mientras tanto desarrollo podrá seguir haciendo check-in sin problema en su
entorno y sin interferir en los demás entornos.

Trabajando con versiones cerradas y atómicas, hacemos que las subidas puedan estar
mucho más controladas y podemos acotar que tengamos que probar grandes
desarrollos en poco tiempo, más vale probar menos PBI’s y asegurarnos que probar más
y que el equipo de Testing se desborde.

Cuando estemos en un proyecto siempre debemos de luchas por que tengamos

nuestro propio entorno, así podemos asegurar casi en su totalidad una calidad
realmente buena en el trabajo que realizamos y que los factores externos no estropeen
nuestras pruebas.

23. Diferencia entre falso positivo y falso negativo.

En relación al artículo de ayer, he estado investigando la diferencia entre un falso
positivo y un falso negativo en la realización de pruebas. Este tipo de problemas nos
pueden ocurrir, como ya comentamos, en entornos inestables o que no sean del todo
herméticos.

La definición de falso positivo llevada a la informática es la siguiente:

"es un error por el cual un software de antivirus informa que un archivo o área de
sistema está infectada, cuando en realidad el objeto está limpio de virus; Esto también
ocurre en los navegadores de Internet cuando se descarga un archivo."

33
 La definición de falso negativo para informática es la siguiente:

"es un error por el cual el software antivirus falla en detectar un archivo o área del
sistema que está realmente infectada."

Estas definiciones se basan en los antivirus, pero si hablamos de pruebas, creo que el
resultado es prácticamente igual.

¿Cuándo hablamos de falso positivo?

Un falso positivo en Testing nos ocurre cuando probamos un módulo o sección de la
aplicación del proyecto y detectamos defectos cuando en realidad no lo son, por
inestabilidad del entorno, por datos de la BBDD corruptos o por alguna causa externa
que haga que el entorno no esté funcionando como debería.

¿Cuándo hablamos de falso negativo?

Un falso negativo llevado a pruebas nos ocurre cuando damos por válida una sección
o módulo cuando en realidad está fallando. Este tipo de fallos suelen ocurrir más por la
persona que está probando que a causa del propio entorno, aunque también nos
pueden ocurrir, en la mayoría de los casos por que tengamos datos que no cubran todas
las casuísticas posibles.

Este tipo de fallos que nos pueden ocurrir al realizar nuestras pruebas desvirtúan
totalmente los resultados y pueden hacer que la calidad del proyecto descienda
radicalmente. Es uno de los problemas más graves a los que nos podemos enfrentar los
que nos dedicamos al Testing.

No hay demasiadas maneras de evitar estos problemas, pero os voy a dar dos
soluciones que sí que pueden disminuir el riesgo de que ocurran.

Para los falsos positivos, tendremos que tener un entorno totalmente hermético, que
sepamos que hasta que nosotros no demos la orden de subir algo o de que la versión
cambie, tengamos la certeza de que estamos probando siempre con una BBDD correcta
y con nuestros datos bloqueados. También que sepamos que la versión que tenemos
desplegada en nuestro entorno no ha cambiado ni cambiará hasta que la demos el visto
bueno.

Para los falsos negativos, una de las pocas soluciones que os puedo dar es tener
preparados de antemano unos datos coherentes, correctos y sólidos, además de unos
casos de prueba estudiados, bien organizados y sobre todo estructurados para que
nuestras pruebas puedan ser todo lo buenas que deben de ser. Si tenemos un módulo
bien cubierto, con todas las casuísticas posibles contempladas y sin dejar ningún
agujero, casi al 100% estamos salvándonos de estos falsos negativos tan impactantes en
el proyecto.

Seguro que se os ocurren mil maneras más de evitar estos falsos positivos y
negativos, al fin y al cabo, el día a día es el que marca nuestras soluciones.

34
 24. Utilizar Firebug para facilitar la vida del tester
Una gran ayuda para el tester y para detectar errores "ocultos" es el uso de la consola.
En la mayoría de los casos suelo probar en Mozilla Firefox ya que habitualmente el
equipo de desarrollo utiliza Chrome por las herramientas del desarrollador que son
mucho más extensas que en otros navegadores y les facilitan la vida muchísimo e
Internet Explorer lo dejo para las pruebas automáticas en CodedUI por su
compatibilidad con Visual Studio.

Al utilizar Mozilla Firefox, recomiendo altamente el uso de Firebug, una sencilla y a la

vez completa consola que facilita muchísimo las pruebas en consola y donde ver las
llamadas realizadas con cada acción que hagamos en la aplicación a probar.

Con Firebug podemos ver cada llamada de manera ordenada e ir depurándolas por
si existiese algún error:

En el caso de que exista un error, quedará registrado en color rojo y podemos saber
al instante que es lo que ocurre y poder abrir el defecto con toda la información posible
para el desarrollador.

En este caso está fallando una referencia a un evento al pulsar un botón en una
aplicación y nos da este error en la consola de Firebug, si abrimos el defecto con esta
información, el desarrollador sabrá exactamente el problema y le será más fácil ir al
grano para solucionarlo.

Además de tener una consola podemos depurar código y algo muy importante es
poder ver las llamadas y el tiempo que tardan en realizarse:

Como vemos en el pantallazo podemos depurar todas las llamadas que se realizan y
el tiempo que tardan en ejecutarse, pudiendo reportar errores sencillos de rendimiento
o saber exactamente porque una página tarda en cargar más de la cuenta.

A mí, personalmente, la consola de Firebug me facilita muchísimo la vida a la hora de

hacer Testing de JavaScript, ya que de ninguna otra manera detectaré los fallos que
puedan surgir o el por qué no funciona un determinado botón.

Si estáis probando una aplicación web utilizar la consola para facilitaros la vida y si
encima esa aplicación lleva JavaScript con mucha más razón, encontrareis una manera
sencilla de detectar errores y no volveros locos para ver porqué suceden ciertas cosas.

25. Mejorar nuestro trabajo con un procedimiento de Testing

Cuando comenzamos un proyecto de cero o incluso, si entramos cuando el proyecto
ya está avanzado, tenemos muchas dudas e incertidumbre de lo que nos vamos a
encontrar, que organización tendrá, que metodología, forma de trabajo...Una solución
a todos estos males es la realización de un procedimiento de Testing para ese proyecto.

Un procedimiento siempre nos ayudará a encontrar una forma de trabajo acorde al

mismo, una ayuda de lo que tenemos y de lo que podemos hacer, de lo que hasta ahora

35
se ha logrado y lo que podemos aportar nosotros, mejorando el trabajo o ayudando para
que sea mejor.

Este tipo de documentos se pueden crear a nivel personal para ver a que nos
enfrentamos, ya que, habitualmente, donde entremos, tendremos a un responsable
directo que se encargará de velar por estos problemas, aunque en algunos casos,
siempre se le puede presentar para ayudarle y mejorar la vida a nuestros compañeros y
a nosotros mismos.

En ambos casos, este aporte nos ayudará siempre a ir un poco más lejos y a valorar
lo que tenemos hasta la fecha y lo que no, para poder ponerlo en práctica.

El primer punto que tenemos que tener en cuenta es como está actualmente el
proyecto, que puntos fuertes tiene, que puntos flacos y que es lo que se está realizando
ahora mismo. Una valoración propia de lo que se ve en tu día a día.

El segundo punto siempre tiene que ir dirigido a la línea que tiene que seguir el
proyecto en el futuro, qué medidas se pueden tomar para mejorar, que medidas hay
que reforzar y en que hay que seguir igual porque está funcionando (a veces, todo
funciona, no penséis mal). Este punto será decisivo ya que es donde vamos a poner todo
nuestro esfuerzo para que algo que no funcione cambie de rumbo y pueda ir del todo
bien. Siempre tenemos que valorarlo desde nuestro punto de vista y mirar alrededor,
no todo puede estar concentrado en nosotros mismos.

Una vez realizado este primer análisis de la manera actual de trabajo y las mejoras a
futuro, podemos comenzar con una metodología de trabajo dentro del programa que
utilicemos para hacer nuestras pruebas, por ejemplo:

Si estamos utilizando un gestor de pruebas, como Quality Center o Test Manager,

una manera de organizarse es crear un árbol de carpetas de pruebas donde organizar
los casos de prueba de manera correcta, organización por variantes, por módulos, por
funcionalidades...existen infinitas posibilidades.

Una buena manera de organizarse, aparte del programa que utilicemos, es una
nomenclatura en los defectos, que sea clara y concreta y que de un vistazo podamos
detectar de donde es el defecto, que variante o módulo es y en que entorno. Un ejemplo
podría ser:

[ENTORNO/EQUIPO] - [VARIANTE/MÓDULO/FUNCIONALIDAD] - [TÍTULO CLARO Y

CONCISO]

El entorno lo pongo, ya que, en algunos casos, se prueba en dos entornos, uno para
pruebas exploratorias y otro de preproducción, pero no llega a ser necesario en muchos
casos. También se puede definir el equipo, que puede ser de Testing o de aceptación
(todo funciona en base a la forma y manera de trabajar).

36
 Estas ideas son solo un caso básico de lo que podemos llegar a realizar, pero puede
ser el primer el primer paso para lograr una mejor y eficiente organización de nuestro
trabajo y en algunos casos el de nuestros compañeros o equipo.

26. Automatizando lo automatizable

Cuando hablamos de automatización lo primero que pensamos es hasta donde
podemos llegar, donde debemos de parar y que páginas son las más factibles de
automatizar.

En muchos de los proyectos en los que podemos trabajar, no tienen claro cuáles son
los límites de la automatización y el principal pensamiento es, todo es automatizable y
por lo tanto hay que automatizar el 100% de las pantallas. Un error muy común y muy
dañino para asegurar la calidad.

¿Se puede automatizar? Sí, claro, pero con cabeza. La automatización dependerá de
cómo es la aplicación, cuál es su complejidad y cuantas variables diferentes tengamos
en cada pantalla.

Si intentamos automatizar el 100% de las páginas, al final, tendremos el grave

problema del mantenimiento, que se nos irá de las manos, y si automatizamos las
páginas que no son necesarias, al final no valdrá la pena gastar tiempo y dinero en ellas.

Antes de automatizar nos tenemos que sentar tranquilamente a estudiar nuestras

pruebas manuales, cuales nos han dado más problemas y cuáles son, en la mayoría de
los casos, fáciles y simples y no tengan demasiadas combinatorias.

Una vez que tengamos separadas estas pruebas del resto, valoraremos la cantidad y
el tiempo que disponemos, para no pillarnos los dedos. Si estamos justos, seleccionamos
las más críticas y dejamos el resto para más adelante. Lo principal es buscar un término
medio entre el coste de realizar las pruebas y el tiempo que le vamos a dedicar,
sumándole aparte el tiempo que nos llevará el mantenimiento de las mismas. Es muy
sencillo, si automatizamos más de la cuenta, el tiempo de creación y de mantenimiento
se nos dispara, por lo tanto, es inviable llevarlo a cabo porque no tendremos tiempo
para otras funciones.

Cuando nos piden automatizar absolutamente todo, lo primero que se piensa es que
las pruebas manuales desaparecerán, un error que comete prácticamente todo el
mundo, simplemente hay que automatizar con orden y sin pensar que nuestras pruebas
manuales desaparezcan al 100%.

Mi principal consejo es que cuando automaticemos tengamos mucho cuidado de

valorar el tiempo que nos puede llevar y no saturarnos, ya que la dedicación absoluta a
la realización de pruebas automáticas siempre, puede llevar a abandonar la realización
de pruebas manuales y otras funciones y nos puede acarrear más problemas que
soluciones. Si somos dos o más, lo tenemos muy sencillo, uno se dedica a realizar
pruebas automáticas y el otro a las pruebas manuales y cada cierto tiempo rotaremos

37
para que ambas personas puedan dedicarse a ambas tareas.

27. Dando valor a la batería de pruebas de regresión.

Una de las peores cosas que nos pueden pasar en un entorno productivo es una
regresión, algo que funcionaba perfectamente y que, por una refactorización o un
cambio, deja de funcionar.

Cuando nos enfrentamos a regresiones, tenemos dos opciones, agachar la cabeza y

aguantar el temporal o tener una buena batería de pruebas de regresión que nos
aseguren que toda la aplicación en conjunto funcione como debe de funcionar.

Una regresión puede ser producida, en el mayor de los casos, por algún cambio
transversal en otro módulo y que haga fallar una parte de la aplicación que,
supuestamente, no se ha tocado.

Para evitar este tipo de problemas, tenemos que tener una buena batería de pruebas
de regresión. Esta batería de pruebas hará que tengamos que probar las partes más
problemáticas o ciertas partes transversales para evitarnos disgustos sin sentido.

Preferiblemente y bajo mi punto de vista, la batería de pruebas de regresión tiene

que ser y estar automatizada, así cada vez que tengamos un cambio de versión
podemos, de manera automática, lanzar estas pruebas para comprobar que,
efectivamente, todo funciona correctamente.

En cada sprint, nos podemos guardar un tiempo para seleccionar los casos que
observemos que sean regresivos y automatizarlos, habitualmente, pueden ser 4 o 5
como mucho, así que nos llevará poco tiempo y nos podemos ahorrar un tiempo muy
valioso en cada cambio de versión.

Un buena batería de pruebas tiene que tener indispensablemente todos los

elementos transversales que nos encontremos en la aplicación, todos los módulos que
tengan más uso o que sean más propensos a estropearse y en el caso de que podamos,
puede contener casos que reprueben defectos que sean graves y que puedan volver a
ocurrir, por eso es muy importante guardarnos un porcentaje de tiempo para
dedicárselo.

Gracias a este tipo de pruebas, podemos evitar uno de los grandes males que nos
encontraremos en los entornos de producción y que afectan gravemente la visión
positiva que pueda tener un proyecto.

28. Pruebas exploratorias, antes que nada.

Cuando nos presentan un entregable, antes de realizar unas pruebas exhaustivas,
deberíamos de realizar siempre unas pruebas exploratorias. Estas pruebas nos ayudan
a dar una primera vuelta y detectar errores tempranos, dejando total libertad al tester
y que empatice con la página a probar.

Las pruebas exploratorias no tienen por qué llevar un orden ni especificar unas

38
pruebas a realizar, sino que tratan de que la página se pruebe como si el tester fuese un
usuario más, pulsando botones, combos o guardando una página sin tener que seguir
un patrón de casos de prueba.
¿Cómo nos ayudan estas pruebas?
La principal ayuda que nos brindan las pruebas exploratorias es, además de la
libertad, el detectar errores tempranos que puedan ser solucionados antes de pasar
nuestros casos de prueba, creando así una validación más a las que normalmente se
realizan.

Un tester que realice pruebas exploratorias antes que se realicen las pruebas de
sistema con sus casos de prueba y sus formalizaciones, podrá trabajar mucho más su
imaginación y su iniciativa a la hora de ver más rápidamente errores o incluso a la hora
de pensar los posibles casos que cubran una página determinada.

Las pruebas exploratorias nos ayudan y nos enseñan a mejorar nuestros sistemas de
pruebas, nuestras maneras de probar, nos enseñan a tomar otro tipo de caminos y lo
mejor de todo es que pueden ser utilizadas como pruebas de caja negra y de caja blanca.

¿Cuándo hay que realizarlas?

Las pruebas exploratorias hay que realizarlas siempre después de tener creados los
casos de prueba de un módulo o sección en concreto, nunca antes y las deberíamos de
utilizar como una manera de comparar el resultado esperado que pensábamos que
ocurriría con el resultado final. El tester al fin y al cabo evaluará y observará de manera
crítica el módulo que está probando e intentará hacer todos los caminos posibles y que
se le ocurran.

¿Existen herramientas para Testing exploratorio?

Si, se pueden utilizar herramientas de grabación de video, captura de pantalla…por
ejemplo, Microsoft agregó en su herramienta Test Manager la pestaña de “exploratory
Testing” con la que podemos grabar la pantalla y los pasos que estamos realizando para
luego crear de manera automática un boceto de un caso de pruebas que podemos
agregar a nuestra batería.

Por otro lado, también HP agregó a su herramienta Quality Center el llamado

“Sprinter”, que realiza, prácticamente las mismas funciones que su competencia.

Las pruebas exploratorias, bajo mi recomendación, deberían de realizarse siempre,

ya que, además de contar con una validación más en nuestro rango de pruebas, nos
valdrán para expandir y mejorar nuestras formas de trabajo.

29. Repartir el trabajo de una manera eficiente.

Cuando estamos a cargo del Testing de un proyecto o dentro de un grupo de
profesionales, tenemos que tener muy claro cuál es la carga de trabajo que puede
soportar una persona y hasta dónde puede llegar, de esta manera, podemos controlar
la cantidad de defectos solucionables o que se van a solucionar dentro de una fase de
trabajo completa.

39
 Cuando abrimos defectos y nosotros mismos somos los encargados de asignárselos
a las personas de desarrollo, tenemos que conocer a la perfección las cargas de trabajo
que pueden asumir cada uno, ya que así repartiremos el trabajo más adecuadamente y
nos cubriremos las espaldas al poder solucionar más defectos y desarrollar nuevas
tareas.
La primera medida que hay que tomar, es saber cuáles son las colas de trabajo de
esos profesionales, haciendo querys de sus tareas y/o defectos pendientes, siendo
mucho más eficientes cuando se realizan de manera independiente. De esta manera,
con solo pulsar un botón sabemos cuáles son sus tareas y defectos asignados y vemos
los tiempos estipulados por el jefe de equipo.

Tenemos que tener claro que en la mayoría de los casos y lo que siempre es más
eficiente es guardar un 20% de cada desarrollador para la resolución de defectos, por lo
tanto, viendo los tiempos estipulados, calcularemos los defectos que tenemos que
asignar y dependiendo de la complejidad, redirigirlos a otro profesional para que se
pueda cubrir en esa fase de trabajo el mayor número de defectos posible.

Otra medida a tomar para buscar unos tiempos mejores es tratar con el jefe de
equipo a diario, pudiendo observar y charlar sobre los tiempos que ha decidido para las
tareas e ir viendo cuanto tiempo queda o como le están exigiendo desde arriba para
finalizar algún tipo de entregable. Sabiendo esto, respetaremos al profesional que esté
con esa tarea y podemos repartir el trabajo entre los demás.

Dentro de un equipo, no hay nada peor que sobrecargar a un desarrollador y que

cuando entre a su herramienta vea una lista de tareas o de defectos enorme. Cuando
esto sucede, la persona comenzará a ponerse nerviosa, intentará solucionar todo
deprisa para llegar a tiempo y la calidad de desarrollo bajará de manera abismal.

Cuando la calidad de desarrollo desciende, habitualmente por las prisas, nuestro

trabajo será más complejo y se nos empezarán a encolar tareas a nosotros mismos que
tendremos que probar corriendo, abriendo más defectos que de costumbre y a su vez
sobrecargando más todavía al desarrollador por la devolución de ese trabajo, pero
realizado.

Por lo tanto, siempre que vuestro proyecto os lo permita, intentar hablar de tú a tú

a cada profesional y no lo sobrecarguéis de trabajo ya que, al final, será peor en todos
los sentidos.

30. El error de no pensar en el Testing

Cuando se habla del tester, en muchos casos, se habla de esa persona que hace ese
trabajo que puede hacer cualquiera, ese trabajo que no es importante, que no es
especializado o que como no hace las maravillas que puede hacer un desarrollador, se
le ningunea como el que más. Gran error y equivocación total.

Por mucho que nos encontremos este tipo de cosas, esos comentarios no están más
que equivocados, no se dan cuenta que esa persona que hace pruebas les ha salvado y
les seguirá salvando día tras día.

40
 Un grandísimo desarrollador, una eminencia, un gurú del desarrollo, no es nadie, si
no tiene a ese humilde tester al lado que pruebe sus maravillosas líneas de código, abra
todos esos defectos y se solucionen para que una vez tenga en sus manos la aplicación
el usuario final, pueda tener buenas vibraciones y pueda realizar un uso correcto de la
misma.

A día de hoy hay que hacer entender que el tester no es especialista de desarrollo,
que quizá no sepa por qué pasa un determinado defecto que a ojos de un desarrollador
sea evidente o que, simplemente no sepa cómo se arregla, pero, a pesar de eso, sí que
es capaz de ver a simple vista un defecto que ni por asomo ha podido ver el desarrollador
al hacer sus pruebas o tiene el conocimiento suficiente para realizar una combinación
necesaria para probar y abrir defectos en algo que ni siquiera se había contemplado.

Habitualmente el Testing se ve como algo que no hace falta una especialidad, como
ya he comentado antes, algo que puede hacer cualquiera en cualquier momento y si
esto ocurre, lo más probable es que se le entregue al usuario final una aplicación
defectuosa que tendrá un futuro muy poco prometedor y sobre todo una valoración
negativa en las principales tiendas de aplicaciones donde pueda encontrarse.

Actualmente, aunque muchos no lo vean así, el Testing es necesario al 100%, sobre

todo cuando los usuarios son cada día más exigentes y sobre todo tan fugaces. Una
aplicación puede tener millones de usuarios, pero un solo día de error puede hacer que
la gran mayoría de estos se pasen a la competencia, haciendo casi imposible poder
volver a recuperar a la mayoría de ellos.

Los que nos dedicamos al Testing tenemos que tener siempre en mente que somos
los que hacemos que las cosas funcionen bien y cuando nos enfrentamos a un proyecto
en el que los tester son ninguneados, ir con la cabeza muy alta pensando que, sin ti, casi
seguro y por muchos gurús del desarrollo que trabajen en ese proyecto, estará abocado
al fracaso.

31. ¿Cómo reportas tus defectos?

Una manera de que se resuelvan de manera fácil los defectos es que su descripción
sea clara y fácil de reproducir.

Un defecto tiene que cumplir una serie de reglas para que el desarrollador pierda el
menor tiempo posible en entenderle y poder solucionarle:

• Su título tiene que ser corto y claro. Tiene que ir al grano. Si es posible, se pondrá
el entorno donde se ha encontrado y el módulo relacionado.

• La descripción tiene que ser breve y concisa. Que no tenga demasiadas florituras
y que contenga en si misma los pasos para reproducirlo, el navegador y la versión
del mismo y si puede ser la build en la que estamos probando.

41
 • Debería de contener todos los adjuntos que podamos, como mínimo una imagen
de la pantalla y si puede ser, un pantallazo del error en concreto en el código y
un video de reproducción de los pasos.
• Un defecto bien explicado y estructurado hará ganar un tiempo precioso ya que,
de esta manera, el desarrollador lo leerá e ira al grano, no tendrá que intentar
comprender que es lo que queremos decir.

Cuando introducimos los pasos, el mismo desarrollador, puede reproducirlo en su

máquina y así podrá ver exactamente qué es lo que está fallando. Esto mismo ocurre
cuando añadimos pantallazos, ya que, si se tuviese alguna duda al leer el texto, en el
pantallazo vemos donde está sucediendo el problema y se podrá ir directamente a esa
pantalla.

La velocidad de corrección de errores depende proporcionalmente de tu manera de

reportarlos, ganando tiempo siempre y cuando ayudemos al desarrollador.

Sobre todo, cuando reportemos un error, es preferible únicamente escribir los pasos
para reproducirlo, que contar la historia de cómo lo hemos encontrado y entretenernos
en florituras innecesarias para embellecer el texto, seamos ágiles y ayudemos a que el
proyecto tenga una velocidad adecuada aportando nuestro granito de arena.

32. Prestando nuestros casos de prueba

A la hora de realizar nuestros casos de prueba, tenemos que pensar que no solo
nosotros podemos trabajar con ellos, si no que se los podemos "prestar" al equipo de
desarrollo y también al equipo de aceptación.

Unos casos de prueba bien realizados podrán ser utilizados por todas las personas
del proyecto para apoyarse, por ejemplo, en la realización de las pruebas unitarias o de
integración. El equipo de desarrollo, podrá leer nuestros casos de prueba y entender a
la perfección que combinatorias se pueden encontrar a la hora de hacer sus pruebas y
pueden enfocarlas mejor e incluso hacerlas con más profundidad.

Una vez que el equipo de desarrollo utilice nuestros casos de prueba para realizar sus
pruebas unitarias, nosotros podemos "reutilizarlas" para comenzar a crear nuestra
batería de pruebas automatizada.

La ventaja de tener una batería de pruebas automatizada en base a las pruebas

unitarias de desarrollo es que podemos acceder a secciones del código que
posiblemente con una prueba automática de Testing no podríamos alcanzar.

La otra parte de prestar esos casos, es que el equipo de aceptación (producto,

proyectos o similar) los recupere para crear sus propios casos o reutilizar los nuestros,
mejorándolos para sus pruebas, introduciéndole datos más concretos de la parte del
negocio de la aplicación.

Gracias a nuestro trabajo previo, podemos facilitarles la vida a todas las personas del
proyecto, quitándoles algo de responsabilidad y aportando un conocimiento muy
42
importante que a nosotros mismos nos reportará experiencia de cara a otros grupos de
trabajo.

Como veis, la importancia que tiene el "prestar" nuestro trabajo a otras personas es
importantísimo, pero siempre hay que cumplir una regla esencial, nuestros casos jamás
deben de alterarse por ninguno de estos grupos, siempre se realizarán copias
independientes en el caso de que otro equipo quiera modificarlos o adaptarlos a sus
propias necesidades. Si no, nuestro trabajo puede quedar alterado y sobre todo
desvirtuado.

Lo más importante cuando realizamos nuestros casos de prueba es pensar que

muchas personas se pueden beneficiar de ellos, por lo tanto, tienen que tener una
calidad y una definición muy buena para que no se nos escape ninguna posibilidad.

33. ¿Usamos correctamente el nombre de proceso de desarrollo?

Cuando trabajamos en un modelo de desarrollo, tenemos que tener en cuenta que
la sección de Testing no puede ser independiente, siempre tiene que ir de la mano y en
conjunto con los desarrolladores y demás partes que colaboran en el proyecto.

Erróneamente, desde mi punto de vista, siempre se tiende a llamar "proceso de

desarrollo" a la forma de trabajo que se implementa en un proyecto, pero si miramos
más globalmente, desarrollo no es la palabra más exacta para definirlo, ya que hay
muchos más departamentos o secciones que participan en él. Más bien lo llamaría, por
ejemplo: "proceso de trabajo", "forma de trabajo" o "ciclo de trabajo".

Cuando pensamos en una nueva manera de implementar un proceso de trabajo en

el proyecto, tanto si es desde cero como si ya está avanzado y simplemente tenemos
que cambiarlo para que funcione mejor, tienen que convivir dos "subprocesos", que
ahora sí que llamarían "subproceso de desarrollo" y "subproceso de Testing". Estos dos
procesos tienen que ser independientes y a su vez dependientes, lo explico mejor:

Conceptualmente, los dos subprocesos son independientes ya que se tienen que

gestionar y crear diferenciados. Cada uno dependerá de un departamento, cada uno se
implementará con una serie de herramientas y cada uno tendrá prioridades diferentes,
pero a su vez, los dos son dependientes entre ellos ya que en ciertos puntos se tienen
que entrelazar.

Cuando se terminen ciertas fases del "subproceso de desarrollo", tendrán que

ponerse en marcha ciertas fases del "subproceso de Testing", como, por ejemplo, en el
caso de que un desarrollo de una determinada funcionalidad esté finalizado. En ese
punto "acabará" una fase del "subproceso de desarrollo" y se activará la fase de pruebas
de ella dentro del "subproceso de Testing".

Uno de los "errores" (entre comillas) de muchas implantaciones es que solo cuentan
con un "proceso de desarrollo" que, con el tiempo, se acaban cayendo por su propio
peso, ya que sin esa parte de Testing, está vendido. Por eso, opino, que hay que intentar
buscar otra nomenclatura para este tipo de procesos que puedan ser menos equívocos

43
y, sobre todo, encontrar una coordinación perfecta entre los que yo, personalmente,
llamo "subprocesos" (Testing y desarrollo).

Las personas que nos dedicamos a la calidad del software tenemos que intentar
entrelazar los dos subprocesos y buscar una afinidad entre ambos, para que todo vaya
más fluido y no nos encontremos con puntos muertos, que frenen el ciclo de vida de la
aplicación. Si esto ocurre, los primeros perjudicados seremos nosotros ya que un
proceso fluido y coordinado hace que la calidad del software sea mucho más elevada, el
trabajo de todo el proyecto sea más vistoso y, sobre todo, más efectivo.

34. Introducción al Testing metódico con Microsoft Test manager.

Gracias a la herramienta de gestión de pruebas de Microsoft, podemos implementar
de manera sencilla una manera de trabajar que nos permita gestionar nuestro trabajo y
que quede organizado en un solo sitio.

Test Manager es una herramienta que Microsoft sacó al mercado en 2010 y que poco
a poco se va implementando en cada vez más proyectos. En la actualidad podemos
trabajar con Test Manager 2013 que viene acoplado únicamente en la suite de Visual
Studio 2013 test professional y ultimate. Esta nueva versión dispone de algunas mejoras
que se pueden consultar aquí.

Tras una mínima explicación vamos a ver cómo nos puede ayudar esta herramienta:

• En primer lugar, nos permite crear un árbol de carpetas donde organizar a

nuestra manera los casos de prueba que estemos creando. Podemos tener
tantos niveles como consideremos y crear una estructura cómoda y que se
adapte al proyecto en que trabajamos.
• Podemos crear los casos de prueba a nuestro gusto sin excepciones y añadiendo
mejoras que nos servirán para ganar tiempo a la hora de ejecutarlos e incluso
crear posteriores, como en el caso de los pasos compartidos, que nos permitirán
escribir un caso único, automatizarlo y reutilizarlo en todos los casos de prueba
que creamos necesario.
• Crear una sencilla automatización basada en clics en coordenadas que nos
facilitará la vida y nos hará ganar mucho tiempo a la hora de reprobar, de rellenar
campos o, por ejemplo, de hacer clics en ciertos menús. Esta sencilla
automatización del caso de prueba se realizará la primera vez que pasemos el
caso y en posteriores repruebas de esos casos, podemos, simplemente, pulsar el
botón "play all" y test manager nos ejecutará el caso de manera automática.
Además, esto nos permite hacer una conversión desde Visual Studio y convertirla
a CodedUI para añadir o modificar en código lo que queramos.
• A la hora de ejecutar, Test Manager nos facilitará el trabajo en el sentido de que
podemos, en tiempo real, dar el OK y el KO, cambiar el caso de prueba, un paso,
abrir defectos y asociarlos a esa ejecución, agregar capturas de pantalla, vídeos
y un sinfín de información que se agregará automáticamente (en el caso de que
la habilitemos, claro). Esta información, a la hora de abrir un defecto, también
aparecerá, facilitando así, el trabajo de investigación al desarrollador.

44
 La herramienta de gestión de pruebas de Microsoft es un apoyo impresionante en un
proyecto, y sobre todo a la hora de hacer un Testing de calidad, organizado y sobre todo
metódico. Su integración total con Visual Studio, TFS y herramientas de desarrolladores
de Microsoft es una ventaja muy importante al poder capturar en ambos sentidos toda
la información, enlazarla y dejar una trazabilidad perfecta para que las métricas y datos
que exportemos sean reales y totalmente utilizables para mejorar el proceso interno del
propio proyecto.

Poco a poco iré escribiendo artículos de Microsoft Test Manager entrando en detalle
en todos sus módulos, características y sobre todo dando pistas y consejos a la hora de
configurarlo para que la ayuda sea completa y efectiva. Utilicemos este pequeño post
para adentrarnos en la herramienta y empezar a conocerla mejor.

35. Especializarse o morir.

Cuando hablamos del trabajo de un tester solemos pensar en una persona que se
pone delante de la pantalla de un ordenador y hace, de manera más o menos mecánica,
pruebas en una aplicación.

Bien, a grandes rasgos, esto es así, o, mejor dicho, esto era así hace muchos años,
cuando el Testing era una profesión emergente, poco conocida y se trabajaba según la
vieja escuela. ¿Qué ocurre a día de hoy? El tester tiene que estar especializado y ser un
especialista.

Durante los últimos años, la persona que se dedica a la calidad del software, tiene
que buscar una especialización en alguna de las ramas que este trabajo ofrece
(hablemos de pruebas funcionales manuales, automáticas, rendimiento, carga...) y a su
vez ser un especialista en ese terreno, con certificaciones, reconocimientos o incluso
cursos que hagan que pueda destacar por encima de otros trabajadores de su misma
rama.

Un tester especializado y centrado en un solo tipo de pruebas, podrá hacer destacar

su trabajo y, sobre todo, lo hará mucho mejor. Es mejor abarcar poco y bien, que querer
hacer de todo y de manera mediocre.

El primer paso que debe de dar un tester junior es elegir a donde quiere enfocar su
carrera, tanto si es a realizar pruebas de rendimiento o a automatizar casos de prueba
dentro de una aplicación, entre muchos más ejemplos. Una vez que está decidido este
paso, tiene que dedicarse exclusivamente a la realización de estas pruebas, siempre que
sea posible, llevando por ese camino su carrera, intentando coger la mayor experiencia
posible y a su vez, realizando exámenes y certificaciones que avalen su buen trabajo.

Desde mi punto de vista, a pesar de las empresas que quieren hacer negocio con
exámenes y reconocimientos en los que se estudia un temario que ellos aportan y dicen
que las cosas se realizan de esa manera por el simple hecho de que ellos lo dicen y
encima lo quieren globalizar, sí que hay ciertos reconocimientos que nos permitirán
abrir muchas puertas que antes ni siquiera se nos abrían, incluso poder llegar a ser uno

45
de los pocos profesionales que trabajen con una determinada herramienta o
metodología de todo un país.

Para mí, tendrían que existir cinco grandes especializaciones:

• Especialidad en pruebas manuales.

• Especialidad en pruebas automáticas.

• Especialidad en pruebas de rendimiento.

• Especialidad en pruebas de carga.

• Especialidad en pruebas de seguridad.

Un tester especializado vale mucho más que un tester sin más. Esto se puede
extrapolar a cualquier tipo de trabajo o de formación, ya que una persona que ha tocado
todos los palos de su rama, pero no se ha especializado en nada, sabrá de todo, pero a
su vez no tendrá unos conocimientos profundos en algo en concreto, que es lo que se
busca en el mundo laboral a día de hoy.

36. Utilizando las etiquetas de TFS y Test Manager 2013

Una de las nuevas funcionalidad de TFS 2013 y Test Manager 2013 son las etiquetas
o "tags" que nos van a facilitar la vida mucho más de lo que nosotros pensamos.

¿Qué son exactamente las etiquetas de TFS?

Las etiquetas son una manera de organizar el trabajo de una manera sencilla y
facilitar la manera de realizar consultas o marcar los elementos de trabajo que
utilicemos en nuestro proyecto.

¿Dónde están estas etiquetas?

Las etiquetas aparecen en absolutamente todos los elementos de trabajo que existen
en TFS, desde PBI's, tareas, defectos, casos de prueba...cualquier elemento de trabajo
puede ser etiquetado y organizado a nuestro gusto.

¿Qué aportan exactamente?

La mayor aportación de las etiquetas a un proyecto es la facilidad de organizar los
elementos de trabajo y a su vez de crear consultas lógicas y rápidas con solo definirlas
previamente.

Antes de las etiquetas teníamos que crear campos, crear métodos de trabajo
complicados o incluso organizaciones de elementos de trabajo en carpetas o con una
nomenclatura predefinida, pero ahora, con etiquetar todos los elementos que sean
iguales con una única etiqueta, podremos realizar un filtro con una consulta que nos
46
saque el listado completo de lo que queremos consultar.

Todas las ventajas que aportan se pueden caer por su propio peso si no creamos, en
base a las necesidades del proyecto, unas etiquetas predefinidas, porque si no, lo más
seguro es que cada uno escriba la palabra a su manera y tengamos etiquetas diferentes
para la misma solución, por ejemplo, podemos escribir en mayúsculas o minúsculas o
poner una tilde o quitarla. Por eso, es muy importante que tengamos claras las etiquetas
que usemos y dejarlas por escrito repartidas en todo el proyecto.
La recomendación que os puedo dar para el uso de etiquetas es que utilicéis etiquetas
claras, con una sola palabra y que definan lo que querías aportar. Siempre utilizar las
mayúsculas y aunque no suene bien, evitar símbolos de acentuación, esto acotará los
errores bastante. Un ejemplo de etiqueta pudiera ser INTEGRACION, donde al leerla
sabemos a qué se refiere, es clara, está escrita en mayúsculas que no ayudará para verla
mejor y le hemos quitado el signo de acentuación de la O para evitar duplicarla.

El funcionamiento de las etiquetas es exactamente igual que el que tenemos en

cualquier página web, blog o similar, simplemente la añadimos y listo. Microsoft ha
realizado un impecable trabajo con este tipo de mejoras para que la experiencia del
usuario sea mucho mejor y sobre todo más cómoda. Estoy seguro que cuando
comencéis a trabajar con etiquetas, si usas TFS o Test Manager, si por necesidades del
proyecto, no tengáis estas herramientas, las acabareis echando de menos.

37. Planificando el sprint del equipo de Testing

Después de unas tranquilas y merecidas vacaciones de semana santa, vuelvo a la
carga. Hoy vamos a comprobar la importancia de una buena planificación dentro del
sprint.

El equipo de Testing, para llevar un control del trabajo que está realizando, tiene que
tener una planificación y una organización independiente del equipo (siempre y cuando
este equipo sea independiente y no estemos hablando de organización del Testing en
cada equipo de trabajo).

Si estamos trabajando en un proyecto donde cada equipo realiza sus propios sprint,
independientes, el sprint del equipo de Testing tiene que empezar cuando empieza el
primer equipo y finalizar cuando finaliza el último equipo, habitualmente, usaremos la
regla de sprint de un mes como máximo.

Si los equipos de trabajo mantienen todos el mismo sprint, lo tenemos más fácil ya
que nos acoplaremos a esas fechas directamente, trabajando la primera semana en
creación de casos de prueba y similar y la segunda comprobando los desarrollos que nos
van entregando (siempre y cuando los sprint sean de 2 semanas).

Habitualmente, si trabajamos en un equipo de Testing que, de soporte externo a cada

equipo de trabajo, tendremos que acostumbrarnos a que los últimos días del sprint
anterior organicemos el sprint que vamos a comenzar y que la primera semana será para
preparar casos de prueba, datos...dando prioridad a preparar esos conjuntos de pruebas
que más adelante vamos a utilizar. Las siguientes o siguientes semanas iremos

47
recibiendo los nuevos desarrollos y utilizando estos datos para probarlos, abrir defectos
o probar todo lo que tengamos que probar. A esto se suman las repruebas, los defectos
solucionados anteriormente y una cantidad bastante grande de factores externos que
tenemos que tener en cuenta para no pillarnos los dedos. Siempre que podamos
avanzar en la preparación de esos datos, ganaremos tiempo por si un factor externo nos
quita horas de más.

Una de las cosas más importantes que tiene que tener un proyecto es una
planificación excelente en el departamento de Testing ya que la calidad del mismo
dependerá de él. Si desde el principio planificamos mal esta parte, todo se irá
desmoronando y al final el proyecto no saldrá adelante todo lo bien que debería. El
pensamiento más importante que hay que hacer entender es que Testing es la pieza
central del puzle de un proyecto, no queda otra.

38. La Calidad empieza en nosotros mismos

La definición de Calidad es el conjunto de propiedades inherentes a un objeto que le
confieren capacidad para satisfacer las necesidades implícitas o explícitas.

Esto por sí mismo no nos puede llegar a decir mucho, pero si pensamos en la calidad
alrededor de nuestras vidas, esa definición cambia y además nos hace recapacitar y
darnos cuenta que en muchos casos se nos ha olvidado que es y porque nos dedicamos
a ello.

Cuando nos compramos algo siempre buscamos que ese gasto de dinero nos valga,
que sea duradero, resistente, de buen material...en resumidas cuentas, que sea de
calidad.

¿Qué ocurre con nuestro trabajo? Exactamente lo mismo. Cuando una empresa se
gasta el dinero en algo, está buscando algo duradero, creado con buenos materiales
(bien programado), duradero (buen diseño), resistente (que no se caiga ni falle
fácilmente), en resumidas cuentas...busca exactamente lo mismo que nosotros en
nuestra vida diaria. Esto es extrapolable al trabajo realizado, evidentemente, un trabajo
de calidad, merecerá la pena pagarlo y por lo tanto el reconocimiento será mayor.

Los profesionales que nos dedicamos al Testing queremos encontrar la calidad en un

producto, pero a veces, nos olvidamos, que, para encontrar esa calidad, lo principal es
que nuestro trabajo también lo sea y si no aportamos esto, nos costará sacar a flote un
producto sin errores y que funcione a la perfección.

No podemos olvidar que la calidad empieza desde nosotros mismos y que no

podemos exigir esto sin que nosotros lo pongamos a prueba a diario, trabajando de la
mejor forma, con la mejor motivación y dando todo lo que podamos en nuestro día a
día para buscar esa satisfacción personal que nos será recompensada cuando el usuario
final utilice la aplicación.

Seamos consecuentes con lo que hacemos, desde nosotros mismos comienza la

48
calidad, nosotros en sí debemos ser esa calidad y poner en práctica esta idea nos
ayudará a que nuestro trabajo se realice mejor y más eficientemente.

39. Introduciendo una regresión en todos los ciclos de desarrollo

Cuando configuramos y gestionamos el tiempo de un ciclo completo de pruebas
dentro del sprint de desarrollo tenemos que pensar en guardar un porcentaje para las
pruebas de regresión. Al principio será muy costoso, porque habitualmente, nuestro
tiempo será más que limitado, pero al cabo de un tiempo, veremos los grandes
beneficios de la regresión.
Las pruebas de regresión se realizan para descubrir defectos que se producen con un
cambio del sistema, una subida errónea o algo que no se ha tenido en cuenta.

En muchos casos y según la teoría de ciertos libros, las pruebas de regresión son casos
que se realizan basados en un defecto y que en cada sprint probamos viendo que no
vuelve a suceder. Yo, en los proyectos donde he trabajado, siempre doy un paso más,
con los casos de prueba de alguna funcionalidad, siempre marco uno o dos (los básicos)
para agregarlos a estas pruebas de regresión. Así tenemos un conjunto de casos de
prueba, que, a falta de ser profundos, prueban todos los caminos de la aplicación y por
lo menos, podemos ver, que no fallan las cosas básicas.

Lo ideal es siempre intentar automatizar estas pruebas de regresión, pero lo habitual

es que no tengamos tiempo o equipo para realizarlo, así que, al principio, por lo menos,
con un esfuerzo extra, las pasaremos a mano.

A la hora de crear un sprint de Testing en base al de desarrollo, como ya dije

anteriormente, tendremos que dejarnos, al final de este, ese tiempo "extra" para pasar
estas pruebas, ya que su utilización mitigará muchos problemas en entornos de
producción.

Si en el proyecto que trabajamos, existe una build nocturna que actualiza el entorno
que sea con versiones nuevas, lo mejor es que intentemos automatizar estas pruebas
(al igual que las unitarias) y que se pasen siempre con ella y para rizar el rizo (que ya es
muy complicado) si estas pruebas no pasan en OK, la actualización del entorno no se
realiza porque existe algún tipo de fallo. Todo esto en un mundo ideal y sin prisas de
negocio, algo que es muy complicado de ver, aunque sí que conozco sitios donde lo han
conseguido.

Si mantenemos la política de comenzar a utilizar y gestionar bien estas pruebas de

regresión, posiblemente nos curemos en salud en muchos aspectos y tendremos un
entorno mucho más limpio de fallos colaterales.

40. Entrenando los sentidos con una metodología exploratoria

Quería volver a retomar el blog, del que he estado un poco desprendido por falta de
tiempo, para contaros algo que me pasó hace unos días y que me pareció muy
sorprendente. Fue así, porque, personalmente, me considero una persona muy
metodológica trabajando y cuanto más tiempo pasa, más me arraigo a eso, perdiendo
un poco la diversión de la prueba sin ataduras, digamos que, de la prueba exploratoria

49
por que sí.

Como algunos sabes, hace un mes y algo, así dos, me encargaron la tarea de ser el
responsable del área de Testing de la empresa, de llevar un equipo y de crear e
implementar una metodología de pruebas que asegure la calidad del proyecto mucho
más que antes.

Así que ya llevamos un tiempo trabajando así, introduciendo mejoras y con una
metodología definida y robusta.

Pues para mi sorpresa, llevando a cabo esta metodología, que nos está ayudando y
ampliando horizontes muchísimo, deje un poco de lado (un poco, no totalmente) esa
manera de sorprenderme cuando hago pruebas exploratorias, cuando pruebo una
pantalla según me parece, sin ataduras de casos de prueba ni de "organización".

Estaba, como ya os he dicho antes, hace unos días probando una sección de un
módulo. Me había leído el análisis funcional del PBI, lo había asimilado y había creado
unos casos de prueba en base a ello, hasta ahí, todo perfecto. Me puse a probar la página
con esos casos y bien, todo correcto, así que, en ese momento, casualidad de la vida,
tenía un punto de menos carga de trabajo, así que pensé, voy a darle una vuelta a la
funcionalidad por mi cuenta, voy a "divertirme", a trastear, como decimos algunos.

Y ¡sorpresa!, haciendo una combinación un tanto rara, descubro que esa pantalla no
hace lo que debe de hacer en un punto en concreto...me vuelvo al análisis
funcional...nada. No se hablaba ni una palabra de esa combinación...que raro...

Me levanto del sitio y voy a hablar con el desarrollador que ha implementado esta
funcionalidad, una persona, que, además, suele ser bastante metódica y es extraño que
deje algo al azar. Vuelvo a reproducir los pasos que di en esa prueba exploratoria y
¡doble sorpresa! resulta que esa combinatoria ni se había planteado, ni estaba definida
ni nadie había pensado en ella. Así que nos pusimos a trabajar enseguida y solucionamos
el problema.

¿Qué os quiero contar con todo esto? Que, aunque tengas un maravilloso
procedimiento de trabajo, que seas muy meteorológicos, no os olvidéis de esa
capacidad de sorprender que aportan las pruebas exploratorias, no dejes de probar a
vuestro parecer, sin ataduras, sin seguir unos pasos definidos.

Desde entonces, llevo dando vueltas a un paso más en la metodología de trabajo que
se está implementando al equipo y por extensión al proyecto, y me gustaría investigar,
probar o realizar un "piloto" de una metodología exploratoria que sea previa a la
aplicación de la metodología de Testing y que nos ayude a realizar esas pruebas que
saquen a la luz las combinatorias que no habíamos planteado, que nadie había pensado
en ellas. Evidentemente no será siempre, serán momentos muy concretos y en
funcionalidad pequeñas y muy cerradas, pero estoy seguro de que saldrán.

50
 Así que, iré creando una especia de "diario exploratorio" con las experiencias que nos
aportará esta manera de trabajar y os las iré contando por aquí. Sobre todo, no os
olvidéis de una cosa: ¡no dejes de lado vuestra capacidad de inventar con las pruebas
exploratorias!

41. El peligro de no dimensionar bien el equipo de Testing

Al pensar en el Testing como un apoyo al equipo de desarrollo, nos enfrentamos a
que no se suele dimensionar bien a las personas que van a realizar las pruebas.

En la mayoría de los casos, lo que sucede es que nos solemos quedar cortos en el
equipo, ya que se le da prioridad al desarrollo antes que a las pruebas y después ocurre
lo de siempre, que cuando el cliente da la colleja, nos pensamos mejor esto y damos
prioridad a la Calidad antes que a la Cantidad.

Cuando nos quedamos cortos en el equipo de Testing suele ocurrir que el trabajo nos
desborda y que no podemos hacer las pruebas todo lo bien que debemos y,
habitualmente, dejamos de lado automatizaciones y cosas menos prioritarias que sí que
podemos dar importancia si el número de personas del equipo es el correcto.

Un equipo corto de personal de Testing es un gran cuello de botella, porque no

soltará el trabajo tan rápido como se desea, siempre y cuando se lo permitan, porque lo
que sucederá, como casi siempre, es que la entrega sea en una fecha determinada y se
acabe probando rápido y con prisas.

Al contrario, si el equipo está sobredimensionado, tenemos el problema de gente

parada y de que, en la mayoría de los casos nos pisaremos unos a otros. Un equipo de
Testing más amplio de lo necesario dará la sensación de que su trabajo no es todo lo
importante que es y condicionará mucho la idea de realizar pruebas en el futuro.

En algunos casos, durante los años que llevo trabajando, he visto como el equipo en
el que trabajaba estaba escaso de personal y nos matábamos a trabajar, mientras que
otros equipos estaban más que dimensionados y daban la sensación de hacer más bien
poco. Este problema es más habitual de lo que parece, ya que, el tester está
infravalorado y se piensa que cualquiera puede hacer su trabajo, así que se paga poco y
la especialización es escasa, aunque el músculo de pruebas será muy grande.

Hace unos años tuvimos una mala época cuando se decidía externalizar todas las
pruebas a países como la India, que cobraban más bien poco, pero el resultado no era
del todo satisfactorio. Al final, es como todo, una especialización se paga y sino no se
conseguirán los resultados esperados.

A la hora de embarcaros en un proyecto siempre tener en cuenta ciertas reglas que

se dan en alguna metodología, como que cada cuatro desarrolladores tengamos un
tester, cosa que me parece exagerada. Habitualmente, lo ideal es que por cada seis o
siete desarrolladores tengamos un tester. Ese número nos resultará muy cómodo a la
hora de trabajar con soltura y sin embotellamientos.

51
 42. Realizando el Daily meeting con TFS
Cuando trabajamos con metodología Agile y con herramientas de gestión de tareas
como TFS, podemos enfocar la realización del Daily de una manera más sencilla
apoyándonos en esta herramienta.

Si realizamos las Queries necesarias, o incluso, trabajamos en el mismo panel del

equipo, podemos actualizar los PBI’s y las tareas en base al Daily y lo que comente cada
compañero. La realización de esta reunión diaria con dicha herramienta nos proporciona
una visión mucho más global que la que tenemos si utilizamos cualquier tipo de plantilla,
por ejemplo, un Excel.

A mí, personalmente, me gusta más trabajar con Queries que con el panel, ya que
tengo una visión más concreta de cada estado y me quito PBI’s que en ese momento
pueden no aplicar (porque estén en desarrollo o porque ni siquiera se ha comenzado a
trabajar con ellos).

En la primera querys, hago una búsqueda por los PBI’s que están listos para integrar
desde el equipo de desarrollo, hasta nuestro entorno y una vez que sabemos que trabajo
se ha realizado el ida anterior, podemos planificar ese mismo día y el siguiente,
aceptando esos desarrollos para probarlos.

En una segunda querys, revisamos lo que ya está en nuestro entorno y así nos
hacemos una idea del trabajo que hemos tenido y el que puede quedar pendiente,
valorando si realizamos el paso anterior o no (habitualmente esto lo hacemos antes).

En una tercera querys, revisamos los PBI’s que ya hemos dado el OK y que pondremos
en el siguiente estado para que se realicen las pruebas de validación. De esta manera
los PBI’s pasan a otro entorno de QA y el equipo de Producto/Negocio realizará sus
pruebas y validarán el producto que se les ha proporcionado.

Si trabajamos con ciertas herramientas que gestionan nuestras tareas tenemos que
evitar el duplicar trabajo y usarlas siempre, de este modo, nos quitaremos de un
plumazo la planificación diaria y la revisión del trabajo.

43. Cuando la cabeza no da para más.

De vez en cuando, a mí personalmente me ha pasado, estoy probando una nueva
funcionalidad o un desarrollo que me han pasado y no soy capaz de ver ni un solo
defecto, ni siquiera una mejora. Esos días grises en el que la cabeza no da para más.

Nos encontramos en un punto de frustración bastante alto y por más que lo

intentemos, nada, cero defectos y no vemos ni los más evidentes. En esos días, os
recomiendo dejar de probar, a mí por lo menos me funciona. No sé por qué sucede,
pero se cómo evitarlo, por lo menos en mi caso.

Cuando llevo un rato en el que no veo nada, no soy capaz de ver más lejos, paro. Me
dedico a reprobar defectos, a crear casos de pruebas, a leer PBI’s o funcionales, todo,
menos probar. Es completamente absurdo ya que me bloqueo cada vez más y la

52
frustración va en aumento.

Cuando me pasa eso, al parar y continuar al día siguiente, todo vuelve a su ser, vuelve
a funcionar y los defectos, mejoras y demás surgen por sí mismas, algo que vuelve a
darme esa vidilla y me ayuda a seguir durante horas, porque sí, me gusta encontrar
defectos, me gusta proponer mejoras que a nadie se le han ocurrido.

Cuando tenemos uno de esos malos días, lo mejor, de verdad, es parar, ya que si no
podemos dar por bueno algo que en realidad no funciona bien y liarla más que
solucionar cosas.

Os puede parecer una lectura sin fundamento, sin nada nuevo, sin técnicas de Testing
novedosas o herramientas que podemos utilizar, pero realmente todo eso no vale de
nada si nuestro día es malo y nuestra cabeza no da para más. Muchas veces es mejor
parar, respirar hondo y continuar al día siguiente, un buen consejo en ciertos momentos
nos puede ayudar más que un post sobre cómo, cuándo o con que probar.

44. Cuando la Juventud es un “problema”

En los años que llevo trabajando, en ciertos momentos me he encontrado que, por
culpa de la juventud, ciertos pensamientos o ideas no se tienen en cuenta tanto como
me gustaría y a veces, tiene que venir alguien con más experiencia o un rango
reconocido a decir exactamente lo mismo.

Poco a poco eso va cambiando, evidentemente porque la experiencia va en aumento

y cuando se deja cierta libertad, se dan oportunidades y uno responde, día tras día se va
teniendo todo mucho más en cuenta.

La juventud es una gran ventaja, un cúmulo de ganas, de entusiasmo, de comerse el

mundo, que en otro caso no aparece, pero es una lacra a la hora de hacerse escuchar y
sobre todo que te tengan en cuenta en ciertos sentidos. Muchas empresas dan una
confianza enorme, seleccionando candidatos jóvenes y motivados para realizar tareas
que por su experiencia no debería de ser así, pero que, en ciertos momentos, dan el
mismo o mejor resultado.

Tras esa confianza y ese buen hacer, a mi parecer, existe un recelo al quizá meta la
pata, al quizá lo que dice puede no ser lo correcto, al no se ha pegado lo suficiente en
algunos proyectos y no dará la talla, no es así.

Un profesional joven pero capaz y capacitado puede comerse al profesional más

experimentado y sacar el trabajo mucho mejor y con ideas innovadoras que, en algunos
casos estos últimos pueden llegar a estar obsoletos.

La sangre nueva que cubre el mercado laboral tiene que demostrar y luchar día tras
día, como el que más, para hacer ver que, en ciertos momentos, se puede tener razón y
se puede dar la talla al 200%, eso sí, el paso principal lo tienen las empresas, que tienen
que apoyar este cambio y dar la oportunidad a la juventud, en mi caso, solo puedo dar
las gracias por la confianza ciega que han puesto en mí y espero que poco a poco todos

53
tengamos las mismas oportunidades para demostrar que valemos muchísimo.

La juventud viene pisando fuerte, solo hay que dejarla hacer.

45. Testing con TFS vol.1: Sacando partido al panel principal de TFS del
equipo.
Como TFS es la herramienta del proyecto y en la que me he basado para realizar el
procedimiento de Testing en él, quiero realizar una serie de post relacionados, para
mostraros pantalla por pantalla el rendimiento y el partido que se le puede sacar a esta
gran herramienta (más pensada para desarrollo) pero que se puede adaptar
perfectamente a un equipo de Testing.

En el panel principal he creado una serie de consultas indispensables, donde poder

ver con números, que entregables tiene que probar el equipo, que entregables se han
entregado a validación y que entregables están pendientes de ser aceptados para que
podamos probarlos próximamente. En la mayoría de los casos os presentaré pantallazos
genéricos, ya que por confidencialidad no puedo mostraros toda la información.

Como veis en la imagen podemos configurarnos unas Queries gráficamente donde

ver de un vistazo cual es nuestro trabajo actual y para los próximos días, dentro del
sprint.

Encima de estas Queries, veremos el gráfico de ítems del Backlog, que se pintará en
verde si no superamos la capacidad del equipo o en rojo si estamos superando las horas:

Como veis y os he comentado antes, a día de hoy tenemos horas de más en el sprint
ya que se nos han ido de tiempo algunas tareas, cosa que se arreglará realizando una
post planificación (incluso este incremento se puede dar porque no hemos ajustado de
manera correcta alguna tarea, es algo asumible).

Justo al lado de esta gráfica podemos ver el sprint actual de manera minimizada, si
pulsamos en ella, podemos observarla más en detalle y nos mostrará el trabajo restante
y los días que nos quedan:

Evidentemente el trabajo ideal es la diagonal. Como vemos el pico que sobresale al

final, en relación a la otra gráfica, vemos que el incremento de las horas es causa de este
pico de trabajo que tenemos a mitad del sprint.

Como os comentaba anteriormente y justo por debajo, me he configurado unas

gráficas en formato círculo donde poder ver el número de defectos tiene cada equipo
del proyecto y en qué estado están, de esta manera el equipo nada más entrar, verá los
que tiene que dar el OK.

Otro tema que podemos utilizar para darle rapidez y agilidad al equipo es la sección
de Trabajo:

54
 Si pulsamos en “Crear nuevo” nos aparecerá un desplegable con todos los tipos de
elementos de trabajo configurados en el proyecto que podemos crear, de esta manera,
de manera rápida abriremos defectos, PBI’s, tareas, casos de prueba o lo que
necesitemos. Tras crearlo, aparece una lista donde veremos los últimos elementos
creados. Así accedemos a ellos para configurarlos o enviarlos a un equipo al momento.

Por último, la parte que también sacaremos partido y utilizaremos, será en la sección
de “otros vínculos”, el enlace “configurar programación e iteraciones”.

Al abrirlo, veremos una pantalla como esta, donde configuraremos los Sprint del
equipo y las fechas de inicio y cierre.

Dentro de este primer volumen de Testing con TFS solo os he enseñado la pantalla
principal, que no tiene demasiado, pero es muy importante a la hora de darle al equipo
rapidez y agilidad para mirar el trabajo que tienen de un vistazo. De hecho, en el post
XXX os comenté como utilizábamos TFS para la realización del Daily. Simplemente
utilizando esta sección, se hace rápido y le queda claro a todo el mundo su trabajo.

46. Educar al equipo para que sea auto gestionable.

Cuando creamos un equipo multidisciplinar y proactivo en el que confiemos para que
las tareas las realicen por sí mismos y puedan gestionar su tiempo, tenemos que dar un
paso más, que sea auto gestionable.

Un equipo auto gestionable hace que la gente que lo forma, pueda recoger tareas y
llevarlas a cabo sin la necesidad de estar preguntando constantemente a su responsable
y pudiendo gestionar su tiempo de forma más eficiente.

El responsable de un equipo tiene que ser, bajo mi punto de vista, un gestor de

personas, un gestor de eficiencia y de felicidad de su equipo. El bastón de mando no
tiene que ir dirigido a imposiciones y a gestionar el tiempo de las personas sin saber
cuánto terminarán en realizar las tareas, si en las nuevas metodologías se deja que los
profesionales planifiquen el tiempo de sus tareas, ¿porque no dejarles una gestión
completa de las mismas?

Cuando estamos a cargo de un equipo tenemos que proporcionar las herramientas

correctas y los procedimientos para que el equipo trabaje lo mejor y más cómodo
posible.

Cuando un equipo sabe gestionarse a sí mismo el responsable de equipo tendrá la

tranquilidad de que gracias a esa proactividad, en el caso de que esta persona no se
encuentre disponible y no pueda priorizar el trabajo desde el Daily, el equipo podrá
coger esas tareas y continuar con ellas.

Esa autonomía por parte del equipo nos dará una fluidez y una rapidez que no
podemos encontrar con un equipo dibujado de la manera tradicional.

Cuando realizamos esta serie de acciones, e equipo busca el apoyo del responsable

55
para priorizar las tareas en base a la criticidad, para preguntar dudas, para que se
solucione algún impedimento para realizar su trabajo, pero el mismo, puede, después
de esa planificación general y la re planificación diaria que se puede hacer en una
reunión tipo Daily, recoger las tareas asignadas y sacarlas adelante de forma continuada
sin necesidad de que el responsable tenga que estar pendiente a cada hora del trabajo
realizado.
Todo esto se consigue, en primer lugar, con una buena planificación previa al inicio
del ciclo de pruebas o de desarrollo y en segundo lugar con una buena "educación" de
todo el equipo desde el principio.

No os voy a descubrir nada nuevo y seguramente cada uno gestione a su equipo de

la mejor manera posible y no sea necesario nada de lo que escribo, pero mi consejo, es,
sobre todo, que se realice un sólido procedimiento de QA que esté en continua
actualización durante los 5 o 6 primeros Sprint para ver posibles fugas y corregirlas. Iré
ampliando más este tema cuando disponga de más tiempo.

47. Ayudando a reconducir el camino de las empresas

Desde siempre, en este país al menos, existe una corriente de trabajo en la que la
realización de pruebas no es un objetivo prioritario dentro de los proyectos que se lleven
a cabo. Poco a poco, en los últimos años hemos ido reeducando a las empresas para que
el Testing sea el eje principal en todos sus elementos de trabajo.

Años atrás, prácticamente el 100% del presupuesto que tuviese un proyecto estaba
destinado al desarrollo, a meter más y más gente que picara código y que realizara todo
lo más rápido posible y pudiera subirse a producción. Esto ha sido un error que se ha ido
arrastrando a lo largo de muchos años pero que está terminando cada vez más.

A día de hoy, muchas empresas van repartiendo ese presupuesto para la realización
de pruebas por un equipo especializado y asegurarse la correcta subida a producción de
los desarrollos realizados. Hay una entrevista muy interesante a Rick Marselis que nos
dice que entre el 30 y el 40 por ciento del presupuesto se destina a revisar proyectos
que han salido mal a producción.

Habitualmente, como se están implantando nuevas metodologías, aparece un tester

(o varios) en cada equipo, aunque, personalmente, yo prefiero un equipo de Testing
agrupado que pueda realizar pruebas transversales y no centrarse en un único
desarrollo. También aparecen equipos multidisciplinares en los que los desarrolladores
cambian el rol y realizan pruebas, esto, como ya he hablado muchas veces tiene sus
ventajas y sus inconvenientes, no voy a entrar en detalle.

Como suelo decir, prefiero que se realicen pruebas sea como sea y de la manera en
la que la empresa esté cómoda, que no realizar ninguna. Incluso si una empresa aún
tiene una mentalidad más antigua y no tiene ningún tester en plantilla, aceptaría que
los desarrolladores realicen pruebas unitarias o de integración.

Los profesionales que nos dedicamos a esto, tenemos que tener claro que nos
enfrentamos día tras día al difícil camino de demostrar que nuestro trabajo es mucho

56
más valioso de lo que parecen y tenemos que reeducar a las empresas poco a poco para
que se vayan realizando pruebas.

La manera más fácil de que esto se lleve a cabo es realizar buenos trabajos en algunas
empresas en las que la competencia no realice pruebas o no realice las suficientes.
Cuando la satisfacción de sus clientes suba y la de la competencia baje, perdiendo
clientes por esa razón, esas empresas tendrán que ir realizando una cultura de pruebas
para mantener el nivel de sus principales competidoras.

Si comparamos la realización de pruebas que se hacían hace 10 o 15 años con lo que

se está realizando ahora, el porcentaje de cambio es abismal y sigue en aumento. Esto
como ya he comentado anteriormente es a causa de que el usuario final cada vez es más
exigente y cambiante cuando encuentra un fallo o no puede realizar una acción en una
aplicación o software determinado. Según TICBeat (y es una noticia de 2013), las
empresas aumentaban su inversión en TI un 23% para la Calidad del Software. A fecha
de hoy esa inversión sigue en aumento y en muchos casos puede superar el 50% del
mismo.

La competencia es brutal y el no estar al día puede hacer que se desaparezca por

completo. La reeducación de las empresas es un trabajo de todos y sobre todo de ellos,
cuya mentalidad tiene que cambiar radicalmente.

48. Realización de una regresión en Producción

Cuando se realiza una nueva subida a producción, el equipo de Testing siempre tiene
que realizar una regresión para mantener la estabilidad del mismo y evitar que
aparezcan errores que se han producido en la misma subida.

¿Dónde realizamos esa regresión?

Nunca hay que hacer la regresión en el mismo entorno de producción. Nunca hay que
probar en el entorno del cliente, bajo ningún concepto y todo lo que sea diferente a eso
es un error.

Para realizar las pruebas tenemos que tener un entorno de "pre despliegue" o en
algunos sitios llamados "staging" (puesta en escena), que simplemente es un entorno
clon de producción en el que podemos tocar sin problemas.

Este entorno tendrá exactamente la misma base de datos y exactamente el mismo

código que se va a subir a producción y por lo tanto todo lo que probemos allí es lo que
va a subir. De esta manera nos curamos en salud y podremos hacer una pequeña
regresión por si existiese algún tipo de error.

¿Cómo realizamos la regresión?

Esta regresión tiene que tocar todos los puntos "críticos" de la aplicación y saber
exactamente donde está el foco de utilización en ese momento.

La regresión tendrá puntos comunes que se tienen que pasar siempre y en cada
subida entrarán pruebas específicas para comprobar los puntos que se suben en ese

57
momento.

Cuando tengamos programada una subida a producción, hay que hacer una subida
previa el día anterior a este entorno para realizar esta regresión y el equipo de Testing
se dedicará al 100% a estas pruebas.

El resultado de las pruebas determinará el resultado de la subida y si hay que

retrasarla para arreglar algún imprevisto. Esto no debería de pasar ya que se han
realizado las suficientes pruebas en entornos anteriores y los casos de prueba estarán
en OK.

Nosotros, en el equipo, marcamos ciertos casos que nos resultan más "críticos" y que
tenemos que probar si o si para garantizar el buen funcionamiento de la aplicación (por
lo menos mínimamente), así vamos sacando, sprint tras sprint, una batería de regresión
contundente que nos determinará el buen estado de una subida.

Siempre recomiendo la realización de esta pequeña regresión final para asegurar más
aún el resultado de una subida, ya que entre entornos se puede haber desvirtuado el
código y tener algún problema, aunque en la subida posterior también podría ocurrir,
por lo menos podemos quedarnos más tranquilos y que los usuarios finales no tengan
ningún disgusto.

49. El equipo de trabajo en los meses de verano

Desde junio hasta comienzos de septiembre comenzamos a tener problemas a la
hora de tener activos en nuestros equipos. Comienzan las benditas vacaciones, época
para disfrutar, relajarse y, sobre todo, desconectar.

Pero tenemos un problema, ¿qué pasa en esos meses cuando nuestro equipo está
bajo mínimos? La respuesta es sencilla, pivotar, priorizar y jóvenes talentos.

Una de las ventajas de los meses de verano, es que al igual que nuestro equipo, los
equipos de desarrollo también están diezmados, por lo tanto, el trabajo que llega es
menor, pudiéndose asumir con más facilidad. Aun así, tenemos que priorizar muy bien
las vacaciones.

Primero, hay que intentar que el 50% del equipo esté siempre, repartiendo las
semanas de vacaciones entre todos para ver cuál conviene a cada uno. Nunca debería
de bajar a un 20% el número de activos trabajando ya que peligraría la entrega del
trabajo y nuestros compañeros sufrirían una presión innecesaria en meses que
supuestamente suelen ser más calmados.

Hay veces que no es posible realizar una repartición cualitativa de las semanas de
vacaciones y el porcentaje puede bajar del 50% ya que varios miembros se pueden pisar,
entonces, lo mejor que podemos hacer es asumirlo y dejar que se vayan, siempre y
cuando no baje el porcentaje del 20%. Más vale un profesional contento y motivado y
no un profesional quemado y con un gran malestar por no haber podido compatibilizar

58
las vacaciones con su familia. Es preferible asumir entre los que se quedan algo más de
trabajo que "obligar" a los profesionales a no poder disfrutar de sus merecidas
vacaciones.

Una vez que tenemos esto controlado, en segundo lugar, tenemos que tener muy
claro el trabajo que va a llegar. Tenerlo todo priorizado y estar muy atento de que se
guarda cada equipo para saber qué semanas o días van a ser más problemáticos. Como
ya digo, los equipos de desarrollo suelen estar diezmados y es muy probable que la carga
de trabajo sea mínima (al menos hasta la segunda semana de agosto, después puede
aumentar ya que en algunos proyectos quieren tener mejoras finalizadas para lanzarlas
en septiembre).

Después de que hemos recopilado todo el trabajo pendiente y que se va a realizar en

estos meses, tenemos que pivotar al equipo en función de la prioridad que se le dé a los
entregables. Es preferible pivotar a la gente para probar algo prioritario detenidamente
y dejar lo demás para mañana que intentar probar todo con poca gente y que no este lo
suficientemente probado.

Una vez que tenemos claro que el equipo tiene que pivotar todo lo posible, tengamos
otra idea en la cabeza: "jóvenes talentos".

Desde mi punto de vista, en estos meses de verano, tenemos que tener en cuenta a
jóvenes que están adentrándose en el mercado laboral y que quieren formar parte de
la rama de trabajo a la que nos dediquemos. Siempre deberíamos de intentar guardar
algo del presupuesto o tener cerradas pequeñas contrataciones o prácticas (entiéndase
prácticas como algo beneficioso para el profesional, no lo que suele pasar cuando se
sangra a la gente...), ya que estos jóvenes talentos pueden convertirse en activos muy
importantes después del verano y podemos ir formando un equipo motivado y con
confianza (llegando a los meses de más trabajo con un abanico amplio de
conocimientos).

Se debería de hacer un llamamiento a las empresas para que tengan en cuenta esta
idea, ya que muchas veces no se dan las oportunidades necesarias a los jóvenes. No se
puede salir de estudiar y que te pidan experiencia, la experiencia se gana trabajando,
por lo tanto, aprovechemos estos meses en los que todos estamos más tranquilos para
dar esas oportunidades y abrir puertas en el mercado laboral a profesionales para
evitarles, en la medida de lo posible, problemas que hemos tenido la mayoría en muchos
sentidos.

50. Mi gran amigo DEV

A pesar de lo que se escucha a veces por este mundillo, en cada proyecto en el que
estemos, tenemos un gran aliado sentado, posiblemente, a nuestro lado: El DEV (o
desarrollador).

El desarrollador es esa persona que está en manada en los proyectos, que nos supera
en número y que trabaja de sol a sol para sacar una aplicación adelante mediante sus
infinitas (y soporíferas, a veces ;)) líneas de código.

59
 Es esa persona que cuando no han trabajado con Testing, según entras por la puerta
notas sus ojos clavados en ti con una mezcla entre "que narices hace este ti@" y "como
me abra más de dos defectos le mato".

Ahora, fuera de broma. El desarrollador es nuestro mejor aliado dentro de un

proyecto. Es a quien tenemos que ganarnos desde el principio y el que nos arreglará los
defectos de la mejor manera posible en base a nuestras peticiones.

Cuando trabajamos dentro de un equipo de desarrollo, siempre tenemos que buscar

su ayuda y ser lo más políticamente correcto con nuestros defectos, ya que son ellos los
que nos los arreglaran, los que nos escucharán las peticiones y los que, cargados de
paciencia, intentarán adaptar nuestras mejoras para que el usuario final tenga una
experiencia mucho mejor.

En mi vida laboral he trabajado en muchos proyectos diferentes, con distintas

metodologías, diferentes formas de trabajo, en equipos de desarrollo, en equipos de
Testing, con mis propios equipos...muchas maneras de trabajar, pero siempre he
encontrado el apoyo incondicional del desarrollador que sabe que le ayudaremos a
mejorar su trabajo y, por lo tanto, ellos a nosotros.

De la gente de desarrollo he aprendido muchas cosas, desde herramientas que

desconocía que me han ayudado a detectar defectos ocultos, maneras de leer el código,
integraciones con él, buenas maneras a la hora de automatizar...infinidad de cosas
aprendidas y por aprender.

Cuando llevamos un tiempo en un proyecto que no se había realizado un Testing

propiamente dicho, el desarrollador comienza con algo de desconfianza, pero después
confía ciegamente en nuestro trabajo y sabe que su desarrollo subirá a producción y lo
podrá utilizar el cliente final con una calidad excelente y sin problemas.

Mi recomendación, muy sincera, es que no tengáis al desarrollador como un enemigo

ni nada por el estilo, podemos aprender mucho de ellos y también enseñarles a
implementar calidad en su trabajo. En el proyecto donde nos encontremos, el
desarrollador es nuestro mejor amigo.

51. El tablón como apoyo a nuestro trabajo

Desde que salieron a la luz las nuevas metodologías, cambios en los métodos de
trabajos tradicionales y demás, se han puesto de moda los tablones de trabajo. Nada
más lejos de la realidad, estos se han utilizado desde siempre, pero con diferentes
formas y especificaciones.

Un panel de trabajo o pizarra de tareas (como se conocía desde hace años) no es más
que un apoyo visual para que el equipo se pueda gestionar mucho mejor. Hay una serie
de reglas para que el panel nos diga algo, pero cada uno debería de adaptarlo a su
proyecto o equipo como mejor le funcione.

60
 Un ejemplo de tablón es el que usamos en el proyecto actual. Es simplemente un
apoyo a la aplicación, que es TFS y que de un vistazo podamos ver cómo está la situación
del trabajo en el Sprint.

Como referencia al panel de arriba, lo ideal es, si se trabaja con una herramienta del
tipo TFS, Jira Agile (Greenhooper), RedMine, HP QC o Test Manager, entre otras muchas,
es sacar las gráficas adecuadas a nuestro proyecto y que a los integrantes del equipo le
den una información concreta. En mi caso tenemos gráficas de velocidad, de flujo
acumulado, de carga de trabajo, el resultado de las pruebas y comparaciones entre el
sprint actual y el anterior.

Estas gráficas nos darán una idea de lo que hemos estado haciendo en el sprint
anterior y lo podemos ir comparando al trabajo que tenemos actualmente, así veremos
si tenemos que coger otro rumbo o seguir igual para que sprint a sprint nuestro equipo
mejore.

Justo al lado de las gráficas del sprint tenemos una pequeña leyenda de que significa
cada cosa en el tablón y debajo un tablón independiente para las tareas internas del
propio equipo. Este tablón es exclusivo para nosotros y tiene un flujo típico y sencillo de
"To Do, in progress y Done".

Para facilitar el trabajo de los compañeros también he minimizado el flujo de trabajo

y explicado con breves notas los pasos por si existe alguna duda que lo puedan consultar
rápidamente.

En el tablón grande, donde ya entra todo el proyecto (aunque el panel es exclusivo

del equipo y lo configuro y mantengo según me conviene), tenemos cuatro columnas de
estado y cuatro columnas de equipos. En las cuatro columnas de estado copiamos el
mismo flujo de trabajo que tengamos y así trabaja remos de manera adecuada.

Cada Post It es un PBI diferente y en el viene explicado a donde pertenece

(funcionalidad), el ID y la persona que se encarga de ello (esto todavía no lo he
implementado y tengo en mente hacerlo en breve, aunque también he pensado
adjudicar a cada uno un color para que sepan cuáles son los suyos).

Si el PBI tiene defectos le ponemos una etiqueta azul para saber que está bloqueado
en nuestro entorno y si el PBI es prioritario le ponemos una etiqueta verde (estas
etiquetas posiblemente sufrirán cambios ya que he tenido que utilizar los que hay ahora
mismo en papelería).

Hay muchas maneras de crear un tablón y de adaptarle a nuestro proyecto. No os

cerréis a ideas que os dan un libro o un manual ya que en muchos casos no valdrán u os
será demasiado engorroso actualizarlo o llevarlo a cabo.

52. Automatizar con CodedUI

Cuando tenemos una versión estable de nuestra aplicación, nos encontraremos con
un camino nuevo que podremos empezar a utilizar y sacar el 100% del partido. Es la

61
automatización.

La automatización de pruebas de software es una manera de ahorrar en tiempos y

en costes a largo plazo y que nos permite poder comprobar de una manera muy robusta
y optimizada, la aplicación en la que trabajemos.

Desde mi punto de vista, una buena batería de automatización contará con los
caminos felices y los casos de regresión, no con validaciones complejas, excepciones,
caminos extraños o puntuales. Siempre hay que intentar mantener una batería de
pruebas que sea lo más completa posible en ese sentido.

Para automatizar, si además trabajamos con entornos Microsoft o relacionados con

el mismo, siempre recomiendo utilizar CodedUI.

¿Qué ventajas se pueden encontrar en CodedUI?

• Está totalmente integrado con la suite de trabajo de Microsoft (Visual Studio,
TFS, Test Manager, IExplorer, Edge...entre muchos otros).
• El código es bastante permisible, tiene varios caminos para realizarlos, se puede
generar automáticamente o se puede picar desde el principio, personalizándolo
a nuestro parecer.
• Se pueden utilizar los Laboratorios de MTM y de esta manera reutilizarlo para
todos los entornos y combinatorias posibles o que quisiéramos cubrir.
• Se puede crear una total independencia con cada test creado, siendo muy
personalizable y atómico.

Para comenzar a automatizar en CodedUI tenemos que agregar una Prueba de IU

codificada desde el explorador de soluciones de Visual Studio.

Después de agregarla, podemos utilizar el grabador de CodedUI que es muy sencillo

de utilizar:

Este grabador tiene un botón similar al de REC, como vemos en la captura de pantalla
y podemos comenzar a grabar los pasos que vayamos realizando en el navegador o en
la pantalla.

Una vez que estemos grabando con el grabador de acciones, podemos añadir
aserciones o más acciones con un simple click de ratón (pulsando al icono del círculo).

Después de añadir la acción o la aserción, pulsaremos "generar código" y se creará el

CodedUI de la prueba que acabamos de grabar con sus pasos correspondientes, un
ejemplo es el siguiente:

[CodedUITest]
public class CodedUITest1
{ ...
[TestMethod]

62
 public void CodedUITestMethod1()
{
this.UIMap.diarioDeUnTester();
this.UIMap.VerifyResultValue();
// To generate more code for this test, select
// "Generate Code" from the shortcut menu.
}
}
Como podemos comprobar, es un código muy sencillo y limpio, que nos permite
personalizar todo lo que queramos en cualquier momento.

Si tenemos una acción ya grabada y codificada, la podemos editar en cualquier

momento, abriendo, en este caso el archivo UIMap.uitest.

También nos permitirá validar un control (por ejemplo, que en un campo de texto
aparezca el valor correcto). Solo hay que añadir a la clase UIMap algún tipo de control o
método. Podéis encontrar más información aquí.

Si, además, utilizamos Test Manager, tenemos una tabla en la que se especifican los
tipos de pruebas automáticas que se pueden crear y las que se pueden ejecutar como
parte del plan de pruebas que tengamos creado:

Existe mucha información, sobre todo en la documentación de MSDN sobre CodedUI.

Aquí os he explicado a grandes rasgos como comenzar a automatizar en CodedUI y
algunas de sus ventajas, pero es un mundo muy amplio que daría para muchos artículos
y muchas conversaciones, ya que cada cual utiliza sus herramientas y sus maneras de
trabajar, solo espero haber añadido algo de luz sobre esta herramienta y os animo a
probarla.

53. Pruebas de portabilidad

Hoy vamos a tratar un tipo de pruebas que no son de las más conocidas, las pruebas
de portabilidad, que son las que se realizan para determinar la portabilidad de un
software a otro software o de un hardware a otro.

Para la realización de este tipo de pruebas lo mejor es montar un laboratorio estanco

e independiente donde probar todo con garantía. Este entorno de pruebas tendrá que
tener varias posibilidades que hagan que se cumpla la normativa y que posibilitemos
diferencias de hardware y nuevo software para facilitar la portabilidad del producto.

Este tipo de pruebas tendrán que cumplir la normativa escrita en la ISO/IEE 9126-1,
donde se describe la capacidad de un software a ser transferido de un ambiente a otro,

Dentro de la portabilidad y de la normativa anteriormente descrita, un producto

tiene que ser capaz de ser adaptado a los ambientes especificados sin aplicar acciones
o medios que aquellos suministrados con el propósito de que el software cumpla sus
fines. También tiene que cumplir la Instabilidad, que es la capacidad de dicho producto
para ser instalado en un ambiente especificado y la reemplazabilidad la cual describe
que el producto software tiene que ser capaz de ser usado en lugar de otro especificado

63
para los mismos fines y en el mismo ambiente.

Por lo tanto, para este tipo de pruebas hay que comprobar que el software sea
Portable, Instalable, reemplazable y adaptable.

¿Cómo realizamos las pruebas de portabilidad?

Para ejecutar este tipo de pruebas hay que tener en cuenta el tipo de producto, ya
que las que trabajan en escritorio o vía web son más sencillas de probar que el resto.

En primer lugar, hay que tener en cuenta los requisitos previos de instalación (en el
caso de que fuesen necesarios), hay comienza la complicación de las pruebas ya que se
podrán sacar fallos de Instabilidad y que no sea reemplazable en algún sistema por la
falta de compatibilidad de algún pre-requisito.

Tras la instalación de los requisitos previos hay que valorar si este flujo es único o hay
varias posibilidades, ya que, en algunos casos, la instalación de estos tiene que ir
enlazada y por pasos porque podría pasar que al instalar algún pre-requisito antes que
otro, este no funcione correctamente. Al realizar todas estas pruebas tendremos el flujo
de instalación ya realizado completamente.

El siguiente paso es verificar que la instalación ha sido correcta, habrá que ejecutar
la aplicación y revisar que se "levanta" como se espera. Si esto es correcto, hemos
completado el punto exitosamente.

Otra cuestión a revisar es la desinstalación del producto. Habrá que revisar cómo se
desinstala, que componentes se pueden quedar, que archivos no se borran
adecuadamente o que registros quedarán tras ello. Hay que comprobar todos los flujos
que hemos ejecutado en la instalación y paso por paso ir eliminando todo lo que hemos
instalado previamente.

Cuando hemos realizado todos los flujos, quedarán una serie de disconformidades
que se convertirán en defectos que hay que solventar, tanto a nivel funcional como a
nivel de código.

Este tipo de pruebas nos permitirán ver si nuestro software tiene una instalación
rápida, sencilla, correcta y funciona como debe en todos los sistemas que probemos y
queramos englobar. Para ello el uso de laboratorios es imprescindible, porque
podremos "virtualizar" de una manera rápida, una gran cantidad de versiones para
nuestro producto.

54. Cada día somos más exigentes

Hoy en día nos encontramos con una capacidad evolutiva enorme a nivel de
aplicación. Constantemente nos bombardean con nuevas actualizaciones, con
evolutivos, con cambios... ¿por qué se produce esto? Muy sencillo, cada vez exigimos
más que algo funcione correctamente.

64
 Desde hace unos años, con el nacimiento y expansión de los dispositivos móviles, nos
encontramos con alrededor 20 aplicaciones que usamos a diario, esto nos aporta una
gran cantidad de funcionalidad que se puede hacer con un solo click o una sola pulsación
de pantalla, exigiendo una fiabilidad absoluta y sobre todo una exigencia de rapidez de
carga para consultar algún tipo de dato.

¿Qué ocurre cuando nuestras aplicaciones típicas como WhatsApp, Twitter, Google
Maps o el correo electrónico...fallan? Pues que se pierde ese minuto de consulta que
necesitamos en un momento puntual y que nos cabreamos.

¿A quién no le ha pasado en el metro, entre estaciones, que tiene unos minutos de

conexión e intenta consultar algo rápidamente antes de que se vuelva a perder? Creo
que todos somos conscientes de la cantidad de veces diarias que accedemos a nuestras
redes sociales, a periódicos digitales, a aplicaciones de mensajería...un solo segundo o
un solo fallo, puede causar que muchos de los usuarios huyan despavoridos y se acaben
descargando la aplicación de la competencia.

Hace un tiempo apareció LINE, por ejemplo, una nueva aplicación de mensajería que
iba a destronar al omnipresente WhatsApp, ¿recordaos que sucedió? Pues que era
terriblemente lenta, pesada y consumía demasiados datos, así que la gran cantidad de
usuarios que comenzaron a utilizarla, volvieron a la anterior mucho más liviana y ágil.
Después han ido mejorando y la aplicación funciona muy bien, pero los usuarios ya se
han acomodado y no se quieren mover.

Nos movemos en un nivel de exigencia altísimo, motivado como ya os digo, por los
dispositivos móviles, por esa gran facilidad de conectarnos con un solo click, con esa
falta de tiempo que solo nos permite uso pocos minutos (aunque sea varias veces al
día). Esa exigencia es tan real que cualquier empresa debe de cubrirse las espaldas de
cualquier modo y cerciorarse de que todo lo que sube a producción esté como una
patena, totalmente impoluto, un solo desliz, puede ser catastrófico para los números
anuales y puede llevar incluso hasta desaparecer y que quede totalmente en el olvido
(recordar ahora casos tan importantes como Tuenti, un producto estrella que compró
Telefónica y que ha acabado como compañía móvil, desapareciendo como red social
para siempre).

Incluso hasta los más grandes pueden cometer errores importantes, haciendo que
sus aplicaciones desaparezcan de un día para otro o tengan unas críticas de lo más
negativas. Por ejemplo, Apple, sacó Maps con una versión horrible que contenía muchos
errores y no desapareció de milagro. Y por supuesto, el mayor error fue Ping, una red
social que la mayoría de los usuarios no entendieron y que fue totalmente innecesaria,
un cierre que no fue por errores, si no por una interfaz poco intuitiva, falta de
comunicación y apertura en un mal momento. Así podría llenar páginas y páginas con
los mayores errores que han tenido las grandes compañías, pero creo que todos las
sabemos.

Esta es la exigencia del mundo actual, un monstruo que devora día tras día

65
aplicaciones, que pudieron haber sido "bestseller" y haberse hecho un hueco
importante en nuestros dispositivos y en nuestro día a día.

55. Pruebas en dispositivos móviles

Estamos en una época en la que las pruebas en dispositivos móviles son una de las
cosas más importantes que hay que hacer en un proyecto. Muchos de los usuarios
potenciales que acceden a nuestras aplicaciones y servicios lo realizarán a través de un
dispositivo.

No tenemos que obviar bajo ningún concepto este tipo de pruebas y comprobar,
tanto si nuestra aplicación es Responsive web Design como si no, si es funcional en tablet
y teléfonos inteligentes. Evidentemente no podemos cubrir el 100% de dispositivos, ya
que en el mercado hay muchísimos y hay muchos muy antiguos, pero sí que tenemos
que cubrir una mayor parte de ellos y no solo fijarnos en gamas altas, cuya cuota de
mercado no siempre es la mayor.

Las pruebas en dispositivos móviles se pueden hacer con un laboratorio de

dispositivos físicos o utilizando cualquiera de las herramientas que existen en el
mercado actual, os dejo algunos ejemplos:

• Perfecto Mobile: Es una herramienta basada en web (SaaS) con disponibilidad

24x7 que permite acceso instantáneo a cientos de teléfonos entre los más
relevantes del mercado actual.

• TestDroid: Es un servicio web que permite instalar un plugin en Eclipse y se podrá

enviar nuestra aplicación a más de 100 terminales reales en un clúster específico.
Tras las pruebas se envía un log con los resultados.

• AppyTest: Según reza en su web: AppyTest es la solución para garantizar la

calidad de las aplicaciones para Smartphone que ofrece servicios de testeo,
consultoría y monitorización de aplicaciones móviles tanto para desarrolladores,
consultoras, como para empresas usuarias de apps.

• TestObject: Un complejo entramado de más de 150 dispositivos para realizar

pruebas en las aplicaciones que mandemos. Nos aporta trazabilidad en los
defectos y ajustes personalizados para, por ejemplo, GPS o idioma.

Muchas de estas soluciones son perfectamente funcionales y nos permiten no tener

un laboratorio de dispositivos físicos que siempre puede ser más limitado y quedarse
obsoleto en cualquier momento. El servicio siempre será algo más caro, pero a la larga
nos beneficiaremos de tener siempre dispositivos libres y usarlo cuando necesitemos,
bajo demanda.

También, las grandes firmas tecnológicas nos ofrecen sus propios laboratorios y sus

66
soluciones para poder tener una buena batería de pruebas y cubrir todos los casos
posibles.

En el caso de HP nos ofrece HP Testing for mobility o IBM con Rational Test también
nos ofrece una solución completa para poder organizarnos mejor en base a nuestras
pruebas en dispositivos.

También desde HP podemos descubrir información muy completa de pruebas en

aplicaciones móviles con su Suite de Pruebas totalmente adaptada para estas labores.

Microsoft no nos aporta una solución única integrada en su suite de pruebas, si no

que se apoya en plugins para Visual Studio que son muy completos y nos permiten
realizar las pruebas de manera más cómoda y completa. Por ejemplo, podemos destacar
SeeTest Plugin o una completa integración con Perfecto Mobile.

Como veis, hay muchísima información para apoyarnos en este tipo de pruebas, y
con el tiempo habrá más, ya que el rango de utilización en los dispositivos móviles cada
día es mayor y los usuarios son cada vez más exigentes, así que, manos a la obra y no
descuidemos este campo.

56. Rotar en un equipo de trabajo

Siempre que formemos parte de un equipo, es muy importante no quedarnos
estancados en algo en concreto. En el caso del Testing pasa exactamente lo mismo. Si
una persona día tras días prueba lo mismo y basa su trabajo en las mismas pantallas,
tendrá un nivel de estancamiento importante y al final por aburrimiento querrá cambiar
de trabajo.

¿Qué podemos hacer para esto? muy sencillo, rotar.

Habitualmente un equipo de Testing tiene gente especializada en algunos campos,

en algunos módulos, pantallas...y a veces nos resulta difícil dar el paso para que se
dediquen a otra cosa, porque sabemos que, si esas personas lo prueban, el resultado
estará 100% garantizado.

Cuando estamos en esa tesitura, un buen momento para rotar a la gente es después
de una subida a producción importante, cuando sabemos que el día después comenzará
una época más tranquila y que las personas podrán ponerse a aprender lo que les pueda
tocar.

Las ventajas de que la gente rote son muchas, sobre todo el cansancio mental que
supone que día tras día nos tengamos que enfrentar a las mismas cosas. Cuando
cogemos algo nuevo, nuestra motivación es mayor, tenemos ganas de aprender y de
hacer cosas nuevas, entonces, matamos dos pájaros de un tiro, la gente tiene la
motivación más alta y si estaba "aburrida" ya no lo está y sofocamos una posible salida
al menos inmediata.

Otra ventaja de las rotaciones es que el equipo coge conocimientos de algo más,

67
salen de su "zona de confort" y adquieren conocimientos que hasta ahora no tenían.

En el caso de que alguna persona del equipo esté de baja de repente o se coja
vacaciones, no tendremos muchos problemas ya que los demás también podrían apoyar
esa parte y no se quedaría tan huérfana como si no hubiese nadie con los conocimientos
necesarios.

En su contra, he de decir que depende de la madurez del equipo, las rotaciones

pueden ser un problema ya que si una persona lleva mucho tiempo en el mismo puesto,
cambiarla, puede llegar a ser un problema, principalmente, porque cuando cualquiera
de nosotros está haciendo lo mismo durante años, al final se relaja y deja de "aprender",
por lo tanto un cambio, puede suponer que se tengan miedos a lo que vendrá, a si uno
será capaz de asumir su nuevo rol o nuevos conocimientos y por lo tanto, puede
empeorar su rendimiento.

57. La dificultad de validar desarrollos externos

Cuando nos enfrentamos a un desarrollo que nos entrega una empresa externa,
siempre tenemos la incertidumbre de hasta dónde llegarán sus pruebas y validaciones.

En la mayoría de los casos, un desarrollo externo no cumple con ciertas "reglas" que
sí que cumplen cuando trabajamos con nuestros equipos internos, donde además
tenemos la ventaja de poder tratar a diario y cara a cara con los desarrolladores.

Cuando nos entregan un desarrollo externo y en la mayoría de los casos es algo

cerrado y en bloque, tenemos que realizar un tratamiento de choque y pivotar
prácticamente a todo el equipo para encontrar de un solo vistazo todos los defectos (en
el caso de que los hubiese) que podamos, asegurando que al menos, tras esta primera
validación todo funcione como debe.

Esta primera validación se debería de realizar con la técnica de las pruebas

exploratorias que ya os he comentado en varias ocasiones.

En el caso de encontrar defectos, esto nos dará un tiempo muy valioso que
dedicaremos a mejorar (o a realizar) los casos de prueba, en base a los requisitos
antiguos y nuevos que se especifiquen después (suele ocurrir en estos casos, que se
cambien cosas en el momento).

Una vez que se devuelvan los defectos y podamos reprobarlos, dedicaremos el 100%
del tiempo a validar el desarrollo externo con los casos de prueba completamente
actualizados, permitiéndonos encontrar otros defectos que no hemos podido encontrar
en una primera exploración.

Una vez que hemos pasado los casos de prueba y hemos encontrado defectos que
tendrán diferentes criticidades, de esta manera nos resultará muy fácil montarnos una
batería de pruebas de regresión funcional que podremos automatizar y poder cerrar
siempre este desarrollo y comprobar que no falla en ninguna de las subidas a producción
que tengamos en el futuro.

68
 58. Pruebas en Responsive web Design
Desde hace bastantes años venimos escuchando cosas como, por ejemplo, que las
páginas se auto adaptan a los dispositivos o que realizando una sola versión es portable
a cualquier móvil o Tablet. Esto es gracias al Responsive web Design o diseño adaptable.

Esta filosofía de diseño y desarrollo se basa en la idea de “web for all” que, en
resumidas cuentas, es adaptar la apariencia de las páginas web a los diferentes
dispositivos del mercado donde se visualice la misma. En principio, debería de tener una
visualización adecuada en cualquiera de estos, proporcionando una lectura clara,
sencilla y cómoda para los usuarios.

La primera vez que se utilizó la definición de Responsive Design fue en A List Apart y
tras fue ampliamente descrito en la W3C en julio de 2008 con el nombre de “One Web”.

La idea principal del Responsive web Design se ha visto truncada en los últimos años,
por la gran cantidad de dispositivos en el mercado, que hace muy complicado que la
respuesta en todos sea buena y provoque una navegación tortuosa y costosa, sobre
todo en los que son de gama baja o “clones”.

Habitualmente, para realizar este tipo de diseños, se utiliza CSS3 que “selecciona” la
versión más optimizada para ese dispositivo y reorganiza los elementos o discrimina los
que no funcionarían correctamente. Además, HTML5 permite que la experiencia para
los usuarios sea excelente.

La gran ventaja de este tipo de diseños es el ahorro de costes, a largo plazo, ya que
el desarrollo se centra únicamente en una sola web y no hace falta desarrollar varias,
para los diferentes SO que hay en el mercado (mínimo serían tres: iOS, Android y
Windows Phone). Además, permite no duplicar contenido, mejorando el SEO de la
misma, mejora gratamente que tus contenidos sean repartidos por redes sociales de
una manera rápida y el mantenimiento es más sencillo.

En algunas páginas podemos encontrar ejemplos, artículos, recursos o patrones,

como en: https://responsivedesign.is/

Aquí os dejo un manual bastante completo sobre HTML5:

http://www.w3schools.com/html/html5_intro.asp

Es realmente importante conocer bastante este tipo de tendencias, ya que, en la

mayoría de los casos, y actualmente cada vez más, nuestras pruebas se centrarán en
probar productos así, donde tendremos que adaptar nuestros casos de prueba, revisar
más versiones, comprobar que los requisitos cumplen todas las posibilidades y, sobre
todo, realizar una gama de pruebas más compleja.

Personalmente, cuando realizo baterías de prueba para este tipo de productos,

realizo diferentes casos de prueba por dispositivo o sistema operativo, ya que no en
todos, aparecerán los mismos elementos, la funcionalidad no será la misma y quizá un

69
módulo funciona correctamente en un dispositivo de gama alta pero no en uno de gama
baja y viceversa (puede que aún no esté preparado para una versión tan moderna de
sistema operativo).

Hace un tiempo escribí un artículo para la realización de pruebas en dispositivos

móviles y que aplicaciones nos ayudan a realizarlas: Pruebas en dispositivos móviles.
Este artículo nos resultará muy útil para realizar pruebas en bloque con dispositivos y
no tenerlos físicamente si no lo creemos conveniente. Además, escribí otro artículo
sobre pruebas de compatibilidad en diferentes navegadores, que nos aportará algo de
luz sobre cómo realizar pruebas en Responsive web Design, ya que, al fin y al cabo,
estamos probando la “compatibilidad” del producto en diferentes dispositivos.

59. Pruebas con mapas de calor

Cuando vamos a probar una aplicación web, tenemos que tener claro cuáles son los
puntos donde más se ven afectados los usuarios a la hora de que tengamos errores, al
igual que necesitamos los puntos “más calientes” de utilización y donde tenemos que
centrar nuestras pruebas de regresión y poner “banderas” de atención para darle
prioridad a unas secciones que a otras menos utilizadas y por lo tanto “menos
importantes”.

Las herramientas que nos ayudan a realizar este tipo de averiguaciones son los
“mapas de calor”.

¿Qué es un mapa de calor?

Pues simplemente es un gráfico que resalta mediante diferentes colores las zonas de
la web en las que más tiempo pasa el ratón de los usuarios. El funcionamiento es
bastante simple: sigue el movimiento de los visitantes, analiza el número de clics y
realiza las gráficas en consecuencia. La apariencia es similar a la visión de calor de un
Predator, para los más freaks. Os dejo unas imágenes para que os hagáis una idea:

Para realizar este tipo de “gráficas” necesitamos una gran cantidad de datos y de
pruebas, porque, si no, no sacaríamos conclusiones fiables y no se conseguiría
absolutamente nada.

¿Cómo se utilizan en la realización de pruebas?

La utilización de estas herramientas nos vendrá muy bien a la hora de detectar, como
su nombre indica, puntos calientes, o sea, de utilización máxima por los usuarios para
centrar nuestras pruebas, para ser puntillosos y sobre todo para dar respuesta rápida a
esas zonas antes que a otras que apenas se usen o afecten a un menor número de
usuarios.

También podemos justificar la realización de pruebas de rendimiento en base a

puntos de mayor utilización e incluso tener check List de previsiones de utilización por
periodos de tiempo pudiendo ampliar capacidad de hardware o disminuirla y ahorrar
costes.

70
 Todas las pruebas y gráficas, junto con unos test A/B nos pueden ofrecer casi
exactamente donde colocar cada elemento de la web para que la experiencia del usuario
sea lo más satisfactoria posible, diferenciándonos de la competencia y obteniendo
mejores resultados.

¿Qué herramientas se pueden utilizar para este tipo de pruebas?

• CrazyEgg: es el más conocido de todos, tiene 30 días de prueba gratuita y luego

tiene pagos mensuales bastante asequibles. Para mi es la mejor herramienta y la
que está más avanzada.
• Page analytics de Google: la podemos conseguir en forma de extensión para
Chrome y nos dará de manera automática un mapa de calor basado en los datos
de los clics que tenemos en nuestra página. Tenemos que tener una cuenta de
Google.
• Visual WebSite Optimizer: Es una herramienta para experimentar con test A/B
y que muestra gran cantidad de datos y mapas de calor relacionados. Es de pago.
• Feng-GUI: Potente herramienta que nos muestra gráficas de calor, informes muy
completos, análisis visuales y como mejorar el diseño de una web.

60. Pruebas funcionales de SEO para web

Cuando realizamos unas pruebas en una página web o en una aplicación basada en
web, no podemos perder de vista el posicionamiento SEO y todo lo relacionado con él.

Se puede realizar una auditoría del buen funcionamiento del mismo con unas
sencillas reglas y pasos.

Aquí os expongo algunas pruebas que se pueden realizar, dentro de las muchas que
existen, donde poder comprobar que el SEO de una página es correcto, que está bien
indexada y que concretamente, los principales buscadores nos mantendrán en las
primeras posiciones para que tengamos más visitas y/o clientes potenciales.

1. La primera prueba y esencial, es no repetir los títulos en las pestañas del

navegador. Cada pestaña tiene que tener una etiqueta META diferente y una
descripción suficiente y coherente para que los principales buscadores la
indexen correctamente.

2. Para realizar esta prueba y si cumple nuestros requisitos, basta con abrir
varias pestañas de diferentes páginas de la web y observar que no se repite
ni el título ni la descripción.

3. Comprobar que no existen textos genéricos ni cortos en la web, de esta

manera, los usuarios finales que accedan a la web o al portal en concreto,
sabrán exactamente lo que se promociona en ella y se harán una idea de la
finalidad de los servicios proporcionados.

4. Revisión y adecuación de las URLs. Este punto es sumamente importante ya

71
 que la gente suele entender y quedarse con URLs claras y sin demasiados
caracteres. La solución puede recaer en editar la configuración del fichero
.htaccess o de tu CMS. Esta prueba se realizará abriendo varias pestañas y
fijándose que las URLs sean claras, cortas y con textos que describan lo que
aparece en la página en concreto.
5. Velocidad de carga. Para realizar esta prueba tendrás que utilizar una de las
muchas herramientas que nos proporciona internet. En este caso, os dejo
algunos ejemplos para que podáis utilizarlos:

• https://developers.google.com/speed/pagespeed/insights/: la
herramienta estrella de Google, en ella tendremos mucha cantidad de
datos y a su vez, nos ofrece directamente los reportes e informes
personalizados que queramos. Otra ventaja es que incluye una utilidad
de los cambios que deberíamos de hacer para mejorar el rendimiento.
• http://www.webpagetest.org/: herramienta sencilla, con muchas
opciones y totalmente gratuita.
• http://tools.pingdom.com/fpt/: ofrece menos datos que las anteriores,
pero a su favor podemos decir que están realmente bien organizados y
son muy sencillos de entender.

6. Revisión de agregadores para mantener o aumentar el ranking de la página.

En esta prueba tendremos que verificar y garantizar que nuestros enlaces,
servicios, páginas o similar se encuentran en los principales agregadores.
Sobre todo, podemos hablar de Google+. Una vez que comprobamos que
estamos correctamente expuestos y distribuidos en Google+, tendremos que
comprobar que Google indexa las páginas y nos muestra en las búsquedas
relacionadas.

7. Comprobación de enlaces salientes de un dominio y el PageRank de la página.

Este tipo de test se realiza agregando un backlink al sitio o URL en concreto y
comprobar que la indexación del buscador es correcta.

Como veréis, estas seis claves que os aporto son algo relativamente sencillo y hay
muchos más puntos que comprobar, pero únicamente os quiero guiar hacía donde
encauzar las pruebas en posicionamiento web y poder aportar un extra más a nuestro
trabajo.

Espero que os sirvan para ayudar a que en vuestros proyectos (si es que lo necesitáis),
se ha realizado un buen SEO.

61. Automatización con Selenium

Después de tratar el tema de la automatización con CodedUI, vamos a ver una de las
herramientas más universales que se usan para automatizar en los proyectos.

72
 Para los que no lo conocen, Selenium es una herramienta que automatiza en
navegador web y que contiene dos herramientas en su suite de pruebas:

• Selenium IDE: Es la herramienta que realiza los casos de prueba grabando y

ejecutándolos. También se pueden exportar. El mejor navegador para esta
extensión es Mozilla Firefox.
• Selenium WebDriver: Es un complemento o API para trabajar desde Visual
Studio. Con él se pueden realizar los Test en la Suite de trabajo de Microsoft.

La instalación de Selenium IDE es muy sencilla, ya que es una extensión de Firefox,

después no hay más que abrirlo desde las herramientas del navegador. Cuando abrimos
la herramienta, vemos que es tan sencilla como su instalación.

Pulsamos el botón REC (Círculo rojo) para comenzar a grabar y después, pulsaremos
el botón "Play" para reproducir lo grabado. Tenemos un módulo para ver los comandos
que hemos grabado y para editarlos si quisiéramos, añadiendo nuevos o
parametrizando datos.

En la parte de más abajo del editor tenemos los comandos. Selenium tiene tres
principales:

• Acciones que activan o cambian el estado de la aplicación (por ejemplo, pulsar

un botón, rellenar un campo...).

• Los llamados "Accessors" que examinan y guardan resultados en variables.

• Afirmaciones: que verifican el estado de la solicitud, esperan, o comprueban. Por

ejemplo "verify", "waitFor" o "ClickandWait.

Existen muchas referencias sobre Selenium IDE en su página web, las podeís
consultar aquí.

Las acciones se pueden crear desde el propio Selenium o más sencillo todavía
pulsando en el botón derecho de Mozilla Firefox, en el elemento que seleccionemos. La
opción será "Show all Available commands" o "Visualizar todos los comandos
disponibles".

De esta manera, se nos desplegará un listado con las opciones que podemos utilizar
en el elemento y así insertar una acción de manera más sencilla.

Una vez que tengamos nuestra pantalla "grabada" podemos exportarlo con la API
que nos proporciona la Suite, Selenium WebDriver.

En el caso de que utilicemos Visual Studio, trabajemos con .NET / C# o similar, la

exportación del código es bastante sencilla y funcional, pudiendo ejecutar los test en

73
Visual Studio y apoyar nuestro trabajo de manera muy eficiente. En muchos casos, tanto
CodedUI como Selenium tienden a complementarse, por lo tanto, no descartaría la
utilización de ambos.

Otra extensión o framework que viene muy bien para complementar, ejecutar o
editar estas pruebas es Unit que se puede descargar aquí. En la mayoría de los casos
tendremos que utilizarlo con Selenium WebDriver para la exportación de casos en C#.

Cuando tengamos una buena batería de pruebas automatizada con Selenium, existe
otra extensión muy interesante, que es Test Results (Selenium IDE).

Esta nos permite guardar los resultados de los Test con un solo Click, pudiendo tener
un Log y unos históricos muy interesantes. Además, como complemento, se podrán
exportar los casos de manera individual.

Como veis, existen muchas herramientas para automatizar nuestras aplicaciones y

cada una nos aporta unas ventajas y unos inconvenientes. Lo mejor que tiene Selenium
es su capacidad de adaptación, su universalidad y sobre todo que es totalmente
gratuito.

Lo único que tenemos que hacer es ir utilizando todo este abanico de herramientas
e irnos adaptando a sus posibilidades, hasta que encontremos la que mejor encaja en
nuestro proyecto para nuestra aplicación.

62. Pruebas de interoperabilidad

Por definición, la interoperabilidad es la habilidad de dos o más sistemas o
componentes para intercambiar información y utilizar la información intercambiada. A
día de hoy, la interoperabilidad es uno de los elementos clave para la administración
electrónica, impulsándose a través de estudios científicos.

Las pruebas de interoperabilidad son las que determinan la interoperabilidad de un

producto software y por lo tanto es la revisión de un producto o sistema, cuyas
interfaces son conocidas, para que funcione con otros productos o sistemas existentes
o futuros sin restricción de acceso o de implementación.

Para la realización de este tipo de pruebas es necesario conocer el estándar definido

por los diferentes fabricantes.

Un ejemplo muy sencillo de donde comprobar la interoperabilidad en

funcionamiento es en los teléfonos móviles. Se puede comprobar en una red de
telefonía móvil donde hay dispositivos de diferentes marcas en funcionamiento, la
interoperabilidad es comprobar que todos esos dispositivos de tan diversas marcas,
funcionan correctamente en la misma red, pudiendo realizar llamadas, conectarse por
internet móvil o mandar SMS. También podría aplicarse a la utilización de otra red
cuando viajamos al exterior, pudiendo utilizar todos los servicios de la misma manera.

74
 Hace unos años, la tecnología española lideró unas pruebas de interoperabilidad con
el 100% de éxito en la OTAN. El programa tenía el nombre de SEISMO y estaba financiado
por la subdirección general de tecnologías e innovación (SUBTECIN) y realizó un número
de pruebas satisfactorias muy por encima al de otros sistemas, siendo el único que
demostró ese nivel de éxito. El programa de cooperación intentaba maximizar el uso de
recursos de vigilancia y reconocimiento, así como mejorar la situación a través del
empleo y el uso colaborativo de productos de sensores y capacidades de explotación.

Una vez que comprendemos que es la interoperabilidad y varios ejemplos de

ejecución de la misma, vamos a tratar de ponerle nombre dentro de las
telecomunicaciones, donde, habitualmente, es donde realizaremos nuestro trabajo.

Como hemos hablado anteriormente, la mayor utilidad de estas pruebas es en redes

de telefonía y las pruebas que se pueden realizar están relacionadas con la ejecución de
llamadas y conexión a una red de telefonía IP. Dentro de este tipo de pruebas cabe
destacar las que podemos realizar en la arquitectura TCP/IP y se podrían examinar tres
zonas:

• Capas de protocolo: hay que regirse por lo que diga la norma técnica y por lo
tanto cada capa tiene que ser interoperable. Para probar esta zona se han de
efectuar acciones que sean precisas y comunicarse con otros elementos a través
de mensajes e intercambio de datos.

• Códec: Entrarían dentro, las pruebas con carga de video y audio, que cada día
son más complejas por el gran abanico de protocolos que se utilizan. Se pueden
realizar unas pruebas aisladas de los mismos o realizar pruebas en conjunto para
ver cómo se comportan unos con otros.

• Aplicación: este tipo de pruebas deberían de comprobar la integración de todas

las funciones, comprobando la lógica de la aplicación con la pila del protocolo de
los códec y con las funciones propias del software, dando por supuesto, si todas
las pruebas son positivas, que, a partir de ahí, el conjunto es interoperable,
certificándose como correctas las correspondientes pruebas de
interoperabilidad.

Este tipo de pruebas entran más en la rama de las telecomunicaciones, pero siempre
tenemos que tener toda la información de las mismas ya que con el avance de pruebas
móviles, puede ser necesario realizar unas comprobaciones similares para verificar que
todo es correcto dentro del software que estemos certificando.

63. Pruebas de Internacionalización de software

Alrededor del año 2000, se comenzó a realizar la creación de software
internacionalizado que ofrecía una compatibilidad universal y empezaron a aparecer
directrices para controlar la calidad del mismo en base a una situación “ideal”.

75
 Esto ha cambiado mucho a lo largo de los años y ahora mismo, podemos garantizar
la internacionalización de una manera más clara y sencilla, ya que el código utilizado
suele tener una tendencia única y hay reglas y bases asentadas que llevan los desarrollos
a un camino mucho más unificado.

Garantizar la internacionalización supone comprobar directrices de desarrollo que se

pueden agrupar en los siguientes puntos, con sus respectivas pruebas:

1. Globalización del código: no se deben de hacer suposiciones acerca de cuál

es el sistema predeterminado del sistema (configuración regional) y se tiene
que utilizar Unicode para la codificación del texto. Además, hay que llamar a
funciones NLS API cuando se pidan operaciones que distinguen la
configuración regional, como por ejemplo el formato de fecha
(DD/MM/YYYY). Cuando se realizan pruebas para cubrir estas necesidades,
el principal objetivo es asegurar que el código pueda controlar toda la
compatibilidad internacional sin interrumpir funcionalidad ni pérdidas de
datos o visualización. Entre otras cosas, algunos ejemplos de posibles errores
que nos podemos encontrar pueden ser los siguientes:

o Pueden aparecer signos de interrogación en lugar del texto al no

realizarse correctamente la conversión de Unicode a ANSI.
o Pueden dar problemas caracteres ANSI aleatorios que aparecen en lugar
del texto y que nos mostrarán problemas con códigos ANSI equivocados
((¼, «, †, ¶, etc.).
o Pueden aparecer cuadros, barras verticales o tildes en lugar del texto o
de algunos caracteres como: [□, |, ~]. Esto puede indicar que no se
pueden mostrar ciertos caracteres.

2. Localización de la aplicación: Todo lo que se lea en pantalla se debe de poder

modificar sin poder cambiar el código descrito o sin compilar nuevamente.
La interfaz de usuario multilingüe (MUI) nos da las suficientes capacidades
para mostrar varias versiones de idiomas de la interfaz de usuario en el
mismo tiempo en el mismo software. Un paso clave para que se cumpla este
punto es que se reflejen en todos los documentos de diseño del software en
el que trabajemos. Para realizar estas pruebas, hay que comprobar que la
interfaz del software se puede traducir correcta y fácilmente a cualquier
idioma de destino sin realizar modificaciones de código.

A día de hoy, hablar de internacionalización de un software es prácticamente algo

habitual y en todos los proyectos se suele trabajar ya de la misma manera, pero no está
de más hacer un repaso histórico a la realización de este tipo de pruebas, cuando se
comenzó a tomar un sendero común y como se hacían las cosas hace unos años y en
algunos casos, actualmente también.

76
 64. Habitualmente...
Habitualmente, cuando hablamos de un equipo de Aseguramiento de la calidad o de
Testing, tenemos que mirar al final del proceso, al último paso de todos, al maravilloso
mundo de la falta de tiempo y de jornadas para tener todo completamente listo e
impoluto para subir con garantías. No se le da la importancia suficiente a la validación,
pero sí que se le da la importancia suficiente a las lamentaciones cuando algo falla en
producción de cara a un cliente.

Habitualmente y erróneamente, solemos planificar un elemento de trabajo en

jornadas de desarrollo y una vez que se termina, lo demás queda en el aire, a nadie le
preocupa, a nadie le importa que un desarrollo de semanas, cuente con una jornada o
unas horas para validarlo y que inmediatamente suba a producción o se quiera tener ya
listo y cuanto antes, quitando y restando importancia a tener un tiempo suficiente y
constante para probarlo y verificarlo de la manera correcta.

Habitualmente, los equipos de desarrollo se comen las ventanas de tiempo, ya que

las planificaciones son demasiado ajustadas, impidiendo que a la validación se le
dedique el tiempo suficiente que requiere algo tan importante que vaya a ser usado por
clientes (que nos pagan los sueldos). Pero eso no importa, es más importante que
podamos tenerlo rápido en producción y entregar algo a medias y funcionando no del
todo bien.

Habitualmente, corremos riesgos innecesarios, programando subidas a producción

sin la ventana suficiente o queriendo abarcar más elementos de la cuenta y de manera
innecesaria, mantenemos a muerte las fechas, aunque desfondemos al equipo que
realice las pruebas, porque, habitualmente, qué más da…total, solo prueban, no hacen
cosas bonitas ni "vistosas".

Habitualmente, se guarda un presupuesto ínfimo para los equipos de Calidad, “micro

dimensionando” sus integrantes y masificando a los equipos de desarrollo, dejando a
una sola persona para probar desarrollos que realizan equipos de 8 o 10 personas.

Habitualmente, se piensa, erróneamente, que es mejor tener a un gran equipo de

desarrolladores y pocas personas validando, que pararse a pensar, que quizá con dos o
tres personas más que validen, estaría solucionado el problema.

Habitualmente, se menosprecia a las personas que nos dedicamos a probar,

ofreciéndoles remuneraciones menores que otros compañeros de profesión, pensando
que como no hacemos cositas bonitas y solo “miramos pantallas”, no nos merecemos
más, aunque en la gran mayoría de los casos, gracias a nuestro trabajo, muchos de esos
compañeros sigan sentados en sus sillas gracias a que la aplicación funciona por nuestro
trabajo.

Habitualmente, pienso que podía haber dedicado a especializarme en otra rama de

trabajo del amplio mundo de la informática, algo más preciada para el resto de los
mortales, algo más valorada…pero se me quitan las ganas y mi cara esboza una sonrisa

77
de satisfacción personal, cuando miro atrás, cuando no estábamos y los usuarios de
ciertas aplicaciones no podían tan siquiera acceder en muchos casos y ahora, felizmente,
pueden trabajar con total comodidad y seguridad porque hay un “ángel de la guarda”
que revisa todo el trabajo y se lo entrega todo lo bien que se lo permiten, luchando a
contracorriente día tras día para que, en algún momento, pueda, habitualmente,
sentarse de igual a igual con el resto de compañeros de profesión.

65. Nos crecen los enanos

Cuantas veces he escuchado esta frase a lo largo de mi vida profesional...cuantas
veces he sufrido en mis propias carnes situaciones que llevan a gritarla bien alto, a
tirarnos de los pelos y repetir una y otra vez la dichosa frase.

Cuando sucede algo así ya no podemos pararlo, tenemos un problema tras otro,
solucionamos una cosa y nos falla por otro lado, volvemos a solucionarlo y nos cuesta
un parto estabilizar de nuevo, los astros se alinean en nuestra contra y todo salta por
los aires...bien, paremos, recapacitemos, respiremos... ¡ALTO!

Llega el momento de tranquilizarnos, sentarnos en una sala los implicados, relajarse

y pensar con calma...no vale dar palos de ciego, no vale tapar de mala manera agujeros,
lo que comúnmente se dice cómo hacer "ñapas" para que de momento funcione...no,
eso no vale...arreglaremos un agujero y explotará otro. Es hora de recapacitar.

Una vez reunidos los implicados, buscamos un plan de choque, pensamos las
primeras medidas, las primeras impresiones y apuntamos punto por punto que hacer y
empezamos a crear un plan de choque. Ahora bien, no existen fallos, no puede haber
un, pero, no queda hueco para el error. La tensión es grande, cual película de suspense,
nos jugamos mucho y hay que hacerlo bien.

Tenemos el plan de choque, el plan de contingencia, como queráis llamarlo,

comenzamos a trabajar en el primer punto, sin pausa, bien, centrándonos en el
problema, cerrando todos los agujeros, preguntando, trabajando en equipo,
manteniendo la calma y los nervios fuera, tendremos presión, pero hay que ser
profesional...de nuestro trabajo depende que "no nos crezcan los enanos"...

Esto es un trabajo en equipo, no un tira y afloja para ver quién es el más fuerte, como
se dice comúnmente, a ver "quien la tiene más larga", de quien ha sido la culpa o quien
hace mejor su trabajo...lo principal es ayudarnos, hacer equipo, trabajar con un ritmo
adecuado e ir paso a paso sin parar y sin pausa.

Cuando "nos crecen los enanos" aflora nuestra profesionalidad absoluta, nos
ponemos a trabajar en conjunto, bien, con esa tensión especial que nos concentra al
100% en lo que hacemos y no fallamos, somos uno y lo hacemos realmente bien, te das
cuenta de lo "jodidamente" buena que es la persona que tienes al lado, que
posiblemente en más de una ocasión has puesto verde y recapacitas y piensas y meditas
y quizá, parte del problema has sido tú.

¡Vaya!, no lo habías pensado...tú, que no fallas nunca, que haces todo bien, que

78
siempre es culpa del de al lado, puede que tengas parte de culpa en que esos enanos
estén creciendo sin parar, vaya chasco, ¿verdad?

Quizá, cuando "nos crecen los enanos" nos damos cuenta de que, si todos trabajamos
en equipo, con humildad y ayudándonos unos a otros, no necesitamos gritar una vez
tras otra esa dichosa frase que tantos disgustos nos da.

66. Pruebas de Stress

Dentro de las pruebas no funcionales, podemos encontrar un determinado tipo de
pruebas muy importantes en el día de hoy, las pruebas de stress. Estas pruebas tratan
de medir la capacidad de una aplicación a situaciones "complicadas" para medir su
respuesta y poder llevar a cabo los cambios que acordemos para que esa respuesta sea
mejor.

Las pruebas de stress se suelen hacer para cubrir los siguientes puntos:

• Ajustar configuraciones de hardware y/o arquitectura. Por ejemplo, permite

decidir si el servidor actual es correcto o hay que ampliarle ya que no cubre un
determinado abanico de picos de acceso por usuario o similar.

• Conocer los límites de la aplicación. De esta manera sabemos que, si hay un pico
de entrada o de uso excesivo, tenemos que elevar la disponibilidad y así ahorrar
costes, pudiendo tener una disponibilidad menor en otros momentos.

• Uno de los puntos más importantes, es poder reducir riesgos de caídas de

sistema y que el usuario no pueda utilizar el servicio que le queremos aportar.

• También nos servirá como identificación de cuellos de botella en alguna sección

y por lo tanto tendremos que refactorizar o cambiar lo necesario.

Cualquier fallo en algún punto de los descritos más arriba suele tener un coste
bastante importante en cualquier aplicación, tanto a nivel de credibilidad como a nivel
monetario, por ello, este tipo de pruebas son muy importantes.

Lo primero que tenemos que hacer cuando vamos a comenzar con este tipo de
pruebas es saber exactamente qué es lo que nos interesa medir y crear un buen
escenario de pruebas, el tiempo es oro y no podemos desaprovecharlo.

Algunos puntos a medir con las pruebas de stress son los siguientes:

• El tiempo de respuesta de la aplicación.

• El número de transacciones realizadas en un periodo de tiempo que quisiéramos

gestionar.

79
 • La cantidad de memoria consumida en el servidor físico o virtual en un momento
determinado.

• La cantidad de peticiones que se hacen a memoria o a disco y donde se realizan.

• Número de solicitudes de alguna acción determinada (login, descarga, datos...).

Existen herramientas muy interesantes para realizar pruebas de stress. Os voy a

proponer Comerciales y OpenSource.

1. JMeter: Es una herramienta desarrollada por Apache que se utiliza para

realizar pruebas de carga, analizando y midiendo el desempeño de
aplicaciones web, entre muchas otras. Se puede parametrizar
completamente y las pruebas que se realizan son muy completas. Se puede
descargar desde la web oficial.
2. LoadUI: Era una herramienta Opensource, que ahora necesita licencia. Es una
extensión de SoapUI y permite añadir plugins de desarrolladores de terceros.
Es bastante completa y además podemos tener la Suite de pruebas SoapUI
para realizar más tipos de pruebas. Se puede descargar desde aquí.

3. LoadRunner: La herramienta estrella de HP, totalmente integrable con su

Suite HP ALM y HP Quality Center. Permite simular miles de usuarios al
mismo tiempo, la actividad que puede realizar, generar mensajes entre
componentes de la aplicación o simular la iteración con la interfaz
(pulsaciones o movimientos de ratón). Se pueden exportar scripts que
después pueden personalizarse. Si queréis más información tenéis en HP
todo lo que necesitáis.

Esto es una primera aproximación a los que son las pruebas de Stress, su utilización
y algunas de las herramientas que se pueden utilizar para llevarlas a cabo. Como os digo,
las pruebas de stress son muy importantes para saber los puntos débiles de las
aplicaciones y cuando o donde debemos de poner el foco para que los usuarios tengan
una garantía de poder utilizar las aplicación en todo momento, tanto crítico como no.

67. Herramientas para el control de la calidad

Hace unos años, el Testing de software era completamente diferente. Muchas veces
la única manera de hacer una organización más o menos coherente era la utilización de
una hoja de Excel, una práctica nada recomendable en los tiempos que corren.

A continuación, os voy a exponer una serie de herramientas OpenSource que podréis

utilizar con vuestras pruebas de software:

• Testlink: es una aplicación web para gestionar pruebas. La plataforma ofrece

80
 soporte para casos de prueba, planes de prueba, proyectos, gestión de usuarios
y además proporciona una serie de informes y estadísticas. Podéis descargarla
desde su página oficial.

• RedMine: es una herramienta para la gestión de proyectos que incluye un

seguimiento completo de incidencias. También contiene calendarios, diagramas
de Gantt, wiki, foro, repositorio de control de versiones…Desde mí punto de vista
es más completas que sus principales competidores y el interfaz son más
intuitivo, en su contra tiene que es más complejo configurarle y empezar a
trabajar con él. Podéis descargarlo desde aquí.

• Mantis bug tracker: es una solución completa para gestionar tareas. Es muy
sencilla de instalar y de comenzar a utilizar. Permite el seguimiento de equipos
de trabajo y realizar históricos. Quizá sea la menos potente de las tres. Podéis
encontrarla en su página web.

Estas tres herramientas OpenSource, para mí, a día de hoy, son las mejores que
podéis encontrar y las que más experiencia tienen porque llevan en el mercado ya
bastante tiempo. Hay otras muchas que seguramente se puedan acoplar a vuestros
proyectos, incluso, mejor que estas, todo es cuestión de probar e ir configurando la
mejor de ellas para vuestras necesidades.

Ahora vamos a hablar de herramientas que no son OpenSource. Las cuales suelen
tener unas características mucho más expandidas que las anteriores y que tienen ciertas
garantías a la hora de trabajar con ellas.

• Jira: Para mí la mejor herramienta para proyectos ágiles. Es una aplicación web
para el seguimiento de defectos. Gestiona requisitos, tiene seguimiento y un
flujo configurable, panel ágil, gestión de proyectos…es muy completa y
altamente intuitiva. Desde la web de Atlassian se puede recopilar información
de la misma.

• HP Quality Center: La más veterana de todas, lleva muchísimos años en el

mercado y es, desde mi punto de vista, la más avanzada de todas. Está incluida
actualmente en el paquete HP ALM y fue desarrollada por Mercury interactive,
pasando después a ser comprada por la misma HP que la ha ido mejorando poco
a poco. Su interfaz está algo desfasada pero su agrupación por módulos es un
punto muy fuerte. Incluye gestión de requisitos, gestión de pruebas, procesos de
negocio y es el centro del control de calidad de software en un proyecto. Si
queréis tener más información de cómo es, podéis entrar en Diario de un Tester
y para información para adquirirla en la misma página de HP.

• Microsoft Test Manager: es una herramienta incluida en ciertas versiones de

Visual Studio que nos permitirá tener un control total de la Calidad del software,
81
 totalmente integrado con el desarrollo en aplicaciones basadas en tecnologías
Microsoft. La interfaz es bastante moderna y sencilla, al estilo de Microsoft y su
utilización es dependiente de TFS. Su punto fuerte son los laboratorios de
pruebas. Tenéis información bastante completa sobre su utilización en Diario de
un Tester y podéis descargarlo desde aquí, con licencia incluida.

Con esta aproximación a las principales herramientas de control de calidad de

software, espero haberos podido ayudar y que vuestro día a día sea más sencillo. Sobre
todo, lo principal es que tengamos una ayuda adicional que nos permita que nuestro
trabajo sea más organizado y esté en un repositorio central de trabajo donde apoyarnos,
ayudarnos y sobre todo con toda la información guardada para el futuro.

68. El oficio de repartir felicidad

Hace bastantes años que me dedico a comprobar que las cosas funcionan, que hacen
lo que tiene que hacer…en definitiva, a asegurar la calidad de productos digitales, de
software.

Es un oficio complicado, a veces malogrado, que no brilla, en el que hay que estar
luchando día tras día para buscar la valoración exterior e interior que uno cree necesaria,
en fin, diríamos que difícil.

Dedicarse a asegurar la calidad, a hacer Testing, a probar, a validar, a verificar…como

lo querías llamar, es un oficio de pocos que vale para mucho, me explico:

Habitualmente en los proyectos somos muy pocos, pero nuestro trabajo hace feliz a
muchos, ¿en qué sentido? Pues muy sencillo, queridos lectores:

Hace feliz a desarrollo, que hace que su trabajo se entregue con calidad, pudiendo
irse tranquilo a casa, hace feliz a los directivos, que ven como su proyecto va viento en
popa y tienen que dirigir su esfuerzo y su mirada a otros asuntos, quizá más importantes
(una preocupación menos), hace feliz al bolsillo de la empresa, podemos hacer ahorrar
mucho dinero y sobre todo, la parte que más me gusta: hace feliz a los usuarios, la gente
que utiliza el producto.

Cuando alguien intenta utilizar el producto en el que hemos dedicado tantas horas y
esfuerzo y puede trabajar a gusto, sin problemas, esforzándose en hacer bien su trabajo
y no en cómo hacer funcionar ese maldito programa, todo va como la seda…que a gusto
vive uno cuando utiliza algo y funciona bien, no falla, dedica sus minutos justos y
necesarios, guarda, apaga y se dedica a otra cosa. Tranquilidad absoluta.

Echando la vista atrás y recapacitando, me doy cuenta de a cuanta gente he hecho

feliz con mi trabajo, cuantas personas han podido dedicar el tiempo exacto a realizar la
tarea que tenían entre manos y no han encontrado ninguna pega ni ningún problema.
Cuantos profesionales nos hemos podido ir a casa tranquilos, sin preocupaciones,
dedicando todo el esfuerzo en nuestra vida personal.

82
 Ahora cierro los ojos y me doy cuenta que realmente no me dedico al Aseguramiento
de la Calidad del Software, me dedico a Garantizar Felicidad.

Gracias a todos los profesionales que garantizan esa felicidad, vuestro trabajo es
único y vuestra dedicación la más importante, seguir haciendo sonreír al mundo.

69. Split Testing

Este tipo de Testing es aquel que se realiza cuando se llevan a su fin una serie de
pruebas aleatorias controladas, para mejorar las métricas de un determinado sitio web.

Este tipo de pruebas aleatorias implican el rellenado de diferentes formularios,

compras en un ecommerce, pulsaciones en banners de publicidad, pulsaciones en
botones o en secciones de la web…y un largo etcétera.

El Split Testing se utiliza prácticamente en su esencia para probar los formularios de

inscripción, las páginas de registro, en fin, la mayor parte de los campos que tenga una
web, sobre todo, para verificar que la información llega correctamente. También se
suele utilizar para realizar un proceso completo de compra en un ecommerce, ayudando
al dueño del mismo a aumentar los pedidos de su producto.

Habitualmente y en diferencia a los Test A/B, el Split Testing se utiliza cuando existen
más de dos variables, aportándonos información sobre si un cambio en la web nos
implica un incremento o una maximización de un determinado módulo o acción (por
ejemplo, que se pulse más en un banner de publicidad).

Al realizar este tipo de test, podemos asegurar en cierta medida que un diseño u otro
de la web nos benefició o no, dependiendo de la utilización que queremos que se dé a
la misma. Los clientes o usuarios, tendrán una experiencia más rica, si se elige un diseño
que otro y les facilitará la vida el uso de una manera que, de otra, por lo tanto, es
realmente importante saber este tipo de casuísticas para que estos clientes puedan
decantarse por este producto y desechar a la competencia.

Se puede utilizar el Split Testing con elementos visuales, como son imágenes, videos,
colores determinados, con tipos de texto (que llamen la atención o pasen más
desapercibidos, con la colocación y tamaño de los botones, hay gran cantidad de
variantes a utilizar y por utilizar.

Este tipo de Testing se utiliza mucho en publicidad y podemos seguir una serie de
consejos que nos ayudarán mucho a la hora de tomar medidas de mejora:

• Títulos: un buen título puede llamar la atención a los usuarios o espantarlos

definitivamente, es prácticamente el punto más importante y donde el mayor
número de porcentaje de entras y salidas se realizan.

• Primer párrafo: cuando un usuario da el primer paso o sigue leyendo, después

del título, la primera opción es el primer párrafo, que le llevará a interesarse más

83
 en la noticia o en lo que esté leyendo o le llevará a seguir buscando. Es muy
importante que este primer párrafo llame la atención.

• Formularios: cuando una persona quiere suscribirse o aceptar algo, es muy

importante que los formularios sean sencillos, vistosos y no asusten.

70. La importancia de las pruebas de aceptación

Los test de aceptación son una parte muy importante y quizá esencial de verificar el
software antes de sacarlo definitivamente a la luz.

Una vez que hemos comprobado que cada módulo funciona independientemente,
que funciona junto con los demás módulos, que se puede utilizar bajo un stress y unas
condiciones extremas, necesitaremos escuchar que es lo que piensan los usuarios
finales del software que hemos realizado.

Este tipo de pruebas las realizan un conjunto estanco y seleccionado de usuarios

finales y validarán que este, cumplirá sus expectativas. Entran dentro del rango de
pruebas de caja negra ya que únicamente se verificarán las entradas y salidas de datos,
no el funcionamiento interno.

Los usuarios finales comprobarán el software dejándolos a su aire o utilizarán unos

casos de prueba que se han realizado previamente, tanto por desarrolladores como por
el equipo de calidad. Estos casos de prueba servirán de guía para que los usuarios finales
comprendan y puedan comenzar a utilizar el software en cuestión.

De esta manera acabarán sacando defectos o algún tipo de aportación que no se

había tenido en cuenta y que quizá sea clave para el buen funcionamiento o poder
destacar de los principales competidores.

Si se le ha proporcionado una serie de casos de prueba, habitualmente, una vez que

han sido ejecutados y verificados, se deja al cliente utilizar el software con total
tranquilidad, de esta manera podemos saber cómo lo usará o de qué manera.

En este punto es muy efectivo el uso de mapas de calor, ya que sabremos si la

usabilidad del software es la correcta o si hay que mejorar algo antes de que los demás
usuarios lo utilicen.

En esta fase de pruebas comprobaremos realmente el auténtico nivel de calidad del

software y nos permitirá evaluar si se supieron capturar las ideas que se nos dieron antes
de comenzar y supimos desarrollarlo correctamente.

En este punto el cliente podrá opinar libremente, dando el visto bueno, reportando
mejoras o defectos o invalidarlo por completo ya que puede ser el caso de que no sea
bien recibido por su parte.

84
 71. Cuatro tipos de pruebas básicas en el mundo del Testing
Cuando comenzamos a trabajar en el mundo del Testing, tenemos una serie de
pruebas básicas que tener en cuenta.

El primer grupo de pruebas son las de progresión funcional.

Este tipo de pruebas se realizarán cuando nos vayan entregando trabajo. Son pruebas
profundas, realizadas con casos de pruebas y que tienen que entrar en todo el detalle
posible.

Este tipo de pruebas se suelen realizar en todo tipo de metodologías, tanto en

cascada como “nuevas” metodologías Agile. Son el bloque más importante de pruebas
a las que podemos enfrentarnos ya que cubren un porcentaje muy alto del trabajo de
un tester.

La progresión funcional tiene como punto fuerte, encontrar defectos que no son tan
básicos y que podemos limpiar con el siguiente grupo de pruebas: Las pruebas
exploratorias.

Las pruebas exploratorias son unas pruebas más básicas, sencillas y rápidas con las
que haremos una primera limpia.

Las pruebas exploratorias no están relacionadas con casos de prueba y ponen en

práctica técnicas de auto enseñanza del propio tester además de despertar sus sentidos.
Se tiene que experimentar con la pantalla y que a uno mismo se le ocurran todos los
caminos y pasos posibles para ir limpiando la pantalla de defectos primarios.

Estas pruebas nos ayudarán a dar una primera vuelta a la descripción y realización de
los casos de prueba, ya que en la teoría pueden salir unos y dando una vuelta a la
pantalla se nos pueden ocurrir algunos más.

Otro grupo de pruebas importante son las pruebas de Retesting. Estas pruebas
cubren un ratio de ejecución importante en nuevas metodologías, ya que son cosas que
se han quedado pendientes o han fallado en los Sprint anteriores y que tenemos que
retomar después. No se pueden integrar en el grupo de progresión funcional ya que han
pertenecido a este en el sprint anterior al que estamos y no son nuevos desarrollos, sino
cosas pendientes anteriores. Estas pruebas se realizan con casos de prueba y
habitualmente son nuevas ejecuciones de esos casos de prueba que ya hemos pasado
anteriormente.

Por último, tenemos el grupo de las pruebas de regresión. Estas pruebas tienen un
vacío legal dependiendo de las personas y de su opinión. Hay gente que basa estas
pruebas en defectos anteriores que pueden ser críticos y no queremos que pasen, hay
otros que marcan ciertos casos de prueba como de regresión y hay otros que realizan
casos de regresión para revisar que la aplicación, por lo menos, funcione de manera
correcta.

85
 Yo soy de los que opina que ninguna de las tres opciones es la correcta, sino una
mezcla de las tres. Me gusta en un primer momento marcar casos realizados que son
más críticos e ir ejecutándolos durante todos los Sprint siguiente y cuando tenemos algo
más de tranquilidad ir haciendo una batería de pruebas de regresión exclusiva que nos
permita probar lo que nosotros veamos y poder automatizarla después. A esta batería
nueva agregaremos casos de defectos o casos más críticos que nos podamos encontrar
por el camino.

En grandes rasgos estos tipos de pruebas son los más “básicos” que podemos realizar
y que se pueden ampliar con muchos otros, además de, poder sustituirlos y cambiar la
manera de realizarlos. Con esta simple guía, espero dejar algunos temas claros para que
los nuevos integrantes del mundo del Testing se apoyen y aclaren sus dudas, aunque
sea de una manera sencilla.

72. Pasos básicos para dar de alta un defecto

Cuando abrimos un defecto, tenemos que tener muy claro para quien va dirigido. No
es para nosotros, sino para otro compañero que desarrolla software que tiene que saber
al instante de que trata y poder entenderle y solucionarlo cuanto antes.

Un defecto tiene que tener unas características muy claras y siempre bien definidas.
En primer lugar:

El título tiene que ser totalmente claro. Leyendo el título, cualquier persona tiene que
saber de qué trata, sin ni siquiera haber leído la descripción. De esta manera
facilitaremos el trabajo al desarrollador, a nuestros compañeros si tienen que consultar
el listado y a nosotros mismos si queremos buscarlo y no podemos consultar el ID o
similar.

La descripción tiene que ser igual de clara y debería de contener una serie de pautas
y homogeneizar de la mejor manera posible todos los defectos que demos de alta. La
descripción principal tiene que explicar en una frase corta que es lo que sucede,
poniendo detalles del error y donde se produce.

En segundo lugar, tras la descripción, tendremos que describir pasó por paso como
reproducir el defecto, en que pantallas tenemos que ir entrando o donde tenemos que
pulsar para que nos aparezca. De esta manera, el desarrollador que no tiene que tener
un conocimiento funcional muy amplio de la pantalla, podrá reproducirlo fácilmente
siguiendo nuestros pasos y se podrá poner a solucionarlo más rápidamente.

Una vez que tenemos una descripción y los pasos de reproducción, uno de los puntos
más importantes es en que entorno lo hemos reproducido, en que variable, con qué
sistema operativo o con que navegador web. Aquí deberíamos de poner todo lujo de
detalles, así el desarrollador podrá descargarse o montarse el entorno lo más similar
posible dentro de sus posibilidades y de esa manera poder reproducir el defecto más
fácilmente.

Por último y algo importante, también, es intentar adjuntar una captura de pantalla

86
del defecto en concreto. Lo ideal es intentar adjuntar una captura completa de la
pantalla y no solo un pequeño trozo de ella, así si el desarrollador tiene alguna duda,
consultando la pantalla, sabrá exactamente donde nos encontramos.

La gran mayoría de nosotros sabemos exactamente como realizar este tipo de cosas
y más que nada, abrir defectos, pero las personas que quieren comenzar en el mundo
del Testing, quizá, no suelen encontrar toda la información posible en Internet, así que
poco a poco desde www.diariodeuntester.es y www.testingbaires.com los podremos
ayudar y centralizar toda la información posible por y para ellos.

73. Introducción al aseguramiento de la calidad del software

Coloquialmente hablando, diríamos que el Aseguramiento de la Calidad del Software
agrupa una serie de medidas que aseguran que el software o producto que estemos
probando haga lo que tiene que hacer.

En la década de los años 70, comenzó a realizarse más habitualmente el desarrollo

de software, que tuvo su boom más importante a partir de mediados de 1980, entrando
ya en los años 90. En este periodo de tiempo se utilizaban unas técnicas de validación
bastante rudimentarias que no cubrían todos los aspectos necesarios para asegurarse
de que verdaderamente, el software funcionaba bien.

Para ello, con este boom, se comenzó a utilizar la técnica de V&V (Verificación y
validación) que se ejecutaba a lo largo de todo el ciclo de vida del producto, así se fue
evolucionando al denominado Control de Calidad Software y llegando a nuestros días
como la evolución natural, llamada Aseguramiento de la Calidad del Software.

Esta evolución natural, introduce herramientas novedosas, técnicas corroboradas,

ideas tradicionales de los antiguos sistemas, mejoradas y nuevas que nos ayudan a
asegurar y garantizar el funcionamiento correcto de absolutamente todo el proyecto
donde estemos trabajando.

Ahora que conocemos más, podemos deducir la importancia que tiene a día de hoy
este trabajo, ya que nos encontramos en un mundo con usuarios y clientes cada vez más
exigentes que buscan resultados en los productos por los que invierten un determinado
dinero.

Una empresa que busca implantar en Producción un software o programa y que

quiera cobrar por ello, tiene que tener la certeza absoluta de que funciona
correctamente y que los clientes obtendrán un beneficio recíproco que les aporte la
satisfacción adecuada.

El Aseguramiento de la Calidad no se puede tomar como una determinada fase

dentro del ciclo de vida de un software, si no que tienen que ser puntos de control a lo
largo de todo este ciclo, que vayan asegurando pasó por paso esta Calidad y no se escape
nada. Para ello, un profesional dedicado a Asegurar la Calidad debería de cumplir lo
siguiente:

87
 • Realizar un plan de determinadas actividades que aseguren en todas las fases del
ciclo de vida la Calidad que se busca.

• Realizar las diferentes verificaciones en estas fases con las pruebas y

procedimientos necesarios.

• Auditar y cumplimentar los informes que servirán de histórico para los diferentes
evolutivos o actualizaciones que tenga el software o para diferentes proyectos a
lo largo del tiempo.

• Realizar diferentes informaciones y peticiones, en forma de defectos, a los

equipos de desarrollo para que solucionen los problemas encontrados en las
verificaciones anteriores.

• Preparar un plan de comunicación, en base a toda la información que se ha

trabajado, para poder implantar mejoras en el ciclo de vida evitando que vuelvan
a suceder diferentes problemas que se han encontrado.

• En base a los datos trabajados, poder encauzar un plan de contención que se

adelante a posibles desviaciones de tiempo y de dinero, mejorando el proceso
gratamente.

Todas estas fases, evidentemente, no las puede llevar a cabo una sola persona, por
lo tanto, es altamente recomendable el tener un equipo completo de Aseguramiento de
la Calidad que nos de la confianza suficiente.

Un equipo completo y un buen plan de Aseguramiento de la Calidad, nos garantizarán

casi completamente, el éxito rotundo del proyecto y, por lo tanto, un hueco en el
exigente mercado digital que tenemos hoy en día.

74. ¿Se puede establecer un método para asegurar la calidad?

Como vimos en un artículo anterior, el aseguramiento de la calidad tiene una serie
de fases y conceptos que hay que ir cumpliendo para garantizar que un software
funcione como debe y que no se debe de centrar en una sola persona, sino en un equipo
de Calidad que se encargue de las tareas del proyecto.

Cuando se comienza un proyecto de aseguramiento de calidad en software, el equipo

de Calidad tiene que poner el foco, principalmente, en determinar un plan y aplicar la
metodología adecuada para la manera de trabajar que se vaya a realizar, de esta manera
las decisiones serán lo más ágiles posibles, ayudando al ciclo de vida del software.

Tras determinar los puntos anteriores, el equipo tiene que guiar al equipo de
desarrollo a implementar la calidad necesaria para ese software, haciéndolo estable,
tapando posibles fisuras con evolutivos y sacar a producción un aplicativo de calidad y

88
bien armado.

La Calidad tiene que realizarse de principio a fin, no vale que únicamente el equipo
de Aseguramiento ponga todo el foco en probar el software, esto tiene que venir de más
abajo, desde desarrollo, cuando este equipo tendrá que realizar sus verificaciones y sus
validaciones para asegurarse que pasa a la siguiente fase lo más limpio posible. Después
de que el software pase las validaciones pertinentes en el equipo de aseguramiento de
la calidad, deben de realizarse otras pruebas que determinarán, definitivamente el paso
total a producción, las llamadas UAT o aceptación (que veremos en artículos
posteriores).

La empresa tiene que ser consciente y apoyar al 100% este ciclo de Calidad de
principio a fin para garantizar totalmente el software, ya que se beneficiará a corto plazo
de las ventajas que se le aportan, tanto a nivel económico como en tranquilidad,
disminuyendo los riesgos.

Cuando se realiza un buen ciclo de Calidad, los usuarios potenciales del software
están contentos, hablarán bien y por lo tanto podremos ganar nuevos, si es, al contrario,
al final acabarán buscando alternativas y nos veremos abocados al fracaso. A nivel de
tranquilidad de trabajadores y directiva, es muy importante, ya que un cliente satisfecho
no presionará para que se solucionen problemas y podrá trabajar tranquilo día a día.

El equipo de aseguramiento de la Calidad, al contrario de lo que se suele pensar, no

está dedicado a hacer pruebas únicamente, si no que su trabajo va más allá. Necesitan
una dedicación a realizar la metodología, una definición de técnicas de calidad, mejoras
en el proceso y sobre todo una documentación (tanto a nivel de documento como de
casos de prueba) que ayudará a modo de histórico al proyecto en curso y a futuros
proyectos que se quieran abrir.

Esta documentación nos aportará que técnicas funcionaron en el pasado, que

técnicas hay que desechar y mejorar, desde un camino ya creado, una manera de
trabajar con elementos conocidos y utilizados, pudiéndonos ayudar a avanzar de
manera más ágil y segura. Sabremos de antemano que errores no tenemos que cometer
y que partes mejorar.

Básicamente, al introducir un ciclo de Aseguramiento de Calidad en un proyecto, de

manera casi inmediata, tendremos los siguientes beneficios:

• El éxito del proyecto aumentará exponencialmente, obteniendo mayor

satisfacción global.

• Este éxito y satisfacción nos reportará mayores beneficios, ya que la gente

confiará en nuestros servicios y se verá apoyado por el buen funcionamiento del
software o la plataforma.

• Tendremos una mayor visibilidad hacía el exterior, tanto a nivel de empresa

89
 como a nivel de nombre de proyecto, mejorando frente a los principales
competidores.

• Se podrán realizar métricas en base a los estándares que hemos aplicado,

pudiendo verificar que puntos se han cumplido, cuales hay que mejorar y cuales
han fallado.

• Con estas métricas, obtenemos un histórico de cara al futuro para no volver a

cometer los mismos errores. En resumidas cuentas, tenemos el terreno
sembrado para plantar nuevos proyectos en él.

• Se podrán monitorizar mucho más los equipos, ganando en velocidad y

estabilidad, ahorrando en recursos innecesarios y pudiendo cumplir las
planificaciones mucho mejor.

75. Los eslabones de la cadena

Cuando hablamos de calidad, sabemos lo que decimos, sabemos que son cosas que, a
priori, son buenas, suelen ser más caras y deberían de durar más que algo que no es de
la misma calidad.

Sabemos que adquirimos un producto o un servicio que nos dará ciertas prestaciones o
nos cubrirá una serie de necesidades de una manera más adecuada o más completa.

Cuando estamos en nuestro puesto de trabajo, estamos realizando tareas o acciones

que van a servir para que otras personas tengan o disfruten de ello, es un movimiento
recíproco, se hace una acción que sirve a otra persona para beneficio suyo o de la
empresa. Una cadena constante que, al unir todos los eslabones, devuelve, de manera
inconsciente en muchos casos, un proceso de trabajo.

Estos eslabones tienen que ser sólidos, constantes, bien definidos y sobre todo que
tengan calidad. Si lo pensamos un poco a más alto nivel, nuestra acción sirve para otra
persona o para otro grupo de personas obtengan un beneficio.
Si ese beneficio no tiene la calidad suficiente, llevará a que el siguiente grupo de
personas no obtenga todo el buen resultado que se podría obtener y así eslabón tras
eslabón haciendo que la cadena se vaya debilitando, incluso pudiendo ocasionar un
deterioro más grave que desbarate todo el proceso.

La calidad en nuestro trabajo tiene que ser consecuente, tiene que ser objetiva, tiene
que aportarnos un beneficio propio y un beneficio mutuo entre iguales, quedando claro
que, si el trabajo se realiza bien bajo nuestro tejado, el siguiente eslabón tendrá una
base reforzada e irá en aumento, aportando un beneficio global que nos repercutirá de
manera recíproca personal y profesionalmente.

Somos dueños de nuestras acciones y somos capaces de aumentar el beneficio de

nuestras acciones por y para nosotros y también enfocándose en el resto de personas o

90
equipos.

La calidad comienza y acaba en cada uno de nosotros a nivel particular, y, además,

somos parte de la calidad dentro de los diferentes procesos globales de los proyectos o
empresas en los que nos encontramos. La consecuencia directa de una calidad personal
y global en un proyecto es una amplitud de beneficios personales, profesionales y
empresariales sin precedentes.

76. Implementando procesos organizativos en los proyectos

Hace unos meses que me propusieron el reto de diseñar y crear un proceso de
desarrollo, calidad y operaciones, manteniendo ideas anteriores, mejorándolas y
aportando otro punto de vista enfocándose más al aseguramiento de calidad del
proyecto. Esta labor va tomando forma, paso a paso y se van implantando pequeñas
piezas que van organizando el proyecto y se va ordenando el trabajo de las personas
para ser más eficientes, aplicar más las técnicas de calidad y enfocarnos todos en un
mismo camino.

Los procesos organizativos que se van implantando, van funcionando, cogiendo forma,
implantando cultura de calidad y cultura de organización global y unificada.

Cada día, veo más claro que estos procesos organizativos son completamente
necesarios en las diferentes organizaciones donde trabajemos. Aportando una serie de
pautas de trabajo, consensuando con las diferentes personas y abriendo, entre todos,
la puerta a la organización, tenemos mucho terreno labrado y parece que no, pero se
nota de sobremanera como todo va mucho más rodado, aparecen menos problemas y
se van tomando una serie de pautas que hacen que la máquina no pare y sea
completamente constante.

Estos procesos se han de implementar de una manera progresiva, haciendo ver que son
necesarios y que poco a poco van ayudando a las personas a mejorar su día a día y a que
se optimice su labor.

Como primer punto a abordar, es esencial una organización de información. Tenemos

que tener claro que queremos aportar, cuando y de qué manera. De esta forma,
elaboraremos una serie de informes que irán repartidos por diferentes áreas o equipos
de trabajo y permitirán que escalafón a escalafón, la información fluya, sea clara y todos
la puedan compartir.

Esta información tiene que ser contundente, sin fisuras y que aporte un gran valor a
cada persona, sin que se sienta perjudicada ni señalada. Nunca hay que buscar un aporte
de información que ponga en tela de juicio el trabajo de nadie, sino que ayude a mejorar,
poco a poco, el trabajo de las personas y los equipos.

En el caso de que alguien se sienta perjudicado hay que saber tomar, de manera ágil y
rápida, una determinación para agrupar todos los problemas que se puedan tener y
mejorar o ayudar a la persona, explicando, porque se ha mandado cierta información y
como puede ayudarle, no perjudicarle.

91
En base a informaciones, siempre hay que tener claro que se ha de aportar, de qué
manera y con qué herramienta vamos a trabajar. Lo ideal es tener informes de datos
concretos, de defectos en diferentes versiones o despliegues, que elementos de trabajo
vamos a desplegar en producción o en que hemos estado trabajando en un periodo de
tiempo. Para ello podemos recopilar diferentes informaciones con Excel y, de manera
más novedosa con Power BI.

Power BI nos muestra una serie de paneles y de informaciones con unos juegos de datos
que podemos migrar desde Excel, OneDrive o VSTS, por ejemplo y explotarlos a nivel
gráfico de una manera muy potente. Os escribiré un artículo con datos concretos y
niveles de utilización de esta herramienta para que le podáis sacar todo el jugo posible.

En segundo lugar, es importante recopilar informaciones de despliegue. Tener claras en

la cabeza una serie de fechas, organizar diferentes puntos de control y siempre
repetirlos a lo largo del tiempo, de esta manera crearemos unas pautas repetibles que
nos darán un nivel organizativo muy potente ya que las personas tomarán una rutina de
trabajo, ajustando las ventanas de tiempo cada vez mejor y optimizándolas lo máximo
posible.

Dentro de los procesos organizativos que podemos aportar en los proyectos donde
trabajamos, existen muchas variantes, muchas formas y maneras, pero siempre es
esencial, como comento en el párrafo anterior, tener claros cuales van a ser y crearlos
de manera rutinaria a lo largo del tiempo para que esa organización se convierta en
rutinaria, cultivando en las personas diferentes culturas, como la de calidad o la
organizativa o de procesos. Esto nos dará la base esencial para que no solo organicemos
el proyecto de manera global si no que cada persona culturalmente hablando,
interiorice las pautas esenciales y las ponga en práctica en su día a día, ayudando a los
que le rodean. Una especie de simbiosis que aumentará la calidad en el proyecto y en el
trabajo diario de cada uno.

77. La teoría del Taylorismo

Cuando hablamos de procesos, tenemos que remontarnos, históricamente hablando, a
tres de los precursores de las diferentes ideas que utilizamos a día de hoy. Vamos a
comenzar por el Taylorismo.

Formulado y diseñado por Frederick Taylor, donde se hacía hincapié en distintas

divisiones en las tareas cuando existía una producción en masa.

Taylor fue el promotor de la organización científica del trabajo y tras ello, realizó el
proceso de trabajo del que vamos a tratar en este artículo. En sus industrias, que eran,
principalmente del acero, hizo estudios, estadísticas y pruebas con medición de tiempos
de ejecución, remuneración en el trabajo y estandarizó una revolución personal de cada
trabajador, mejorando el rendimiento de cada uno.

92
Antes del Taylorismo, los trabajadores tenían libertad para realizar las labores
encargadas, esto suponía que cada uno lo hiciese a su manera y se perdía tiempo en
acciones que no eran del todo óptimas, al final, usando la destreza de cada uno y
determinando que mejor manera de hacer cada acción, se sacaba un “boceto” de cómo
realizar una labor en el mejor tiempo posible, optimizándolo totalmente y ahorrando
costos en el mecanismo.

La principal idea fue el aumento de la productividad de las diferentes personas que

participaban en el proceso industrial, pudiendo de esta manera, mejorar la cadena de
trabajo. Mejorando la cadena, se mejora el rendimiento y mejorando el rendimiento, se
maximiza la eficiencia, consiguiendo mayores beneficios.

Frederick Taylor puso en marcha un cronometraje de las acciones de máquinas y

personas, eliminando movimientos o acciones inútiles. A la vez impuso un sistema de
pagos de primas por rendimiento que supuso una motivación extra y mejoró el beneficio
de una manera muy amplia, añadiendo un gran potencial productivo en las industrias
que utilizaron el Taylorismo.

Una de las pegas que tuvo este método, fue que ciertas industrias comenzaron a pagar
a menor precio las piezas para que los obreros trabajasen más deprisa y obtuviesen más
beneficios aportando más trabajo, esto generó malestar y se solucionó a partir de un
nuevo rango de trabajadores, mejor conocidos como supervisores. Además, tuvo el
problema del monopolio del conocimiento, algo que hemos heredado, en muchos casos
hasta nuestros días.

El Taylorismo, como proceso y precursor del resto, mejoró las industrias en el sentido
de aumentar la destreza de los trabajadores, control del tiempo aumentando el capital,
individualismo personal cualificado, mejora de movimientos innecesarios y aportar un
mayor tiempo productivo dentro del proceso.

Según Frederick Taylor, hay que seguir las siguientes pautas para poner en marcha su
proceso:

• Buscar y contratar a personas muy hábiles en el trabajo al que nos queremos

dedicar.
• Estudiar y definir los movimientos elementales que hay que utilizar para
realizar el trabajo en cuestión.
• Cronometrar puntillosamente cada movimiento o acción realizada para hacer
el trabajo en concreto.
• Revisar los movimientos, eliminando los inútiles, lentos o poco productivos,
pudiendo agilizarlos y mejorarlos.
• Apuntalar los movimientos efectivos, concretos y ágiles y llevarlos a cabo en
una secuencia totalmente aséptica y repetirla constantemente.

Este proceso tuvo auge a finales del siglo XIX, cuando el crecimiento industrial fue
enorme, pero tuvo un rechazo enorme en los trabajadores, por lo tanto, se mejoró,
dando lugar al fordismo, que lo trataremos en el siguiente artículo. También,

93
aparecieron variantes mucho más modernas como el Taylorismo digital.

78. Alcatraz o como evitar las fugas de talento

El otro día, viendo un documental en televisión me di cuenta de que la calidad y la
ejecución de procesos van más allá de lo que aplico en mi día a día.

El documental era de Alcatraz, donde se hablaba de la fuga más famosa de la prisión

federal de EEUU y de la serie de “ayudas” que tuvieron los presos a la hora de poder
escapar.

La fuga, en realidad y tratando el tema que realmente nos interesa, fue una degradación
constante de los métodos y procesos utilizados para los presos, un relajamiento en los
diferentes trabajos de los carceleros y una serie de malas acciones en el método de
trabajo que se aplicaba hasta la fecha. Por lo tanto, la calidad en general, descendió.

Durante más de 25 años, en sucesivas fugas fallidas, los métodos y procesos de trabajo
utilizados eran infranqueables, seguros y repetitivos, por ejemplo, pudiendo tener un
control absoluto del número de presos y las acciones que realizaban. El proceso tenía
unas pautas de calidad sobresalientes y eso se notó durante todo este tiempo, todo
intento de fuga, fue desbaratado.

Una vez que estas fugas iban siendo fallidas y el tiempo pasaba, el método de trabajo
bajó el listón, por lo tanto, descendió su calidad, aflojando las pautas, siendo menos
severas, dando más libertad de acción a los presos y dejando que la confianza se
apoderase de la que llamaban “la roca”.

Esta confianza, que con el tiempo se convirtió en relajación y costumbrismo, hizo que
tres presos idearan una de las fugas más famosas de la historia, se llamaban: Frank Lee
Morris, Clarence Anglin y John Anglin.

Estos tres presos, escarbaron agujeros en sus celdas, construyeron “tapas” falsas con
papel secado con la forma del agujero, para disimular y con el mismo método,
construyeron unas cabezas falsas que hicieron de señuelo, como si estuviesen dormidos
en la cama.

Esto es realmente similar a lo que puede suceder en algunos proyectos. En similitud,

podemos decir que se pueden realizar fugas de talento.

Habitualmente, un proyecto comienza con un proceso de trabajo férreo, de calidad,

impenetrable y que es seguido por los profesionales, paso a paso. En este tiempo, todo
suele ir rodado. Poco a poco, el tiempo hace que podamos tomar una actitud
costumbrista y esos procesos comiencen a relajarse, a ser más livianos, a no seguirse “a
pie juntillas” y comienzan los problemas.

Con estos problemas empiezan los apaños, tapando agujeros y poniendo soluciones
temporales a cosas que deberían de cerrarse totalmente. La calidad se degrada y esto
hace que las cosas no funcionen correctamente. Como en la historia de Alcatraz, La fuga

94
puede comenzar y con ella una pérdida de información, de talento y de personas, que
determinará un goteo constante que puede hacer que un proceso se desmorone desde
sus cimientos.

¿Qué debemos de hacer para que esto no ocurra?

Lo primero es tener una constante optimización y mejora de los procesos y métodos

utilizados, ajustándolos a las necesidades del proyecto, al tiempo actual y al momento
en el que se encuentre. Por ejemplo, no es lo mismo una etapa de desarrollo de un
proyecto, que una etapa de mantenibilidad o una etapa de evolutivos.

En segundo lugar, se necesita tener un proceso de formación y mejora de personas,

dirigiendo el foco a que estas se encuentren arropadas y en constante ayuda para
verificar sus necesidades. Para ello suele existir la figura de responsable de equipo de
trabajo, que debe hacer reuniones periódicas para dar una cercanía a las personas con
las que trata y verificar que todo sigue correctamente. Si no fuese así, aplica medidas
correctoras para mejorar, entre los dos, esas necesidades.

Por último, tener mecanismos de control de calidad, indicadores de la misma y poder

cubrir todos ellos con acciones personalizadas. Estas nos darán que mejoras o
aportaciones daremos en el proyecto. Hay que utilizar KPIs o indicadores que nos
marquen en cada fase del proyecto que todo sigue correcto o si no, enderezarlo para
que el trabajo y esfuerzo realizado no acabe en fracaso absoluto.

Tenemos que pensar en la historia de Alcatraz, en el momento que los procesos,

métodos o calidad de las acciones realizadas se degrada, se relaja o se pasa por alto
algún punto. Esto afectará directamente al núcleo central del proyecto, haciendo que
disminuya el interés, debilitándolo y produciendo, como ya comentamos antes, ese nivel
de fugas de talento que tanto daño hacen a las organizaciones.

Lo que no se puede hacer, bajo ningún concepto es comparar el sitio donde se trabaja
con Alcatraz, o sea, como una cárcel. En el caso de muchos lectores (o me imagino que
será así) y en mi caso personal, la realidad del proyecto y del sitio donde trabajo dista
mucho de ser una cárcel, todo lo contrario, es un sitio donde disfruto profesionalmente,
donde aprendo cada día cosas nuevas, donde, también, los demás aprenden de mi y
donde existe tal cantidad de talento que sería complicado describirlo en pocas palabras.

Eso si, lamentablemente también hay casos completamente diferentes del mío y cuando
alguien ve el sitio donde trabaja como una cárcel, mi recomendación es que,
dependiendo de las diferentes situaciones personales de cada uno, finalice la relación
laboral ya que para que todo lo escrito anteriormente se cumpla, el profesional y la
organización tienen que sentirse a gusto y beneficiarse mutuamente.

Cuando perdemos la ilusión en algo, es mejor seguir caminos separados y cerrar la etapa
positivamente. Bajo mi punto de vista, hay que evitar convertirse, profesionalmente
hablando, en presos con juicios predispuestos por nuestras propias acciones. El sitio
donde desarrollarnos profesionalmente tiene que ser un sitio donde encontrarnos a

95
gusto y donde poder disfrutar del día a día si no, nosotros mismos podemos llegar a
convertir la realidad en una “Alcatraz personal”.

79. A veces me siento como Alberto Chicote

Cuando estoy haciendo mi trabajo, me acuerdo constantemente en Chicote y su
pesadilla en la cocina (aunque para mi no es una pesadilla, si no al contrario, una ayuda
a personas), me vienen a la mente sus programas y comparo el día a día que he ido
viviendo a lo largo de mi carrera y veo similitud de momentos que son muy similares.

En cada programa tenemos tres fases, cosa que suele pasar también en cada proyecto
que he visitado:

1. Fase de observación: cuando Chicote llega, lo primero que hace es probar los platos,
observar como hacen las cosas, como las cocinan, como trabajan y como actúan de cara
a los clientes. Apunta, aprende y comienza a sacar conclusiones positivas y negativas de
sus acciones principales.

Aquí, se presenta a todo el equipo, lo conoce, le marca distancias, sabe a que atenerse
y como actuar o tratar con todos, para ser más o menos asertivo. Esto pasa exactamente
igual en cualquier proyecto, hay personas más aprensivas a las que hay que tratar de
una manera y otras que se puede hacer un tratamiento de tu a tu, donde las mejoras
fluyen directamente.

Pasa unas jornadas de trabajo con ellos y así puede tener una valoración mucho más
profunda. En esta fase se mantiene, más o menos, al margen y solo interviene en caso
de necesidad excesiva, deja hacer y observa, simplemente.

Esto me suele pasar cuando he llegado a los proyectos donde he trabajado. Primero
observo, dejo trabajar, aprendo como lo hacen y voy valorando poco a poco que cosas
se están haciendo bien y que cosas no se están haciendo tan bien y voy apuntando
donde y como mejorar.

De ahí, ambos, sacamos un plan de actuación, hablando y tratándolo con nuestro equipo
de personas, que nos ayudan a ponerlo en práctica, destacando puntos positivos y
sacando puntos de mejora para que ayudar a las personas sea mucho más fácil.

La única diferencia es que, en Pesadilla en la Cocina, a veces se entra a saco para

destapar desastres ya que la audiencia así lo solicita y en un proyecto hay que hacer las
cosas mucho más calmadas y tratarlas con sumo cuidado. Las personas están por encima
de todo.

2. Fase de ayuda: en esta fase, cuando Chicote tiene unas pautas ya revisadas y
valoradas por su equipo de trabajo, se dedica a introducir pequeños cambios en los
procesos de trabajo, ayudando con mínimas pautas que, en principio, deberían de
mejorar las acciones y hacer que el trabajo fluya mucho mejor.

96
En muchos casos, al seguir haciendo las cosas no demasiado bien durante tiempo o por
falta de conocimientos, estos cambios no suelen ayudar demasiado, aunque lo que, si
que se ve, es que la cosa se puede mejorar y apoyarse en simples pautas generalizadas
que ayudan a que el proceso fluya con mayor facilidad.

En un proyecto, habitualmente, al introducir pequeñas pautas, las cosas fluyen mejor,

no se ve resultado final, pero si que se muestran resultados de mayor calidad que lo que
se hacía hasta la fecha. Se trabaja más en equipo y se ayuda a que el producto se
entregue a los clientes con mayor calidad.

En la fase de ayuda, se sacan unas pautas más personalizadas, ya que, al introducir

pequeños cambios, si que salen las acciones mal realizadas y ya se puede centrar el tiro
en ayudar específicamente a una pauta o trabajo específico. Los clientes no están
satisfechos en su totalidad, pero hay un rango de mejora todavía por superar.

3. Fase de implantación y mejora: Una vez que se han estudiado estas pautas más
personalizadas, se estudian y se sacan acciones concretas que se pondrán en
funcionamiento a lo largo del tiempo.
Estas pautas se van añadiendo en el tiempo y de manera progresiva, ya que no se
pueden realizar cambios de golpe y totalmente en un sitio, ya que causan problemas de
manera disruptiva y las personas que tienen formas de trabajo adquiridas con el tiempo
se les rompe el día a día de manera total.

Chicote, lo que hace es "hacer un lavado de cara" en el negocio, les presenta una nueva
carta y una nueva manera de hacer las cosas, pauta a las personas y las dice donde
tienen que estar y cuales son sus acciones, clarificando su puesto en el restaurante.

Esto es muy similar a lo que ocurre en un proyecto. Se presenta una propuesta que es
un "lavado de cara", se utiliza la base de lo antiguo y se mejora con lo nuevo. Se clarifican
los puestos y las responsabilidades de los profesionales y se les dan pautas de actuación
dentro de un proceso conciso, sencillo y fácilmente ejecutable. En resumen, las nuevas
recetas son las acciones y la nueva carta, de manera global, es el proceso a implantar.

Aquí, Chicote, se queda unas jornadas más, observando el nuevo proceso y su

funcionamiento y ahora si, aporta acciones correctivas que hacen ver como se tienen
que hacer las acciones dentro del nuevo proceso de trabajo, mejorando lo que está
saliendo a los comensales (en nuestro caso, entregando en producción a los clientes).

Como veis, parece que no, pero todo está relacionado con la calidad y los procesos,
desde un programa de mejora de restaurantes a la mayor empresa que nos podamos
imaginar. La calidad es un ente que está por encima de cualquier cosa que nos
imaginemos, por eso, Alberto Chicote, entre otros muchos, tiene la buena fama que
tiene en sus restaurantes, porque nos aporta calidad por encima de todo.

80. Jira con Testlink y de aperitivo Sonarqube

Empecemos por Testlink, un software libre que nos permite gestionar pruebas en el
proyecto que queramos. Muchos ya lo habéis utilizado y sabéis lo potente que es. La

97
última versión, la podéis descargar desde aquí:
https://sourceforge.net/projects/testlink/files/latest/download?source=files

En ella se pueden crear casos de prueba, baterías de pruebas, ejecución de las mismas
y seguimiento de los resultados obtenidos. Es muy similar a lo que se puede realizar con
MTM o con ALM (siendo estas de pago y más completas en algunos casos).

Lógicamente, al ser libre, tiene una comunidad bastante amplia de información y

podemos encontrar muchas cosas de manera fácil. Es totalmente configurarle, tanto por
perfiles, como por módulos.

Como muchos conocéis, la organización de los casos de prueba, es bastante sencilla, a

nivel de árbol jerárquico, creando baterías completas y muy usables. Una de las
opciones que más me gustan, también aplicadas en otras herramientas es el uso de
versiones o de ejecuciones, para saber cuando y como se ha ejecutado todo.

También contamos con asignación a personas, seguimiento de resultados, el avance que

se está haciendo al ejecutar una batería de pruebas determinada y evidentemente,
registrar el resultado de la pruebas que acabamos de realizar. Dejando constancia de su
funcionamiento y poder sacar informes de control para valorar si algo es apto o no para
desplegar en producción.

Una de las cosas que mas me gustan de Testlink, que para ser una herramienta que no
tiene coste alguno, tiene funcionalidades muy potentes y que nos solventan de buena
manera la forma con la que vamos a probar un software.

El reporte de informes en tiempo real es una de las mejores cosas que se pueden
encontrar, ya que permite una consulta directa y efectiva de lo que se está realizando
en ese momento, pudiendo tomar decisiones en base a que pasos dar o que hay que
modificar o mejorar para llegar en fecha y entregar con calidad.

Testlink, a simple vista, parece que es una herramienta que se ha ido quedando más
anticuada, respecto a sus principales rivales, pero para mi, realmente, sigue siendo
bastante potente (más fea a nivel de diseño) pero muy efectiva.

A la hora de realizar una integración con Jira, es relativamente fácil, y como digo, ahora
mismo tenemos otras alternativas como Zephyr, qTest o TestRail, con el inconveniente
de que hay que pagar licencias y puede que no nos cuadre si tenemos un presupuesto
más ajustado.

Si realizamos esta integración, que es el software donde realizaremos el seguimiento de

defectos, incidencias y podemos realizar una gestión integral de proyectos, de manera
bastante más potente que muchos de sus rivales directos, ahí Atlassian ha estado
haciendo muy buen trabajo. Otro punto a favor es que tenemos una licencia de pruebas
de 30 días que nos permitirá saber si el producto se adecua a las necesidades que
buscamos.

98
Jira es personalizable y podemos crear elementos tipo defecto, tipo mejora, historias de
usuario o personalizados, además de asignarle una prioridad y tener un flujo de estados
también personalizable que nos permite introducir procesos de calidad, de mejora o de
lo que consideremos.

Lo que nos permite Jira, por encima de todo y según hemos comentado es realizar el
seguimiento de proyectos, creando mapas de proyectos completos y que nos permiten
poner foco en el tiempo que creamos oportuno para poder tener todo bajo control. Su
integración con infinidad de herramientas le hace ser un aliado perfecto a la hora de
trabajar en un proyecto.

Cuando integramos Testlink con Jira y hacemos que los dos funcionen a la par, podemos
crear unos flujos de pruebas y validaciones muy logrados, cubriendo todas las
necesidades que tengamos dentro del proyecto donde estemos trabajando. Lo ideal es
que la integración esté relacionada con la creación de incidencias al ejecutar casos de
prueba y el flujo de estados que hayamos personalizado, si fuese necesario.

Una gran ventaja que tiene Jira frente a sus competidores, aunque cada vez se van
acercando más, es el panel de trabajo. Es un panel limpio, que muestra solo lo
importante y muy intuitivo. Prácticamente no hace falta tocarlo ni configurarlo en casi
ningún momento, se ajusta perfectamente a la mayoría de los proyectos. Podemos
utilizar diferentes planificaciones, usando Scrum, Kanban, una metodología
personalizada y mixta, pudiendo agregar cosas que necesitemos y siendo lo mas flexible,
prácticamente, del mercado.

Cuenta con un amplio Marketplace donde hay muchas extensiones y productos

totalmente adaptables a la herramienta que permitirán adecuarlo al máximo y sacarle
el mayor partido a todo.

Para cerrar el ciclo, hablando de herramientas indispensables, no podía faltar

Sonarqube, que realiza revisión de código continua, detectando los llamados "Code
Smells", también defectos de código y vulnerabilidades que podamos haber cometido a
lo largo del desarrollo.

Es muy personalizable, pudiendo utilizarla desde entornos en Cobol, como en JavaScript,

ampliando las reglas de manera personalizada o incluyendo las que vienen por defecto.
Es muy rápida de instalar, sencilla y de fácil configuración, además acaba de salir la
última versión 6.7 (LTS) que la podéis descargar desde aquí:
https://www.sonarqube.org/downloads/

Para mi, estas tres herramientas, son de lo más fundamental que podamos tener en un
proyecto y lo mejor de todo, es que dos son gratuitas y solo hay que pagar licencias por
usuario en Jira. En siguientes artículos aprenderemos más sobre él. Hay un foro que está
un tanto antiguo pero que sirve para hacerse una idea y es gestionado por uno de los
referentes en España, Antonio Calero, la URL es la siguiente:
https://www.sonarqubehispano.org

99
Hay un tutorial muy bueno en el que explica como integrar Testlink con Jira:
http://blogs.quovantis.com/step-by-step-integration-of-jira-with-testlink/

100