El Blog de Guino

Uno de los temas más polémicos cuando conversamos entre personas relacionadas con la tecnología es la definición de la Calidad. Algunos se van por el tema de ISO o CMMI, otros por la parte de Usabilidad, otros salomónicamente dicen «depende de a quién se hace esa pregunta».

En uno de sus tantos libros sobre Testing, Rex Black menciona la interesante parábola sobre «los tres ciegos y un elefante». Uno tocó la cola y declaró que era una serpiente. Otro tocó un brazo e insistió que era un árbol. El tercero tocó un lado del elefante y afirmó que era una pared.

Definir la calidad puede ser un proceso similar.  Todo el mundo sabe que entienden por calidad, pero abundan los desacuerdos.

Una de los cosas que manejamos frecuentemente en las Prueba es manejar el riesgo de la calidad, por ello es muy importante una estrategia de Pruebas basadas en riesgos.

Igualmente se busca manejar la insatisfacción del cliente con el producto software y las expectativas razonables sobre determinadas categorías de funcionalidad.

A pesar de todos los esfuerzos realizados en la industria del software por mejorar la calidad de los productos, la complejidad y diversidad de tecnologías y un mercado cada vez más demandante hacen difícil esta tarea. Desde mucho tiempo han habido iniciativas por mejorar la calidad del producto enfocándose la mejora del proceso de desarrollo, un ejemplo de esto es Capability Maturity Model Integration (CMMi), ahora manejada por el CMMI Institute. Sin embargo, este tipo de modelos daba atención limitada a las pruebas, por lo que la comunidad de pruebas ha creado sus propios modelos de mejora, uno de ellos es Test Maturity Model Integration (TMMi) que puede ser usado como un modelo complementario a CMMi.

El marco de trabajo TMMi, ha sido desarrollado por la organización europea TMMi Foundation y tiene sus orígenes en el proyecto Test Maturity Model (TMM) desarrollado por el Instituto de Tecnología de Illinois. TMMi, al estar basado en CMMi, ha sido desarrollado como un modelo por etapas, utilizando conjuntos predefinidos de areas de proceso de modo que se puede definir una ruta de mejora de la organización mediante un modelo de madurez.

Los niveles de madurez TMMi son:

Nivel 1: Inicial

Representa un estado donde no existe un proceso de pruebas formalmente documentado o estructurado. Las pruebas son típicamente desarrolladas de un forma «ad-hoc» luego de escribir código, y las pruebas se tratan de la misma forma que la depuración. El objetivo de las pruebas es probar que el software trabaja. Depende de «héroes» y no existe entendimiento del costo de la calidad

Nivel 2: Gestionado

El segundo nivel se alcanza cuando los procesos de prueba están claramente separadas de depuración. Se puede llegar mediante el establecimiento de políticas y objetivos de la prueba, la introducción de los pasos que se encuentran en un proceso de prueba fundamental (por ejemplo, la planificación de la prueba), y la aplicación de técnicas y métodos de prueba básicos. Se usan ambientes de pruebas.

Nivel 3: Definido

El tercer nivel se alcanza cuando un proceso de prueba esta integrado dentro del ciclo de vida de desarrollo de software, y se documenta usando estándares, procedimientos y métodos formales. Se realizan revisiones y debe haber una funcion de pruebas de software distinta que puede ser controlada y monitoreada. Se realizan pruebas no-funcionales.

Nivel 4: Medido

El nivel cuatro se logra cuando el proceso de prueba es capaz de ser medido de manera efectiva y gestionado a nivel de organización en beneficio de proyectos específicos. Se implementa un proceso de evaluación de la calidad del producto.

Nivel 5: Optimizado

El último nivel representa un estado de madurez de los procesos de prueba donde los datos del proceso de prueba se puede utilizar para ayudar a prevenir defectos, y la atención se centra en la optimización del proceso establecido. Se establece un grupo de mejora del proceso de pruebas permanente.

TMMi no tiene un área de proceso específico dedicado a herramientas de pruebas y/o automatización de pruebas. Dentro TMMi, las herramientas de prueba son tratadas como un recurso de apoyo (prácticas) y son por lo tanto parte del área de proceso en el que prestan apoyo, por ejemplo, la aplicación de una herramienta de diseño de la prueba es una práctica de pruebas de apoyo en el área de proceso de diseño y ejecución de pruebas a nivel TMMi 2 y la aplicación de una prueba de rendimiento es una herramienta es una práctica de pruebas de apoyo en el área de proceso de Pruebas No-funcional a nivel TMMi 3.

Para mayor informacion, puede descargar los documentos desde la pagina del TMMi Foundation: http://www.tmmi.org/?q=downloads

Esa frase «El Software no es mi Negocio» la vengo escuchando de muchas compañías que, por lo general, ven al Departamento de Sistemas o TI como un costo que hay que soportar más que una oportunidad de innovación en un mercado cada vez más cambiante y retador.

Hay otras empresas que afortunadamente tienen una visión distinta, como aquel ejecutivo, cliente de un amigo mío, que decía: «Nosotros somos una compañía de software, enmascarada como un Banco». Ellos tienen muy claro el valor estratégico del software.

Yo, que trabajo en mercado del software desde los 90s y mi primer dispositivo movil fue una HP iPAQ 3630 en el 2001 y comence usando un «Smartphone» allá por el 2005 con el HTC Excalibur, alguna vez fui escéptico cuando Steve Jobs presentó el iPhone en el 2007 y, al igual que Steve Ballmer, no concebia un smartphone sin un teclado. Hoy en dia, soy usuario de un iPhone 5 y no concibo un smartphone que utilice teclado. Todo es digital, todo es soportado por software

El software inevitablemente se esta comiendo al mundo, como ya lo decía Marc Andreessen en un interesante ensayo denominado «Why Software Is Eating the World» escrito hace casi 3 años. Allí describe cómo las nuevas compañías, que comprendieron la importancia del software en la era moderna, apostaron por la innovación, crecieron y fueron rentables, mientras que otras compañías continuaron con el modelo tradicional y algunas de ellas hoy en día se encuentran al borde de la bancarrota.

El software está haciendo que se reinventen las cosas. Ya no compramos libros en una tienda de libros, los compramos con un solo clic usando Amazon Kindle. Ya no compramos CDs en una tienda de discos, adquirimos las canciones que nos gustan a través de iTunes o Spotify. Ya no compramos o alquilamos mas DVDs de peliculas, vemos las peliculas que queramos a través de una suscripción en Netflix. El reclutamiento de personal ya no se hace colocando avisos en los periódicos o mediante las bolsas de trabajo, se usa LinkedIn. Ya no buscamos hospedaje en hoteles, podemos tomar contacto directo con personas interesadas en alquilar espacios a través de AirBnb. Ya no tomamos Taxis, mediante un dispositivo movil tomamos contacto con los conductores usando la plataforma movil de Uber. Cada vez son más las grandes empresas y las industrias basadas en el software y que son entregados como servicios en línea.

Aquí un breve resumen  comparativo entre las empresas «tradicionales» (algunas de ellas al borde de la quiebra) y las empresas basadas en el software:

Si aun no esta convencido que el software se esta comiendo al mundo , será mejor que vea este video sobre un Probador de Vestimenta Virtual, que, seguramente, pronto lo verá en su tienda de ropas favorito, cambiando para siempre nuestra experiencia al probarnos un vestimenta.

En la ultima reunión que tuvimos en el IIBA Capitulo Perú, tuve la oportunidad de ver un interesante video del cineasta Lauris Beinerts que capta en excelente forma lo que siente un ingeniero (experto en el campo técnico) durante reunión con personas de negocio. Este cortometraje se basa en el video ruso «The meeting», del escritor Alexei Berezin.

El pensamiento racional del ingeniero contrasta con el de las personas que representan el negocio cuyos necesidades son expresadas como un disparate. Sin embargo, al Gerente de Proyecto no le importa si se trata o no de una tontería. El dice si a todo, total, ese es su trabajo.

A pesar de ser una comedia, no deja de tener mucha relación con lo que suele suceder en el mundo real.

Puede activar los subtitulos en español como se muestra en la figura:

Suelo escuchar a muchas personas vendiendo la idea de «Experiencia de Usuario» (UX) cuando en realidad se refieren a una «Interfaz de Usuario» (UI). Esto me motivo a intentar explicar la relación que existe entre estos dos términos y que desafortunadamente se usan como si fueran sinónimos.

Si vemos la imagen de la bicicleta, podemos entender como «Interfaz de Usuario» (UI) al «look and feel» de la bicicleta, probablemente una buena combinación de colores, diseño aerodinámico, tamaño, etc. Sin embargo, otra cosa sera cuando comencemos a probar la bicicleta y nos demos cuenta si nuestra «Experiencia de Usuario» (UX) con la bicicleta es positiva o no.

El termino «Experiencia de Usuario» fue acuñado por el investigador de ciencia cognitiva, Dr Donald Norman, a mediados de los 90s mientras trabajaba en Apple. El sentía que era importante tomar decisiones basadas sobretodo en las necesidades y deseos de los usuarios.

La «Experiencia de Usuario» (UX) se refiere simplemente a la forma en que un producto se comporta y se utiliza en el mundo real. Una experiencia de usuario positiva es aquella en que se cumplen los objetivos tanto del usuario como de la organización que creó el producto. La usabilidad es un atributo de una experiencia de usuario satisfactoria, pero la facilidad de uso por sí solo no hace que una experiencia positiva para el usuario.

La «Interfaz de Usuario» (UI) es solo un componente de la «Experiencia de Usuario» (UX). El Diseño de la ‘Experiencia de Usuario» (UX) es el resultado combinado de muchos aspectos que podemos ver en la siguiente figura

Disciplinas del Diseño de Experiencia de Usuario – Dan Saffer

Igualmente, podemos ver las diferencias entre un Diseñador de Experiencia de Usuario que se enfoca en la Investigación y Diseño, un Diseñador de Interfaz de Usuario quien se enfoca en el Diseño (HTML+CSS) y un Desarrollador de Aplicaciones quien se enfoca en la codificación del «Back-End» (JS, .NET, JAVA)

Referencia de Diseño de Experiencia de Usuario (UX):  http://tinyurl.com/psppcn8

Principios de Diseño de UX: http://fransgaard.com/10-examples-of-uxdesign-principles/

Las practicas ágiles son actividades que son usadas para manifestar o implementar los principios y valores Ágiles. Existen numerosas practicas ágiles tales como Historias de Usuario, TDD, Pair Programming, Daily stand-up, etc., pero no existe un conjunto definido de practicas Ágiles.

Las metodologías de desarrollo ágil conocidas como Extreme Programming (XP), Scrum, Lean o Feature Driven Development (FDD)  consisten en un conjunto de practicas ágiles. Algunas como SCRUM, se enfocan mas en practicas ágiles relativas a la gestión; otras como XP se enfocan mas en las practicas ágiles técnicas.

Para conocer mas sobre muchas de las practicas ágiles, clasificadas por áreas como Lean, XP, Equipos, Scrum, Gestión del Producto, DevOps, Diseño y Pruebas, puede hacer clic en este el siguiente link: http://guide.agilealliance.org/subway.html

En el siguiente enlace puede encontrar una lista de Terminología y Practicas Ágiles: http://www.emerald-hill.co.uk/Agile Terms Glossary/engage.html

La División de Calidad de Servicio de la ASQ (American Society for Quality) ha publicado una lista 100 herramientas que pueden usarse para la mejora de la Calidad del Servicio, incluyendo una breve descripción de la herramienta o técnica y un ejemplo práctico.

Las herramientas están clasificadas por: Enfoque en el Cliente y Mercado, Enfoque en el Empleado, Comunicación, Entrega del Servicio, Liderazgo, Desarrollo Estratégico, Gestión de la Prestación de Servicios, Gestión de Procesos, Mediciones y Análisis, Gestión de la Información y Entorno e Infraestructura.

Puede ver la lista haciendo clic en: http://asq.org/service/body-of-knowledge/tools

«Si hubiera preguntado a la gente lo que ellos querían, ellos habrían dicho caballos mas rápidos»   — Henry Ford

Si Henry Ford hubiera preguntado a las personas lo que ellos querían, ellos nunca hubieran descrito el Modelo T. En 1908 la persona promedio no tenia ni el conocimiento técnico ni la visión para la concepción de un transporte a motor personalizado. Al mismo tiempo, sin embargo, si Ford hubiera hecho las preguntas correctas, la respuesta no habria sido ‘caballos mas rápidos’.

Generalmente un ingeniero, representante de ventas o ejecutivo insiste en una funcionalidad y lo justifica diciendo que muchos clientes/usuarios lo han requerido, limitando un análisis profundo necesario para determinar si deberiamos añadir la funcionalidad al producto.

Sin embargo, en las conversaciones con los clientes, no deberíamos enfocarnos en la funcionalidad. Debemos esforzarnos en entender los problemas que enfrentan. No son expertos en las características o soluciones; son expertos en sus experiencias y desafíos. Si les preguntamos lo que «quieren», son propensos a pensar en soluciones, interrumpiendo el entendimiento de todo lo importante de los problemas que enfrentan.

Puede encontrar información de los modos en los cuales muchas compañias toman decisiones sobre sus productos aquí:  http://blog.cauvin.org/2013/09/5-ways-companies-make-product-decisions.html

La Guia BABOK (Business Analysis Body of Knowledge) es el estándar reconocido internacionalmente para la practica de Analisis de Negocio. La versión 3 es un esfuerzo verdaderamente global que representa la práctica de del Análisis de Negocio a lo largo del mundo.

Puede participar en la revisión de la versión 3, ya sea de todo el documento o enfocándose solo en las áreas de su expertise y proporcionar retroalimentación al equipo principal. La mayor cantidad de personas de muchos países, industrias y compañías de todos los tamaños que contribuyan, hará que esta version de la Guía BABOK sea más completa.

Para participar ir al siguiente enlace:  http://www.iiba.org/babok-guide-v3-public-review/index.html