February 2008 - Artículos
Vídeo íntegro de la conferencia de Bill Gates en la Universidad de Stanford (Palo Alto, CA) en la que resalta el papel de los estudiantes en el futuro de la informática, como portadores de nuevas ideas y aceleradores del proceso innovativo en la industria del software.
Thanks Mr. Gates
El proximo jueves 21 de Febrero a las 18h tendrá lugar en el Salón de Actos de la Escuela Politécnica Superior de Alicante una charla sobre Microsoft Robotics Studio y robótica en general.
Los ponentes seremos Andrés Pérez y un servidor, y llevaremos a cabo demos "live" con un robot Lego MindStorm. Como siempre al tratarse de una charla del Club .Net de la Universidad de Alicante, el contenido de la misma va enfocado a un público estudiantil. No obstante, también como siempre, estaremos encantados de que cualquier persona de fuera de la universidad se acerque a hacernos una visita.
Prometo que será divertido y, por supuesto, muy didáctico 
Ya está aquí Microsoft DreamSpark, una iniciativa de Microsoft para que los estudiantes de España y 9 países más (Alemania, Bélgica, Canadá, China, Finlandia, Francia, Suecia, UK y USA) tengamos acceso a software de Microsoft gratuitamente.
Hasta la fecha de hoy, dependíamos de que nuestros centros (universidades, etc) tuvieran Academic Alliance (el cual sigue existiendo), pero desde hoy tan sólo necesitaremos que nuestro centro esté afiliado a RedIRIS (hay más de 300 centros asociados, podemos verlos aquí) o disponer nosotros mismos de una tarjeta internacional de estudiante (ISIC) para poder acceder a descargas directas de software a través de la web de Channel 8.
El software disponible desde ya es:
-
Microsoft Visual Studio 2008 Professional Edition
-
SQL Server 2005 Express
-
SQL Server Developer Edition
-
Virtual PC 2007
-
Visual Basic 2005
-
Visual C++ 2005
-
Visual C# 2005
-
Visual J# 2005
-
Visual Studio 2008
-
Visual Web Developer 2005
-
Visual Studio 2005 Professional
-
Microsoft Expression Suite: Blend, Design, Web, Media y Encoder
-
Microsoft Windows Server 2003 Standard Edition
-
XNA Game Studio 2.0 y licencia XNA Creators Club por 12 meses
Más información disponible en la propia web de Channel 8: What is DreamSpark? y FAQ
Además, puedes ver al propio Bill Gates presentando este programa en una entrevista concedida a Channel 8:
También, en los próximos días dispondremos de tutoriales, screencasts y gran cantidad de recursos de formación sobre el software disponible en Dream Spark a través de la web de Channel 8! 
Así es como se deben hacer los negocios:
Padre: Quiero que te cases con la chica que yo elija...
Hijo: Elegiré yo mismo a mi futura esposa, papá.
Padre: Pero la chica que yo he elegido es la hija de Bill Gates.
Hijo: Bueno, en ese caso... OK.
Al día siguiente...
El padre se reúne con Bill Gates.
Padre: Tengo el marido ideal para su hija.
Bill Gates: Pero mi hija es demasiado joven para casarse!!
Padre: Pero el candidato para casarse con su hija es el vicepresidente del Banco Mundial.
Bill Gates: Bueno, en ese caso... OK.
Por último, el padre se reúne con el Presidente del Banco Mundial:
Padre: Voy a recomendarle un candidato para ser vicepresidente de su banco.
Presidente: Yo ya tengo más vicepresidentes de los que me hacen falta!
Padre: Pero este candidato es el yerno de Bill Gates.
Presidente: Bueno, en ese caso... OK!
PIM Backup es una herramienta gratuita que nos permite hacer backups de toda la información almacenada en nuestros SO Windows Mobile 2003 SE, Windows Mobile 5.0 y 6.0
El programa nos permite configurar qué tipo de información queremos almacenar: contactos, citas, tareas, mensajes, listas de llamadas, opciones de marcado rápido, sistema de archivos... Una vez hayamos realizado el backup, éste se almacena en la tarjeta de memoria del dispositivo, de forma que podamos llevarlo a otros dispositivos sin ningún tipo de problema.
Además, es posible configurar la opción de "autobackup" de forma que podemos olvidarnos de realizarlo y que él mismo guarde una copia de seguridad de nuestro SO Mobile de manera periódica.
¿A qué esperas para probarlo?
Vídeo documental que cuenta la verdadera historia de cómo es la vida en el Cuartel General de Microsoft. Todo aquello que siempre quisimos contar y nunca pudimos, ahora ve la luz!
Como bien ha dicho uno de los creadores del vídeo en on10.net: "Este vídeo jamás habría sido creado sin unas cuantas latas de cerveza..."
No dejéis de ver este vídeo para estar al tanto de lo que se cuece por aquí
A primera vista, podría dar la sensación de que es más sencillo romper que crear. Reventar códigos fuente debe ser, sin duda, mucho más sencillo que crearlos. Sin embargo, no es así.
¿Por qué?
Si consideramos el Software Testing como un proceso metódico y disciplinado (como deberíamos hacer), dicho proceso requerirá el mismo esfuerzo y dedicación que el desarrollo de dicho software. En realidad, el Software Testing implica una serie de habilidades similares a las del developer, pero con algunos matices diferenciadores.
Como habréis deducido a estas alturas de la serie, la mayoría de compañías actuales con un cierto grado de madurez consideran el Software Testing como un rol imprescindible y necesario como complemento del rol de developer. Por desgracia, aún existen muchas compañías en las que esto no es así. Compañías en las que la filosofía coincide con la expuesta en una de las anteriores entregas:
Soy mejor cuanto menos tardo en generar artefactos, y una vez los haya generado realizaré una serie de pruebas con las que quedaré satisfecho si no encuentro fallos: ¡Qué gran developer estoy hecho!
En el sistema competitivo del mercado actual, este segundo tipo de compañías no permanecen en escena durante mucho tiempo: Los clientes deciden no comprar esos productos plagados de bugs!!
Una buena o mala planificación de tests puede llevar una compañía al éxito o reducirla a cenizas!
Con esta perspectiva, deberíamos considerar una decisión crítica la buena elección de profesionales dedicados al proceso de pruebas. Pero...
¿Qué características debemos considerar vitales en un tester?
- Capacidad para "imaginar" soluciones a problemas existentes. Un tester debe ser capaz de poder realizar hipótesis con un grado de fiabilidad aceptable acerca de la causa de un error cuando éste se produce. En esta fiabilidad influye el hecho de que el software debe, por un lado, conocer los principios de arquitectura y diseño que se han seguido en la creación del software, así como tener un dominio bastante amplio de la tecnología con la que ha sido elaborado, del lenguaje, para poder "destripar" el código que tiene entre manos y también de los escenarios de uso posibles para dicho software, de modo que sepamos si el error observado corresponde a un caso de uso más o menos frecuente y, a su vez, crítico del sistema.
- Un tester es un explorador nato: No tienen ningún miedo por adentrarse en terrenos y situaciones desconocidas. Un buen tester está deseando obtener la última versión beta de un cierto producto para explorar sus entrañas y, a ser posible, ser el primero en encontrarle fallos.
- Un tester es incansable: Un tester SIGUE BUSCANDO. Estas palabras resumen la filosofía de explorador de un tester. Debo confesar que frente a mi mesa de trabajo tenía un folio clavado en un panel de corcho con dos palabras en inglés a tamaño 48, negrita y subrayadas: KEEP TRYING!
- Perfeccionistas con criterio: La perfección de un producto radica en el equilibrio perfecto entre fiabilidad y coste. De nada nos sirve un software desarrollado en tiempo récord si tiene muchos fallos; a su vez, tampoco nos resulta útil un software fiable al 99'9999% si el coste de su desarrollo es estratosférico y por sí solo supone un balance negativo superior a las pérdidas que un producto "parcialmente" imperfecto puede conllevar.
- Creatividad: Probar lo extraño no es suficiente para un tester. Probar únicamente lo obvio es pecado capital.
- Buen criterio economista: Un tester debe ser capaz de decidir qué tipo de bugs buscar, estimar cuánto tiempo debe dedicar a seguir el rastro de un determinado bug o saber distinguir un bug real de algo que tan sólo es un "comportamiento disperso" de la aplicación.
Hasta aquí, definiríamos las características necesarias para la caza de bugs. Ahora bien, una vez que han sido detectados por el tester: ¿Qué características son deseables en un tester para continuar con el proceso de testing (localización de bugs + reporte de bugs + establecer prioridad de la solución + asegurarse de que han sido resueltos) adecuadamente?
- Diplomacia y capacidad de expresarse con tacto, aún cuando lo que se está haciendo es criticar el trabajo de otros... A pesar de tratarse de una crítica constructiva y enfocada a mejorar el producto final, no es algo sencillo. Uno de mis compañeros de equipo con más experiencia en el rol, me resumió esta cualidad con la siguiente frase:
"Hay que saber cómo dirigirse a un developer para resaltar defectos de lo que él ha hecho. A nadie le gusta que le digan que un hijo suyo es feo..."
- Persuasividad: Hay que ser capaz de acotar bien el bug expuesto y, realmente, convencer al resto de miembros del equipo de que dicho fallo DEBE ser resuelto a la mayor brevedad posible.
Como véis, existen unas cuantas características que diferencian a un tester de un developer, discusión que previamente ya habíamos tenido por Geeks.
¿Qué características os parecen fundamentales en un tester a vosotros?
Quedan escasas horas para el inicio de la primera edición de la Campus Party que se celebra fuera de su país de origen, España. Uno de los mayores eventos relacionados con internet, las nuevas tecnologías y las comunidades de usuarios ha decidido irse de viaje, y ni más ni menos que ha escogido la ciudad de Sao Paulo, en Brasil.
Ya está todo preparado para que en cuestión de horas, se ponga en marcha esta gran fiesta. Para muestra de los preparativos este vídeo!!
Seguiré informando!
El proceso de pruebas de software es una tarea técnica, precisa del dominio del lenguaje de programación en el que el artefacto a probar fue generado, también del conocimiento necesario para comprender la arquitectura del sistema implementado y de las implicaciones de tipo lógico que su diseño pueda suponer. Adicionalmente, el tester deberá conocer los lenguajes y herramientas que ha de usar para llevar a cabo este proceso de pruebas.
No obstante, el Software Testing es algo más que una tarea técnica. Es necesario un cambio de mentalidad importante por parte del tester. Consideremos la siguiente definición de Software Testing:
"El proceso de pruebas consiste en demostrar que los artefactos generados están libres de fallos"
"El proceso de Testing tiene como objetivo demostrar que el software realiza correctamente aquellas tareas para las que fue diseñado"
¿Es esta definición correcta? Obviamente NO. El proceso de pruebas no va orientado a demostrar la ausencia de fallos en el software, sino más bien a todo lo contrario: encontrar cuantos fallos existan, por escondidos que se encuentren o difícilmente reproducibles que sean.
Como ya comenté en la introducción de esta serie de posts, la gran mayoría de nosotros tiene la tendencia a entender la creación de software como un proceso únicamente constructivo. Soy mejor cuanto menos tardo en generar artefactos, y una vez los haya generado realizaré una serie de pruebas con las que quedaré satisfecho si no encuentro fallos: ¡Qué gran developer estoy hecho!
Cuando un artefacto llega a manos de un tester, su función dentro del proceso de ingeniería software es añadir valor al producto sobre el que está trabajando. ¿Esto qué significa? Una aproximación válida al concepto de valor añadido por un tester podría ser "incrementar la fiabilidad del software". Esto se consigue encontrando la mayor cantidad de bugs posibles, realizando un informe adecuado de los mismos, establecer la prioridad de resolución para cada uno de ellos... Otro factor que marca la mayor o menor validez de un tester consiste en la pregunta: "¿Hasta cuándo debo de intentar encontrar bugs?", a dicha pregunta le dedicaremos una entrada completa más adelante, pero básicamente podemos establecer que, obviamente, la respuesta no puede ser "hasta que hayamos probado todas las posibles ejecuciones del programa y estemos seguros de que no existe ningún bug oculto más". ¿Y por qué no? Principalmente, cuando consideramos artefactos suficientemente complejos, resulta imposible abarcar todas las posibles entradas y salidas posibles, todas las posibles trazas de ejecución, así como todas las situaciones de "incertidumbre" que se puedan producir.
Por tanto, una definición más acertada acerca de lo que es el Software Testing podría enunciarse de la siguiente forma:
"Software Testing es el proceso de ejecutar un programa con la intención de encontrar fallos"
Una vez hayamos sido capaces de llevar a cabo este cambio de mentalidad, podremos comenzar con nuestra labor de tester de una manera más efectiva y beneficiosa dentro del proceso de Ingeniería del Software. En el próximo post os hablaré acerca de las condiciones que debería tener un buen tester.
Tras unos cuantos meses deseando dar comienzo a esta serie de posts, por fin me he decidido/he encontrado algo de tiempo para organizar por escrito estas ideas difusas que rondaban por mi mente e intentar expresarlas de manera que sean entendibles. Seguramente habréis oído esa célebre frase que dice "Si no eres capaz de explicarlo, no eres capaz de hacerlo", algo así me sucedía a mí.
Os cuento mi planning de posts en esta serie acerca de Software Testing: Creo que estaréis de acuerdo conmigo en que la mayoría de posts que tenemos la suerte de leer en Geeks.ms versan acerca de Desarrollo de Software, perspectiva Developer 100% (o 99%, como queráis, jeje). Esto es, la perspectiva de la Ingeniería de Software sobre la que podríamos pasarnos días y noches intercambiando ideas sin parar, pero que resumíré de manera osada como "Entender el desarrollo de aplicaciones centrándonos en la construcción de una serie de bloques". Lo sé, es muy osada la definición y espero no me tiréis a la hoguera por ello...
Ahora bien, ¿qué papel juega el tester en este proceso? El tester vive por y para encontrar fallos en estos bloques que el developer crea. Debe hacer todo lo posible por romper los bloques creados por el developer, y no debería sentirse satisfecho si tras horas de trabajo es incapaz de realizarlo...
Partiendo de esta vaga introducción, me propongo revisar algunos de los conceptos esenciales para comprender mejor el rol de un tester (o Ingeniero de Software de Pruebas, hablando en términos rimbombantes). Estos conceptos no sólo son aplicables a un tester puro, sino a cualquier rol que actúe en la industria del software y que en algún momento deba realizar pruebas, o bien planificar dichas pruebas tanto en su descomposición en diferentes tareas, como en su presupuesto (temporal y de asignación de recursos).
Algunos de los posts que veréis por aquí en las próximas semanas son:
-
¿En qué consiste el proceso de pruebas de software?
-
¿Qué cualidades debe tener un buen tester?
-
La interacción del tester con el resto de roles dentro del proceso de ingeniería del software.
-
Creación de equipos de testing: Roles internos, responsabilidades, cualidades idóneas de cada uno de los miembros.
-
Varios posts sobre estrategias de Software Testing en distintos escenarios, tanto a nivel teórico como explicación de algunas herramientas concretas que nos ayudarán en nuestras tareas.
-
Buenas prácticas de Software Testing.
Espero que sean de vuestro agrado... Que tiemblen esos malditos bichos que vamos a por ellos!!