TESTING y CHECKING Refinado - Traducción al Castellano

Hace un tiempo largo,realicé una traducción de un post de IlariHenrik Aegerter y ahora me he propuesto traducir otros artículos interesantes de otros autores, por que muchos no saben o no tiene tiempo de leer en inglés. No soy traductor profesional, pero trataré de hacer lo mejor posible. Lo único que no traduciré en algunos casos son las palabras Testing, Tester y Checking, para que no haya confusión.

Este articulo es de los autores James Marcus Bachy Michael Bolton, pueden ver mas post en su idioma original aquí y aquí.


Este post es co-escrito con Michael Bolton. Hemos pasado horas discutiendo sobre casi cada frase. También queremos agradecer a Iain McCowatt por su rápida revisión y comentarios.

Las pruebas y el uso de herramientas son dos cosas que han caracterizado a la humanidad desde sus inicios (No las únicas dos cosas, por supuesto, pero sin duda dos de las varias cosas que la caracterizan) Pero mientras que el testing es cerebral y en gran parte intangible, el uso de herramientas está al descubierto. Las herramientas invaden en todos los procesos que tocan y las herramientas cambian esos procesos. Por lo tanto, durante al menos un centenar o un millar de siglos, los más filosóficos entre nuestra especie se han preguntado: "¿Yo hice eso o lo hizo la herramienta? ¿Soy un guerrero o una plataforma de lanzamiento de lanzas? ¿Soy un agricultor o un empujador del arado?" Como dijo Marshall McLuhan "Damos forma a nuestras herramientas, y después de eso nuestras herramientas nos dan forma a nosotros".

Esta evolución puede ser un proceso insidioso que desafía la forma en que nos etiquetamos a nosotros mismos y las cosas que nos rodean. Podemos ser testigos de cómo la industrialización cambió ebanistas por fábricas de gabinetes, y que puede tentarnos a hablar de la evolución del papel del ebanista, pero el trabajador de la fábrica de gabinetes, ciertamente no es un ebanista mutado. Los artesanos del gabinete todavía están allí afuera, menos numerosos es verdad, nunca cerca de una fábrica, haciendo gabinetes costosos y bien hechos. El habilidoso cabineteer (Estaba lo suficientemente motivado para Googlear si había una palabra especial para este tipo de expertos) se encuentra todavía en demanda, para resolver problemas que IKEA no puede resolver. Existe esta posición en el campo de la ciencia y la medicina, también. Existe en todas partes: ¿cuáles son las implicaciones de la evolución de las herramientas sobre el trabajo de la mano de obra cualificada? Cualquier persona que busca la excelencia en su oficio debe luchar con el rol apropiado de las herramientas.

Por lo tanto, no hay que sorprenderse de que el Testing es hoy un proceso que incluye a las herramientas de muchas maneras, y que esto desafía la idea de un tester.
Esto siempre ha sido un problema - He estado trabajando con y discutiendo sobre esto desde 1987, y la literatura de esto se remonta al menos a 1961, pero algo nuevo ha sucedido: la informática móvil y distribuida a gran escala. Sí, esto es nuevo. Esto siempre ha sido un problema - He estado trabajando con y discutiendo sobre esto desde 1987, y la literatura de esto se remonta al menos a 1961, pero algo nuevo ha sucedido: la informática móvil y distribuida a gran escala. Sí, esto es nuevo. Veo que este es el mayor desafío para el Testing tal como lo conocemos desde el advenimiento de las micro-computadoras. ¿Por qué exactamente es un reto? Porque además de la complejidad de los productos y plataformas que han ido creciendo de manera constante durante décadas, ahora existe un gran mercado para los productos de software que se espera que sean distribuidos y actualizados al instante.

Queremos probar un producto rápidamente. ¿Cómo lo hacemos? Es tentador decir "Hagamos que las herramientas lo hagan!" Esto pone una enorme presión sobre los testers de software especializados y aquellos que crean herramientas para que los testers usen. Mientras tanto, las personas que no son expertos testers de software, tienen visiones de la industrialización del Testing similares a aquellas primeras fábricas de gabinetes. Sí, siempre ha habido estas presiones, en algún grado. Ahora el toque de tambor de "despliegue continuo" ha abierto otro frente en esa guerra.
Creemos que el trabajo cognitivo calificado no es trabajo de fábrica. Por eso es más importante que nunca entender lo que es Testing y cómo las herramientas pueden apoyarlo.

Checking vs Testing

Por esta razón, en la metodología de Rapid Software Testing, distinguimos entre los aspectos del proceso de pruebas que las máquinas pueden hacer frente a los que sólo los humanos capacitados pueden hacer. Lo hemos hecho lingüísticamente mediante la adaptación de la palabra comun en Inglés "checking", para referirse a lo que las herramientas pueden hacer. Esto es exactamente paralelo con la convención de larga data de distinguir entre "programar" y "compilar".
La programación es lo que los programadores humanos hacen. La compilación es lo que hace una herramienta en particular para el programador, a pesar de que un compilador  podría ser, técnicamente, lo que los programadores hacen. Ahora que lo pienso, nadie habla de la programación automática o programación manual. Hay programación, y hay un montón de otras cosas hechas por las herramientas. Una vez que se crea una herramienta para hacer esas cosas, nunca se llama de nuevo programación.

Ahora que Michael y yo hemos tenido más de tres años de experiencia trabajando con esta distinción, hemos agudizado nuestro lenguaje aún más, con las definiciones actualizadas y una nueva distinción entre la comprobación humana y la comprobación de la máquina.
Primero echemos un vistazo a Testing y Checking. Aquí están nuestras nuevas definiciones propuestas, que pronto sustituirán a los que hemos utilizado durante años (sujeto a revisión y comentario por colegas):

Testing es el proceso de evaluación de un producto mediante el aprendizaje sobre él a través de la experimentación, que incluye hasta cierto punto: cuestionamiento, estudio, modelado, la observación y la inferencia.

(Un Test es una instancia del Testing)

 Checking es el proceso de hacer las evaluaciones mediante la aplicación de reglas de decisión algorítmica a las observaciones específicas de un producto.

(Un check es una instancia del Checking.)

Notas explicativas:

• "Evaluar" significa hacer un juicio de valor; ¿es bueno? ¿es malo? pasa? falla? qué bueno? lo malo? Cualquier cosa por el estilo.
• "Evaluaciones" como un sustantivo se refiere al producto de la evaluación, que en el contexto de Checking va a ser un artefacto de algún tipo; una cadena de bits.
• "Aprendizaje" es el proceso de desarrollo de la mente de uno. Sólo los humanos pueden aprender en el más amplio sentido del término, como lo estamos usando aquí, porque nos estamos refiriendo al conocimiento tácito y al explícito. 
• "Experimentación" implica la interacción con un objeto y la observación , ya que está en funcionando, sino que también nos estamos refiriendo a los "experimentos mentales" que involucran la interacción puramente hipotética. Al hacer referencia a la experimentación, no estamos negando o rechazando otros tipos de aprendizaje; simplemente estamos tratando de expresar que la experimentación es una práctica que caracteriza al Testing. También implica que el Testing es congruente con la ciencia.
• La lista de palabras en la definición Testing no son exhaustivas de todo lo que podría estar involucrado en las pruebas, sino que representan los procesos mentales que pensamos que son más vitales y característicos.
• "Algorítmico" significa que se puede expresar de manera explícita en una manera que una herramienta podría realizar.
• "Observaciones" pretende abarcar todo el proceso de observar, y no sólo el resultado.
• "Observaciones específicas" significa que el proceso de observación resulta en una cadena de bits (de lo contrario, las reglas de decisión algorítmica no podían operar en ellos).

Hay ciertas implicaciones en estas definiciones:

• Testing abarca Checking, mientras que Checking no puede abarcar Testing
• Checking es un proceso que puede, en principio ser realizado por una herramienta en lugar de un ser humano, mientras que el Testing sólo puede ser apoyado por herramientas. Sin embargo, las herramientas se pueden utilizar para mucho más que comprobar.
• No estamos diciendo que la verificación deba ser automatizada. Pero la característica definitoria de una verificación es que puede ser completamente automatizada, mientras que el Testing es intrínsecamente una actividad humana.
• Testing es una investigación abierta - piensa en "Sherlock Holmes"- mientras que Checking es la abreviatura de "Checking de hechos" y se centra en los hechos y las normas específicas relacionadas con esos hechos.
• Checking no es lo mismo que confirmación. Checking se utiliza a menudo en un modo de confirmación (típicamente durante las pruebas de regresión), pero también podemos imaginarlos utilizarse para des-confirmación o para la exploración especulativa (es decir, un conjunto de controles generados automáticamente que pisa al azar a través de un vasto espacio, en busca de algo diferente). 
• Un problema común en nuestra industria es que checking se confunde con Testing Nuestro propósito aquí es reducir la confusión.
• Un verificación es descriptible; una prueba podría no serla (eso es porque, a diferencia de una verificación, una prueba implica conocimiento tácito)
• Una afirmación, en el sentido de las Ciencias de la Computación, es una especie de verificación. Pero no todas las verificaciones son afirmaciones, e incluso en el caso de las afirmaciones, puede haber código antes de la afirmación que es parte de la verificación, pero no es parte de la afirmación.
• Estas definiciones no son juicios morales. No estamos diciendo que la comprobación es inherentemente, hacer algo malo.Por el contrario, la comprobación puede ser algo muy importante que hacer. Nosotros afirmamos que para el checking  se considere bueno, debe ocurrir en el contexto de un proceso de inspección. Checking es una táctica de Testing.

¿Hacia dónde va la Sapiencia?

Si usted sigue nuestro trabajo, ya sabe que le hemos dado mucha importancia a la sapiencia. Un proceso sapiente es un proceso que requiere un ser humano debidamente capacitado para llevarlo a cabo. Sin embargo, en varios años practicando con esta etiqueta, hemos encontrado que es casi imposible de evitar dar la impresión de que un proceso no sapiente (es decir, uno que no requiere de un ser humano, pero podría implicar un ser humano muy talentoso y hábil, no obstante) es un proceso estúpido para gente estúpida. Eso es porque la palabra sapiencia suena como la inteligencia. Algunos de nuestros colegas han tomado una fuerte excepción a nuestra discusión de los procesos no sapientes sobre la base de ese malentendido. Por consiguiente, consideramos que es hora de ofrecer a este término en particular del arte, su jubilación.

Checking Humano vs Checking mecánico

Aunque sapiencia es problemática como etiqueta, todavía tenemos que distinguir entre lo que los seres humanos pueden hacer y lo qué las herramientas pueden hacer. Por lo tanto, además de la distinción básica entre control y prueba, también distinguimos entre checking humano y checking mecánico. Esto puede parecer un poco confuso al principio, ya que checking es, por definición, algo que se puede hacer por las máquinas. Usted podría ser perdonado por pensar que el control humano es lo mismo que checking de la máquina. Pero no lo es. No puede ser.

En el checking humano, los seres humanos están tratando de seguir un proceso algorítmico explícito. En el caso de las herramientas, sin embargo, las herramientas no están simplemente cumpliendo ese proceso, ellas lo encarnan. Los humanos no pueden encarnar dicho algoritmo. He aquí un experimento mental para demostrarlo: dígale a cualquier humano que siga una serie de instrucciones. Consiga que esté de acuerdo. Ahora observe lo que ocurre si usted lo hace imposible para él completar las instrucciones. Él no va a sentarse allí hasta que muera de sed o de la exposición. Él se detendrá a sí mismo y cambiará o saldrá del proceso. Y ahí es cuando se sabe a ciencia cierta que este ser humano, desde el principio, estaba encarnando algo más que el proceso que él acordó seguir y trató de seguir. No hay forma de evitar este caso si estamos hablando de personas con capacidad cognitiva normal, o incluso mínima. Cualquiera que sea el procedimiento que parecen estar siguiendo los humanos, ellos siempre están haciendo algo más, también. Los seres humanos están constantemente interpretando y ajustando sus acciones en formas que las herramientas no pueden. Esto es inevitable.

Los seres humanos pueden realizar acciones motivadas; las herramientas sólo pueden mostrar un comportamiento programado (ver el brillante libro de Harry Collins y Martin Kusch La Forma de las acciones, para obtener una explicación completa de por qué esto es así). La conclusión es: puedes definir una verificación con bastante facilidad, pero un ser humano realizará por lo menos un poco más durante esa verificación - y también menos en algunas formas-que una herramienta programada para ejecutar el mismo algoritmo.

Por favor comprenda, un papel sólido para las herramientas en el Testing debe ser aceptada. A medida que trabajamos hacia un futuro de Testing calificado, potente y eficiente, esto requiere una cuidadosa atención tanto a la parte humana y la parte mecánica de la ecuación de Testing. Las herramientas nos pueden ayudar de muchas maneras que van mucho más allá de la automatización de las verificaciones. Pero en esto, ellas juegan necesariamente un papel de apoyo a los humanos capacitados; y el uso torpe de herramientas puede tener terribles consecuencias.

Aprender experimentando, incluye el estudio, el cuestionamiento, el modelado, la observación, la inferencia, etc.

También puede preguntar por qué no nos limitamos a llamar al checking humano, "testing". Bueno, lo hacemos. Tenga en cuenta que todo esto está ocurriendo en el ámbito de Testing. El checking humano es parte de Testing. Sin embargo, creemos que cuando un ser humano está tratando de forma explícita de restringir su pensamiento a los confines de una verificación - a pesar de que no podrá hacer eso completamente- es ahora una táctica específica y restringida de Testing y no toda la actividad de Testing. Se merece una etiqueta propia dentro de Testing.

Con todo esto en mente, y con el objetivo de despejar la confusión, afilar nuestra percepción, y promover la colaboración, recuerde nuestra definición de checking:

Checking es el proceso de hacer las evaluaciones mediante la aplicación de reglas de decisión algorítmica a las observaciones específicas de un producto.

A partir de esto, hemos identificado tres tipos de checking:

Checking humano es un intento de proceso de comprobación en donde los seres humanos recogen las observaciones y  aplican las reglas sin la mediación de las herramientas. 

Checking mecánico es un proceso de comprobación en donde las herramientas recogen observaciones y  aplican las reglas sin la mediación de los seres humanos. 

Checking humano/mecánico es un intento de proceso de comprobación en el que los seres humanos y las herramientas interactúan para recoger observaciones y aplicar las reglas.

Para explicar esto a fondo, tendremos que hablar de ejemplos específicos. Puedes buscarlos en un próximo post.

Mientras tanto, te invitamos a comentar sobre esto.

ACTUALIZACIÓN 10 de abril 2013: Como resultado de intensas discusiones en la conferencia de pares SWET5, he actualizado el esquema de control y prueba. Tenga en cuenta que Testing está sentado fuera de la caja, ya que está describiendo toda la cosa, una descripción de Testing está en el interior de la misma. Checking humano se caracteriza por una nube, ya que su límite con aspectos no verificables del Testing no siempre es claramente discernible. Checking Mecánico se caracteriza por una línea punteada precisa, porque a pesar de su límite está claro, es una actividad opcional. Técnicamente, la comprobación humana también es opcional, pero sería un proceso de prueba verdaderamente extraño que no incluya al menos algunas comprobaciones humanas. Doy las gracias a los asistentes de SWET5 por ayudarme con esto: Rikard Edgren, Martin Jansson, Henrik Andersson, Michael Albrecht, Simon Morley, y Micke Ulander.