Artwork

Contenido proporcionado por Diego Laballós. Todo el contenido del podcast, incluidos episodios, gráficos y descripciones de podcast, lo carga y proporciona directamente Diego Laballós o su socio de plataforma de podcast. Si cree que alguien está utilizando su trabajo protegido por derechos de autor sin su permiso, puede seguir el proceso descrito aquí https://es.player.fm/legal.
Player FM : aplicación de podcast
¡Desconecta con la aplicación Player FM !

92. El coste de no tener tests automatizados

9:41
 
Compartir
 

Series guardadas ("Feed inactivo" status)

When? This feed was archived on February 04, 2022 02:10 (2y ago). Last successful fetch was on August 03, 2021 05:49 (2+ y ago)

Why? Feed inactivo status. Nuestros servidores no pudieron recuperar un podcast válido durante un período sostenido.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 220074446 series 1911761
Contenido proporcionado por Diego Laballós. Todo el contenido del podcast, incluidos episodios, gráficos y descripciones de podcast, lo carga y proporciona directamente Diego Laballós o su socio de plataforma de podcast. Si cree que alguien está utilizando su trabajo protegido por derechos de autor sin su permiso, puede seguir el proceso descrito aquí https://es.player.fm/legal.

La principal razón por la que hago este episodio es que a veces es difícil explicar, a alguien que no tiene el conocimiento técnico, el por qué estos tests automatizados son necesarios y por qué hay que invertir en ellos. Para ello, vamos a hacer un breve resumen de lo que son, de qué tratan y cuál es su utilidad.

¿Cómo funcionan los tests automatizados?

En primer lugar hay que mencionar que los tests automatizados son básicamente código de programación que verifica que todo funciona como debería. Es decir, código de programación que verifica otro código de programación. Sí es un poco enreversado, pero es así.

Para verlo mejor con un ejemplo, imaginemos una aplicación muy simple que tiene un botón que, cuando se clica se va a la siguiente pantalla y nos muestra el tiempo que hace en Barcelona. Esto es un ejemplo muy simple, pero va a servir para verlo.

Básicamente esta aplicación puede parecer algo muy sencillo, incluso podríamos definirla con una sola frase, con unas pocas palabras, es decir, una aplicación en la que clicas en un botón y obtienes el tiempo a través de un servidor; de un servidor cualquiera que tiene un servicio que devuelve los datos del tiempo en Barcelona.

Tratando el tema de los test automatizados, lo que haríamos aquí es programar test automatizados que comprobarían que todo lo que vamos a programar funciona como debería.

Por ejemplo, el primer test podría ser que, cuando abro la app, me aparece un botón para ver el tiempo; y, otro test podría ser que cuando le doy a este botón obtengo la información de la temperatura que hace en Barcelona.

Básicamente estos tests cumplen la misma función que haría una persona que prueba la aplicación, pero la diferencia es que, en vez de minutos en este caso, tardaría segundos.

El problema es que estos test hay que programarlos y esto tiene un coste y aquí es donde viene la cuestión que planteaba en un principio.

Esta cuestión es que es difícil a veces si no se explica bien, justificar este coste a una persona que no tiene un perfil o un conocimiento tecnológicos; podríamos decir que esta aplicación tan simple, sin ningún tipo de tests automatizados, y solo programando lo que vendría a ser la funcionalidad, podríamos dar (por decir algo) 150 euros.

Sin embargo, sí queremos añadir estos test automatizados, es decir, queremos programar estos tests para que se hagan de forma automatizada y que no los haga una persona manualmente; podríamos decir que tendría un coste extra de unos 50 euros; así que se situaría en torno a unos 200 más o menos.

¿Por qué no optar por la solución económica?

Aquí viene el problema. SI lo miras desde esta perspectiva, simplemente con el coste es fácil optar por la solución económica, ya que el beneficio que obtienes de estos test automatizados, no parece ser tan grande.

Al fin y al cabo, es algo que puedes hacer manualmente en unos pocos minutos y te ahorras unos 50 euros.

Pero, vamos a ver los costes reales de no explicar esto y en qué consisten exactamente los tests y donde está el beneficio real.

El primer punto a tener en cuenta es cualquier aplicación por simple que parezca no lo es tanto realmente.

En este caso que estamos poniendo de ejemplo, se ha descrito esto como una app que, a través de un botón te da la temperatura de Barcelona. Sin embargo, vamos a ver todas las situaciones que realmente se pueden dar en esta aplicación tan sencilla.

En primer lugar, tendríamos que verificar que la app muestre el botón inicial en la pantalla principal, después tendríamos que verificar qué pasa si estamos consultando el tiempo cuando no tenemos conexión a internet, que se muestre un mensaje de error coherente.

Luego ¿Qué pasa si obtenemos la información del servidor, pero este no responde por cualquier motivo. ¿Qué pasa si el servidor responde, pero con unos datos que la aplicación no entiende, porque está algo mal el servidor y nos devuelve unos datos que están mal; ¿Qué mostramos al usuario en ese caso?

También puede ser, que obviamente el servidor te devuelva la información correcta, en ese caso tienes que poder ver la información del tiempo en Barcelona.

Y también finalmente deberíamos comprobar que después de consultar el tiempo, puede volver atrás para volver a consultarlo otra vez; poder navegar entre las dos pantallas sin ningún problema.

Lo que era una app, sencilla, extremadamente sencilla, ahora ya no lo es tanto. Tiene varios casos de uso. Ahora vamos a imaginar esto con una app de verdad o ya puestos, con esta misma aplicación, pero añadiéndole algo más como opciones para consultar cualquier localidad, para ponerla tú a través del teclado, quizás una opción para obtener la localidad automáticamente a través del GPS, mostrar más datos del tiempo, etc.

Podríamos seguir añadiendo cosas hasta hacerla una aplicación que realmente fuera útil, que realmente fuera una aplicación de verdad. Los casos de uso como se pueden ver, se van incrementando, incrementando exponencialmente ¿qué pasa?

Cada vez que añadamos algo más dentro de la aplicación, que la actualicemos, que hagamos cualquier cosa, deberíamos probar todos estos casos uno por uno, para asegurarnos que todo funciona. Da igual el cambio que hagamos, que sea un cambio muy pequeño, que sea una cosa que sólo afecte una parte de la app.

Cualquier cambio en el código, puede afectar cualquier parte de la aplicación y puede producir un error; esto es así y es cómo funciona la programación.

A todo esto, tenemos que añadirle un punto súper importante dentro de los móviles, y es que lo que funciona en un móvil puede ser que no funcione en otro. O, lo que funciona en una versión de Android o de IOS, puede ser que no funcione en otra. Hay muchos motivos por los cuales esto puede pasar, pero esto es así.

De repente todas las situaciones se van incrementando cada vez más; en un mundo ideal tendríamos que ir paso a paso por todas estas situaciones, a través de diferentes móviles y de versiones de sistema operativo para estar seguros de que nuestra app funciona al cien por cien.

Si no lo hacemos, básicamente no podemos estar seguros de que nuestra app funciona y si aparece un error, es lo más normal del mundo, puede pasar y cuanto menos probemos, más posibilidades tenemos de que aparezca un error.

Obviamente es imposible probar todo al cien por cien, aunque tengamos test automatizados, aunque hagamos miles y miles de test manuales; es imposible estar seguro y los errores van a aparecer, es algo que está ahí, que todas las aplicaciones tienen.

El problema es que cuanto menos probemos, más errores vamos a tener. Esto nos lleva al tema del episodio: el coste de no tener test automatizados.

Desventajas de no tener test automatizados

Supongamos que una app normal tiene unas cien situaciones que deberíamos probar y, realmente estoy siendo muy generoso, porque cualquier aplicación tiene más de 20,30,40, 50 funcionalidades y estas pueden tener diferentes situaciones; se pueden ver envueltas en distintas situaciones.

En el caso de que no tengamos test automatizados, tendremos una persona, la figura del tester que se encargará de probar todos estos tests, los hará manualmente y básicamente se va a dedicar a ello.

Esta persona, obviamente va cobrar un salario por hacer ese trabajo y cuantos más casos de uso tengamos, más tiempo va a necesitar esa persona o más personas vamos a necesitar.

Por otro lado, si tenemos test automatizados, la figura del tester sigue siendo imprescindible, por lo menos para probar los casos principales, pero quizás un 80% de los casos pueden estar cubiertos por estos test automatizados, que lo hacen en pocos segundos.

Y lo más importante de todo, no cobran nada por hacerlo, porque básicamente son máquinas; si hacemos cuentas, los test automatizados, aunque tengamos que invertir un poco en su desarrollo inicialmente y luego de vez en cuando son infinitamente mucho más económicos que probar todo manualmente, que tener varias personas probando la aplicación constantemente cada vez que haces un cambio; y aquí es donde se ve el coste real.

Los tests, una vez están hechos, no necesitan cambiarse si nada es diferente. Sin embargo, los test manuales son imposibles de automatizar, porque, al fin y al cabo, son manuales. Vas a tener que estar pagando a esa gente, que se ocupa de hacerlos de forma manual con lo cual si comparas los salarios de esa gente que tienes que tener, con el coste que te supone desarrollar los test automatizados únicamente una vez, no hay ni comparación con el coste.

The post 92. El coste de no tener tests automatizados appeared first on Diego Laballós.

  continue reading

100 episodios

Artwork
iconCompartir
 

Series guardadas ("Feed inactivo" status)

When? This feed was archived on February 04, 2022 02:10 (2y ago). Last successful fetch was on August 03, 2021 05:49 (2+ y ago)

Why? Feed inactivo status. Nuestros servidores no pudieron recuperar un podcast válido durante un período sostenido.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 220074446 series 1911761
Contenido proporcionado por Diego Laballós. Todo el contenido del podcast, incluidos episodios, gráficos y descripciones de podcast, lo carga y proporciona directamente Diego Laballós o su socio de plataforma de podcast. Si cree que alguien está utilizando su trabajo protegido por derechos de autor sin su permiso, puede seguir el proceso descrito aquí https://es.player.fm/legal.

La principal razón por la que hago este episodio es que a veces es difícil explicar, a alguien que no tiene el conocimiento técnico, el por qué estos tests automatizados son necesarios y por qué hay que invertir en ellos. Para ello, vamos a hacer un breve resumen de lo que son, de qué tratan y cuál es su utilidad.

¿Cómo funcionan los tests automatizados?

En primer lugar hay que mencionar que los tests automatizados son básicamente código de programación que verifica que todo funciona como debería. Es decir, código de programación que verifica otro código de programación. Sí es un poco enreversado, pero es así.

Para verlo mejor con un ejemplo, imaginemos una aplicación muy simple que tiene un botón que, cuando se clica se va a la siguiente pantalla y nos muestra el tiempo que hace en Barcelona. Esto es un ejemplo muy simple, pero va a servir para verlo.

Básicamente esta aplicación puede parecer algo muy sencillo, incluso podríamos definirla con una sola frase, con unas pocas palabras, es decir, una aplicación en la que clicas en un botón y obtienes el tiempo a través de un servidor; de un servidor cualquiera que tiene un servicio que devuelve los datos del tiempo en Barcelona.

Tratando el tema de los test automatizados, lo que haríamos aquí es programar test automatizados que comprobarían que todo lo que vamos a programar funciona como debería.

Por ejemplo, el primer test podría ser que, cuando abro la app, me aparece un botón para ver el tiempo; y, otro test podría ser que cuando le doy a este botón obtengo la información de la temperatura que hace en Barcelona.

Básicamente estos tests cumplen la misma función que haría una persona que prueba la aplicación, pero la diferencia es que, en vez de minutos en este caso, tardaría segundos.

El problema es que estos test hay que programarlos y esto tiene un coste y aquí es donde viene la cuestión que planteaba en un principio.

Esta cuestión es que es difícil a veces si no se explica bien, justificar este coste a una persona que no tiene un perfil o un conocimiento tecnológicos; podríamos decir que esta aplicación tan simple, sin ningún tipo de tests automatizados, y solo programando lo que vendría a ser la funcionalidad, podríamos dar (por decir algo) 150 euros.

Sin embargo, sí queremos añadir estos test automatizados, es decir, queremos programar estos tests para que se hagan de forma automatizada y que no los haga una persona manualmente; podríamos decir que tendría un coste extra de unos 50 euros; así que se situaría en torno a unos 200 más o menos.

¿Por qué no optar por la solución económica?

Aquí viene el problema. SI lo miras desde esta perspectiva, simplemente con el coste es fácil optar por la solución económica, ya que el beneficio que obtienes de estos test automatizados, no parece ser tan grande.

Al fin y al cabo, es algo que puedes hacer manualmente en unos pocos minutos y te ahorras unos 50 euros.

Pero, vamos a ver los costes reales de no explicar esto y en qué consisten exactamente los tests y donde está el beneficio real.

El primer punto a tener en cuenta es cualquier aplicación por simple que parezca no lo es tanto realmente.

En este caso que estamos poniendo de ejemplo, se ha descrito esto como una app que, a través de un botón te da la temperatura de Barcelona. Sin embargo, vamos a ver todas las situaciones que realmente se pueden dar en esta aplicación tan sencilla.

En primer lugar, tendríamos que verificar que la app muestre el botón inicial en la pantalla principal, después tendríamos que verificar qué pasa si estamos consultando el tiempo cuando no tenemos conexión a internet, que se muestre un mensaje de error coherente.

Luego ¿Qué pasa si obtenemos la información del servidor, pero este no responde por cualquier motivo. ¿Qué pasa si el servidor responde, pero con unos datos que la aplicación no entiende, porque está algo mal el servidor y nos devuelve unos datos que están mal; ¿Qué mostramos al usuario en ese caso?

También puede ser, que obviamente el servidor te devuelva la información correcta, en ese caso tienes que poder ver la información del tiempo en Barcelona.

Y también finalmente deberíamos comprobar que después de consultar el tiempo, puede volver atrás para volver a consultarlo otra vez; poder navegar entre las dos pantallas sin ningún problema.

Lo que era una app, sencilla, extremadamente sencilla, ahora ya no lo es tanto. Tiene varios casos de uso. Ahora vamos a imaginar esto con una app de verdad o ya puestos, con esta misma aplicación, pero añadiéndole algo más como opciones para consultar cualquier localidad, para ponerla tú a través del teclado, quizás una opción para obtener la localidad automáticamente a través del GPS, mostrar más datos del tiempo, etc.

Podríamos seguir añadiendo cosas hasta hacerla una aplicación que realmente fuera útil, que realmente fuera una aplicación de verdad. Los casos de uso como se pueden ver, se van incrementando, incrementando exponencialmente ¿qué pasa?

Cada vez que añadamos algo más dentro de la aplicación, que la actualicemos, que hagamos cualquier cosa, deberíamos probar todos estos casos uno por uno, para asegurarnos que todo funciona. Da igual el cambio que hagamos, que sea un cambio muy pequeño, que sea una cosa que sólo afecte una parte de la app.

Cualquier cambio en el código, puede afectar cualquier parte de la aplicación y puede producir un error; esto es así y es cómo funciona la programación.

A todo esto, tenemos que añadirle un punto súper importante dentro de los móviles, y es que lo que funciona en un móvil puede ser que no funcione en otro. O, lo que funciona en una versión de Android o de IOS, puede ser que no funcione en otra. Hay muchos motivos por los cuales esto puede pasar, pero esto es así.

De repente todas las situaciones se van incrementando cada vez más; en un mundo ideal tendríamos que ir paso a paso por todas estas situaciones, a través de diferentes móviles y de versiones de sistema operativo para estar seguros de que nuestra app funciona al cien por cien.

Si no lo hacemos, básicamente no podemos estar seguros de que nuestra app funciona y si aparece un error, es lo más normal del mundo, puede pasar y cuanto menos probemos, más posibilidades tenemos de que aparezca un error.

Obviamente es imposible probar todo al cien por cien, aunque tengamos test automatizados, aunque hagamos miles y miles de test manuales; es imposible estar seguro y los errores van a aparecer, es algo que está ahí, que todas las aplicaciones tienen.

El problema es que cuanto menos probemos, más errores vamos a tener. Esto nos lleva al tema del episodio: el coste de no tener test automatizados.

Desventajas de no tener test automatizados

Supongamos que una app normal tiene unas cien situaciones que deberíamos probar y, realmente estoy siendo muy generoso, porque cualquier aplicación tiene más de 20,30,40, 50 funcionalidades y estas pueden tener diferentes situaciones; se pueden ver envueltas en distintas situaciones.

En el caso de que no tengamos test automatizados, tendremos una persona, la figura del tester que se encargará de probar todos estos tests, los hará manualmente y básicamente se va a dedicar a ello.

Esta persona, obviamente va cobrar un salario por hacer ese trabajo y cuantos más casos de uso tengamos, más tiempo va a necesitar esa persona o más personas vamos a necesitar.

Por otro lado, si tenemos test automatizados, la figura del tester sigue siendo imprescindible, por lo menos para probar los casos principales, pero quizás un 80% de los casos pueden estar cubiertos por estos test automatizados, que lo hacen en pocos segundos.

Y lo más importante de todo, no cobran nada por hacerlo, porque básicamente son máquinas; si hacemos cuentas, los test automatizados, aunque tengamos que invertir un poco en su desarrollo inicialmente y luego de vez en cuando son infinitamente mucho más económicos que probar todo manualmente, que tener varias personas probando la aplicación constantemente cada vez que haces un cambio; y aquí es donde se ve el coste real.

Los tests, una vez están hechos, no necesitan cambiarse si nada es diferente. Sin embargo, los test manuales son imposibles de automatizar, porque, al fin y al cabo, son manuales. Vas a tener que estar pagando a esa gente, que se ocupa de hacerlos de forma manual con lo cual si comparas los salarios de esa gente que tienes que tener, con el coste que te supone desarrollar los test automatizados únicamente una vez, no hay ni comparación con el coste.

The post 92. El coste de no tener tests automatizados appeared first on Diego Laballós.

  continue reading

100 episodios

Todos los episodios

×
 
Loading …

Bienvenido a Player FM!

Player FM está escaneando la web en busca de podcasts de alta calidad para que los disfrutes en este momento. Es la mejor aplicación de podcast y funciona en Android, iPhone y la web. Regístrate para sincronizar suscripciones a través de dispositivos.

 

Guia de referencia rapida