miércoles, 15 de febrero de 2017

96. Pruebas cudradas (Desde el divan del gato)

Un tema muy interesante en desarrollo en el que yo en lo personal no coincido con muchos colegas o incluso con la literatura, es el tema de pruebas, principalmente en esta época en que las aplicaciones dejan de construirse para un grupo pequeño de usuarios (anteriormente yo hablaba que una aplicación era usada en una PC con características que conocía, y era usada por los usuarios de una empresa o sector en particular) a aplicaciones que si tienen éxito serán empleadas por millones de usuarios en dispositivos con características que desconozco.

Sumemos otro factor, la exigencia de los usuarios hoy en día es mayor, si hablamos de hace 10 años los usuarios estaban acostumbrados a que un buen numero de aplicaciones eran lentas y si fallaban pues había que vivir con el problema, no existía otra opción, hoy en día, esas opciones nacen todos los días y si la aplicación falla, o no enamora al usuario, simplemente se dejara de usar.

Un error grave debe corregirse en minutos, mientras menos usuarios lo vean, menos usuarios perderé.

Otro factor importante, es el numero de entradas que hoy en día tiene un sistema, cada una de ellas puede ser un factor que genere un error no controlado.

La comunicación, puede variar aun en sitios en los que se supone esta no falla, un ambiente heterogéneo, no controlado, que debe hacernos mirar para muchos lados para conseguir un verdadero sistema, que sea capaz de recuperarse de una falla.

Esto hace que los casos de prueba, que en la mayoría de los casos solo revisan reglas de negocio, dejen de ser suficientes, y mas por que la mayoría de los ambientes de pruebas son ambientes controlados, es decir yo se lo que hay, conozco la infraestructura y esta nunca falla.

El equipo de pruebas hoy en día debe ver mas allá, pero no solo ver que el sistema no falle, debe ver también que el usuario, que es un cliente potencial (el puede recomendar el sistema) se sienta cómodo con el.

Mi sistema debe sobreponerse a fallas en este ambiente heterogéneo, ya que una falla puede ocasionar que el usuario se sienta inseguro y lo deje de usar.

¿Qué debo mirar?

Ve 2 cosas al desarrollar, primero que nada que el sistema sea fácil de usar, y no complique de mas los procesos, este punto es el mas complicado de hacer, por que todos somos diferentes, y recordando la frase que dice que el sentido común es el menos común de los sentidos, la situación se vuelve mas complicada.

Observa el sistema como los bloques que lo forman

Los procesos que se desarrollan en el sistema son un núcleo aislado que se compone de un conjunto de entradas y salidas, estas entradas y salidas forman flujos que conectan diversos componentes.

Todo aquello que entre y salga del núcleo son puntos en los que siempre se puede suscitar una falla que se encuentre fuera de los casos de prueba de un sistema, además todos estos son los puntos que se vuelven vulnerables a ataque principalmente en este mundo conectado.

Ve la base de datos, es algo externo a tu sistema, siempre puede fallar
Ve las comunicaciones por red, nada te garantiza que la red siempre este conectada
Ve el almacenamiento, los accesos a disco, nada te garantiza que tienes un espacio ilimitado
Ve las comunicaciones entre tus componentes, pese a que sean en el mismo equipo, los datos están viajando
Ve todos aquellos componentes que ocupes de terceros, que trabajen junto a tu sistema
Ve los dispositivos de entrada y salida

No pierdas de vista esto, por que recuerda, hoy en día el usuario no perdona, el usuario abandona


Felices líneas

No hay comentarios.:

Publicar un comentario