Así no se hacen las cosas por Ernesto Kiszkurno

En la revista www.InfoTesting.com de Abril 2011 salió publicada una nota escrita por Nora y por mí sobre el uso de Kanban en testing. Para los que quieran leerla pueden ir desde aquí . Seguimos pensando..

Me encuentro con un interesante informe publicado el 18 de febrero de 2011 por World Economic Forum sobre el futuro de la información personal en internet. Resulta un poco escalofriante ver las proyecciones que hacen respecto de la cantidad de información personal que habrá disponible en la web para el 2020. Por un lado no deja de resultar útil tener cada vez más información cargada «en la nube»: ahorra tiempo, permite darte a conocer y conocer nuevas personas, amplía las capacidades de acción en nuestro trabajo, achica distancia, etc. Por otro, sin darnos cuenta vamos sumando pequeños pixels que, de a uno a la vez, van conformando una fotografía muy precisa acerca de nosotros. El informe igualmente, como se comenta en Is Personal Data the Next Killer App for the Web? , se concentra en la oportunidad económica que esta fotografía representa. Para mí, parándome del lado del individuo, la pregunta clave es: ¿Quién tiene acceso a esta foto y para qué? Seguimos pensando..

En el post What’s Brewing with Beer Ads? se puntualiza el hecho de que la mayoría de las marcas de cerveza utilizan el mismo mensaje a la hora de promocionar cierta categoría de producto. En particular dice: In a world of fierce originality and brand competition, it is a curious phenomenon that a whole category tends to follow the same basic advertising approach. Why? Is it the lack of a unique selling point/message? Y luego pregunta: And could this happen in other categories? For instance, could it be that all cellular companies will communicate the same message? Or should they make an effort to come up with a distinctive message?!    Pensando en esto creo que en 0aservicios de consultoría pasa algo similar . Cuando uno recorre el material comercial de cualquiera de las empresas de esta categoría (y aquí sumo también a empresas de desarrollo de software) se encuentra con mensajes muy similares que giran alrededor de 3 conceptos centrales: Confianza ...

Hace un par de días salió publicada una colaboración mía en el blog Mejores Proyectos . Agradezco a José Esterkin por la oportunidad de participar en su exitoso blog. Seguimos pensando..

En uno de mis primeros trabajos de testing de software usábamos un documento Word® para registrar los casos de prueba y un Excel® para registrar los incidentes. Gracias a esto, los problemas que teníamos eran los que todos podemos imaginarnos: no teníamos trazabilidad entre casos, ejecuciones e incidentes, era difícil paralelizar las pruebas, al igual que juntar los incidentes de todos los testers, solo podíamos compartir el material con desarrollo una vez que habíamos terminado, etc. En esa época, 15 años atrás, no era tan obvia la necesidad de tener una herramienta que gestionara toda esa operatoria. Ahora sí lo es. No es posible instaurar un proceso de pruebas de software razonable si no contamos con una herramienta de registración y seguimiento de incidentes (errores) . Y en realidad tampoco alcanza con registrar solo los incidentes, sino que también debemos registrar las ejecuciones realizadas, los casos de prueba definido y en qué proyectos (o pruebas). A continuación doy...

Las licitaciones son una herramienta fundamental a la hora de abastecerse de recursos para sus proyectos. Sin embargo no son la única opción.  Un buen CIO debe saber decidir qué servicios licitar y qué servicios contratar directamente. En algunos casos es conveniente recurrir a los proveedores estratégicos directamente, confiando en que nos ayudarán de la mejor manera posible. Por el otro lado, el CIO debe ser un buen licitador . Una vez que decidió que un servicio será adjudicado por licitación, debe elaborar un pliego que le permita atraer a los mejores proveedores y asustar a los peores (como comenté en Teoría Económica y Outsourcing ). Seguimos pensando..

Hace un par de días recibí un correo con la información de un vuelo que debo hacer la semana próxima. En él figuraba el código de reserva que debía usar para hacer el checkin on-line. Hoy, 72 horas antes, intenté hacer el checkin como otras tantas veces pero el sistema me dijo que no alegando que el susodicho código estaba mal. Luego de varios intentos, llamé al call center de la aerolínea para ver que había pasado y allí me enteré que estaba usando un código incorrecto. “¿Incorrecto?” dije yo “pero si ustedes me enviaron el código”. La pregunta que me hacía luego es ¿cómo pudieron mandarme el código mal? ¿Alguien que se equivocó al tipear? ¿Había un error en alguno de los tantos sistemas por los que mi reserva pasó?  Un checkin que usualmente demora 10 minutos terminó llevándome 25 minutos. Imaginen que en una persona cualquiera esto produce irritación pero dada mi área de expertise (ingeniería de software, calidad, informática) la frustración es peor. Las empresas pie...

Por referencia de un compañero de trabajo tomé contacto con una serie de posts que James Whittaker publicó en Google Testing Blog . La serie se titula How Google Tests Software y cuenta varios aspectos relacionados con la forma en que se organizan, los roles que ocupan y la filosofía/estrategia de pruebas que manejan. A todos aquellos interesados en los temas de testing de software les recomiendo leer la serie y ver algunas de las charlas que el autor ha dado para GTac. Resalto en este post dos ideas que a mi criterio son interesantes y con las que concuerdo. La primera tiene que ver con la relación entre desarrollo y testing : At Google, quality is not equal to test. Yes I am sure that is true elsewhere too. “Quality cannot be tested in” is so cliché it has to be true. From automobiles to software if it isn’t built right in the first place then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-th...