Mostrando entradas con la etiqueta Enfoques. Mostrar todas las entradas
Mostrando entradas con la etiqueta Enfoques. Mostrar todas las entradas

sábado, 3 de octubre de 2015

5to Debate ISSADIO 21/10


Los invitamos a la edición número 5 de ISSADIO. Debates y exposiciones sobre temas actuales relacionados con el desarrollo de software.
Estos son los temas y expositores de la próxima reunión, como siempre en UNTREF / SADIO el 21/10 en Galerías Pacifico de 9.30 (café) a 12.30 (estrictos).


¿Es posible certificar ISO 9001 en serio usando agilidad?
La vigencia de la llamada Ley de Software trajo como consecuencia un boom de certificaciones de calidad, y es de esperar que su renovación por otros 10 años, continuará el auge de las certificaciones. 
En este marco ISO 9001 aparece como la certificación más requerida. El atractivo de los beneficios puede hacer que la tentación de "prefabricar" la certificación sea muy grande.
Es totalmente factible hacer una implementación de un sistema de gestión de la calidad, con principios y métodos ágiles, que sea sencilla minimalista y compatible con las normas ISO y los principios ágiles. 


Alvaro Ruiz de Mendarozqueta
Alvaro Ruiz de Mendarozqueta se desempeña como consultor independiente en temas de gestión, calidad, desarrollo, estrategia, planificación, capacitación e ingeniería del software. También es consultor en la Fundación Sadosky. Es Consultor Ejecutivo en Liveware IS y Consultor Principal en Taller Technologies en temas de gestión, calidad e ingeniería del software. Tiene más de 34 años de experiencia en desarrollo de software en áreas tales como telecomunicaciones, finanzas, seguridad pública, sistemas embebidos y transporte. Docente de posgrado en UTN FRC y UTN FRSF.v


Entendamos a la TI de hoy
Dado el crecimiento y la relevancia que han adquirido en la actualidad las Tecnologías de la Información, los responsables de áreas de TI tienen el desafío de alinearse con el negocio, generar valor y demostrarlo. Para poder hacerlo, es necesario evolucionar en el gobierno y la gestión de TI. Pero, como siempre, primero hay que saber de qué se trata.
¿Gobierno y gestión, es lo mismo? ¿En qué se diferencian? ¿Qué comprende cada uno? ¿Existe algún marco de referencia que los abarque? ¿Por dónde se empieza?

Guillermo Angelani
Profesional de nivel gerencial de Tecnología Informática, con más de treinta y cinco años de trayectoria. Ha conducido diferentes áreas de TI responsables de planificar, implementar y dar soporte a servicios de misión crítica. Además de la conducción, ha llevado a cabo profundas reorganizaciones de estas áreas, fijando no sólo el marco de gestión sino también su rumbo estratégico, siempre sobre la base de metodologías, estándares y buenas prácticas de la industria. También ha liderado múltiples proyectos de TI de gran envergadura y exposición


sábado, 23 de mayo de 2015

Videos de ISSADIO

Hemos realizado la primera reunión abierta de ISSADIO el 13/5 con muy interesantes resultados e ideas de como continuar diseñando este espacio de debate sobre los temas de Ingeniería de Software.

Le hemos querido dar un enfoque no exclusivamente técnico, sino más abierto. Creemos que en general muchas de estas prácticas fallan en su implementación por desconocer / ignorar el entorno en el cual deben aplicarse.

Por lo mencionado estamos incorporando temas sobre la importancia del software en el negocio, la organización de una empresa de software hoy, innovación, enseñanza de la ingeniería de software, user-experiencie y otros que se propondrán a medida que el espacio de debate avance.

Adjunto los videos de las dos primeras intervenciones, de Santiago Ceria y Diego Fontdevila.

@santiagoceria https://www.youtube.com/watch?v=f8I5yitXvpg 

Diego Fontdevila @dfontde https://www.youtube.com/watch?v=HOlLBKNLEMkv 

Saludos,
Raúl
@raulmartinez582

sábado, 18 de abril de 2015

¿Son compatibles los productos de software actuales con la norma ISO 25000?



Dada la velocidad con que se producen hoy los cambios en la tecnología, y consecuentemente en el software que las maneja, los tiempos de proyectos cada vez más cortos, la complejidad de determinar en forma precisa sus requerimientos y resultados, surge una pregunta: 

¿Puede ayudar un estándar de calidad de producto como ISO 25000 a una mejor comprensión del problema y a resolverlo teniendo en cuenta el contexto antes mencionado?



Saludos,
Raúl
@RaulMartinez582

sábado, 21 de marzo de 2015

Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder et al.

No es sencillo hacer comentarios y críticas sobre una obra que nos atrae y cuyas ideas en su gran mayoría se comparten. Aún así trataré de ser objetivo y expresar el resultado de la lectura del libro.

La propuesta


Value Proposition Design (VPD) continúa desarrollando la idea planteada en su primer libro por Alex Osterwalder et al., Business Model Generation(1) (BMG).

Si bien VPD puede leerse en forma independiente del primer libro, es útil leer BMG, dadas las referencias y el hecho de que VPD desarrolla en particular dos bloques de los nueve del modelo BMG, correspondientes a la generación de la propuesta de valor (VP) y el análisis del segmento de clientes (CS).

Como en el libro anterior, los autores plantean la explicación en una posible secuencia, por etapas: Canvas, Diseño, Prueba y Evolución, y también como en BMG, el trabajo real es altamente iterativo.

El libro elabora sobre algunas ideas conocidas y otras nuevas, empaquetadas de forma amigable y legible.

Las etapas

Canvas

Trafico tomado del sitio con material que acompaña al libro VPD

En el Segmento de Clientes (círculo del gráfico) se desarrolla la investigación de quién es el cliente, qué quiere hacer, qué le impide hacerlo y qué resultados lograría haciendo lo que quiere, y qué contexto social y emocional tiene el trabajo.


Este análisis es muy interesante en los ambientes actuales de desarrollo de productos, por ejemplo los tecnológicos, que están altamente relacionados con la persona cliente / consumidor y su circunstancia emocional y social.

La inclusión de los temas sociales y emocionales, además de los funcionales, denominados “trabajos” recuerdan la propuesta de Clayton Christensen para segmentación basándose en la circunstancia(2).

En la Propuesta de Valor (cuadrado del gráfico), se desarrolla la idea de qué resultados le permitiría lograr al cliente el utilizar el producto y qué obstáculos le ayudaría a eliminar para lograrlos.  

Los resultados que el usuario lograría – gains – se clasifican desde aquellos requeridos (sin ellos el producto no sirve) hasta aquellos no esperados (sorprende positivamente que los tenga). Una clasificación similar a la de Kano(3).

El ejemplo que los autores utilizan varias veces, es el análisis de la persona que lee libros de negocios. Interesante y sencillo de seguir.

Todo lo anterior, es decir el análisis del CS y de la VP se hace para determinar el ajuste, encaje o “fit” de nuestro producto/servicio a las necesidades reales del cliente.

La recomendación es que los análisis del CS y la VP se hagan por separado y luego buscar el encaje entre nuestra oferta y la necesidad del cliente de modo de ver su cobertura.

Diseño

El diseño es la actividad que intenta convertir las ideas de la VP en un producto/servicio tangible para el cliente.

La propuesta se basa en prototipar -- investigar la reacción del cliente -- volver a dar forma a la idea y probar de nuevo.

Los prototipos deben ser baratos, hacerse rápidamente y ser aproximados a la oferta que queremos hacer para validar su factibilidad y desarrollar VP alternativas.

Los autores proponen desde Diagramas en papel hasta el Producto Mínimo Viable (MVP) siguiendo a Steve Blank (4).

Es interesante determinar el origen de nuestra VP:

Podrá ser Push, resultado de una tecnología o una innovación que encontramos (la solución en busca del problema) o 

Podrá ser Pull, por una necesidad manifestada por el cliente (un problema en busca de solución).

Otro análisis que se hace comprueba cómo encaja la VP en el modelo de negocio. 

Teniendo en cuenta que para crear valor para el negocio hay que crear valor para el cliente y para seguir creando valor para el cliente, se necesita crear valor para el negocio (sustentabilidad). 

Prueba

Para una idea nueva, y dada su incertidumbre, el enfoque de experimento es más conveniente que el plan de negocios tradicional.

Todas las ideas deben ser probadas con el cliente y el resto de interesados como socios, canales, etc.. 

Integrando los principios de lean start-up, se comprueba primero la viabilidad del producto y la empresa se crea al final.(5)

Gran parte de la propuesta se basa en trabajar basados en evidencias. Antes de enfocarnos en cómo ayudar al cliente, debemos validar que el cliente necesita que lo ayuden en ese trabajo, que encuentra obstáculos para hacerlo y como se beneficiaría si lo logra.

También debe comprobarse que al cliente le interesa nuestro producto, y lo ve como un medio para evitar esos obstáculos y lograr los resultados.

Se proponen modelos de Tarjetas de prueba y  Tarjetas de aprendizaje, como registro de lo hecho y obtenido.

Una idea interesante es la del “call to action”, es decir, proponer al cliente que él realice una acción que puede ir desde tocar un botón en la pantalla hasta completar una encuesta o enviar un mail. Prueba un principio de interés en el producto, con una evidencia comprobable. Evitaríamos el "creo que le gustó" tan subjetivo.

Una lectura imperdible de este capítulo es el caso Owlet y el video de su presentación. Allí se materializa lo explicado en el libro.

Evolución

Esta parte final trata quizás el aspecto más complejo de la propuesta de valor: Lograr el alineamiento y compromiso de todos los interesados, explicando qué se quiere lograr, y proveer indicadores que muestren el progreso hacia ese objetivo.

Los modelos utilizados, BM y VPD, son muy útiles para comunicar y analizar avance basado en evidencias. Brindan indicadores objetivos de medición. Pero disponer todas estas herramientas no simplifica el problema, sólo ayudan.


Mis consideraciones

El libro continúa con la modalidad de ilustraciones y texto con diseño atrayente, muy útil por la claridad, aunque su estilo fresco y transgresor no cae bien a todos los lectores de estos temas. Los gráficos son claros, quizás algo más claros que en BMG (cuestión de gustos).

Los casos desarrollados en el libro en forma de ejercicios, son de ayuda. Los ejercicios que están en el sitio de apoyo son en varios casos preguntas y una calificación.

Hay todavía partes sin desarrollar del material de apoyo. Dado el tiempo en que se publicó deberían esperarse a la brevedad.

El sitio no es demasiado claro para navegar. La mezcla de soporte y propuestas comerciales no favorece. Son temas diferentes, el libro ya se compró y si se quiere ofrecer un seminario o software sobre VPD, la vía debería ser totalmente independiente.

Conclusión

El libro es interesante y completo. No aporta tremendas novedades pero ordena algunas conocidas, como hemos mostrado en las referencias.

Puede tener varias aplicaciones  aparte de crear/pensar un producto nuevo. Por ejemplo, como un modelo de análisis para manejar la incertidumbre en las aplicaciones de software actuales.

En mi opinión, hubiese convenido agregar más fuentes para quien quiera profundizar, y evitar algunas partes que se repiten.

Mi conclusión final es que: a quien ha leído y practicado BMG seguramente le aportará valor completando el detalle de dos importantes bloques, Propuesta de Valor y Segmento de Clientes.

A quien no leyó el libro anterior de estos autores, les puede ser de utilidad también por el orden, el lenguaje sencillo que aporta y la visión práctica de cómo crear productos con mayor probabilidad de que a la gente le interesen.

Si hay otras visiones y opiniones, bienvenido el debate.

Saludos,
Raúl


Raúl Martínez 



Referencias

(1) Business Model Generation, Osterwalder, Pigneur, 2009
(2) The Innovator's Solution: Creating and Sustaining Successful Growth, C. Christensen and M. Raynor 2003
(3) Kano Noriaki, Attractive quality (Kano method/Kano model)
(4) The four steps to epiphany. Steve Blank, 2013
(5) The Startup Owner’s Manual. Blank , Dorf, 2012

Nota

-Estos comentarios fueron hechos tomando la edición en inglés del libro
-Donde dice producto, equivale a producto/servicio
​

jueves, 26 de febrero de 2015

La Persona detrás de El Usuario


Al tratar de entender un problema a resolver o la solución a proponer, hablamos habitualmente de El Usuario. Eso es correcto según toda la literatura y es quien en última instancia utilizará nuestro producto/servicio.  

Bastante tiempo atrás nos preocupaba que este usuario recibiera un producto funcionalmente correcto, luego en la medida que la tecnología lo permitió sumamos cada vez más la idea de usabilidad y finalmente hoy debemos sumar algo más abstracto de definir que es la persona que está detrás de ese usuario.

Así como la propuesta Ágil nos muestra, entre varias otras cosas, la Persona que está detrás del Recurso en el Equipo de Trabajo y lo útil que es considerarla, deberíamos examinar cómo nuestro modelo de análisis de los problemas contemplan a la persona detrás del usuario y no sólo la funcionalidad que utilizará en la operación del producto.

Hay varios factores además del funcional, como el social o el emocional, que pueden finalmente transformarse en requerimientos tal como cualquier otro requerimiento funcional que conocemos.

En mi opinión este tipo de análisis es un movimiento imparable debido a la presión y difusión de las tecnologías que hoy ya están totalmente incorporadas al plano social y personal.

Sobre el tema, hay literatura interesante que si bien pertenece a lo que llamaríamos habitualmente libros de negocios, creo que son necesarios para el analista de negocios, el product manager , el arquitecto / desarrollador senior y por supuesto el emprendedor.

Los libros son estos:

--Business Model Generation, Osterwalder, Pigneur, 2009
--Value Proposition Design, Osterwalder, Pigneur , Bernarda, 2014
--The four steps to epiphany. Steve Blank, 2013
--The Startup Owner’s Manual. Blank , Dorf, 2012

Ninguno trae ideas revolucionarias, excepto el formato gráfico de los dos primeros utilizado para plantear temas áridos de negocios. Hay ideas de Christensen, Kim, Ries, etc. Bien condensadas y presentadas.

Conviene empezar por el primero Business Model.

Hay que tomarse un tiempo para leerlos, desprenderse del preconcepto de “eso es un  tema del negocio, no mío” y recordar siempre la frase de Steve Blank  -- get “outside of the building” -- que las cosas ocurren fuera de nuestro lugar de trabajo. Con la lectura no basta.

Hasta la próxima.

Raúl Martínez
rmartinez@rmya.com.ar


sábado, 21 de junio de 2014

Sobre la importancia de la camiseta

En estos días en que el mundial de fútbol está al tope de las noticias y es tema de conversación aún entre los no futboleros, solemos darnos cuenta del valor de los buenos equipos. No sólo de las figuras o estrellas con que se cuente, o de los buenos entrenadores. Y de cómo en equipo se logran victorias, que individualmente no es tan fácil o posible lograr.

Trasladando esto a los equipos de trabajo, es claro que si cada integrante “corre” hacia distinto lugar sin un objetivo común, lo que se logre será sumamente pobre.

Y esto es lamentablemente así y puede tener resultados a veces catastróficos, en los proyectos relacionados con TI, y en particular con la construcción de software. Seguramente cada uno lo habrá podido apreciar en diferentes contextos, proyectos, posiciones dentro de los equipos, posiciones dentro de las organizaciones para las que se llevan a cabo.

Si bien no siempre se requiere un equipo compacto y súper motivado, ya que hay tareas para las cuales se requiere un grupo de trabajo, por ejemplo en mantenimientos repetitivos y otras tareas más rutinarias (que no implica que sean sencillas), en un proyecto no ocurre lo mismo.


Cuando se lo requiere, hay varios aspectos de la gestión de proyectos relacionados con la gestión del equipo de proyecto, como por ejemplo:
  •          Roles necesarios
  •          Momentos en que debe involucrarse cada rol
  •          Capacitaciones / habilidades requeridas
  •          Mecanismos de incorporación y desafectación / proveedores
  •          Dependencias
  •          Responsabilidad / autoridad
  •          Motivación
  •          Incompatibilidades
  •         Localización
  •          Restricciones
  •          Aspectos culturales y de idioma
  •          …

Habitualmente nos preocupa tener a la gente adecuada y capacitada, y disponible cuando se la requiere en las diversas actividades.

Lo que no siempre miramos con igual cuidado, es lo relativo a aspectos motivacionales, buena relación y sinergia entre los miembros de todo el equipo, voluntad de cada persona para colaborar con otros y compartir sus conocimientos, ganas de “poner garra” para triunfar y llegar entre todos a lograr los objetivos del proyecto. Gente que esté “orgullosa de la camiseta”.

Pero cuidado, una gran mayoría de esos aspectos, no dependen sólo de cada persona, dependen de cómo gestionamos el equipo como responsables de hacerlo, de cómo escuchamos a la gente, atendemos sus dudas y problemas, colaboramos también al logro de sus expectativas personales, y al logro de un buen clima en el proyecto. También depende del contexto organizativo donde se desarrolla el proyecto y la cultura de cada organización participante.

Claramente, muchos podrán aducir que la mayoría de esos aspectos son muy difíciles o imposibles de manejar cuando los proyectos que actualmente se contratan se basan en menores costos, tercerización, distribución de pequeños paquetes de trabajo, desconociéndose el “todo” de los proyectos, etc.

Pero creo que cualquiera sea la forma de la contratación, es fundamental la formación del equipo, y lograr que se trabaje de la forma más satisfactoria para todos, cliente, proveedor, personas.
Y por favor, dejemos de llamar a nuestra gente recursos. Es el primer obstáculo que ponemos en el camino a construir un buen equipo de trabajo.

Hasta la próxima
Pilar


viernes, 18 de octubre de 2013

La prueba y el contexto del producto

Más allá de los procesos y los aspectos técnicos de la prueba de un producto de software (planificar o no, escribir o no casos de prueba, a qué nivel de detalle, tipos de prueba que conviene realizar, ambientes, herramientas, buenas prácticas, modelos de calidad, …), están los equipos de trabajo que llevan adelante estas actividades. Las personas que los forman. Sus intereses y expectativas. Sus conocimientos. Su sentido ético y profesional. Podríamos seguir la lista.

Quedarse sólo a este nivel pensando que la prueba del software es meramente algo técnico y repetitivo que hace un equipo de trabajo, nos hace perder de vista muchos aspectos del contexto que impactan en la calidad del producto de software percibida o “vivida” por los interesados.
Puede conducir al fracaso del producto cuando es recibido por ellos, o a su éxito.
Las expectativas de los interesados se satisfarán o se frustrarán. 
Los requerimientos explícitos e implícitos estarán cumplidos o no, probados o no, se irán corrigiendo los defectos remanentes y evolucionando el producto según nuevos requerimientos aparezcan o se detecten otras necesidades o tendencias, o aparezcan nuevas tecnologías.


Y los interesados son muchos, diversos, internos o externos a las organizaciones que construyen o proveen el producto de software, conocidos o desconocidos, sujetos a control respecto a la forma en que interactúan con el producto o no, interrelacionados de alguna forma, simple o compleja, … 

