Archivo por meses: agosto 2012

Fallos: la importancia de las pruebas.

Hace unos días, hablaba con un viejo amigo que se ha especializado en el área de Pruebas de sistemas (en LinkedIn podéis ver su perfil por si os interesa) y hablando de salarios me comentaba lo difícil que resultaba, habiéndose especializado en ese área, conseguir un salario alto.

 

Esto me hizo pensar en que quizás el problema podría estar en que si de por sí en nuestro sector la labor de Programador no estaba muy valorada, en el caso de Ingenieros de Pruebas la cosa era a veces incluso peor.

Lo curioso es que para mí, que llevo ya un tiempo en este mundillo, tan importante me resulta una tarea como otra, ya que ambas son parte del mismo proceso de Diseño y Desarrollo de Software. Y si la programación debe de conseguir implementar correctamente los requisitos de usuario, tanto en funcionalidad, operativa como en rendimiento, las pruebas deben de ser las que validen que así se ha hecho, además de validar (según la aplicación que estemos diseñando) cosas como la seguridad y estabilidad del sistema resultante.

 

Todo esto me hizo recordar una noticia que había leído hace muy poco (el 2 de agosto pasado) sobre las pérdidas sufridas por la firma de corretaje Knight Capital, de hasta 440 millones de dólares, por un error informático:

“Este problema estuvo relacionado con la instalación de un software para realizar transacciones en los mercados y que provocó que Knight enviase numerosas órdenes erróneas de valores cotizados en la bolsa de Nueva York (NYSE)”, explicó hoy la empresa de Nueva Jersey en un comunicado.

 

Como podéis ver en este caso concreto, un fallo informático (aunque detrás de todo fallo informático está siempre un fallo humano, como bien dice Fernando Suárez)  ha supuesto un enorme descalabro en las cuentas de la empresa, y la pérdida de valor bursátil al día siguiente.

Y aunque no haya datos en este caso sobre el ‘error informático’, no estaría de más revisar cuál ha sido el proceso de diseño-desarrollo-pruebas del nuevo software, para establecer porqué no se detecto en las pruebas realizadas, o si es que realmente alguien decidió que no era necesario realizar tales pruebas (o no tenían que ser especialmente exhaustivas) pensando en ahorrar unos cuantos miles de dólares.

 

Esto, que a toro pasado parece algo evidente y lógico, por desgracia aún a día de hoy no está debidamente valorado, muchas veces por quien desarrolla el software, otras muchas por quien será el usuario de dicho software y paga la factura.

O sencillamente, las prisas por llevar a producción un sistema o no tener el entorno adecuado de pruebas, terminando provocando que lo que parecía una buena solución de ahorro pase a ser el motivo de pérdidas económicas.

 

Y es que según algún estudio, los fallos informáticos están a la orden del día y pueden suponer hasta 75.000€ de pérdidas por hora, algo que en tiempos de crisis y necesidad de optimizar y mejorar nuestra productividad no es algo como para no tener en cuenta.

Pérdidas que se pueden producir tanto por operaciones incorrectas, como en el caso anterior, como por número de horas de trabajo perdidas porque esa nueva versión software no funciona o lo hace a un rendimiento inferior al esperado.

Aunque también hay casos mucho más graves, como los que he encontrado en esta entrada en el blog ‘Pensamientos Computables’ donde se mencionan casos de fallo Software que han conllevado muertes humanas por mal funcionamiento.

Y por supuesto, no nos olvidemos de las pruebas relativas a la seguridad de aplicativos que se usen a través de internet, para evitar que algún intruso pueda acceder al sistema y liarla.

 

Por todo ello, en la Ingeniería del Software y según recogen las distintas metodologías de software, el proceso de pruebas es una parte más del proceso global, y por tanto nos lo debemos tomar muy en serio para asegurar la calidad del SW desarrollado y la menor tasa de errores en entornos de producción.

 

 

Y por eso mismo, asegurarnos de contar con la gente adecuada para realizar tanto el diseño de los casos de pruebas, como para montar los entornos de prueba adecuados (reproduciendo los entornos de producción finales), dotándoles de las herramientas adecuadas para poder realizar los distintos tipos de pruebas, evitando así llevarnos sustos innecesarios.

 

Si en algún momento nuestro proyecto requiere ahorrar en costes, la solución pasa por buscar el ahorro optimizando el trabajo o usando mejores herramientas, pero nunca eliminando partes necesarias del proceso de desarrollo o pensando que ‘cualquiera puede probar‘.

Truco: Proxy on / Proxy off

Los que solemos llevarnos el portátil del trabajo a casa tenemos un problema común, habilitar y des-habilitar el proxy de la empresa en el portátil.

Si usais IE, Chrome o si en Firefox le ponemos que use la configuración del proxy del sistema, el tema pasa por entrar en las opciones de IE, ya sea desde el propio IE o desde las opciones que Chrome que invocan el mismo dialogo de IE.

Harto de este rollo cada vez que voy y vengo, me puse a buscar una forma de hacerlo por línea de comando. Lógicamente este valor debe estar en el registro, así que lo primero era buscarlo, por medio de la utilidad REG que trae windows:

reg query HKCU /v proxy

Salieron unos cuantos resultados, pero el mas probable era este:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings
ProxyEnable REG_DWORD 0x1

Una vez comprobado que este era el valor correcto, ya solo era cuestión de hacer un par de scripts (si teneis curiosidad por los parametros, usad REG /?):

proxy_on.bat
reg add  "HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings" /v ProxyEnable /t REG_DWORD /d 1 /f


proxy_off.bat
reg add  "HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f

Listo. (ya solo me falta que en el arranque de windows un script mire mi IP y des-habilite el proxy si no es la de la empresa, pero eso ya será otro día).