Lo que se esconde detrás de un máximo de caracteres

Lo que se esconde detrás de un máximo de caracteres

Es ideal que los QAs y los testers estén involucrados en la captura de requerimientos y su posterior conversión en especificaciones. El agilismo así lo defiende y yo lo comparto, puesto que permite reconocer y alertar sobre áreas de riesgo, detectar potenciales problemas futuros, conocer de antemano los detalles de la funcionalidad que va a venir, adelantar el diseño de las pruebas… Es ideal, pero no siempre es posible.

En esos casos, la documentación disponible es de cosas ya hechas; es decir, funcionalidad ya implementada. En esa documentación pueden faltar detalles de implementación o meta-conocimiento del que disfrutaríamos si hubiéramos estado involucrados desde en un principio.

Hay varias maneras de recuperar ese terreno perdido, la idea de “Show & Tell” de Darren McMillan me parece fantástica (por la que el desarrollador hace una “demo” de la funcionalidad al tester, antes de submitar el código al repositório). Otra manera es mediante el própio testing exploratorio, mediante la própia exploración de la funcionalidad, apretando las tuercas a cada frase, cada palabra, cada coma, de la especificación de lo testeado.

En cualquier caso, los objetivos son los mismos:

  1. Disponer del conocimiento máximo de las aplicaciones a testear
  2. En caso de que el objetivo anterior no se cumpla, hacer todo lo que esté en nuestra mano para conseguirlo 🙂

Este objetivo no es un fin en sí mismo, es un medio para hacer mejor nuestro trabajo. Por ejemplo, un caso real con el que me he encontrado esta misma semana: nueva funcionalidad para una aplicación, me puedo incorporar a testearla sin haber podido participar en su concepción, luego valido  y re-valido todo lo que dice en la especificación que viene con la funcionalidad, y me encuentro con…

El campo XXX puede albergar un máximo de 256 caracteres.

“Eso habrá que verlo”, me digo. Y no era así, admitía 255, uno menos de lo esperado y especificado. En este punto, me podría haber parado, reportar el defecto y a otra cosa, pero en ello no ganaba conocimiento, luego me pregunté…

Y de dónde viene esta limitación?

Un dato así, a grandes rasgos, puede venir de…

  1. Exigencia expresa transmitida por el equipo de negocio
  2. Limitación técnica
  3. “Había que poner un máximo y no sabíamos cual”

Es fácil salir de dudas, preguntando al desarrollador responsable de la funcionalidad. En este caso, se trataba de (2): el límite viene del ancho de la columna de la base de datos que almacena el valor en el campo. Pero había un detalle, el campo es de tipo tinytext, cuyo ancho máximo es 255 caracteres y no 256, luego esto no es un defecto, es una errata en la documentación y ya está, puesto que no había problema por parte de negocio en que el campo tuviera una capacidad de 255 caracteres.

Learnings del caso concreto:

  • Saber de donde viene el máximo establecido en el campo concreto
  • Un defecto menos en el bugtracker, una errata corregida en la documentación
  • Aprender que el tipo de dato tinytext en SQL admite hasta 255 caracteres, útil para futuras pruebas de esta y otras funcionalidades.

Admito que no es un aprendizaje enorme ni me va a arrojar luz sobre las grandes dudas del testing o de la humanidad, pero si de cada pequeño cambio en una funcionalidad sacamos un conocimiento así, al cabo de un tiempo estaremos bastante más cerca del conocimiento máximo de las aplicaciones que testeamos.

Anuncios

2 comentarios en “Lo que se esconde detrás de un máximo de caracteres

  1. Totalmente de acuerdo. Y además lo importante de mantener un repositorio de Learnings para que toda la organización pueda aprender de ello.

    Aprovecho para darte la enhorabuena por el magnífico blog que escribes, el cual todavía estoy empezando a seguir.

    • Muchas gracias Roberto por seguir y comentar!

      Sobre repositorio de learnings, últimamente practico mucho la idea de la documentación ligera, no en el sentido de superficial, sinó más bien en lo que se refiere al mantenimiento y pertenencia al proyecto, no cayendo en la religiosidad extrema en estos sentidos. Si dedicas una mañana a entender una cosa, dedica una hora más, escribe un párrafo al respecto, haz un flowchart, un esquema… Compártelo y guárdalo, y mientras sirva, pues fantástico! Llegado el momento, se actualiza o se tira, sin aspavientos 😉

      Un placer saludarte,

      — Mauri

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s