Los robots algún día dominarán el mundo, siempre y cuando no nos extingamos antes. Eso sí, todavía queda un poco de tiempo para ello…

Una de las claves en cualquier desarrollo (o cualquier cosa que realicemos de forma manual / programada), sea del tipo que sea, es comprobar que funciona. Si funciona es que es probablemente la hayamos desarrollado de forma correcta. Y digo probablemente porque no siempre es así. A veces algo que funciona mal funciona bien (o eso creemos). O el mal funcionamiento es una nueva funcionalidad.

En el caso del desarrollo de aplicaciones y herramientas, los tests que realicemos pueden ser manuales y sistemáticos (no recomendable, pero a veces no queda más remedio que un humano revise el buen funcionamiento) y automatizados (es lo recomendable, siempre que los propios tests sean adecuados y correctos).

Varios aspectos a tener en cuenta:

• El desarrollo del los tests también requiere programación. Hay que programarlos bien, sin errores, o puede que den un resultado erróneo.
• Hay que conocer qué inputs y outputs (entradas y salidas de datos) deben recibir y deben utilizar los diferentes casos de test que desarrollemos. Sin conocer internamente qué debería devolver una funcionalidad (método, función, API…) para unos datos de entrada o datos disponibles dados, no podremos comprobar que esté dando la salida esperada.
• Hay que comprobar todos los casos (o la mayor parte de ellos) de inputs, con sus correspondientes outputs. Si un caso de test únicamente comprueba un output para un input dado, puede que para otros inputs falle (y no nos demos cuenta hasta que sea demasiado tarde).
• Hay funcionalidades muy difíciles de testear si se hace de forma automatizada. Por ejemplo, el caso en el que se deban calcular los días festivos entre 2 fechas, suponiendo que el usuario pueda almacenar diferentes fechas festivas en la base de datos y que estos varíen según el usuario. En este caso, calcular los días festivos supone la necesidad de obtener fechas de la base de datos y recalcular los días festivos… pero eso mismo es lo que se está haciendo en el método a ser testeado… Es decir, hay cosas que dependen de la configuración del sistema (y pueden ser muy variables).
• Es necesario testear todo lo posible para encontrar posibles bugs, no solo en nuevos desarrollos, sino en actualizaciones de funcionalidades ya existentes. De esta forma, nos aseguramos también de compatibilidades hacia atrás, o que en cambios de versiones principales siga funcionando todo como era de esperar.
• Se deben automatizar los tests que sean posibles. Y se debe testear todo aquello que sea posible (tests unitarios, de integración, de UX, de funcionamiento de UI, de eficiencia… incluso de la calidad de documentación…). Para ello hay innumerables herramientas disponibles.
• Realizar el desarrollo de los tests lleva tiempo. Es un tiempo que no se ve, pero que se debe tener en cuenta (tanto en planificación temporal como en presupuestos). Y también se debe incluir la documentación y comentarios que sean necesarios en los casos de test desarrollados (ya que sigue siendo código).
• No se debe testear en ambientes de producción. Por el bien de todos.

En este punto se puede abrir otra vía de debate: ¿Es bueno que la misma persona que realiza el desarrollo de una funcionalidad realice los casos de test para comprobar su correcto funcionamiento?. En principio es lo más rápido, pero no es recomendable (ya que si el desarrollador comete un error en la asimilación de lo que debería realizar la funcionalidad desarrollada la propagará también a los casos de test). En caso de que sean dos personas diferentes, llevará un coste y esfuerzo adicional (ya que otra persona, además del desarrollador principal, deberá estudiar y asimilar los requisitos de las funcionalidades desarrolladas)

También conviene realizar una monitorización en tiempo real del código / sistema desarrollado. Existen herramientas que, tras instalar un agente, son capaces de obtener cuellos de botella, analizar los métodos más utilizados y que más recursos consumen, etcétera… por lo que ayudan a mejorar la calidad del código, y por tanto, a cometer menos errores en el desarrollo y programación.

Y sobre todo, hay que recordar que cualquier sistema es mejorable y rompible. Y si está roto hay que arreglarlo. Y aunque tú no te percates de algún error, siempre habrá alguien que haga algo extremadamente idiota o inteligente capaz de romper una funcionalidad de tu sistema (o el sistema completo).

Siempre me ha llamado la atención la gente que era capaz de hacer cosas. Cosas de cualquier tipo, pero sobre todo, gente capaz de hacer cosas con sus manos utilizando herramientas. Ya no solo desde la prehistoria, con la capacidad de los homínidos y sus dedos prensiles para agarrar objetos y prehistóricas herramientas, sino en la actualidad.

Por ejemplo, yo no sería capaz de hacer una mesa a partir de unos tablones. O mejor dicho, sería capaz, tras mucho sufrimiento, tras muchas horas, tras cortar muchas maderas y clavar muchos clavos… y al final estaría coja. O no estaría nivelada. O se prendería fuego tras dejar cualquier cosa encima de ella.

Sin embargo, otras personas son especialmente hábiles para según qué tareas. Para otras no tanto, para otras nada de nada, pero en ciertos campos se desenvuelven con soltura. Son personas con recursos para todo (dentro de sus respectivos campos). Algunas personas, eso sí, no tienen recursos en ningún campo.

A mucha gente le da vergüenza dibujar cuando son adultos, pero a casi todos nos ha gustado pintar y dibujar cuando éramos pequeños. No se trata ya de no saber dibujar, sino de haber dejado de practicar. El diablo sabe más por viejo que por diablo, y es por ello que, tras muchas horas de ser diablo, llega a ser un experto en diabluras. Dicen que para ser experto piloto hacen falta unas 10000 horas de vuelo, para el diablo debieron ser algunas más.

Aún así, hay algunos campos que no llegarás a ser experto nunca. Bien por incapacidad o limitaciones propias, bien por falta de tiempo, bien porque el campo es tan amplio y extenso que es imposible alcanzar sus horizontes… Cuando llegas al grado de experiencia que podrías considerarte como experto, te das cuenta de que el horizonte sigue estando más adelante (en el propio horizonte para ser exactos).

Y no solo es cuestión de tiempo. En muchas ocasiones se necesitan herramientas para hacer las cosas. Es cierto que hay tareas que pueden ser realizadas sin las herramientas adecuadas, pero tener una buena herramienta ayuda.

En el caso del desarrollo no basta con tener un ordenador decente. Eso está bien, y puedes hacer tus proyectos, pero si vas a trabajar durante mucho tiempo conviene tener un buen equipo, un buen teclado, un buen monitor, buenas aplicaciones… porque todo ello, aunque no te des cuenta, ayuda a realizar tu trabajo de forma más eficiente y cómoda.