Te comparto acá un post escrito por Sara Martínez, de Abstracta, con quien asistimos al curso de Rapid Software Testing de Michael Bolton, el cual fue impartido en la misma semana que estuvo en Uruguay para el TestingUY 2017. Entonces, aquí sus apuntes del curso de Rapid Software Testing y de la experiencia de tener a Bolton entre nosotros por una semana.
En esta oportunidad voy a contarles un poquito sobre la experiencia de conocer a un groso en testing como Michael Bolton, centrándome en los principales aspectos de su famoso curso Rapid Software Testing.
Desde que Bolton llegó a Uruguay, nos sorprendió con su personalidad abierta y sencilla. Siempre con un sí cuando alguien le pedía sacarse una foto, que aunque no lo crean fueron muchos. Estuvo abierto a las opciones que le planteamos, y hasta se desplazaba solo caminando, para conocer un poco más de Montevideo. Él también se llevó sorpresas con nuestra capital, se sentía muy seguro cuando estaba en la calle, y un día hasta viajó en el asiento trasero del auto de Vera teniendo de un lado la sillita de su bebé y a mí del otro, un genio.
Aspectos generales del curso
Ahora sí, vamos a enfocarnos y a conocer un poco más sobre el curso Rapid Software Testing (RST), el cual fue creado en conjunto por James Bach y Michael Bolton. Es apto tanto para novatos como expertos, y se trata de un enfoque que viene de la escuela del “context driven”, (basados en el contexto), adaptable a cualquier realidad. Se pretende enseñar a los testers, o personas relacionadas de alguna manera con el testing, a ver esta tarea como un proceso que implica un continuo aprendizaje del producto, obteniendo así excelentes resultados, más rápido y con menor costo.
Antes de adentrarnos en aspectos puntuales del curso, si me preguntan cuál fue la idea que me quedó más marcada, sería el poder de preguntar y no asumir. Siempre preguntar haciendo uso del pensamiento crítico y el famoso “think outside the box”, de esta manera haremos pruebas más provechosas que no están condicionadas por suposiciones.
La dinámica del curso y la forma en la que Bolton lo fue planteando, fue otra cosa que me sorprendió gratamente. No se trató del típico curso en el que el profesor dicta el temario, realiza ejercicios y contesta preguntas. Generalmente antes de adentrarse en un nuevo tópico realizaba un ejercicio con determinada consigna. Éramos un grupo testers muy variado, algunos con más de 10 años de experiencia, y otros con menos de 1, pero todos teníamos algo en común: la necesidad de comenzar a testear. Enseguida de planteado el ejercicio y pese a que él consultaba si teníamos alguna pregunta, todos nos concentramos en intentar resolverlo, muchas veces encasillados en suposiciones y sin tener del todo clara la consigna. Luego de un rato y de presentar los resultados de los diferentes equipos de trabajo, Bolton nos mostraba cómo el proceso que llevábamos a cabo no era del todo claro y que muchas veces se utilizaban recursos por no realizar preguntas a tiempo. Al cabo del segundo día ya todos habíamos entendido y logramos cambiar nuestra forma de encarar los ejercicios, realizando preguntas que nos permitieran optimizar el tiempo y obtener resultados de calidad.
Una de las cosas que aclaró desde el principio fue que el testing no es lo mismo que el checking. Hacemos testing cuando realizamos un cuestionamiento del producto, utilizando habilidades, sentidos, emociones e inteligencia; lo cual no es posible automatizar ya que de antemano no sabemos qué va a suceder. En cambio cuando estamos haciendo “checking” lo que hacemos es recopilar información en base a una secuencia algorítmica de acciones y validaciones, actividad que puede realizar una máquina. El testing tiene elementos repetitivos, pero no es repetitivo en sí, de hecho el que exista variedad es crítico para el proyecto. En la mayoría de los casos sólo podemos automatizar una porción de las actividades de testing, para el resto precisamos de las personas.
Testear es un proceso estructurado donde se evalúa el producto, aprendiendo de él a través de la exploración y la experimentación, y cuando lo hacemos buscamos que exista cierta cobertura. Para ésto se necesita modelar el producto, hablar de cobertura es hablar de modelos.
Durante este proceso debemos usar todas las herramientas que tengamos a nuestro alcance para aprender más sobre el producto a testear y su funcionamiento. Si no tengo información disponible del lado del cliente, la solicito, si no existe lo investigo, o busco productos similares por ejemplo.
El poder de las preguntas
Como remarcaba anteriormente, el uso de las preguntas es fundamental a la hora de desarrollar un testing exitoso. Éstas nos ayudan a entender su funcionamiento, el relacionamiento con otros productos, las necesidades de nuestro cliente y de quienes lo utilizarán, entre otras cosas. Por este motivo debemos realizar preguntas que abarquen diferentes aspectos relacionados con el producto: Misión, Información, Desarrollo, Equipo de testing, Herramientas, Cronograma, Producto a testear, Entregables, Restricciones, Sentimientos, Problemas.
Premisas del RST
A continuación te dejo un extracto del material del curso que contiene las 8 premisas del RST, las cuales me parece que complementan la idea del punto anterior y ayudan a marcar el camino por el cual debemos avanzar para lograr aplicar y entender este enfoque (esto es simplemente mi traducción de un fragmento obtenido del material del curso de Bolton). Las premisas sobre las que se basa el curso y la metodología RST son:
- Los proyectos y productos de software, son relaciones entre personas las cuales son racionales y emocionales.
- Cada proyecto se realiza bajo condiciones de incertidumbre y presión de tiempo.
- A pesar de nuestras mejores esperanzas e intenciones, un cierto grado de inexperiencia, descuido e incompetencia es normal.
- Una prueba es una actividad, no un artefacto. Hasta que un tester no se relaciona con el producto, lo observa, e interpreta esas observaciones, no se ha realizado ninguna prueba.
- El propósito del testing es descubrir el estado del producto y cualquier amenaza a su valor, para que nuestros clientes puedan tomar decisiones informadas al respecto.
- Nos comprometemos a realizar pruebas creíbles y rentables, e informaremos a nuestros clientes de cualquier cosa que amenace ese compromiso.
- No vamos a engañar a sabiendas o negligentemente a nuestros clientes y colegas.
- Los testers aceptan la responsabilidad por la calidad de su trabajo, aunque no pueden controlar la calidad del producto.
Tips para mejorar las pruebas
Se plantearon algunas modificaciones a la forma en la que nos plantamos frente a diferentes situaciones, las cuales buscan mejorar tanto el proceso de testing como los resultados obtenidos:
- En lugar de “Verificar que…”, optar por intentar “Desafiar la creencia de que…”.
- Elegir “Investigar” por sobre “Validar”.
- “Confirmar que…” lo reemplazamos por: “Encontrar problemas con…”.
- No busquemos si el resultado “Pasa o Falla”, mejor cuestionemos si “Existe un problema?”.
- No comparar el “Resultado esperado con el resultado actual”, optar por comparar “Resultado actual con el oráculo”.
- En caso de “no contar con buena documentación de requerimientos”, investigar qué hace el producto y documentarlo.
- Si “no tenemos suficiente tiempo para probar”, pensar cómo podemos agregar “testability” al producto.
Los sentimientos y el testing
Un punto en particular que se tocó durante el curso, que en lo personal me pareció muy llamativo ya que nunca me lo había cuestionado, fue el significado de diferentes sensaciones o sentimientos que experimentamos mientras testeamos.
La importancia de la interpretación de lo que sentimos al momento de trabajar con el producto, puede darnos información importante sobre éste:
| SENTIMOS | PROBLEMA DE |
| Impaciente | Performance |
| Frustración | Capacidad (capability) |
| Miedo | Seguridad |
| Sorpresa | Confiabilidad |
| Confusión | Usabilidad / Testability |
| Molestia | Carisma |
| Aburrimiento | Pruebas que no aportan |
| Ansiedad | Falta de una skill |
| Curiosidad | Punto a investigar |
| Cansancio | Hora de un descanso |
Conclusiones
El curso terminó con un ejercicio en el cual por equipos nos daban cinco dados, los tirábamos, y después decíamos un resultado y Bolton daba el suyo. La consigna era adivinar el algoritmo utilizado por Bolton para dar su respuesta en base a lo que visualizaba en cada tirada de dados. El objetivo al final el ejercicio era mostrarnos como muchas veces perdemos tiempo buscando soluciones por el camino más complicado y no probamos con la solución más simple. Es necesario realizar un modelo de la realidad, que nos simplifique las pruebas y nos permita enfocarnos donde realmente debemos hacerlo.
