jueves, 28 de noviembre de 2013

La importancia de la usabilidad (y pequeña experiencia personal)

En muchas ocasiones se dice aquello de "el usuario no sabe lo que quiere". Steve Jobs también expresó esta idea pero introduciendo un matiz:
"La mayoría de las veces la gente no sabe lo que quiere hasta que se lo enseñas"
Yo opino que los usuarios sí saben lo que quieren, pero no siempre saben transmitirlo adecuadamente. Por esta razón resulta útil (como decía Jobs), enseñarle al usuario lo que quiere (o pensamos que quiere) mediante un prototipo de la aplicación, por ejemplo. De esta manera resulta mucho más sencillo obtener feedback útil para construir un mejor producto software final y así lograr una mayor satisfacción del usuario.



sábado, 23 de noviembre de 2013

I Jornada sobre Calidad del Producto Software (2/2)

La JCPS continuo con la charla de Javier García Guzmán titulada "El producto software y los modelos de desarrollo (ágil, iterativo y cascada)". Javier hizo un repaso por los diferentes tipos de modelos de desarrollo software, destacando las ventajas y los inconvenientes de cada uno de ellos. Cuando llegó el turno de las metodologías ágiles, realizó una afirmación tremendamente obvia pero que puede sorprender a más de uno:
Las metodologías ágiles no sirven para todo
¿Es que un desarrollo en cascada ya no sirve en ningún caso? ¿Deben todas las empresas aplicar metodologías ágiles tengan o no éxito con sus modelos actuales? Evidentemente, no. En mi oponión, las metodologías ágiles no sirven para todo... ni para todos. Las metodologías ágiles son muy útiles en proyectos que parten de requisitos cambiantes, cuando se cuenta con un equipo multidispciplinar y auto-organizado y cuando es especialmente importante contar con productos potencialmente entregables en un corto espacio de tiempo. Aquí enlazo con otro concepto ampliamente nombrado en estas jornadas: el time to market. En ocasiones es más importante tener un producto "imperfecto" en el mercado pronto (e ir perfeccionándolo en futuras versiones) que llegar después que tus competidores con un producto completamente terminado.

Otro punto que me pareció muy interesante en la charla de Javier es el del riesgo que supone realizar una incorrecta gestión de las expectativas del cliente. Por ejemplo, si en 15 días el equipo de desarrollo crea un prototipo para mostrar al cliente, éste puede pensar que en poco más tiempo tendrá el producto completo.

Precisamente la estimación de tiempos es uno de los principales escollos de las metodologías ágiles porque generalmente sólo se cuenta con una estimación de las próximas funcionalidades (o historias de usuario) que se van a desarrollar pero no se cuenta con la "foto completa" de funcionalidad de todo el proyecto.

El Big Data se presentó como una posible solución para mejorar las estimaciones ya que una fuente enorme de datos podría ayudarnos a obtener estimaciones por comparación con históricos de tareas similares de otros proyectos.

El diseño centrado en los usuarios (implicar al usuario en el desarrollo del software), la dualidad desarrollo en factorías vs. desarrollo artesanal fueron otros temas tratadas en esta charla. En el diseño centrado en los usuarios es necesario que tanto desarrolladores como usuarios cambien de mentalidad, busquen un lenguaje común y estén dispuestos a invertir parte de su tiempo en colaborar en la obtención de un producto software de alta calidad.

I Jornada sobre Calidad del Producto Software (1/2)

I Jornada sobre Calidad de Producto SoftwareDurante los días 21 y 22 de noviembre se ha celebrado la I Jornada sobre Calidad del Producto Software (JCPS) en el Salón de Grados del Campus de Leganés de la Universidad Carlos III de Madrid. En mi caso, por motivos de trabajo, sólo pude asistir el día 21.
Al llegar al campus, la organización entregó a todos los asistentes una identificación, un diploma de asistencia, una libreta, bolígrafos, y demás material publicitario de algunas de las empresas participantes. También facilitaron un vale para comer en la cafetería del campus y a media mañana sirvieron café y bollería. Este parón para coger fuerzas fue la excusa perfecta para saludar a antiguos compañeros, conocer a otros profesionales del sector y participar en interesantes debates con las charlas escuchadas como punto de partida. El famoso networking siempre es una de las partes más interesantes de este tipo de eventos.

La JCPS se inauguró con un breve discurso de 3 personas entre las que se encontraba Juan Andrés Pro Dios, CIO de El Corte Inglés. De sus palabras destacaría lo siguiente:
  • En primer lugar, subrayó los problemas que según él aparecen en un alto procentaje de proyectos de software:
    • Desviaciones de requisitos.
    • Larguísimas iteraciones de pruebas en las que se invierte hasta un 35% del tiempo y costes de un proyecto.
    • Aumento de los costes por la no calidad del software.

  • Posteriormente destacó que las medidas que se aplican en El Corte Inglés para paliar o eliminar estos problemas son:
    • Modelo de desarrollo nearshore porque las factorías de desarrollo en el extranjero no les han funcionado debido a la barrera del idioma y las diferencias culturales
    • Creación de una Oficina de Calidad que garantice que el proveedor de software sigue el proceso de desarrollo correcto y entrega un producto con la CALIDAD CONCERTADA previamente. El usuario final o promotor del proyecto no se implica en su desarrollo.
    • Buscar la calidad del producto asegurando la calidad del proceso de proceso (aplicando CMMI, ISO2000, Deming, etc.), para alcanzar la INDUSTRIALIZACIÓN Y REPETIBILIDAD del proceso de desarrollo de software, como si de la construcción de un coche se tratara.

Por tanto, en esta primera exposición aparecieron algunos términos y conceptos que todos hemos escuchado en más de una ocasión cuando se hala sobre calidad de software:
  • Industrialización
  • Calidad Concertada
  • Proyectos llave en mano

miércoles, 14 de agosto de 2013

Cómo elaborar un Análisis de Riesgos del Producto

En un proyecto de testing, como en todos los proyectos, hay que lograr determinados objetivos con ciertas restricciones de costes, tiempo y alcance.

Esto se traduce directamente en una máxima que es uno de los principios fundamentales del testing según ISTQB®: No es posible probarlo todo.

Sólo sistemas extremadamente simples pueden ser testeados con pruebas exhaustivas (todas las combinaciones posibles).

Entonces, ¿cómo decido hasta dónde pruebo y cómo pruebo?
Lo más común en estos casos es responder a estas preguntas usando como base un Análisis de Riesgos del Producto.

El Riesgo puede cuantificarse según la siguiente fórmula:

Riesgo = Probabilidad de fallo x Impacto

Y a su vez, la Probabilidad de Fallo es igual a:

Probabilidad de Fallo = Complejidad Técnica x Frecuencia de Uso

lunes, 24 de junio de 2013

SMART y MoSCoW: Redactando y priorizando requisitos

La calidad de un producto software asienta sus bases en una correcta toma de requisitos (tanto funcionales como no funcionales). Como ya comenté en un artículo anterior, el coste de la resolución de defectos en la fase de requisitos es mucho menor que en fases posteriores. Y lo que es mejor, en esta fase es posible prevenir muchos defectos en producción.

Existen varios listados de características que tienen que tener los requisitos. Quizás el más famoso es el criterio SMART:
  • Specific (Específico): Los requisitos deben ser claros y precisos y no deben dar lugar a interpretaciones. Los requisitos deben revisarse para eliminar toda ambigüedad en su redacción. Además, cada requisito debe tener un identificador único que permita referirse a él de forma unívoca.
  • Measurable (Medible): Un requisito del tipo "La página web debe ser visulamente atractiva y fácil de manejar" no es un requisito válido porque describe una característica subjetiva y que por tanto no se puede medir.
  • Attainable (Alcanzable): Un requisito debe ser accesible, realista y técnicamente posible.
  • Relevant (Relevante): Cada requisito debe contribuir a alcanzar los objetivos globales del proyecto y debe estar en consonancia con el resto de requisitos.
  • Time-bound (Acotado en el tiempo): La realización de cada requisito debe tener una fecha máxima de entrega; es decir, deben ser realizables dentro de unos márgenes de tiempo acotados. Esta "T" de SMART también podría significar "Trazable" o incluso "Testable".

lunes, 22 de abril de 2013

Testing Exploratorio

Todos los proyectos cuentan con plazos de realización muy ajustados. El tiempo dedicado al testing suele ser reducido y si los retrasos acumulados son muy grandes este tiempo puede acortarse aún más o llegar incluso a desaparecer.

Por otro lado las inversiones deben justificarse en periodos muy cortos de tiempo: si el ROI (Return of Investment) de un proyecto no es evidente tras un espacio breve de tiempo, puede llegar a cancelarse.

Además, en ocasiones la documentación no está completa, está desactualizada o simplemente no existe, por lo que realizar un diseño de casos de prueba detallado es muy difícil.

Con estos condicionantes, las empresas que ofrecen servicios de testing deben afrontar el reto de encontrar soluciones que permitan detectar un gran número de defectos en un corto espacio de tiempo.

En múltiples ocasiones el Testing Exploratorio (proceso interactivo en el que aprendizaje, diseño y ejecución de pruebas ocurren de forma simultánea) se erige como la solución escogida, bien en su estado "natural" o bien modificado o adaptado dando origen a múltiples variantes:

miércoles, 17 de abril de 2013

Requisitos de instalación de TestLink, HP ALM y Borland SilkCentral Test Manager

Os presento 2 tablas con los requisitos de instalación de 3 herramientas de gestión de pruebas muy conocidas y utilizadas en el mundo del testing:

Obviamente, los requisitos de instalación no deberían ser el factor determinante a la hora de elegir una herramienta pero no es menos cierto que siempre es algo a tener en cuenta.

He dividido los requisitos en parte "Servidor" y parte "Cliente". Las fuentes principales que he consultado para elaborar estas tablas están al final del artículo:

Requisitos de Instalación (Servidor)

TestLink 1.9.6 + Mantis 1.2.15
HP ALM 11.5
Borland SCTM 12.1
CPU
N/A
Windows: Procesador Quad Core AMD64 o equivalente
Linux:
Procesador Quad Core AMD64 o equivalente
Solaris:
Arquitectura SPARC (arq. x86 no soportada)
Intel Core i5 o equivalente
RAM
N/A
8 GB (mínimo)
4 GB (mínimo)
Sistema Operativo
No hay requisito sobre el Sistema Operativo. Los desarrolladores confirman su correcto funcionamiento bajo GNU/Linux y Windows XP
Recomendados: 
Windows 2008 R2 SP1 64 bit
Linux Red Hat 6.2 64 bit
 
Soportados: 

Windows Server 2008 SP2 (32 y 64 bit)
Windows Server 2008 R2 SP1 (64 bit) 
Sun Solaris 10 (64 bit SPARC) (arq. x86 no soportada)
 Linux Red Hat 6.2 (64 bit)
 Linux SUSE 11 (64 bit)
Windows XP Service Pack 2 or later
Windows Server 2003 R2 Service Pack 2
Windows Server 2008
Windows Server 2008 R2 Service Pack 1 64 bit
Servidor Web
Apache 1.3.x o 2.x o superior
IIS 3.x o superior
Recomendados:
IIS 7.5
Apache 2.2
Tomcat
IIS
Apache como balanceador de carga
Bases de Datos
MySQL 4.1.1 o superior (recomendado 5.x)
Postgres 8.x o superior
Microsoft SQL 2000 y 2005 (con limitaciones)
Recomendados:
SQL 2008 R2 SP1
Oracle 11.2.0.3
Microsoft SQL Server 2005 Service Pack 2
Microsoft SQL Server 2008 R2
Oracle 10g (
version 10.2.0.5)
Oracle 11g (
version 11.2.0.2)
Disco Duro
300 MB (mínimo)
8 GB (mínimo)
30 GB (mínimo, más el espacio ocupado por el servidor de base de datos)
PHP
PHP 5.2 y 5.3
 N/A
N/A
Otros
N/A
 N/A
SilkMeter como Servidor de Licencias


Requisitos de Instalación (Cliente)

TestLink 1.9.6 + Mantis 1.2.15
HP ALM 11.5
Borland SCTM 12.1
CPU
 N/A
Core duo 1.6 Ghz (o superior) o equivalente
Intel Core i3 o equivalente
RAM
 N/A
2 GB mínimo
1 GB
Disco Duro
 N/A
2 GB mínimo
1 GB
Pre-requisitos
 N/A
Visual C++ 2005 SP1 ATL Security Update Redistributable
Microsoft .NET Framework 4
Microsoft Office 2010 (recomendado)
 N/A
Sistema Operativo
 N/A
Windows XP (SP3) 32 bit
Windows 7 (SP1) 32 bit (recomendado)
Windows 7 (SP1) 64 bit
Windows 2008 R2 SP1
Windows Server 2008 SP2 32 bit
Windows Server 2008 SP2 64 bit
 N/A
Navegador Web
Mozilla Firefox 1.0 o superior
Microsoft Internet Explorer 6.x y 7.x
En general, cualquier navegador que soporte JavaScript, XHTML y CSS
Microsoft Internet Explorer 8
Microsoft Internet Explorer 9
Microsoft Internet Explorer 8
Microsoft Internet Explorer 9
Mozilla Firefox
Google
Chrome


Fuentes

viernes, 15 de marzo de 2013

MadQA: Pequeños cambios para renovar el rendimiento de aplicaciones

Ayer asistí a una nueva reunión del grupo de testing de Madrid en MeetUp: MadQA

En esta ocasión el ponente fue Pedro Sebastián Mingo [Blog][Twitter][LinkedIn], un profesional experto en pruebas de rendimiento software con más de 15 años de experiencia.

Pedro explicó que normalmente siempre se hacen las mismas pruebas y se siguen las mismas costumbres y estándares, de forma que se marca un camino del que a veces parece difícil salirse. Con este punto de partida, el ponente propuso 4 cambios o enfoques diferentes para enriquecer las pruebas y aportar valor al cliente:


viernes, 8 de febrero de 2013

Comprobación de enlaces con WebDriver


WebDriver (Selenium 2.0) es un framework que permite automatizar acciones realizadas en un navegador. Esta herramienta es muy utilizada en testing y permite usar diferentes lenguajes de programacióm como Java, Python, C#, etc.

También existe Selenium IDE, que es un plugin de Firefox que permite automatizar casos de prueba de una forma aún más simple.

El propósito de este post no es realizar un tutorial ni de WebDriver ni de Selenium IDE, sino compartir con vosotros un pequeño ejemplo de uso práctico de WebDriver pero si queréis un pequeño curso para dar vuestros primeros pasos con WebDriver usando Java, os recomiendo visitar este enlace:
http://www.udemy.com/start-using-selenium-webdriver-with-java/

El siguiente código utiliza WebDriver, está escrito en Java y tiene como principal misión la de buscar todos los enlaces de una página web y comprobar si funcionan correctamente o no (comprobando el código de estado). Para ello, no necesita abrir una ventana de ningún navegador por lo que puede ejecutarse en un equipo sin interfaz gráfica. Este código lo he utilizado con éxito junto con Jenkins, Maven y JUnit.

jueves, 31 de enero de 2013

MadQA: Qué caracteriza (y qué no) a las organizaciones que mejor desarrollan software

Esta tarde he asistido a mi tercer MeetUp de MadQA: Qué caracteriza (y qué no) a las organizaciones que mejor desarrollan software.

En esta ocasión el ponente ha sido Javier Garzás (@jgarzas / javiergarzas.com), profesor titular en la Universidad Rey Juan Carlos, director de la empresa Kybele Consulting S.L., consultor, auditor TI, investigador, autor de numerosas publicaciones, etc.

Lo primero que quiero resaltar es que la ponencia ha sido muy amena. Ha estado centrada en la experiencia profesional de Javier Garzás, quien (sin dar nombres) nos ha contado múltiples ejemplos, anécdotas y vivencias profesionales estructuradas en 6 puntos fundamentales que caracterizan a las empresas que mejor desarrollan software. En la parte de "Ruegos y preguntas" las aportaciones de los asistentes también han sido muy interesantes.

Lamentablemente (pido disculpas), no he apuntado literalmente el título de los 6 puntos, pero si recuerdo varias ideas y frases que me han parecido muy interesantes y que recopilo a continuación:

  • El equipo técnico y el equipo comercial deben estar coordinados  y deben conseguir que sus objetivos individuales se complementen en beneficio del éxito del proyecto.
  • El software lo hacen personas, no máquinas. Desarrollar es una actividad intelectual, lo que significa que el estado de ánimo, la motivación, etc. de los desarrolladores puede influir en la productividad y en la calidad del código.
  • Desarrollar software no es como hacer casas o coches por lo que una desviación en la línea base de tiempo de un proyecto no se soluciona simplemente con introducir más recursos... no es tan fácil. Del mismo modo, no se puede medir el avance de un proyecto en número de líneas de código escritas.
  • La calidad no es como poner azúcar en el café. No se puede tener el desarrollo hecho y posteriormente intentar introducir calidad sino que la calidad tiene que comenzar desde la toma de requisitos y debe formar parte de la cultura y el buen hacer de la organización. No se puede simplemente "espolvorear" por encima del código.
  • "En el desarrollo de software no hay balas de plata" (Brooke). No todas las metodologías son apropiadas para todos los proyectos. No hay metodología o una buena práctica mejor que otra en términos absolutos sino que cada una será más o menos acertada en cada proyecto concreto. Lo mismo se puede decir de las personas que forman el equipo: hay que saber elegir a las personas adecuadas para cada proyecto.
  • En el desarrollo de software es imposible llegar a saber todo de todo. Siempre se puede seguir mejorando y aprendiendo a nivel personal y colectivo para eliminar poco a poco malas prácticas y desarrollar mejor software.
  • La presentación ha finalizado con una frase que venía a decir lo siguiente: "Los equipos de desarrollo son el motor de los proyectos de futuro más exitosos y pioneros".

Otras 3 frases que recuerdo bien y que reflejan el pensamiento de algunas empresas que no desarrollan bien software fueron:
  • "Los técnicos son una "commodity"... lo importante es el negocio."
  • "Pensaba que al aplicar una metodología ágil no hacía falta documentar nada"
  • "¿Qué problema hay en hacer un copy pega del código?

La ponencia ha sido grabada en vídeo. En cuanto esté disponible actualizaré el artículo para agregarlo.

Muchas gracias a Javier Garzás por la charla y a Antonio Martín (@antoni0martin) por organizar estos eventos tan interesantes.

miércoles, 23 de enero de 2013

Selección de Técnicas de Diseño de Pruebas

En el mundo del testing existen múltiples metodologías, siendo ISTQB y TMap dos de las más conocidas.

Cada metodología popone sus propias técnicas de prueba (en el caso de TMap se distingue entre técnicas básicas y técnicas de diseño) pero en todos los casos se hace hincapié en algunos conceptos muy importantes:
  • No se puede aplicar cualquier técnica de prueba en cualquier proyecto
  • No todas las técnicas de prueba son aplicables a un mismo tipo de aplicación objeto de pruebas
  • Cada técnica de prueba sirve para encontrar un tipo de defecto distinto
  • Para cada atributo de calidad a probar hay técnicas de prueba más adecuadas que otras
  • No todas las técnicas de prueba son aplicables en todos los niveles de prueba
  • Una misma técnica de prueba se puede aplicar con diferentes grados de profundidad/intensidad
  • El cliente debe estar informado de todas las decisiones de prueba y debe tener la última palabra

miércoles, 2 de enero de 2013

Traducción de TestLink 1.9.5 al español

    

Hace pocos días abrí una nueva "incidencia" en la herramienta de gestión de incidencias/defectos (Mantis) de TestLink:
http://mantis.testlink.org/view.php?id=5444

En esa incidencia adjunto un archivo .zip que contiene los ficheros:
  • /locale/es_ES/strings.txt
  • /locale/es_ES/description.php
  • /locale/es_ES/texts.php

con todos los textos de TestLink 1.9.5 completamente actualizados al español (de España).

Dejo un enlace alternativo para ese mismo archivo .zip aquí:
http://dl.dropbox.com/u/36666049/es_ES.zip

La actualización de idioma también está ya disponible en la versión en desarrollo de TestLink en Gitorious (y estará incluida en la versión 1.9.6). Este es el detalle del commit que incorpora los cambios:
https://gitorious.org/testlink-ga/testlink-code/commit/f364aff589c163c53d515ba2223d79f1fbc29c82/diffs/d161bb8b4a821f444b467fee8fd1b4abc94cc5c4

Si quieres descargar la versión en desarrollo de TestLink con este (y otros) cambio, pulsa el siguiente enlace:
http://gitorious.org/testlink-ga/testlink-code/archive-tarball/testlink_1_9

Llevo algunos días repasando la traducción en busca de erratas y frases traducidas de forma excesivamente literal para mejorarla. Si usáis los ficheros y véis algún error, por favor, avisadme dejando un comentario en este blog o en el enlace a Mantis.

Hay dos palabras que he dejado en inglés por no encontrar una buena traducción al español:
  • Keyword
  • Build

la primera puede traducirse como "Palabra clave" aunque no termina de gustarme. La segunda quizás es traducible como "Versión", pero eso puede confundirse con las versiones/revisiones de requisitos y casos de prueba y por eso he preferido dejar de momento (hasta encontrar una solución mejor) el término original en inglés.

*** Actualización 25/01/2013  ***
La versión 1.9.6 será lanzada el 10 de marzo de 2013, momento en el cual esta traducción será parte de la versión oficial.

*** Actualización 14/11/2014  ***
La versión más actualizada de la traducción de TestLink al español está disponible en el siguiente enlace:
http://jesus.hernandez.abeleira.com/2014/11/traduccion-de-testlink-1912-al-espanol.html

Compartir