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:  

Resumen QA&TEST 2010 (second day)

On 1 noviembre, 2010, in Conferencias, by twiindan

Despues de un muy buen comienzo de las jornadas, llego el segundo día con unos contenidos igual de interesantes que el primer día.

El día empezo con la Keynote de Tammy Noergaard donde explico los principales errores que cometemos dividido en varios niveles, desde errores que se producen por parte de planificación o dirección (como no tener en cuenta los deadlines a la hora de planificar, o escoger el lenguaje de programación correcto a la hora de diseñar y programar la aplicación, o no definir la estrategia de testing desde el primer día). Una keynote muy instructiva donde se nos recordaba errores que siempre cometemos y que conviene siempre tener presentes (creo que me haré una lista y la colgaré en mi sitio para no volverlos a cometer).

Seguidamente se realizaron varias presentaciones dentro de dos tracks (Testing Safety Critical Systems y Requirment Management). Dentro del primero destacar la conferencia sobre análisis estático, y varios problemas o errores que pueden surgir si este no se realiza.  También una gran presentación por parte de Bryan Bakker sobre diseño de tests automáticos emfatizando sobretodo la parte de test de integración, generalmente otro tipo de testing un poco olvidado (por lo menos en mi organización).

Despues de todo esto un descanso bien merecido y una gran comida a base de varios pescados en el restaurante del Palacio de Euskalduna.

Ya con el estomago lleno, volvian las conferencias de nuevo con dos tracks diferentes (People in Software Testing y Testing Techniques & Testing Proccess). Yo me tuve que quedar en la primera de ellas ya que mi conferencia estaba en este track.  Muy destacable el toque de humor de Tony Simms a la hora de narrar los diferentes problemas que podia tener un project manager y que generalmente no tenemos en cuentaa. Seguidamente una descafeinada presentación en la que estaba totalmente de los nervios! Despues de todo este tiempo, fue el momento, 40 intensos minutos donde explique las funciones que se realizan dentro de Diagnostic Grifols, por suerte los nervios se fueron poco a poco y en general la gente por lo menos no se dormia. Una vez ya finalizado, 2 preguntas (una de ellas con un poco de mala leche) y un gran aplauso por la presentación!

Para acabar la jornada se realizó un interesante debate donde hubo varios temas centrales como las metodologias ágiles o las certificaciones, dos temas muy candentes actualmente.

ya acabada la jornada, muchas preguntas sobre varios procesos de mi presentación por parte de varias personas y a descansar al hotel.

Ya por la noche una interesante cena de gala donde los organizadores nos regalarón un buen menu y unas cuantas copichuelas en un bar de copas, lo ideal para soltarse un poco más la lengua y acabar de perfeccionar el ingles! Eso si, no muy tarde a dormir que aun faltaba el tercer día!

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¿?

La Real Federación Española de fútbol ha publicado en su página web oficial el calendario oficial para la temporada 2010/2011 un día antes que se realizará el sorteo oficial (se realizará mañana).

Según la federación no se había percatado del error y comentan que el sorteo se celebrará de forma oficial durante el día de mañana por lo que los datos publicados no tienen niguna validez.

Parece ser que el problema ha venido causado por un error informático ya que se estaba gestionando la presentación del nuevo calendario de la Liga 2010/2011 con un nuevo programa de gestión de contenidos.

Este es un ejemplo de una mala gestión de los entornos de prueba en una aplicación web, o seguramente de un mal uso de la nueva herramienta de gestión de contenidos por parte de los desarrolladores web. Siempre que debamos realizar una serie de pruebas antes de lanzar una aplicación o en este caso una página web se han de realizar en un entorno de pruebas y nunca en un entorno de producción para que no se produzcan errores como el ocurrido.

Por si alguien tiene curiosidad, según el calendario el Barcelona-Real Madrid se jugaría el 7 de Noviembre y la vuelta el 30 de Marzo.

Tagged with: