I am a bug!

On 19 abril, 2011, in Jokes, Técnicas, by twiindan

Hace un tiempo tuve la ocasión de tener entre mis manos un libro sobre Software Testing muy peculiar llamado “I am a bug”.

En este libro de Robert Sabourin se narra mediante viñetas que son los “bugs” dentro del software como si fuera un pequeño cuento para niños pequeños haciendo la lectura muy amena y divertida.

A parte también narra las tareas de los testers para minimizar estos “bugs” utilizando algunas técnicas de testing conocidas.

Dentro de la historia podemos ver algunas aclaraciones de los procesos de testing y calidad que afectan a estos pequeños bichillos que en ocasiones nos hacen la vida tan complicada dentro de nuestros productos.

El libro se puede comprar en la tienda de Amazon aunque el precio es un poco elevado. “I am a bug”.

 

Si queréis leerlo se puede realizar de forma totalmente gratuita en formato digital en la página web que Robert Sabourin ha creado para ello.

Os recomiendo que le echéis un vistazo para poder ver nuestro trabajo explicado de forma divertida y muy clara! Y ya de paso podréis explicarles a vuestros hijos mediante una bonita historia a que os dedicáis!

“I’m a bug” ebook.

Tagged with:  

Hace pocos días que Microsoft lanzo la primera actualización menor de su sistema operativo para moviles Windows Phone 7 y ya ha habido varias quejas por parte de los usuarios de errores en la actualización de la versión hasta tal punto de dejar colgado totalmente el telefono.

De momento Microsoft parece ser que ha bloqueado la actualización de su sistema operativo para algunos modelos que se han visto afectados como es el Samsug Omnia 7 y ha reconocido que existe un problema en el proce de actualización.

De este error se puede desprender la importancia de probar tu sistema en todas las plataformas posibles antes de lanzarlo oficalmente a los usuarios. Actualmente existen formas de realizar estas pruebas como utest que te permite que una cantidad de testers prueben las nuevas funcionalidades en varias plataformas antes de lanzarlo a un coste asequible.

Un gran traspies para Microsoft y su nuevo sistema operativo el cual ya no tuvo una buena acogida y que seguramente dañará mucho más la imagen que tenia.

Tagged with:  

Todo el mundo sabe la gran rivalidad que existe actualmente entre Apple y Adobe, debido a que esta primera ha criticado duramente sobre su principal fuente de ingresos Adobe Flash a la hora de entrar en el mercado del Iphone.

Realmente es exagerada la crítica que realiza el CEO de Apple Steve Jobs contra Adobe?

Si analizamos el porcentaje de desarrollo dedicado en la última versió de MacOS (10.6.5) vemos que el 42 % de los errores “fixed” en esta versión forman parte de la plataforma Adobe Flash.

Es decir 42 de cada 100 errores arreglados en esta versión tienen que ver con los complementos de Adobe dentro de MacOS, una cifra bastante escandalosa. Si lo miramos friamente vemos que se han arraglado los mismos errores para este complemento que para el resto del desarrollo del sistema operativo en general.

Vemos entonces que los motivos que tienen desde Apple para atacar a Adobe Flash es infundado y una vez más se ve la importancia de la calidad y testing de un producto para no dañar la imagen de la empresa. Quizás Adobe debe realizar una politica diferente respecto a la calidad de su producto si no quiere seguir viendose criticado por empresas como Apple entre otras, y más ahora que empiezan a existir alternativas como HTML5.

Via 9to5Mac.

Tagged with:  

Porque existen los errores?

On 12 octubre, 2010, in Articulos, Prácticas desarrollo, by twiindan

Una tarde de viernes, despues de una semana de trabajo y de vispera de puente, con una cerveza, unos cacahuetes y los compañeros del trabajo, que mejor escenario para tener una típica discusión entre developers y testers!

Aunque esta vez de la discusión aprendi un par de cosas que me han hecho reflexionar durante estos dias. En la discusión me comentaba un compañero de desarrollo que efectivamente a medida que un developer va ganando experiencia y aprendiendo, seguramente no necesite un tester para encontrar errores porque casi no los cometera. Como no, a mi me parece un razonamiento imposible ya que un developer como persona humana que es (al igual que un tester) siempre comenterá algún error en su código por muy bueno que sea.

Pero esto me hizo pensar en algo curioso… realmente el único motivo por el cual existimos los testers es porque el departamento de desarrollo hace mal ( o no óptimo)  su trabajo? Es culpable el departamento de desarrollo de todos los errores que encontramos?

