Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)

Cuenta James Whittaker, el que fuera responsable de testing en Google, y en un gran artículo en IEEE software, que pidió a su equipo un plan de pruebas para Google App Engine… en menos 10 minutos«.
– Todo ellos sabían – comenta Whittaker- lo que es un plan de pruebas. Y todos ellos conocían bien el Google App Engine. La primera vez nadie pregunto nada.
Cuando 10 minutos después Whittaker fue a ver al equipo, las respuestas fueron: «No es tiempo suficiente para documentar»- «Tío, ¿iba en serio?»-
– Puse de nuevo a cero el cronometro, y cambié de aplicación: «10 minutos para Chrome Web Store”.
– Cada 10 minutos cambiaba de aplicación. Y a medida que los minutos pasaban mi equipo iba entendiendo el mensaje: descartaron la idea de describir el problema, la aplicación o cualquier cosa innecesaria. Cambiaron prosa por listas de viñetas. Caso omiso a cualquier información no relevante para el testing. Si no era importante, lo ignoraban. No había tiempo.
Al quinto intento, ya eran capaces de obtener el 80% del plan en 30 minutos o menos. Hasta que lo lograron. Y así creamos el método ACC (atributos, componentes y capacidades), para completar un plan de pruebas en 10 minutos, o menos.

ACC tiene siete principios

  1. Evita la prosa, utiliza viñetas (bullets).
  2. Un plan de pruebas no es un documento de marketing o ventas, es para ingenieros.
  3. Cortos. No a más texto mejor plan. El tamaño del plan es relativo al sistema a probar, no a la propensión del autor por escribir.
  4. Si no es importante o no se puede hacer, no lo pongas en el plan.
  5. Asegúrese de que el plan sea fluido. Que deje una idea clara de la funcionalidad del producto.
  6. Es una guía para ayudar a pensar al tester.
  7. El resultado de aplicar el plan deben ser casos de prueba. Un plan que no conduce directamente a hacer pruebas es una pérdida de tiempo. Si el plan de pruebas no dice qué casos de prueba que necesitamos escribir, no ha cumplido con su objetivo.

A (atributos)

Los atributos describen por qué el producto es importante para los usuarios y para la empresa. ¿Por qué estamos construyendo esta cosa? ¿Qué valor aporta? No juzgamos porque están ahí, no es asunto nuestro, negocio ya hizo su trabajo.
Los atributos son las cualidades y características que diferencian al producto de la competencia. Explican por qué la gente se decide usar tu producto sobre el de la competencia. Por ejemplo, Chrome está diseñado para ser rápido, seguro, estable y elegante, por lo que estos son los atributos a documentar. Google Sites, es una aplicación libre, para la construcción de una comunidad web.

C (componentes)

Los componentes son el carrito de la compra y el “checkout” de una tienda online. Son las características de formateo e impresión de un procesador de textos. Código que hace al software ser lo que es. Son los módulos de la arquitectura. Son clases.
Deberías ser capaz de enumerarlos en cuestión de minutos. Si te cuesta llegar a los componentes, entonces no estás lo suficientemente familiarizado con el producto y quizás tengas que pasar algún tiempo con él para llegar rápidamente a un nivel de usuario avanzado.

C (capacidades)

Las capacidades son verbos del sistema. Representan acciones que el sistema lleva a cabo en respuesta a entradas del usuario. Ejemplos: Añadir al carrito de la compra, procesar transacciones monetarias con HTTPS, etc. En Chrome, por ejemplo, son la capacidad de mostrar una página web, reproducir un archivo flash, o descargar un documento.
Las capacidades son la intersección de los atributos y los componentes. Los componentes realizan alguna función para satisfacer un atributo de producto y el resultado es una capacidad. Chrome muestra páginas web y reproduce Flash con seguridad. Aplicaciones pequeñas tiene docenas de funciones, sistemas complejos cientos (Chrome OS tiene más de 300, por ejemplo).
Si tu producto hace algo no cubierto por una intersección atributo-componente, no sé por qué está en el producto. Una capacidad que no sirve es “grasa”, se puede eliminar, o si no sabes porque está entonces es que no conoces tu producto (cosa inaceptable).

Terminando…

Como habéis podido ver es, además de gran caso práctico, un gran ejemplo de aplicación de Lean: elimina desperdicio y todo aquello que no aporta valor.
Como siempre, ayúdame a difundir el conocimiento, tuiteando, etc.

Javier Garzás

6 comentarios en “Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)”

  1. Pingback: Bitacoras.com

  2. Hola, me parece muy interesante el articulo, pero la descripcion de C (componentes) no me es clara del todo. ¿Se refiere a los datos válidos para que el sistema funcione? Muchas gracias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba