Google y el testing

Por referencia de un compañero de trabajo tomé contacto con una serie de posts que James Whittaker publicó en Google Testing Blog. La serie se titula How Google Tests Software y cuenta varios aspectos relacionados con la forma en que se organizan, los roles que ocupan y la filosofía/estrategia de pruebas que manejan.

A todos aquellos interesados en los temas de testing de software les recomiendo leer la serie y ver algunas de las charlas que el autor ha dado para GTac.

Resalto en este post dos ideas que a mi criterio son interesantes y con las que concuerdo.

La primera tiene que ver con la relación entre desarrollo y testing:

At Google, quality is not equal to test. Yes I am sure that is true elsewhere too. “Quality cannot be tested in” is so cliché it has to be true. From automobiles to software if it isn’t built right in the first place then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-the-fact.

However, this is neither as simple nor as accurate as it sounds. While it is true that quality cannot be tested in, it is equally evident that without testing it is impossible to develop anything of quality. How does one decide if what you built is high quality without testing it?

The simple solution to this conundrum is to stop treating development and test as separate disciplines. Testing and development go hand in hand.

[...]

At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other.

Me parece interesante porque coincide con algo que yo opino desde hace tiempo: Los testers no están para “controlar” a los desarrolladores. Si instauramos un área o un grupo de testing bajando esta línea a los miembros de ambos grupos (testers y desarrolladores) estamos bajando drásticamente la probabilidad de éxito de la iniciativa. Por si hiciera falta aclararlo, el grupo de testing está para ayudar a entregar productos de calidad en tiempo y forma.

La segunda idea interesante es la de que el testing automático no reemplaza al testing manual. Ambos son útiles y ambos son necesarios pero no intercambiables. Lo que sí hace el testing automático es liberar tiempo del equipo de testing para dedicarse a probar aquellas cosas que no pueden automatizarse a un costo razonable.

Having said that, it is important to note that Google performs a great deal of manual testing, both scripted and exploratory, but even this testing is done under the watchful eye of automation. Industry leading recording technology converts manual tests to automated tests to be re-executed build after build to ensure minimal regressions and to keep manual testers always focusing on new issues. We also automate the submission of bug reports and the routing of manual testing tasks. For example, if an automated test breaks, the system determines the last code change that is the most likely culprit, sends email to its authors and files a bug. 

Dicho esto también creo que el contexto de Google no es del todo extrapolable a cualquier otro lugar donde se desarrolla software. El software de Google tiene una masividad tal que un error podría producirse millones de veces en simultáneo multiplicando el costo de corrección en forma exponencial. En entornos más acotados esto no ocurre y la necesidad de “automatizar todo lo automatizable” no es tan fuerte.

Seguimos pensando..