Como todo en esta vida, y el software no iba a ser diferente, y hasta diría que especialmente ocurre en este nuestro campo… hay y visiones diferentes de las cosas. Eso, yo pienso que es bueno y enriquecedor, salvo cuando alguno se lo toma de mala manera.
El área del Testing es una más, grupos que ven las cosas de una manera, grupos que la ven de otra. Como te contaba en aquel post de Entendiendo las diferentes escuelas de Testing, imprescindible para entender las diferentes (a veces enfrentadas) visiones del Testing hoy.
Según las escuelas que te contaba en el anterior post, desde luego que hay poco “sitio” de encuentro entre los que entienden el Testing Ágil o Context-Driven y las escuelas de Fábrica, Estándares o Formal. Pero tampoco es que haya total coincidencia entre los que propugnan el Testing Ágil y el Context-Driven.
Realmente, hay más diferencias desde el Context-Driven hacia el Ágil que al revés. Esto ha provocado grandes e interesantes debates, que a mí, personalmente, después de echar literalmente horas leyendo las opiniones de unos y otros me ayudó mucho, pero mucho, a entender las diferentes maneras de ver las cosas en el mundo del Testing. El debate, educado, es útil.
Unos de los propulsores, defensores y padre de la escuela Context-Driven es James Batch, del que, si estáis metidos en le tema (y si no te animo a ello), muchos habréis leído extensos debates exponiendo las diferencias entre su idea de ver el Testing y las otras ideas, diferencias claras con Fábrica, Estándares o Formal, pero también marcando diferencias con el Testing Ágil y dejando claras sus diferencias con los(las) propulsores del mismo.
Pero de James Batch puedes recordar dichos debates, pero no hay que obviar, estés de acuerdo con él o no, la profundidad de sus reflexiones. Debates y reflexiones profundas, no sólo sobre escuelas de Testing sino de muchos otros, destaco especialmente aquí las relacionadas con la automatización de las pruebas y la visión del Tester-Programador.
Para exponer dichas ideas, en su día, y habiéndolo refinado varias veces, James Bach, junto con Michel Bolton, escribieron varios post sobre las diferencias entre Testing y Checking (especialmente interesante este post).
No te voy a contar todo lo que ya cuenta este post, para eso está ya escrito, y yo no lo voy a hacer mejor, pero si que quería dejar algo por escrito para concienciar del tema a la comunidad que frecuenta estas “páginas”. Y crearte con ello en interés en profundizar en el tema.
Del anterior post te he súper resumido 6 ideas que son las que a mí me parecen esenciales del Testing vs Checking, puede que para ti debieran ser otras, por ello te recomendó profundizar en el tema, ahí voy:
- El Testing abarca al Checking, mientras que el Checking no puede abarcar al Testing.
- El Checking es un proceso que puede, en principio, ser realizado por una herramienta en lugar de por un ser humano, mientras que el Testing sólo puede ser apoyado por herramientas.
- La característica definitoria del Checking es que puede ser completamente automatizado, mientras que el Testing es intrínsecamente una actividad humana.
- El Testing es una investigación, a lo «Sherlock Holmes», mientras que el Checking es comprobar hechos.
- El Testing se confunde con el Checking.
- El cheking es una táctica de Testing.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Que bueno que se trate de difundir las ideas de James Bach, que me parece una luminaria respetable en el mundo de las Pruebas de Software y cuya opinión siempre cuenta. Yo estoy de acuerdo que no es lo mismo Checking que Testing. Si el testing es «automatizable», entonces porque no lo es la programacion o la gestion de proyectos?