Seis en 75 es una recopilación de los artículos más destacables en todos mis años de dedicación profesional al ámbito del aseguramiento de la calidad. Cada uno tiene su propia historia y ahora, esa historia, la compartiré con todos vosotros. El beneficio íntegro de este libro irá destinado a la Fundación Menudos Corazones, que lleva a cabo los programas y actividades necesarios para mejorar la calidad de vida de los niños y jóvenes con cardiopatías congénitas y de sus familias. Puedes adquirir el libro completo en: http://www.amazon.es/dp/B01EUVJOCE

2. Título: Seis en 75
© 2016, 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
1ª edición – ISBN
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.

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

4. El beneficio íntegro de este libro, irá destinado a la fundación Menudos corazones, que
lleva a cabo los programas y actividades necesarios para mejorar la calidad de vida de
los niños y jóvenes con cardiopatías congénitas y de sus familias.
Muchas gracias por tu ayuda.
Con profesionalidad y cercanía, Menudos Corazones os acompaña y apoya en esas
situaciones, a veces complicadas, que surgen cuando tenéis un hijo con una cardiopatía.
Desde el año 2003, Menudos Corazones adopta la forma jurídica de fundación, pero su
labor comenzó como federación en el año 2001 aunando el esfuerzo de varias
asociaciones de padres que actuaban en las comunidades autónomas.
Nuestra gestión se caracteriza por la transparencia y buenas prácticas. La Fundación
Lealtad, institución independiente y sin ánimo de lucro, ha otorgado a la Fundación
Menudos Corazones el sello “ONG Acreditada”. Se trata de un distintivo único en
España que distingue a aquellas ONG que cumplen las exigencias de transparencia y
eficacia en la gestión.
Menudos Corazones está registrado con el CIF G-83758151.

5. ÍNDICE
1. Nociones básicasde la Calidad del Software
2. La esencia del Testing de manera rápida y breve.
3. Los módulosde HP Quality Center
4. El tester no es un desarrollador
5. La importancia de las pruebasde 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 nuestrasvidas.
9. El flujo de los defectos
10. El testing no es solo cosa de Testers
11. Testing exploratorio en entornoshostiles de desarrollo.
12. Monitorizar una aplicación en MicrosoftAzure
13. Desarrollo y testing ágil
14. Habilitar los registros de diagnóstico de Azure
15. Pruebasde compatibilidad en diferentesnavegadorescon Coded UI
16. ¿Funciona realmente elTest-driven development(TDD)?
17. Apostar por testing, garantía de futuro.
18. La importancia delotro testing
19. Cuando eltester es transversal
20. Pruebasde carga sobre una aplicación web en Azure
21. Cuando eltester tiene la razón.
22. La importancia de un entorno estable de Testing

6. 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 pruebasde regresión.
28. Pruebasexploratoriasantesque nada.
29. Repartir el trabajo de una manera eficiente.
30. El error de no pensar en el testing
31. ¿Cómo reportastusdefectos?
32. Prestando nuestroscasosde prueba
33. ¿Usamoscorrectamente elnombre de proceso de desarrollo?
34. Introducción altesting metódico con MicrosoftTest manager.
35. Especializarse o morir.
36. Utilizando las etiquetas de TFS y Test Manager 2013
37. Planificando elsprint del equipo de Testing
38. La Calidad empieza en nosotrosmismos
39. Introduciendo una regresión en todoslos ciclos de desarrollo
40. Entrenando lossentidos 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 alpanelprincipalde TFS del
equipo.

7. 46. Educar alequipo para que sea auto gestionable.
47. Ayudando a reconducir elcamino 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. Pruebasde portabilidad
54. Cada día somos más exigentes
55. Pruebasen dispositivos móviles
56. Rotar en un equipo de trabajo
57. La dificultad de validar desarrollosexternos
58. Pruebasen responsive web design
59. Pruebascon mapasde calor
60. Pruebasfuncionalesde SEOpara web
61. Automatización con Selenium
62. Pruebasde interoperabilidad
63. Pruebasde Internacionalización de software
64. Habitualmente...
65. Nos crecen los enanos
66. Pruebasde Stress
67. Herramientaspara elcontrolde la calidad
68. El oficio de repartir felicidad
69. Split Testing

8. 70. La importancia de las pruebasde aceptación
71. Cuatro tipos de pruebasbásicasen el mundo del Testing
72. Pasosbásicos para dar de alta un defecto
73. Introducción alaseguramiento de la calidad delsoftware
74. ¿Se puede establecer un método para asegurar la calidad?
75. Gracias

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

10. ¿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.
Elretesting es lamanera de asegurarnos de que lacorrecció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.

11. ¿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 laCalidad de un software siempre nos dará alegrías,lagarantí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 esegranito 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.

12.  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 altalas 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 elque no estánlas 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.

13. El futuro no está en estas metodologías emergentes, de hecho, revisar y preguntar 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.