Los productos (tanto tangibles como intangibles), además de ser de diferentes tipos, se utilizan de diversas maneras, en diferentes ambientes y lugares, por diferentes personas.
Los productos de software actualmente se ejecutan en plataformas complejas, se interconectan, y se regulan en muchos casos.

Los productos existen porque brindan algún valor, son parte de algún servicio que los contiene, o incluso son el centro del servicio.
Por ejemplo, escribimos con un lápiz, pero también podemos hacerlo con otros productos; podemos elegir y cambiar, según el valor que nos brinde el producto en un contexto dado, como el material sobre el que queremos escribir, en qué color, cuán permanente queremos que sea lo escrito, qué tenemos a mano en el momento en que queremos escribir.
El valor es percibido o no por los diversos interesados, a lo largo de su construcción y su vida útil, y el servicio tiene también evolución, aspectos de calidad, y hasta posibilidades de desaparecer la necesidad que le dio origen.
Los productos pueden contribuir a reducir los riesgos o preocupaciones de los interesados, o a su éxito en algún aspecto. O no aportar valor en esos sentidos.

También la cultura de las organizaciones en que los productos y servicios se construyen y/o se brindan, ocupa un lugar preponderante en el contexto del producto y el servicio. Y su facilidad o aversión a encarar cambios de ser conveniente, respecto a la calidad, la fluidez del conocimiento, la estructura, procesos, herramientas, valoración de su personal, entre otros aspectos. ¿Está realmente la organización dispuesta a mejorar la calidad para ser más exitosa? ¿Querrá transmitir a su gente qué es lo que aporta valor al negocio, y cuándo lo está perdiendo? ¿Querrá analizar por qué y emprender un camino de cambios?

¿Tenemos posibilidades de aportar como testers algún valor al negocio sugiriendo pequeños cambios que muestren beneficios en el corto plazo? ¿Estamos dispuestos a hacerlo saliendo de nuestra zona de confort técnica?

Los aspectos más relevantes en el contexto de la calidad del producto de software mencionados están resumidos en este gráfico:



Pero vayamos otra vez a lo técnico. ¿Y con la prueba qué hacemos?

Fundamentalmente, no olvidar que todo ese contexto existe. Si no lo consideramos, pueden quedar aspectos importantes no cubiertos por las pruebas, aunque hayamos pensado, elaborado, ejecutado y/o automatizado cientos de casos de prueba. La identificación de amenazas y riesgos del producto quedará incompleta. La utilización del producto más allá de su construcción podrá tener defectos más o menos fáciles de corregir, pero lo que es más grave, no habremos brindado un buen servicio: proveer a los interesados información valiosa para tomar decisiones respecto al producto de software.  

Las pruebas exploratorias y las planificadas, en cualquier tipo de proceso, pueden alimentarse del contexto para elaborar las ideas y estrategias de prueba. Independiente de nuestra misión específica respecto a un producto dado.

Considerar el contexto nos permitirá brindar un servicio de testing valioso y perdurable, que nos motive a seguir brindándolo, y que motive a nuestros clientes, internos o externos, a seguir comprándolo.

También nos dará la satisfacción de haber contribuido no sólo a elaborar un producto estándar o bueno, sino que deleite.

viernes, 16 de agosto de 2013

Sobre Pruebas de software y Servicios de TI

Anteriormente comenté sobre nuestra misión como testers y sobre el enfoque del testing como servicio y como mitigador de riesgos. 
Entre lo que tenemos que hacer, obviamente es muy importante:

  • Cuestionar y evaluar el producto que estamos probando.
  • Focalizar los riesgos, entender y gestionar los cambios que ocurren en el proyecto o el contexto del negocio durante las pruebas.
  • Entender qué es prioritario probar, qué funcionalidad y atributos de calidad son imprescindibles para lograr la satisfacción de usuarios y clientes, bases sin las que no se obtendrá un producto de software útil y exitoso.
