Testing en Spectra (Parte II de II)

Primera Parte

¿Cuántos casos de prueba se han podido revisar en Windows Vista en la fase de Testing?

Muchos miles. Para cada parte del producto hay diferentes equipos de testeo que se especializan en las diferentes áreas. En España, durante el desarrollo de Windows Vista hemos testeado la parte de Media Center, la compatibilidad con aplicaciones del mercado, todo lo relacionado con conectividad/activación y la interfaz traducida.

Solo verificar la interfaz traducida al castellano eran alrededor de 2000 test cases. Esto no incluye los test cases de Media Center ni los de Compatibilidad

¿Se cuenta con empresas o personas externas o sólo lo hacéis internamente para que "no roben el producto antes de estar listo"?

Siempre que podemos contamos con empresas y personas externas. Para nosotros es muy importante recibir las opiniones de los que va a ser nuestros clientes antes de finalizar el producto. Las direcciones de los productos cambian en función a lo que nos cuentan estos usuarios.

Durante el desarrollo del producto se definen unos milestones (fases). Lo que llamamos “Betas”. En las primeras Betas, el producto está más o menos estable pero todavía en fase muy preliminar. Es muy importante enseñárselo a nuestros clientes para que ellos puedan darnos su criticas y podamos incorporarlas. Así es de importante para nosotros ese feedback.

Pero también es importante para clientes y otros desarrolladores ver versiones preliminares. De este modo, ellos pueden evaluar y planificar sus propios proyectos por si deciden usar nuestra tecnología.

Para coordinar todo el feedback externo abrimos los programas “Beta”.

Los Beta testers son tanto entusiastas que quieren ver lo que se avecina, como empresas que quieren evaluar nuestro software antes de decidir si implantarlo o no

¿Recibís ayuda “anónima”?

Todos los Beta testers tienen un ID. Claro que pueden usar otro nombre, pero es importante hacer seguimiento de quien ha introducido los bugs por si hay que reproducirlo y nos faltan detalles. Introducir bugs en la base de datos, no es cosa trivial. Para que podamos reproducir los errores que se reportan externamente a veces nos hace falta conocer el entorno en el que se ha producido el bug. Si al bug reportado le falta información, va bien poder contactar con quien que lo ha reportado por intentar seguir los mismos pasos y llegar así a identificar el bug.

Varias veces me han llegado comentarios tipo “tengo un amigo que probó tal cosa y no funcionaba…” o “…he oído que tal feature no funciona…”. Cuando pasa esto, miramos de encontrar el bug internamente con las pistas que hemos oído y si tenemos suerte de reproducirlo, lo introducimos nosotros mismos en la base de datos para no perderlo. Mirándolo así, sí que hay ayuda anónima.

¿Se comprueban todas las versiones que va sacando el equipo de desarrollo o hay algunas más importantes que otras dentro del ciclo de desarrollo?

Se comprueban todas las builds pero hay algunas mucho más importantes que otras. A las builds se les asigna una calidad. Cuando salen nuevas builds, son calidad “test”. Si resulta que la build es suficientemente estable se la promueve a calidad “IDW” (Internal Developer Workstation).

Las mejores IDWs se convierten en Betas y son éstas las que publicamos externamente.

Los empleados de Microsoft que no son testesrs y quieren probar el producto, miran de instalarse builds que sean IDWs

Los Project Managers definen al principio del proyecto los diferentes Milestones (etapas). Se define cuando ha de salir una IDW y cuando ha de salir una Beta externa. Y como en cualquier proyecto, también define que ha cubrir cada Beta.

Las Betas que se publican externamente en Internet para todos los públicos, son los Milestones mas importantes por que son las compilaciones a las que tiene acceso todo el mundo.

¿Se comprueba que un bug arreglado en una versión anterior no vuelva a ser introducido?

Si. Cuando encontramos bugs, antes de introducirlos en la base de datos, hacemos una búsqueda no vaya a ser que alguien ya lo haya reportado. En Product Studio (la base de datos que usamos para introducir los bugs) se pueden hacer búsquedas bastante flexibles (por Título, descripción, archivo, palabras sueltas….) Vamos…, que es fácil buscar. Si después de buscar y no encontrar, abrimos un bug y resulta que ya estaba introducido y no lo vimos, el ingeniero lo resuelve como “duplicado” y lo enlaza al bug primario. El tester solo tendrá que verificar que su bug se ha arreglado cuando se arregla el primario.

