domingo, 30 de noviembre de 2014

II Jornadas sobre Calidad del Producto Software & QA Open Space - Día 2 (2/2)

http://calidaddelproductosoftware.com/2014/


(Puedes encontrar la primera parte de este artículo aquí)

La cuarta charla, titulada "Evolución de un Modelo de Pruebas tradicional a un Modelo de Calidad Total", fue presentada por Alfonso R. López Rivero, de Vodafone. En ella se explicó como Vodafone ha transformado por completo su modelo de la calidad para grandes aplicaciones corporativas de la mano de MTP.

Las ponencias en las que una empresa explica su "caso de éxito" siempre me resultan muy interesantes. Alfonso comentó que Vodafone había apostado por la calidad por encima de time to market (aunque sin olvidarse de él por completo, claro).

Para implantar todos estos cambios, realizaron en primer lugar pruebas de concepto y agruparon dichos cambios en 2 grandes grupos:
  1. Cambios Organizacionales
  2. Cambios Culturales
En el primero se encuadran los cambios que implican un cambio en la estructura jerárquica y organizativa de los equipos:
  • RM - Release Management
  • C&DM - Configuration & Data Management
  • SQA - Software Quality Assurance
    • Ejecución de pruebas
    • Automatización de pruebas y tareas
    • Provisión de datos de prueba
    • Calidad de código: cuando hay tiempo, tratan de "limpiar" código legacy para mejorar su calidad.
    • Calidad de requisitos
    • Pruebas de rendimiento: utilizan una línea base de rendimiento para determinar si el rendimiento de un software es o no aceptable
    • Pruebas funcionales

Los cambios culturales son los más difíciles de llevar a cabo:
  1. En primer lugar hay que pensar si realmente se desea cambiar
  2. Posteriormente hay que planificar la ejecución de los cambios
  3. Superar las barreras que se vayan encontrando y
  4. Por último decidir cómo se medirá el éxito (el valor creado)

En este proceso de cambio se lograron mejoras aplicando acciones proactivas, pero también se aprendió mucho a partir de los errores cometidos.

Por último, Alfonso nos comentó algo que realmente me pareció una gran idea y es que cuando hacen un cambio importante de software, hay gente que se desplaza físicamente a las tiendas para obtener el feedback del cliente.

II Jornadas sobre Calidad del Producto Software & QA Open Space - Día 2 (1/2)

http://calidaddelproductosoftware.com/2014/


Los días 26 y 27 de noviembre se han celebrado las II Jornadas sobre Calidad del Producto Software & QA Open Space. Como el año pasado, este evento ha estado organizado por El Corte Inglés, la Universidad Rey Juan Carlos, la Universidad Carlos III y la UNED.

En esta ocasión, las jornadas se han celebrado en el Campus de Móstoles de la Universidad Rey Juan Carlos.

Si las primeras jornadas estuvieron centradas en el "QUÉ", éstas segundas han estado centradas en el "CÓMO". Otra de las novedades han sido los Open Space: los asistentes dejaban notas en un tablón con las ideas, preguntas o sugerencias relacionadas con el tema del Open Space. Posteriormente, los organizadores, a partir de esas notas planteaban 3 líneas argumentales diferentes y los asistentes podían unirse libremente a cualquiera de ellas. De esta forma se crearon debates abiertos y colaborativos en los que cualquiera podía expresar sus opiniones. Los 3 debates finalizaron con la exposición de las principales conclusiones alcanzadas en los debates.



Lamentablemente, sólo pude asistir al segundo día del evento. Tenía muchas ganas de asistir a algunas charlas del primer día pero por imprevistos en mi trabajo, no pudo ser.

La primera charla del segundo día fue "¿Y qué pinta la Integración Continua en un sitio como éste?", presentada por Ana María del Carmen García y Mariano Minoli, de 233gradosdeTI.

Los ponentes explicaron las 6 razones para utilizar integración continua son:

  1. Reducir riesgos y tiempos:
    Con la integración continua se introducen cambios pequeños y frecuentes en el código. Con el sistema tradicional de entrega de software tradicional se realizan grandes modificaciones cada muchos meses o incluso años.
    Una frase de Martin Fowler resume esta idea:
    "Si algo duele, hazlo más a menudo"
  2. Reducir procesos repetitivos manuales: los procesos manuales son propensos a errores.
  3. Crear una versión de software mediante un proceso conocido, confiable, probado, versionado y repetible
  4. Mejorar la visibilidad del estado del proyecto
  5. Lograr una mayor auto-confianza y seguridad en el equipo de desarrollo
  6. Obtener feedback rápido de los usuarios

martes, 4 de noviembre de 2014

Traducción de TestLink 1.9.12 al español (de España)

  


Hace casi 2 años publiqué en este blog la traducción al español de TestLink 1.9.5

Hoy, tras varias versiones sin actualizar, publico la traducción al español (de España) de TestLink 1.9.12 (última versión estable):

https://mega.co.nz/#!RpYWUYgL!GigI3_xE13lygaZvarNGXjEDkU0hwNSImASZGwRKEIE

Este fichero .zip contiene los siguientes ficheros:
  • /locale/es_ES/strings.txt
  • /locale/es_ES/description.php
  • /locale/es_ES/texts.php
  • /locale/es_ES/custom_strings.txt.example

Adicionalmente, he añadido algunas cadenas de texto que sólo aparecen en la versión en desarrollo al fichero strings.txt para que la actualización sea lo más completa posible a fecha de hoy.

También es importante destacar que no he eliminado cadenas de caracteres antiguas (en desuso en la última versión), por lo que podéis utilizar esta traducción con versiones anteriores de TestLink sin ningún problema.

Debido a que en estos momentos el gestor de defectos de TestLink está caído (* ver actualización a continuación), no he podido subir estos ficheros de forma oficial al repositorio de la herramienta. Lo subiré en cuanto el problema esté solucionado.

Por supuesto, agradezco que me informéis de cualquier error que veáis.

**** ACTUALIZACIÓN 05/11/2014 ****
He abierto una nueva incidencia en el gestor de defectos de TestLink adjuntando esta nueva traducción:
http://mantis.testlink.org/view.php?id=6730

Volveré a actualizar el artículo cuando los ficheros pasen a formar parte de la versión en desarrollo de TestLink.


**** ACTUALIZACIÓN 07/11/2014 ****
La traducción ya forma parte de TestLink. El siguiente commit lo demuestra:
https://gitorious.org/testlink-ga/testlink-code/commits/4836668d820e490cc4557ee59ef94ec050e74fa3

Compartir