También me parece interesante compartir un enfoque más amplio del tema, mirado desde el punto de vista de los Servicios de TI.

¿Pará qué está TI?


Para brindar Servicios al Negocio

Según los conceptos actuales, un servicio es un:


Donde los Servicios van mucho más allá de la infraestructura, se apoyan en ella, y deben brindar valor a las áreas del Negocio que los requieren.


¿Qué significa esto para los testers?


La mayoría de los servicios que TI provee al negocio, incluyen sistemas de información computarizados, o se brindan utilizando sistemas o productos de software, ya sean paquetes adquiridos y parametrizados / adaptados, o desarrollos a medida.  De hecho, hay servicios que no podrían existir sin un sistema informático detrás.  Por lo que, para que el cliente reciba el resultado esperado del servicio, el sistema informático tiene que funcionar “bien”, o sea, dentro de pautas de calidad establecidas y acordadas.

Las pautas de calidad del servicio tienen que ver con:


Y aquí es entonces donde debemos poner foco, en el adecuado funcionamiento de los servicios, según su utilidad y garantía. Por ejemplo:


Lo que implica que, las pautas de utilidad y garantía contra las que verifiquemos y validemos las aplicaciones, tienen que contribuir a la calidad del servicio, y provenir de su definición (las mostradas no son las únicas posibles).

¿Cómo se construye un servicio?


Las actividades que conocemos como formando parte del ciclo de vida de la construcción de software, están realmente insertas en el ciclo de vida de construcción del servicio, al igual que deben estarlo nuestras actividades de verificación y validación en cada proyecto o cambio que lo afecte, actividades que deberán permitir diagnosticar acerca de la utilidad y la garantía:



En este sentido, nuestros oráculos de utilidad y garantía, sin duda tienen que estar en línea con, y originarse en, los requerimientos de utilidad y garantía del servicio.

En otras palabras, las aplicaciones que contribuyen a la arquitectura del servicio, tienen que tener funcionalidad y atributos de calidad tales, que el servicio pueda proveer la utilidad y garantía acordada con el cliente y requerida por los usuarios.

Durante la vida útil del servicio, la aplicación de software sufrirá cambios, consecuencia de los cambios solicitados al servicio, que deberemos evaluar, probar e implementar oportunamente, y que operará en un contexto en que tendremos que saber cómo gestionar los incidentes y problemas (del servicio y de la aplicación),  y ejecutar proactivamente mejoras y nuevos proyectos que contribuyan a que el servicio comprometido no se degrade, y siga brindando valor al negocio.

Algunas conclusiones posibles


Creo que esta visión “macro” del servicio, y las buenas prácticas de la industria (ITIL u otros modelos) o los estándares internacionales relacionados (ISO 20000 y otros como ISO 25000), son fundamentales para entender nuestro trabajo de testers y colocarlo en el marco adecuado.

Según nuestra misión (por ejemplo hacer pruebas durante la construcción, pruebas de homologación, o colaborar en pruebas de aceptación de usuarios), estaremos trabajando en un nivel distinto del clásico Modelo V de prueba, y nuestras actividades estarán más focalizadas en la prueba de una aplicación particular, o en la prueba conjunta de las aplicaciones que aportan al servicio completo. 

Lo importante es que podamos entender esa misión, y comprender lo que implica respecto a las pruebas a ejecutar.

La visión del Servicio de TI al negocio también debe darnos ideas respecto a:

·         dónde buscar los requerimientos a testear
·         cómo obtener la cuantificación de los requerimientos de calidad a evaluar
·         cómo gestionar ambientes, configuración, versiones
·         cómo liberar software
·         cómo atender incidentes
·         cómo gestionar cambios

En definitiva, lo que hacemos siempre puede ser mejorado, y la visión del Servicio de TI y su calidad son una excelente e imprescindible guía para nuestro trabajo.
Como testers, tenemos que asumir nuestro pedacito de la responsabilidad.


