Diez ideas equivocadas sobre testing que creen muchas personas que no son testers. 1era parte.

Las pruebas de software es un oficio que muchas personas fuera del área malinterpretan; y que dañan el propósito de este proceso, propiciando una mala comunicación, culpa y resentimientos.

Advertisements
  1. Los testers descomponen las aplicaciones

Está es una falacia muy común que puede ser refutada con un poco de lógica. Los testers no tenemos ninguna herramienta mágica, escondida entre la computadora del desarrollador y el ambiente de pruebas, que inserta defectos a la aplicación, pero de alguna manera, la aplicación siempre funciona bien en la computadora del desarrollador.

La razón no es que el tester lo haya descompuesto. La razón es que el tester hizo algo que el desarrollador no tenía contemplado. Eso podría ser “Correr el software en el ambiente de pruebas sin antes haber instalado todos los prerrequisitos”. También podría ser que se buscaron exhaustivamente las fallas. De aquí podría venir la frase “Pero es que en mi computadora sí funciona”; en el equipo del desarrollador todo lo necesario para que un software se ejecute ya está instalado, toda la configuración está hecha, además de que sabe que está haciendo, así que sus pruebas generalmente se centran en las cosas que deberían ocurrir.

También puede suceder que la nueva funcionalidad que el desarrollador acaba de implementar, interactúa con otra funcionalidad que se acaba de actualizar y que olvidó ligar, así que la cobertura de las pruebas unitarias no fueron tan completas como el desarrollador pensó.

El punto es, hay muchísimas maneras en que una aplicación compleja pueda fallar, en mi experiencia cualquier equipo encontrará al menos una vez con esta situación en alguna etapa de sus carreras.

 

La verdad: Los testers no lo escribieron, así que no pudieron haberlo descompuesto

A diferencia de un objeto físico que puede romperse al dejarlo caer o al usarse de una manera inesperada, el software sólo puede ser estropeado por quien lo escribió. Los testers sólo encuentran donde es que está estropeado y lo reportan. A veces ni siquiera es un falla como tal y es simplemente que lo construido no funciona como los usuarios esperan que funcionara.

 

  1. Los testers no tienen habilidades técnicas

Esta es una idea que hace que rechine los dientes. He conocido algunos muy buenos testers que no podrían codificar y no tienen habilidades técnicas particularmente avanzadas. He conocido también algunos muy buenos testers que podrían sobrepasar las habilidades de cualquier otro programador en su empresa. Tener habilidades técnicas no se trata solamente de programar, sino también de reproducir y rastrear un defecto complicado de reproducir, ser capaz de leer o entender un error de código, poder preparar una aplicación en distintas configuraciones para probarla, poder explicar tanto a un programador como a alguien con nulo conocimiento técnico, que es lo que el software está haciendo y porque ese comportamiento es un problema.

Ser capaz de comunicar los hallazgos del producto, o reproducir un evento extraño, o poder encontrar esas situaciones en que las suposiciones del desarrollador no cumplen con las expectativas del cliente aún antes de que el cliente pueda ver el software funcionando, esas son el tipo de habilidades que importan. Son muchísimo más difíciles de definir y mucho más difíciles de cuantificar que un “puede programar tan bien como un desarrollador”.

Probablemente la forma más sencilla de describir ésto es que testers y desarrolladores tienen habilidades complementarias. Apresurar que un desarrollador tenga las habilidades para hacer cosas de tester toma tiempo que lo alejaría de sus actividades principales, de la misma forma que a un tester aprende a hacer cosas de desarrollador. Ambos perfiles son necesario y cada uno complementa al otro.

 

La verdad: Testing no es desarrollo

Testing es un campo distinto que tiene sus propias demandas. Algunas de esas demandas podrán involucrar desarrollo mientras que otra no.

Los desarrolladores usan sus habilidades para construir soluciones a problemas expresados en requerimientos de usuario. Antes de escribir una sola línea de código revisan casos de uso, o la petición de características, o el ticket de help desk o cualquier otra documentación que llegaran a necesitar, y toman decisiones en base a la mejor manera de ayudar a la persona que hizo el requerimiento. Después, mientras programan, toman decisiones sobre la mejor manera de manejar los distintos retos que encuentren mientras construyen la solución al problema o necesidad de alguien más. Son habilidades orientadas a la solución de problemas.

Los testers usan sus habilidades para analizar la usabilidad de la solución que se les presenta. Compararán el software con el problema en el caso de uso o la petición de características y buscarán los huecos o áreas que no encajen con el problema o la solución. Después usarán cualquier herramienta en su control para buscar posibles riesgos o sorpresas. Donde los desarrolladores se dedican principalmente a resolver problemas, los testers se dedican a encontrar problemas.

No importa si los testers tienen menos (o más) habilidades técnicas que los desarrolladores. Lo que importa es que sus habilidades sean lo suficientemente buena para cumplir con las tareas que necesitan desempeñar o que puedan hacerse de cualquier habilidad para hacer su trabajo a su mejor capacidad.

 

  1. Testing sólo se trata de escribir casos de prueba para luego ejecutarlos

Sólo hay que voltear a ver las ofertas de trabajo para ver como esta idea es comúnmente concebida. Cada posición tendrá una descripción similar: escribir casos de prueba y/o ejecutarlos. Los testers seniors los escriben y los junior los ejecutan. Eso es suficiente para soltar un pequeño gruñido de desdén.

Esta, como tantas otras ideas erróneas, vienen del modelo de fábrica de desarrollo de software, y de la creencia que el testing puede ser hecho por cualquiera con dos pulgares, además creer que cualquier software puede estar tan correctamente documentado que es posible escribir casos de pruebas exhaustivos y cien por ciento detallados mucho antes que el software esté terminado. Esa preconcepción es tan del modelo de cascada y no sobrevive para nada a las prácticas AGIL; y para casos prácticos, tampoco sobrevive a muchos proyectos de cascada.

Ésto es porque son pocos los proyectos que inician conociendo, y entendiendo, a detalle los requerimientos; así que habrá retrabajo y mantenimiento constante de los casos de prueba, no importa que tanto esfuerzo se haga para mantenerlos siempre vigentes. Dicen que el diablo se esconde en los detalles, o en los huecos de los requerimientos.

Como es relativamente sencillo medir el número de casos de prueba escritos y ejecutados, hay una tendencia a perpetuar esta práctica tan ineficiente. Ésto también ocurre seguido si hay un desdén a reducir la documentación requerida. Existen lugares donde tener una documentación detallada es necesaria; software que podría matar a alguien si llegara a fallar, o software para empresas que son muy reguladas, para esas situaciones sus requerimientos exigen que las pruebas sean realizadas profundamente documentadas e incluir evidencia de que fueron realizadas.

 

La verdad: Los casos de prueba son mucho menos importantes en testing a diferencia de la creatividad, la comunicación y la curiosidad

Creatividad, comunicación y curiosidad. Esas cualidades son esenciales para testing. Los casos de pruebas no son cualidades de un buen tester. Un equipo ÁGIL no tendría problemas de producir un código de alta calidad y bien probado mientras haya documentación sobre lo que fue probado, lo que no y el porqué.

Aún en industrias altamente reguladas con una necesidad de una documentación extremadamente detallada, un tester listo puede montar un proceso automatizado que incluya screenshots y así lidiar con la mayoría de las auditorías y requerimientos regulatorios, además de poder usar herramientas de captura para documentar sesiones exploratorias.

Es muchísimo más difícil medir esas habilidades a medir casos de prueba creados y ejecutados, lo cual justo explica la persistencia tan arraigada a los casos de prueba detallados dentro de la comunidad de testing.

 

  1. No funcionó en producción, así que los testers fallaron

Ésto resulta irritante en extremo. Si algo va mal en producción quiere decir que los testers fallaron. Si los testers no escribieron el código que está fallando, ¿porqué culparlos?

No me gusta culpar a testers o desarrolladores por problemas surgidos en producción. Los desarrolladores escriben código, pero cada release malo que he visto fue malo por factores fuera del control de desarrolladores o testers. Los problemas fueron causados por factores que ni los desarrolladores o testers pudieron prever, por ejemplo huecos en la comunicación, dependencias con otros equipos, o escalamiento de problemas que no pudieron resolverse dentro del equipo.

El software es instalado en servidores que no controlamos, usado por usuarios que no controlamos y en circunstancias que no controlamos. He visto a usuarios culpar a los testers por bugs documentados en navegadores así como también por sus propios errores ortográficos.

Sí, los testers cometen errores, pero también los demás. Nunca he conocido a un tester que no se moleste al saber que dejo pasar algo, aún y cuando no tenían manera de predecir que ese problema pudiera ocurrir.

 

La verdad: Nada puede ser probado en su totalidad

Es ingenuo pensar que un tester podría encontrar cada cosa que está mal con un programa. Tomemos por ejemplo una aplicación de una calculadora básica, con o sin funciones avanzadas. Ahora consideremos la función de sumar, para probar solamente el sumar dos números enteros en su totalidad, sería necesario usar cada número que la calculadora puede producir y sumarselo a todo otro número que la calculadora pudiera producir, y después asegurarse que el resultado es el correcto como lo muestre en pantalla.

Aún con una calculadora simple que no muestre notación exponencial y que sólo muestre números entre -999,999 y 999,999, eso son 1,999,998 posibles números enteros, si consideramos que en promedio tarda 5 segundos para hacer el cálculo y revisarlo, se estaría tardando más de 300,000 años en probar cada posible suma de dos números(trabajando 24 horas por 365 días). Nadie tiene tanto tiempo.

Supongamos que automatizamos el proceso y reducimos el tiempo de cálculo a 0.1 segundos, seguíamos tomando miles de años, o miles de computadoras, para poder probar cada posible combinación. Además que, sólo se ha probado sumar dos enteros. ¿Qué pasará cuando se sumen decimales? ¿Otras operaciones? ¿Más de dos números? Y así podemos seguirnos hasta el infinito.

Teniendo en cuenta todo lo anterior, el error de división de pentium se vuelve más razonable, ¿no lo creen? https://es.wikipedia.org/wiki/Error_de_divisi%C3%B3n_del_Intel_Pentium

 

  1. Los testers pueden encontrar todos los bugs

Para empezar, vuelve a mirar el título de este punto. Estoy seguro que con un presupuesto ilimitado y un lapso de tiempo ilimitado (recuerden lo de los miles de años) sería posible encontrar todos los bugs en un software dado. El único problema es que para cuando todo eso termine, los clientes habrán avanzado y el software que fue probado por miles y miles de años, ahora es obsoleto.

Más allá de la diversión que es el incremento de combinaciones matemáticas, hay que agregar que el tiempo de pruebas deberá de aumentar exponencialmente cada que un nuevo sistema operativo, hardware o funcionalidad se agregue a al alcance del software que se esté desarrollando; también hay que mencionar que muchas de las cosas reportadas como defectos en realidad no lo son… técnicamente hablando. En esos casos el software funciona exactamente como fue diseñado y construido, pero su funcionamiento y diseño no cumple del todo las necesidades y expectativas del cliente. Ésto es común, muy común.

 

La verdad: Los testers no pueden hacerlo todo y tampoco pueden leer la mente

No sólo es físicamente imposible probar cada particularidad que el software pueda realizar en cada pieza de hardware que pueda ejecutarlo, a menos que no importe que siga siendo probado después de que tu vida expire. Los testers no son telépatas; lo intentamos, y aún dando lo mejor, no podemos asegurar que es lo que el cliente quiere o necesita. Es por eso que hacemos nuestro mejor esfuerzo en probar lo que realmente importa, hacemos medidas de riesgo e intentamos asegurarnos que las funcionalidades principales del software trabajen de la mejor manera de acuerdo a nuestro conocimiento y habilidad.

 

Author: RobotSQT

Soy el robot que mantiene el blog de SQT.

One thought on “Diez ideas equivocadas sobre testing que creen muchas personas que no son testers. 1era parte.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s