Si para ti la respuesta es NO, entonces coincidimos perfectamente y por ese motivo me gustaria hacer una pequeña lista de las razones por las que pueden haber errores en el sistema:

  1. Errores al programar: Es el primero que nos viene a la cabeza y el inicio de la discusión con mis compañeros. Los humanos no somos perfectos y por lo tanto cualquier persona (developers o testers) cometeremos errores dentro del ciclo de vida del software.
  2. Cambios de última hora: Siempre existen, son como una lacra que sabes que tarde o temprano llegarán, son los temidos cambios a dos semanas de entregar una aplicación, unos cambios que en principio no afectan a “nada” y al final afectan a “todo”.  En todos los proyectos existen cambios, y generalmente no se le dan la importancia que merecen ya que muchos de ellos ni siquiera estan planificados.
  3. Errores de terceros: Siempre que utilicemos software de terceras partes como los entornos de desarollo o librerias externas a nuestro proyecto existe la posibilidad de que existan errores no contemplados. Estos errores son heredados por nuestro software y generalmente son dificiles de detectar en las fases de desarrollo.
  4. Errores de comunicación: Para mi la principal fuente de errores ya que esto conduce en parte al punto 2 (cambios de última hora). La comunicación es una de las partes más imporantes dentro del desarrollo del producto y de ella deriivan los requisitos, especificaciones, diseño… Por lo tanto un error de comunicación en algunas fases de proyecto pueden resultar fatales derivando en especificaciones incompletas o erroneas.
  5. Control de versiones: Generalmente otra fuente de problemas provienen del control de versiones de cada uno de los módulos de desarrollo. Aunque existen una gran variedad de aplicaciones o herramientas para realizar esta tarea es fácil que las malas prácticas dentro de desarrollo acaben con una versión antigua de algún módulo o algún componente erróneo.
  6. Malas prácticas de diseño: Otro de los grandes focos de errores, sobretodo en sistemas que son muy complejos o donde se utilizan nuevas tecnologías o nuevas arquitecturas. Generalmente se designa a un solo analista o arquitecto para realizar el diseño de los componentes de software, en lugar de realizar un brainstorming o realizar revisiones de diseño entre arquitectos para detectar errores tempranos.
  7. Malas practicas de codificación: Aun recuerdo el dia que se instauraron en los departamento de desarrollo las guias de buenas prácticas, un poco más y nos cortan el cuello!!! Pero un tiempo despues se ha comprabado que los errores detectados por las malas practicas han disminuido considerablemente, y ahora la gente de desarrollo se han acostumbrado llegando incluso dejar de lado todas sus manias a la hora de codificar o utilizar herramientas de debugging, analizadores, validarores… un buen programador no solo escribe líneas de código si no que las realiza de las mejor manera posible!
  8. Tiempo de desarrollo imposible: He querido dejar este para el último ya que creo que es de los pocos que estamos de acuerdo todos los departamentos. Cuando se planifica un proyecto de software, nunca he visto que se tenga en cuenta realmente el esfuerzo de este ya que generalmente quien lo planifica no sabe lo dificil que es realizar software. Esto se traduce en presión y stress sobre los departamentos de desarrollo, que incomodan a los programadores y les inducen a producir más errores. A parte como hemos comentado anteriormente (en el punto 2) los cambios que se piden desde el cliente en cualquier punto del proyecto muchas veces no se contemplan en la planificación al igual que la resolución de errores.

He nombrado ocho posibles factores a la hora de introducir errores, pero existen una infinidad más ya que miles de factores influyen en el ciclo de vida del software, aun así remarcar que no toda la responsabilidad de la introducción de errores es por parte de desarrollo ni mucho menos, si no que los errores se introducen en todas las fases desde los requerimientos, diseño… hasta los propios testers que como el resto del mundo, tambien somos humanos!(con nuestro corazoncito, y nuestra alma)

Conoceís algunos factores más que puedan influir en la introducción de errores¿?

Reportando bugs

On 9 junio, 2010, in Consejos, by twiindan

Uno de las muchas discusiones que se tienen entre los departamentos de calidad o testing y los de desarrollo es a la hora de reportar los bugs o fallos de la aplicación sobre la que estamos realizando las pruebas.

Unos consejos para realizar el reporte de los bugs encontrados serían:

– Se muy preciso a la hora de escribirlos, no des muchos rodeos y explica de forma precisa de que se trata el error.

– Has de ser muy claro cuando los reportas para que el departamento de desarrollo no tenga dudas.

– Detalla todo el procedimiento necesario para llegar a la condición de error. De esta manera te ahorraras el tener que explicarles como pueden reproducirlo.

– Explica siempre un solo bug por cada reporte que realices.

– Indica las versiones y precondiciones de las que has partido.

– Puedes escribir también tus conclusiones o opiniones sobre porque puede ocurrir pero indica bien claro que son sospechas.

– Añade todos los logs y imagenes que sean necesarios para explicar con claridad y detalle el error.

– Indica si es posible cual debería ser el comportamiento correcto, indicando la especificación o el diseño pertinente.

Son unas pequeñas pautas que nos ahorraran mucho tiempo y disgustos a la hora de tratar con los departamentos de desarrollo.

Happy reporting!

Tagged with: