Un error informático de la entidad Bankia deja a cientos de trabajadores de distintas empresas valencianas sin cobrar su nómina, según informó Levante-EMV la semana pasada. El fallo, finalmente, se pudo solucionar el martes pasado. Bankia ha reconocido que la incidencia se detectó en la plataforma informática debido a “un fichero de clientes remitido por la Seguridad Social“.

Parece que hoy en día es una práctica muy común de muchas empresas el usar la disculpa de “debido a un error informático no podemos…” y ya está, aquí no ha pasado nada y las empresas parecen no tener ninguna responsabilidad. Hace un par de meses había escrito en otro post la desagradable anécdota que me pasó durante la compra de un billete online con edreams, un “error informático” me dejaba sin vuelo a México (tuve que volver a comprar otro y pagar 400 euros más).

Pues bien, en esta ocasión me ha tocado recibir el susto de los organizadores de la “Zurich Maratón de Barcelona“. Me inscribí al evento hace un par de meses y hoy he recibido un email muy raro de la organización que decía:

“Hemos detectado un error informático que informaba, a muchos de nuestros clientes, con el mensaje de: “Gracias por participar. En el plazo de 7 días te informaremos si se ha realizado satisfactoriamente tu inscripción a la “Zurich Marató de Barcelona 2012″ días después del mail de confirmación que adjuntamos más abajo. Por favor, si es su caso, disculpe las molestias.”

Es decir, debido a un error informático la gente que ya estaba inscrita y confirmada recibía un email como este en el que te indican de nuevo que en un plazo de 7 días te dirán si estás inscrito o no. El caso es que parece ser que finalmente estoy inscrito (aunque tendré que volver a confirmarlo más adelante por si acaso), pero por un momento he pensado que no habían aceptado mi solicitud.

Todo esto no ha hecho más que alimentar mi curiosidad, así que he hecho una búsqueda rápida y me he encontrado con un par de páginas interesantes, una es de los “Fallos informáticos mortales” y el otro el de “Los diez errores informáticos más graves de la historia“. Ambos artículos destacan el Acelerador médico Therac 25, un acelerador que podía emitir electrones o un haz de rayos X…pues bien, debido a un error de programación cinco personas murieron entre 1985 y 1987.

Referencia:
http://www.20minutos.es/noticia/1268079/0/error-informatico/bankia/nominas/

He querido escribir este “post” a raíz de la presentación de Toni Robres en el pasado VLCTesting de Valencia (presentación titulada “¿Es posible encontrar al tester perfecto?“) en la que hablaba, entre otras cosas, sobre la importancia de las “Soft Skills” en nuestro sector. Tampoco quiero entrar en el detalle teórico de todas ellas ya que no soy ningún experto en la materia, sino que simplemente me gustaría dar mi perfectiva personal y como me han ayudado en mi día a día como Quality Assurance.

¿Qué son las Soft Skills? se considera “Soft Skills” al conjunto de capacidades que permiten que un profesional se relacione mejor en el trabajo, que pueden ir desde el liderazgo, trabajo en grupo, habilidades de comunicación, habilidades para resolver problemas, habilidades para trabajar bajo presión o habilidades para adaptarse al cambio (Change Management)…etc…es decir, habilidades sociales. Mientras que las “Hard Skills” serían todas aquellas habilidades que hemos aprendido durante nuestra formación académica…como lenguajes de programación, metodologías de testing, diseño estructurado, diseño de procesos, UML…etc.

Partiendo de esa definición normalmente un “Test Engineer”, “Test Manager” o “Quality Assurance” tiene que trabajar en equipo. Es raro que trabajemos solos o aislado, siempre perteneceremos a un equipo…un equipo formado por personas (analistas, project managers, arquitectos, desarrolladores, product managers..etc, etc). Por tanto debemos tener en cuenta:

• Como profesionales y responsables de la calidad de un producto tenemos que ser políticamente correctos. Tenemos que tener mucho tacto a la hora de hablar con los equipos de desarrollo, a nadie le gusta que le digan que su trabajo está mal hecho o que lo están haciendo de forma incorrecta, por tanto debemos de tener mucha empatía y usar nuestras “Skills” de comunicación correctamente para que nadie se sienta ofendido o atacado.

• La calidad no debe ser impuesta. Lo peor que podemos hacer como Test Managers o como QA Managers es imponer la calidad sin más, simplemente porque sois los responsables de la calidad del proyecto. Con ello lo único que conseguiréis es que la gente os pierda el respeto y no os haga caso. Una vez más las “Soft Skills” son nuestra principal arma.

• Es muy importante aprender a gestionar los cambios. Los proyectos cambian continuamente, es un hecho, debemos vivir con ello y gestionar esos cambios de la mejor manera posible. Un cambio tiene como objetivo que las cosas sean diferentes, así que cuando ocurre un cambio las personas pasan por diferentes fases: Negación – “Esto no es relevante para mi trabajo.”, Enfado / Resistencia – “Yo eso no pienso hacerlo”, Exploración – “Tal vez sea interesante y lo pueda usar en mi trabajo diario”, Compromiso – “Esto funciona para mí y para mis compañeros.”

  

  Pues bien, siempre que hagáis mejora continua, implantación de nuevos procesos, implementación de herramientas…etc, os encontraréis con esta curva. La clave es que no todos pasamos por la curva de misma manera, es decir, unos lo llevan mejor que otros. ¿Qué podemos hacer al enfrentarnos a esta situación?:

  1) Siempre que implantéis alguna mejora hacerlo en un proyecto piloto. Seleccionar un proyecto estable, que no sea demasiado complejo. Esto permitirá a la gente adaptarse mejor al cambio y asimilarlo lentamente. Un proyecto piloto nos permite obtener datos al final del proyecto y ajustarlo a las verdaderas necesidades de la gente, es decir, aterrizar lo que en un principio era todo teórico en algo que realmente es la realidad del proyecto.

  2) Identificar a los líderes y buscar aliados. Convencer de la necesidad de un cambio no es tarea fácil, se necesitan grandes dosis de liderazgo. Para ello es necesario que identifiques a las personas que son claves en la organización y explicarles e involucrarles en el cambio. Si esas personas “compran” el cambio te ayudarán a influir sobre otras personas.

  3) De la misma forma que has identificado a los posibles aliados, identifica también a las personas que crees que pueden “dinamitar” el cambio. Esta es una barrera que debe ser eliminada si queremos conseguir nuestro objetivo. Si las personas que intentan dinamitar el proyecto tiene una gran influencia en la organización, tenemos un problema. ¿Cómo resolverlo? Podrías involucrarles en el proyecto, que se sientan partícipes, pedir su feedback, escuchar sus inquietudes…creo que esa es la mejor manera de ganárnoslos y ponerlos de nuestro lado. En caso de no ser influyentes, yo los aislaría, tarde o temprano verán que para el resto de personas el cambio es positivo y ellos no tendrán más remedio que ceder en su empeño y unirse al cambio.

  4) Como dije en el punto anterior, haz partícipe en el cambio a la gente que no sólo puede aportar valor sino que además puede influenciar al resto. Esta personas que probablemente sean de poco influencia, nos pueden ayudar mucho haciéndoles partícipes de nuestra iniciativa. Se sentirán escuchados y estarán motivados a asumir y liderar el cambio.

  5) Comunica, comunicar y comunicar el cambio. Al principio, durante y después del cambio. Que la gente esté informada en todo momento de lo que está pasando, sean del nivel jerárquico que sean, desde el manager hasta los programadores. Que luego no te digan eso de: “yo no sabía nada, a mí nadie me había dicho nada”. Haz sesiones informativas con cada uno de los equipos y responde sus dudas o inquietudes.

• Habilidades comunicativas, hablar en público. Es importante quitar el miedo a hablar en público. Como responsables de la calidad de un producto os encontraréis en la situación de que tenéis que dar formación a los miembros de vuestro equipo en una nueva herramienta, o que tendréis que explicarles un nuevo proceso o la aplicación de una nueva metodología. Realmente somos negociadores, tenemos que convencer a la gente de los beneficiosos de la calidad y tenemos que sonar convincentes en nuestras explicaciones. Como comentaba en uno de los puntos anteriores, la calidad se tiene que vender y no imponer.

Estos son sólo algunos ejemplos que muestran como las “soft skills” nos pueden ayudar en nuestro día a día. En resumen, si aún no has empezado a trabajar tu “Soft Skills” ahora es el momento. Realmente lo agradecerás a lo largo de tu carrera profesional.

El último número de la revista “Testing Experience” nos habla sobre el “Futuro del Testing” en más de 30 artículos. La verdad que este número es bastante interesante y os invito a que le echéis un vistazo, ya que son artículos escritos por gente de diferentes países y es curioso ver las diferentes puntos de vista. Podréis encontrar bastantes artículos que hablan sobre “Agile”, “Agile” y más “Agile”. En mi humilde opinión la metodoligías ágiles están muy bien pero no son únicamente el futuro del testing. Hay proyectos en los que el “Agile Testing” tiene sentido y otro en el que no. Las cosas no son blancas o negras, todo depende del sector y la tipología de proyectos. Unas veces usaremos metodologías ágiles y otras veces metodologías tradicionales.

Por otro lado encontraréis artículos apocalípticos, que hablan sobre el fin del testing y que el futuro del testing es muy negro. Personalmente creo que según pasan los años y el desarrollo del Software cambia el testing tiene que adaptarse a ese cambio y seguir aportando ese valor añadido que todos los jefes de proyecto y clientes andan buscando. Nuestra métodos de testeo tendrán que cambiar, los roles serán diferentes…probablemente tendremos que ser más versátiles…pero creo que mientras los que desarrollen Software sean personas el testing siempre será necesario.

Destacaría el primer artículo, escrito por Bob Van Burgt & Iris Pinkster-O‘Riordain, sobre “Lean Test Management“…es decir, los conceptos de Lean Management aplicados al Testing. En el último expo:QA tuve la oportunidad de asistir a la ponencia de Iris sobre este tema. A mí me parece muy interesante, aunque tampoco añade nada nuevo al testing, simplemente nos dice que debemos que estar continuamente mejorando nuestros procesos de testing, suprimir lo que no sirve, lo que no nos aporta valor y así de esta forma ganar eficiencia. Recomiendo su lectura. También destacar el artículo de Debra Forsyth & Dave Lloyd, “Collaboration Equals Quality“.

En resumen, mi percepción sobre el futuro del sector en nuestro país es que aún nos queda mucho camino por recorrer. Tenemos grandes profesionales en el sector que no tienen nada que envidiar a los de otros países como Inglaterra o Holanda (donde se supone están los grandes gurus). El problema es que nosotros no nos damos tanto publicidad como se dan ellos, no escribimos libros y no nos animamos a participar en conferencias internacionales. Solamente tenemos que romper esas barreras.

Por otro lado, como comentaba antes, tendremos que ser más versátiles, más todo terreno…y debemos adaptarnos a los cambios. Ya no vale un tester que sólo ejecuta, el mercado pide gente que sepa de programación, de herramientas, que sepa implementar mejora continua, que mejore los procesos en el Ciclo de Vida de Desarrollo, que sepa de automatización, de rendimiento.

¿El futuro del testing en nuestro país? En los próximos años se basará en ofrecer servicios, es un buen momento para las consultoras. Las empresas contratan menos debido a la crisis y subcontratan los servicios.

¿Cúal creéis vosotros que es el futuro del testing en general y en nuestro país?

Hoy me desplazaré a Valencia a la Jornada VLCTesting 2011, donde participaré a las 11,30 como ponente con la presentación “Quality Assurance & Testing, el conjunto perfecto“. Durante la ponencia describiré el role y las responsabilidades del Quality Assurance en una gran organización y como ambos equipos, Quality Assurance & Testing, se complementan y trabajan juntos para alcanzar altos niveles de calidad y madurez dentro de la organización.

A menudo existe un línea muy fina entre Quality Assurance y testing y en muchas ocasiones se confunden los roles, acostumbrando a llamar “QA” a una persona que hace testing. ¿Porque lo llaman QA cuando quieren decir testing? No debemos olvidar que los equipos de testing nos ayudan a encontrar/detectar defectos, mientras el equipo de QA nos ayuda a prevenir defectos. Después de ejercer durante los últimos tres años el role de Quality Assurance Specialist para el programa de uno de nuestros principales clientes en Zurich, he querido hacer esta presentación para compartir mis experiencias y que sirvan de ayuda a personas que tengan en mente crear un departamento de QA. El QA garantiza que los equipos sigan los estandares marcardo por la organizacion y se asegura que los proyectos tengan la calidad esperada, aunque yo describiría al QA como un “facilitador”, una persona que ayuda en todas las fases del ciclo de vida de desarrollo a que los equipos trabajen de la forma más eficiente posible y garantizando un alto nivel de calidad teniendo en mente la satisfacción del client.

Después de la jornada estaré en el “Birras & Blues” con la asociación TestQA presentando un nuevo evento del SeasonTest, el AutumnTest Valencia 2011. Ya he anunciado bastante el evento en articulos anteriores, asi que nos vemos en Valencia!!!!!!!

Edreams me deja en tierra según ellos por culpa de un “error informático“. El pasado 13 de Octubre compré unos billetes a México, cuatro días después llamo a KLM para reservar la cuna de mi hijo y me dicen que todos los tramos están reservados excepto uno y que llame en un par de días. Unos días después llamo a KLM y me encuentro la desagradable noticia de que los billetes no existen, que tal vez fueron cancelados. Llamo inmediatamente a edreams y el servicio de atención al cliente me informa que debido a un error informático los tickets fueron cancelados al día siguiente de mi compra. ¿Cómo es eso posible si yo hablé con KML varios días despues y la reserva existía? Bueno, según edreams nos mandaron un email informándonos de la cancelación, email que no hemos recibido. Pero la cosa no queda ahí, la persona que nos atendió por teléfono nos dijo que tal vez no recibimos el email porque la dirección de correo estaba mal. ¿Estaba mal? ¿entonces como recibimos el email de confirmación de compra?. ¿Otro error del sistema? ¿¿¿¿tal vez no se estén enviando los email de cancelación?????. Les hemos pedido que nos remitan el email de cancelación con la fecha en la que fue enviado y seguimos esperando, está claro que no nos enviarán nada porque no enviaron nada de nada.

Por supuesto edreams no se hace responsable de nada y nos ofrecen los mismos billetes por 400 euros más caros, todo un detalle por su parte!!!!!! Pues nada, gracias a uno o varios errores informáticos tengo que comprar nuevos billetes y encima me constarán más caros…gracias “edreams, ya no viajaremos más contigo!!!!!”. El servicio al cliente en este país es increíble, ni se responsabilizan, ni te llaman…en fin, este sería otro tema diferente.

Muchos podríais pensar que lo que me han dicho es la típica disculpa que cualquier call center da a sus clientes cuando ocurre una incidencia, pero es la información que me ha proporcionado la empresa. “Un error informático”, el error es que ante un problema así no sean capaces de monitorizar e identificar las transacciones fallidas o canceladas para así ponerse en contacto con sus clientes y solucionar el problema. Hace un par de años tuve un problema similar con otra compañía (no recuerdo cual, una de las grandes), tenían un problema con sus sistemas…al día siguiente me llamaron y arreglamos el asunto.

Llevo 10 años comprando billetes online y es la primera vez que me pasa algo así…eso si, ellos responsabilidad cero, me devuelven los 70 eurozos de “gastos de gestión” y venga, aquí no ha pasado nada…ahora a buscar otros billetes.

Este vídeo es del ensayo del ensayo del compositor Ígor Fiódorovich Stravinsky de la pieza “andantino”, uno de los movimientos de su ballet “Pulcinella”. Parece ser que durante los ensayos el compositor dijo la frase: “Si algo se puede hacer mejor, hagámolo mejor“, frase que posteriormente fué usada este pasado verano por BMW como slogan en uno de sus anuncios publicitarios.

Creo que es una frase muy apropiada para este blog, y me hace pensar, ¿porque no se hacen las cosas mejor cuando desarrollamos Software? Está claro que lo que hacemos podríamos hacerlo mejor…y por tanto la respuesta es sencilla ya que en todo proyecto tenemos dos grandes “constrains”: el tiempo y el dinero. Es obvio que los proyectos de desarrollo de software se harían mucho mejor y con mayor calidad si estos dos “constrains” no fuesen tan limitados e incluso en algunos caso, excesivamente limitados diría yo. Aún así, el intentar hacer las cosas un poquito mejor está en cada uno de nosotros, así que espero que os guste este vídeo y que contribuyáis a que las cosas se hagan siempre un poquito mejor:

Hace un par de días me encontré en el centro comercial de la illa un Kiosco informativo del Ayuntamiento de Barcelona, el cual llamó mi curiosidad. Simplemente haciendo una búsqueda normal y corriente en el mapa de la ciudad y la aplicación comenzó a lanzar errores de parseo de XML como loca. Una pena, me marché de aquél kiosco sin pena ni gloria sin poder hacer una solo búsqueda.

Pero cuidado, ya que podéis encontrar en Barcelona 45 de estas terminales, conocidas con el nombre de “Punts bcn”. La verdad que son terminales bastante completos ya que permiten (cuando funcionan) realizar trámites a “casi” cualquier hora del día…ya no es necesario esperar largas colas, o que el funcionario de turno esté de mal humor y no te atienda correctamente. Además, en un futuro próximo se prevé que puedas hacer consultas, pagar tributos, comprar entradas o registrar documentos. Miedo me da!!!!!!!

Si os encontráis un terminal de este tipo en Barcelona, no dudéis en darle un poco de caña!!!!!!

El pasado 2 de Febrero se presentó la red social “sesocial.com“, una nueva red social española que pretende hacer competencia a tuenti. Parece ser que el mismo día que la red salió a producción se colapsó debido a la gran cantidad de persona que intentaron ingresar al sistema. No quiero entrar demasiado en el tema de que si la red social es mejor o peor que tuenti o que facebook, pero lo que si es una realidad es que no es muy buena publicidad para los señores de sersocial.com si su web se le cae el primer día. Lo peor de todo es que ha día de hoy todavía sigue caida aunque en su web se puede leer “estaremos operativos en las próximas horas”, así que la gente de tuenti debe de estar todavía tronchándose de risa…

Esta podría ser una importante lección aprendida para cualquiera. Las pruebas de performance nos ayudan a conocer como nuestro sistema se comportará bajo ciertas condiciones, es muy importante validar y verificar la escalabilidad, fiabilidad y el uso de recursos. Y por supuesto, como en muchas otras actividades de testing, las pruebas de performance deben de comenzar en etapas tempranas del desarrollo, así encontraremos los problemas gordos mucho antes y será más fácil y barato arreglarlos. Existes muy herramientas gratuitas como comerciales para hacer este tipo de pruebas, pero de todas maneras sino tenéis claro como hacerlas y queréis tener mayores garantías…siempre es mejor contratar a un profesional que te oriente y te ayude en esta tarea tan importante que muchas no se le da la importancia que se merece. Es importante destacar que se pueden hacer diferentes tipos de pruebas, de estrés, de concurrencia, de carga, de estabilidad…y por supuesto, como siempre recomiendan los expertos, es aconsejable tener un entorno de pruebas lo más parecido que se pueda al entorno de producción…ya se, ya se…eso cuesta mucho dinero y no es fácil disponer de un entorno exacto al que tenemos en producción, pero es la mejor forma de cumplir los requisitos con garantías.