Este documento discute la importancia del lenguaje preciso en el contexto de las pruebas de software. Señala que el uso impreciso del lenguaje puede conducir a una cultura de ineficacia y disfunción, y proporciona ejemplos de frases comúnmente usadas en las pruebas de software y sugerencias más precisas para expresar el mismo significado. También destaca la importancia de escuchar con cuidado y aplicar el mismo nivel de precisión al lenguaje tanto al hablar como al escuchar.

1. Loquequeríasdecir…
Inspirada en la presentación “What you meant to say”
de Michael Bolton
Lisandra Armas & Gabriela Sánchez

2. Dijiste…
“¡Acabamos de introducir Scrum!”
Quisiste decir…
“Las reuniones diarias
de puesta a punto son
más cortas.”
… significa que
Nada cambió, el negocio
sigue igual.
“¡Y no usamos
sillas!”

3. Dijiste…
“Implementemos un proceso de
desarrollo de software maduro”
Quisiste decir…
“Implementemos el
proceso de desarrollo de
otra persona en lugar de
uno propio”
… significa que
Permites que otro te diga como
hacer las cosas.
… significa que
Continuas siendo
infantil

4. Dijiste…
“Tenemos que hacer X”
Quisiste decir…
“Alguien dice que tenemos
que hacer X”
… significa que
Elegimos hacer X
… significa que
Quizás no tenemos que
hacer X
O…
“Solo sabemos hacer X”
O…
“Estamos dispuestos a
tolerar hacer X”

5. Dijiste…
“Este es el objetivo.”
Es probable que
signifique…
“Mis colegas y yo
estamos de acuerdo que
este es el objetivo.”
…significa que
“Si estás en desacuerdo con nuestra
valoración, o bien no eres un colega
nuestro o no estás siendo objetivo.”
…significa que
“Esto es subjetivo.”

6. Dijiste…
“Prueba (Test)”
Quisiste decir…
Ejemplos:
“Este producto es una porquería! Se deberían haber hecho más
arreglos.”
“Tenemos que empezar a arreglar más temprano en el proyecto!”
“¿Cuánto tiempo se necesita para arreglar el producto?”
“Arreglo (Fix)”
“No tengo idea ¿No podemos simplemente automatizar los arreglos?”

7. Dijiste…
“Probando (Testing)”
Quisiste decir…
¡Inténtalo y mira lo que sucede!:
“¿Por qué está tomando tanto tiempo todo el desarrollo?”
“Todo el desarrollo”
“¿Por qué es tan caro todo el desarrollo?”
“Para evitar que los errores lleguen a los clientes, hay que trabajar
en la mejora de todo el desarrollo.”
“No podemos simplemente automatizar todo el desarrollo.”

9. ¿Por qué las personas no dicen lo que
quieren decir?
“Periódicamente, las personas
se equivocan para hacer valer
la hegemonía sobre la
dialéctica referente a la
ontología. ”

10. Quise decir...
“A veces, las personas usan
palabras que son confusas y
extrañas para tomar el control
de las conversaciones sobre la
forma en que miramos el
mundo. ”

11. Dijiste…
“Ustedes son tan exigentes
con las palabras.”
…significa que
“Estoy hablando muy bien y
rechazo la idea de que mis
palabras no están funcionando.”
Quisiste decir…
“Sabes a lo que me refiero; usted es el que está eligiendo crear
un problema para mí.”
“Estoy bien con el riesgo de ser mal interpretado.”

12. Dijiste…
“Oh, eso es sólo
semántica.”
…significa que
“Oh, eso es sólo ser específico
acerca de lo que estamos
hablando.”
Quisiste decir…
“No estoy al tanto del riesgo de confusión en este punto.”
“No me importa el riesgo de confusión en este punto.”
“Quiero reducir el concepto de 'semántica' a 'pequeñeces'.”
Así que, ¿cuál es el problema?

13. ¿Por qué creemos que esto es importante?
● La gente usa el lenguaje como un andamiaje para su
razonamiento y sus ontologías.
● El mal uso del lenguaje fomenta una cultura de la
ineficacia y disfunción:
● descuido en el trabajo de pruebas.
● sin poder, descalificados, los probadores marginados.

14. ● Mal uso del lenguaje fomenta cultura de la
ineficacia y disfunción:
● la interferencia de personas que piensan que
entienden el Testing.
● centrarse en los adornos, los artefactos y
herramientas en vez de habilidades, la
exploración, la experimentación y el
aprendizaje.
¿Por qué creemos que esto es importante?

15. Más aún...
Un montón de errores son el resultado de:
- malas interpretaciones de los requisitos,
especificaciones, modelos, ...
Un montón de problemas en el proceso son el resultado de:
- las definiciones excesivamente estrechas de "prueba",
"calidad", "errores", ...
- una imprecisa referencia a "requisitos", "planes",
"estrategias", ...

16. Dijiste…
“Automatizar todas las
pruebas!”
…significa que
Automatizar la totalidad de la evaluación
y el aprendizaje
y la exploración
y la experimentación
y modelar
y el estudio de las especificaciones
y la observación del producto
y evaluación de riesgos
y el establecimiento de prioridades
y análisis de la cobertura
y reconocimiento de patrones
y toma de decisiones
y el diseño del laboratorio de pruebas
y preparación del laboratorio de pruebas
y el desarrollo de código de prueba
y la selección de herramientas
y el reclutamiento de ayudantes
y tomar notas de las pruebas
Quisiste decir…
“Automatizar todo el
Checking!”

17. LLamar a esto “Checking” no Prueba
operar un producto para
chequear hechos específicos
(en su mayoría salidas) ...
Observar
Significa
Evaluar Reportar
Interactuar con el producto
de una manera específica
para recopilar
observaciones específicas.
Aplicar algoritmos y reglas
de decisión para esas
observaciones.
Reportar cualquier
prueba fallido.

18. Un chequeo tiene 3 elementos
1. Una observación vinculada a…
2. Una regla de decisión tal que...
3. ambas observación y regla de decisión pueden ser aplicadas de
forma algorítmica.
Se puede realizar un chequeo
por una persona que ha sido instruido
para no pensar
(lento y variable)
por una máquina que no puede pensar
(de manera rápida y precisa)

19. Adquirir la competencia, motivación y credibilidad para…
Testing es…
crear las condiciones necesarias para
… de manera de ayudar a tus clientes a tomar decisiones
informadas sobre los riesgos.
evaluar el producto mediante el aprendizaje de él
a através de la exploración y experimentación,
lo que incluye cierto grado de: cuestionamiento, estudio, modelado,
observación e inferencia, lo que incluye...
operar el producto para
chequear hechos específicos
sobre él...

20. ¿Por qué hacer esta distinción?
• Eficiencia y efectividad son muy diferentes para habilidades empíricas
y explícitas.
• Checking sea excelente -> embebida en un excelente testing
• Porque chequear es mecánico. Se
puede hacer completamente explícito y
automático.
• Porque testing involucra habilidades
empíricas que son desarrolladas a
través de la socialización, no a través de
procedimientos.

21. Dijiste…
“testing manual”
Quisiste decir…
• interactuando directamente con el producto, como lo haría un
usuario.
• verificación realizada por una persona.
• testing que no implique la necesidad de escribir código.
• testing sin necesidad de herramientas (pero eso no sucederá).
No decimos “gerenciamiento manual” o “ciencia manual”,
porque no esperamos que las herramientas puedan hacer esas cosas.

22. Hablemos sobre Lenguaje Seguro
• “Lenguaje seguro” en las pruebas
de software, significa calificar o de
otro modo limitarse a los hechos de
forma de evitar una falsa confianza
o engaño accidental.

23. • Ejemplos:
Hasta ahora…
La funcionalidad
anda..
Parece…
Pienso… Aparece…
aparentemente… Deduzco…
Supuse…
Todavía no he visto ningún
fallo en la funcionalidad...
Observé…

24. El lenguaje seguro
también aplica al escuchar
• Intenta aplicar el lenguaje seguro tanto para lo que escuchas como
para lo que dices.
• Las personas son frecuentemente ingenuas, descuidadas, o
incompetentes para expresarse, a veces también manipuladoras.
• Hablar claro es difícil, escuchar e interpretar también lo es.
Reparamos en lo que oímos, pero no siempre muy bien.
Hablar y escuchar cuidadosamente requiere
mayor esfuerzo, puede volverse más sencillo
con práctica y algunas heurísticas útiles.