Todos los bugs arreglados se repasan en builds posteriores. Esto se hace por si al arreglar algún bug, accidentalmente se re-activa otro que ya estaba solucionado (un mismo fix, puede afectar a varios archivos y al mirar de arreglar un problema se puede romper otro). Antes de hacer la build final se repasan todos los bugs por asegurarse que esto no ocurre. A esto le llamamos hacer “regresión”.

¿Tendréis que repetir pruebas para el SP1 de Vista? ¿Tenéis algo de información ya de este Service Pack?

En SP1 se prueban los componentes que se actualizan. Se hacen test cases para abordar todos los archivos que han sido modificados

¿Cuál es la versión de un Beta Tester y que obtiene en compensación por estar “jodiendo” el software de la compañía?

Los Beta Testers tienen acceso a muchísimas builds. Las builds que son declaradas “Beta” se publican en internet y son de acceso libre a través de la site de Microsoft (www.microsoft.com). Pero los Beta testers tiene acceso a las sites beta (http://connect.microsoft.com/ ) de donde se pueden descargar nuevas builds casi semanalmente.
En el mismo http://connect.microsoft.com/ pueden reportar bugs y encontrar documentación sobre cada proyecto.

En Windows Vista, a los beta testers se les agradeció su feedback con una licencia de Windows Vista Ultimate

¿Y ahora con Longhorn, otra vez desde cero?

En Longhorn, al igual que en SP1, se testea todo lo nuevo y todos aquellos compontes que dependen de las partes que trae Server. Las partes “cliente” de Longhorn que no tienen dependencias no se re-testean tan exhaustivamente como en Windows Vista. Se hace un “sanitiy pass”.

Longhorn incluirá los bug fixes de SP1. O sea que los bugs que no se pudieron arreglar durante Windows Vista y se han arreglado en SP1, se verificarán en Longhorn, claro.

Microsoft ya ha empezado a pedir feedback para Viena, durante el proceso de testing encontraréis características “incomodas” que no pueden ser cambiadas debido a la arquitectura del diseño. ¿Habéis pasado algún feedback para Viena que se pueda contar?

No ;)

¿Alguna curiosidad de vuestro trabajo?

Durante los ciclos de testeo, el tiempo es realmente valioso. Todo lo que se puede automatizar se hace. Cuando acaba nuestra jornada laboral dejamos los PCs de prueba encendidos y ejecutando “Stress”. Esta es una herramienta que auto-estresa el sistema en busca de errores identificables automáticamente.

Otro automatismo que tenemos es para descargar e instalar las builds.
Las builds se hacen en Redmond {horario del Pacifico (GMT – 8)}. Usamos herramientas que leen los servidores de las builds en Redmond y empiezan a descargarlas a nuestros servidores locales tan pronto están listas. La misma herramienta hace una instalación automática en PCs asignados la noche anterior. De modo que cuando llegamos a la oficina por la mañana, ya están listas para probar.

Los equipos de testing son multiculturales y están ubicados en muchas partes del mundo. Para asegurarnos que estamos todos alineados mantenemos comunicación regular con estos equipos. Una de las cosas que más me gusta de este trabajo es poder estar en contacto estos compañeros de otras culturas.

A los betas testers les ocurre un poco lo mismo. A través de los newsgroups están en contacto con otras personas que también están probando el producto. Da igual en que parte del mundo estén, todos tienen algo en común, la pasión por la tecnología

¿Alguna anecdota?

Como te he contado antes, los testers abren bugs en la base de datos y se lo asignan a la persona que debe arreglarlo. Recuerdo hace un tiempo ver un bug que alguien había abierto y asignado a una persona. El título de bug era algo así como: “Will you marry me?”

Obviamente el que reportaba el bug y el que lo tenía que arreglar eran pareja. Ahora son familia ;). Es la manera mas original que he visto de pedir matrimonio!

Celia Pipó