Nota: Revisión del artículo originalmente publicado en excelza el 11/12/2009

viernes, 2 de agosto de 2013

Probamos, pero… ¿evolucionamos?

Dado que el testing es un servicio, queremos ejecutarlo “con calidad”, para que nuestro cliente (interno o externo) nos siga contratando ese servicio, al entender él que colaboramos a obtener un mejor producto, lo que preserva su inversión.

Y recalco el colaboramos: todo el equipo de proyecto es responsable de la calidad del producto generado o modificado, de que se entregue a satisfacción de los interesados, y con una calidad suficiente para lograrla.
Componentes fundamentales en la calidad de nuestro servicio serán la continua capacitación de nuestros testers, y lograr que ellos evolucionen en sus procesos mentales, para ser cada vez más eficaces y eficientes.

Revisando algunas definiciones históricamente aceptadas de qué es probar, de qué es un tester, o qué es calidad, vemos que existe una importante evolución en esas definiciones o conceptos.  Esa evolución está muy bien resumida en, y tiene correlato con, las llamadas “fases mentales del tester”  que describe Beizer en su clásico libro "Software Testing Techniques":
  • Fase 0: El testing y el debugging son aproximadamente lo mismo. El propósito único del testing es ayudar a hacer debugging.        
  • Fase 1: El propósito del testing es mostrar que el software funciona.
  • Fase 2: El propósito del testing es mostrar que el software NO funciona.
  • Fase 3: El propósito del testing no es mostrar que funciona o no funciona, sino reducir los riesgos percibidos a un valor aceptable.
  • Fase 4: El testing no es un acto, es una disciplina mental que resulta en software de bajo riesgo, sin demasiado esfuerzo en hacer pruebas. 
          

Cómo nos impactan estas fases

 Aunque sea básico en cualquier curso de testing explicar axiomas como “nunca podemos encontrar todos los defectos”, “sólo podemos probar la existencia de defectos, no su ausencia” y otros, no siempre los entendemos, o no siempre todos los que están a nuestro alrededor en un proyecto los entienden o aceptan. Pese a que desde que Beizer describió estas fases, la profesión se ha difundido y avanzado mucho. Al igual que el entendimiento de la necesidad de prevenir los problemas de  calidad, mejorar procesos y productos, y hacer pruebas.

Por lo tanto, dependiendo de la madurez de la organización en que estemos trabajando, en muchos casos surgirán problemas a la hora de definir / pedir lineamientos / consensuar mecanismos de:

  • Separación de ambientes (probemos en producción / probemos en desarrollo)
  • Control de configuraciones (para qué?)
  • Control de versiones (seguro que se necesita?)
  • Registración y seguimiento de defectos (sólo luego de que los desarrolladores los aceptan…)
  • Conjunto básico de métricas (horas de trabajo, qué más?)
  • Criterios de reporte (sólo los defectos importantes, o quedaremos mal!!!)
  • Criterios de planificación (lo más difícil o complejo al final, testing sólo al final…)
  • Priorización de defectos / diferencias Severidad-Prioridad (es lo mismo!…)
  • Criterios de finalización de pruebas (fecha fija / cero defectos!!)
  • ….

La imposibilidad de consensuar sobre estos puntos, afecta a la calidad de nuestro trabajo, y a nuestra “calidad de vida” durante los proyectos.  Pero lo más grave, es que dificulta cumplir el principal objetivo del testing, que es el que se logra cuando se llega a Fase 4:

Ayudar a construir software
con la funcionalidad y atributos de calidad requeridos,
entregándolo a tiempo,
con costes que lo hagan financieramente posible,
y logrando la satisfacción de usuarios, clientes y otros interesados

Un punto muy importante sobre el que volveré, tiene que ver con la Fase 3: reducir los riesgos percibidos.


Nota: Revisión del artículo originalmente publicado en excelza el 21/01/2010