Testing en Spectra (Parte I de II)

Celia Pipó es miembro del equipo de Windows Internacional, es una trotamundos. Salio de su casa con una mochila en la espalda a buscarse la vida a los USA, después recayó en Irlanda donde entró a trabajar en Microsoft y desde entonces trabaja para “Spectra”, ahora destinada en Barcelona ¿Por cuánto tiempo? [celiap – no se. lo del tiempo va en función de necesidades y proyectos de la compañía, como todo. Hoy estoy aquí… mañana quien sabe…] en el equipo de testing. A parte es de lo más simpático que te puedes encontrar, así que, como se presta, la he hecho una serie de preguntas sobre que es lo que se cuece internamente por dentro de Windows.

¿Qué comprobaciones son las que realiza el equipo de Testing, vamos, por qué os pagan?

Hola Chema, el equipo de Testing es el responsable de asegurarse que todo funciona como debe. En pocas palabras, responsable de probar, estresar el sistema, encontrar fallos, reportarlos y continuar probando para asegurarse que los fallos reportados son arreglados.

Hay varios equipos que colaboran con el equipo de Testing y que son muy importantes durante todo el desarrollo del producto. Estos otros equipos son vitales para que los Testers puedan hacer su trabajo.

A grandes rasgos están, los PMs (los que diseñan los features y componentes y coordinan), los developers (los que pican código; hacen que cada archivo haga lo que está diseñado para que haga), los Build engineers (los que “montan” los componentes para formar el sistema operativo), los Testers (los que prueban la compilación que han hecho los Build engineers) y los localizadores que son los que escriben la parte que los usuarios vemos. (En compilaciones no-inglesas, éstos son traductores)

Todos estos equipos son dependientes uno del otro.

Para asegurarse que cada una de las partes del producto hace lo que debe, el tester crea una serie de “test cases” para ir repasando esas features que ha diseñado el PM en cada una de las compilaciones de prueba.

Un “Test Case” viene a ser como un guion con instrucciones paso a paso de cómo ejecutar cierta aplicación. Por poner un ejemplo sencillo… si tienes que testear que la impresora imprime, el test case sería algo así como:

Click on Start, Go to Control Panel  Printers  right click on printer  choose properties  click on “print test page”  ensure page is sent to printer

Como el testeo puede durar meses, el test case ayuda a asegurarse que no te olvidas de repasar nada. Una colección de Test Cases forman un “test pass”.

Un ejemplo de un test case real:

Title: EPG; Verify the Edit Channels page is working (block, unblock, remap)
:: Requirements ::
~ Standard MC configured and with working guide

:: Instructions ::
1.) Start MC
2.) Goto Settings -> TV -> Guide -> Edit Channels
3.) Uncheck a channel (e.g., channel 4) and select 'Save'
4.) Go back to Edit Channels and verify that the check box next to the channel is now unchecked
5.) Navigate to the Guide and verify that the channel no longer appears in the EPG
6.) Goto My TV -> Search -> Title and enter the name of a program that normally airs in the channel you just blocked (e.g., Wheel of Fortune). Verify that the blocked channel does not appear in the results list
7.) Goto Settings -> TV -> Guide -> Edit Channels
8.) Check the channel you unchecked in Step 3 and select 'Save'
9.) Go back to Edit Channels and verify that the check box next to the channel is now checked
10.) Navigate to the Guide and verify that the channel does appear in the EPG
11.) Goto My TV -> Search -> Title and enter the name of a program that normally airs in the channel you just unblocked (e.g., Wheel of Fortune). Verify that the unblocked channel does appear in the results list
:: Expected ::
When a channel is removed it should not appear in the Guide Grid nor in any searches done
Navigating through the EPG shouldn't be affected by remapping channels

El testeo solo entra en acción cuando los build engineers han conseguido montar un compilación que es lo suficientemente estable como para empezar a testearla. A partir de entonces se crean los ciclos de testing.

El flujo de trabajo sería:

Build engineers hacen build.
Si la build no pasa el BVT (Build Verification Test).
->Buscan los fallos, los arreglan y vuelven a hacer compilaciones hasta que pase BVT.
Una vez pasa BVT, la envían al equipo de test.
El equipo de test hace todo el test pass.
Introducen los bugs encontrados en la base de datos.
Dependiendo de qué sea el bug, será un ingeniero o un developer o un localizador el que lo arregle.
Se genera nueva build con los fixes.
Se hace BVT.
Se envía a Test.

Y así sucesivamente hasta llegar a ZBB (Zero Bug Build).

Un test pass completo puede ser enorme. Dependiendo del test pass, todo un equipo de testing puede tardar una semana entera en completarlo. Pero si los build engineers hacen builds cada día, no hay tiempo de hacer el test pass. Lo que se hace pues, es dedicar ciertas semanas a test passes completos y otras semanas a testear ciertas partes del producto. Se hace así también porque no todos los componentes se desarrollan a la misma velocidad, por lo que si una semana no ha habido cambio sustancial en cierto componente, no se testea y se centra el esfuerzo de testeo en los componentes que sí han tenido cambio.

También hay semanas que se dedican a hacer “regresión”. Esto es repasar cada uno de los bugs que ya se arreglaron en builds anteriores y asegurarse que no se han “roto” de nuevo en builds recientes. A base de coordinar semanas de “regresión” y semanas de “test pass”, el producto queda testeado exhaustivamente.

Todos los test cases están introducidos en una base de datos interna. Durante cada test pass, el tester introduce el resultado del test case (PASS/FAIL/ PI -> Pass with an issue) en la base de datos y esto queda guardado. De modo que si en algún momento alguien quisiera saber cuándo cierto elemento no funcionaba, solo tiene que mirar en la base de datos.

Hay muchísimas herramientas que ayudan a encontrar fallos, pero en todo ciclo de testeo, las herramientas mas importantes son 1) la que contiene los test cases y 2) donde introducimos los bugs. En Windows estás son:

1) WTT Studio: Herramienta/base de datos que contiene todos los test cases
2) Product Studio: Herramienta/base de datos donde se introducen todos los bugs

El tester introduce los fallos (bugs) en Product Studio y lo asigna al ingeniero o al localizador o al developer, dependiendo de que sea el bug. De no estar seguro, se lo asigna al PM y éste asigna consecuentemente. Cada bug tiene una prioridad y una severidad. Los PMs son responsables de asegurarse que los bugs tienen la prioridad y severidad asignada adecuadamente y que son arreglados según estos criterios. El PM tiene más visibilidad, por lo que también puede decidir en qué fase del desarrollo puede arreglarse el bug. Obviamente los bugs funcionales tienen prioridades más altas que los bugs estéticos.

Cada tester es responsable de hacer seguimiento de sus bugs. Cuando los ingenieros resuelven el error, el tester ha de verificar el fix y cerrar el bug o re-activarlo en función de si el fix ha solucionado el problema original o no.

Finalmente, después de cubrir los diferentes ciclos y cuando se llega a ZBB (Zero Bug Build) el tester firma conforme todo funciona según lo establecido.

Parte II