25. Vocabulario del Lenguaje Seguro
Un vs. El
Ejemplo: "Un problema ..." en lugar de "el problema ..."
• El uso de "Un" en lugar de "El" nos ayuda a evitar varios
tipos de errores de pensamiento crítico.
– una sola causa
– correlación y causas confusas
– un solo nivel de explicación
Al tratar de explicar algo, prefiero "un" a "el".

26. Vocabulario del Lenguaje Seguro
A menos que...
• Cuando alguien hace una pregunta basada en una
premisa falsa o incompleta, trate de añadir "a menos
que ..." a la premisa.
• Cuando alguien le ofrece una gran verdad acerca de
las pruebas, añadir "a menos que ..." o "excepto en el
caso de ..."
Al final de un comunicado, trate de añadir
"a menos que ..."

27. Todo lo que es cierto ahora,
no puede ser cierto por mucho tiempo.
Vocabulario del Lenguaje Seguro
“Hasta el momento” y “aún”
•El producto funciona ... hasta el momento.
•No hemos visto fallar la aplicación... aún.
•Ningún cliente se ha quejado ... aún.
•Cuidado con los “siempre” y “nunca”
– Nunca puede haber una prueba válida para “siempre”. O
“nunca”.

28. Vocabulario del Lenguaje Seguro
También…
• ¡El producto da el resultado correcto! ¡Hurra!
• …También puede estar silenciosamente borrando
archivos del sistema.
• Es posible que haya más de donde vino eso.
Sea lo que sea que está sucediendo alguna otra
cosa podría también estar sucediendo.

29. Dijiste…
“Funciona!”
Sería más correcto decir…
ALGUNOS ASPECTOS de ALGUNA FEATURE
PARECEN cumplir ALGUNOS REQUERIMIENTOS hasta CIERTO PUNTO
basado en ALGUNA TEORÍA
basado en ALGUNA OBSERVACIÓN de que
ALGÚN AGENTE
bajo CIERTAS CONDICIONES
UNA o QUIZÁS MÁS VECES
en MI MÁQUINA

30. Dijiste…
“Funciona!”
Sería más correcto decir…
Puede funcionar.
Lo he visto funcionando.

31. Dijiste…
“Rompí el software.”
Quisiste decir…
"Encontré lugares donde el software está roto."
"Yo rompí las ilusiones de la gente sobre el software."
“Exploré y experimenté donde el software podría presentar
problemas que amenazan el valor para aquellas personas que
importan”
O, más simple “Yo probé el software.”
Podría ser más seguro decir…

32. Porque es importante...
• “El software estaba bien hasta que el Tester lo rompió.”
• “Podemos liberar un producto fantástico a tiempo solo si los Testers terminan de
romperlo.”
• “Los Clientes normales no tienen problemas con nuestro producto; solamente los
Testers lo rompen.”
• “No hay errores sistémicos en la gerencia o el desarrollo que hayan llevado a
problemas en el producto. De ningún modo. Los Testers lo rompen.”
“Pruebo el software”
Puede ser más seguro decir…
Cuándo dices “Yo rompo el software” te provocas a ti mismo un
potencial problema de relacionamiento.
Otros pueden “reparar” “Yo rompo el software”

33. Tú dices…
“No puedo reproducirlo.”
Probablemente quieres decir…
Aún no se como reproducirlo.
Aún no he podido reproducirlo.
¿Por qué importa?
Algunos podrían interpretar “no puedo reproducirlo” como
“en realidad nunca ocurrió”
Y es retenido como “esto nunca volverá a ocurrir”

34. “Pruebas de aceptación”
Checking, no pruebas.
Rechazo, no aceptación.
Rechazo de checking, no de pruebas de aceptación.
No queremos ser engañados y creer que algo que "pasa" las
pruebas de aceptación es aceptable.
Tu dices…
Probablemente quieres decir…
¿Por qué importa?

35. “Definition of done” (“Definición de completo”)
“Definición de no completo aún”
Podemos prever de antemano algunas cosas que nos harían decir "¡no podemos
liberar aún!”
No podemos anticipar todas ellas al inicio del proyecto (sprint, ciclo, o cómo se
llame).
PERO podemos estar de acuerdo en ser humildes y reconocer que
aprenderemos cosas en el camino, algunas de las cuales nos podrían hacer
concluir que no hemos terminado aún.
Tu dices…
Probablemente quieres decir…
¿Por qué importa?

36. Y finalmente…
• No olvides decir ¡Gracias!