Estos días ha habido mucho movimiento debido a dos grandes fallos que han provocado varios problemas en dos grandes compañias, Google y Coca Cola.

El primero de ellos ha sido debido a un error de seguridad en la aplicación Google Wallet (monedero virtual de Google) que permite en algunos telefonos obtener el PIN del monedero virtual y posteriormente realizar compras con las tarjetas de las que dispone.

El grupo de seguridad Zvelo ha realizado una pequeña aplicación para demostrar la facilidad para la obtención de PINs con un telefono rooteado. El PIN se guarda cifrado en la memoria del teléfono, pero como solo hay 4 cifras solo es necesario realizar 10.000 iteraciones para comprobar cual es el PIN correcto. En este caso solo afecta los telefonos con root por lo que Google ha salido del paso indicando que no se recomienda que se instale en estos terminales Google Wallet. La pregunta es… Que pasa si alguien me rootea el movil en algún momento?

Pero la historia no acaba aquí, si no que también se ha descubierto otro error grave y mucho más sencillo. Algo tan facil como borrar los datos de la aplicación y volverla a instalar… en ese momento nos pide un nuevo PIN y podremos utilizar de nuevo la tarjeta! Este caso se puede dar fácilmente en el caso de que nos robaran el móvil. La respuesta de Google en este caso ha sido a mi parecer un poco más débil, utilizar un PIN para el teléfono y un borrado de datos en caso de robo. A mi parecer una solución muy pobre para tapar errores de seguridad de este calibre… Debilidades que harán que mucha gente se lo piense antes de utilizar en Google Wallet!

La otra gran protagonista es Coca Cola, ya que después de hacer un despliegue impresionante en la web para promocionarse en la Super Bowl tuvo problemas de rendimiento. Parece ser que el anuncio a bombo y platillo de su nueva página web durante la Superbowl supero todas las expectativas y desbordo los servidores de Coca Cola mostrando un bonito mensaje de error durante un buen rato…

Después de haber trabajado durante semanas en la publicidad del evento, de todo el coste que pudo suponer el anuncio en la Superbowl, imaginaos el impacto que puede tener que los usuarios solo vean una página de error… Coca Cola no ha comentado en ningún momento el coste de esta caida, pero seguro que ha provocado perdidas muy abultadas, no solo por el coste de la web si no por la perdida de la oportunidad (recordar que la Superbowl es el evento más visto por los americanos en todo el año) y por la mala visibilidad de la marca de cara a los usuarios.

Vosotros tenéis en cuenta las pruebas de rendimiento y seguridad durante vuestra fases de testing? Hasta que punto? Realmente creéis que son suficientes?

Share and Enjoy:
  • Facebook
  • Twitter
  • Google Buzz
  • LinkedIn
Tagged with:  

4 Responses to Porque son importantes los requisitos no funcionales?

  1. Pello dice:

    Creo que a las pruebas de rendimiento no se les dan la importancia que se merecen, sólo se tienen en cuenta cuando ocurre un problema gordo en producción.

    Mi experiencia me dice que aunque hay muchas empresas que hacen pruebas de rendimiento, no siempre se les saca el máximo partido. Estas pruebas deberián ser una pieza clave de nuestro Test Plan y no deben pasarse por alto.

    Creo que algunas empresas no son conscientes del dinero que pueden perder si su web no está funcionando 24×7.

    Las pruebas de rendimiento no son siempre suficientes y los entornos en los que se ejecutan no son siempre los adecuados.

  2. Totalmente de acuerdo a todo lo que dices.

    Aunque muchas empresas realizan pruebas de rendimiento o seguridad, lo hacen como un suplemento, y no le dan la misma importancia que el resto de pruebas “funcionales”. Esto es porque generalmente no se ve como una amenaza en muchos casos, cuando realmente un error de estas características os puede hacer retirar un producto de la noche a la mañana.

    Otra cosa curiosa, es como se plantean las pruebas de rendimiento o seguridad. Mientras que las pruebas funcionales se suelen realizar con un diseño de tests bien razonado y con unos criterios de aceptación, curiosamente no se hace lo mismo con las pruebas no funcionales, improvisando o no definiendo bien lo que realmente se quiere, lo que provoca que no se ataquen en profundidad.

  3. almudena dice:

    Entrar en el proceso con rendimiento es complicado. Hay que convencer y evangelizar a negocio del peligro que conlleva una caída. Hay que concienciar que los recursos no son infinitos y que un buen uso de cpu, disco, red y demás conlleva siempre una mejora para no sólo la experiencia del usuario, si no que también un retorno de inversión. La premisa es que no sólo tiene que funcionar, si no que funcione de manera EFICIENTE. Esa es la clave.
    Luego hay muchos que creen que es “sólo darle al play”, que sabiendo una herramienta de performance ya eres un experto. No, un técnico de rendimiento tiene que conocer no sólo la herramienta, no sólo la arquitectura, también la aplicación y el negocio.La clave es el comportamiento de la aplicación sobre un sistema, no podemos olvidar ninguna de las dos variables.
    Lo anterior conlleva, que el coste de las pruebas de rendimiento en tiempo y en dinero es considerablemente mayor que el de pruebas funcionales, primero necesitas un experto y luego porque necesitas un entorno adecuado.
    Siempre puede pasar que aunque tengas el entorno, el tiempo, el dinero y el experto … se te haya pasado por alto una variable, una funcionalidad que nadie te había dicho, un parámetro configurado sobre producción, o una interpretación errónea de los datos de tus pruebas .

    Aunque apostaría la cabeza … que en el caso de coca cola ha sido exceso de celo de la gente de marketing y no un error del performance engineer 😀

  4. Tory dice:

    It’s good to get a fresh way of loonikg at it.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *