La norma ISO/IEC 25000 "Requisitos y evaluación de la calidad del sistema y del software (SQuaRE). Modelos de calidad del sistema y del software” sigue su camino

En este blog hemos publicado desde hace tiempo varios artículos sobre el tema Calidad de software e ISO/IEC 25000.

Quizás convenga hacer una actualización del estado presente del estándar.

Siguiendo el link http://www.iram.org.ar/index.php?IDM=44&IDN=745&mpal=no&alias=

encontraran la situación de los documentos que componen la norma y cuáles están ya traducidos a nuestro idioma.

Como muchos de Uds. conocen, el modelo de calidad planteado por este estándar, tiene su origen en trabajos previos sobre el tema y en estándares anteriores, siendo la ISO/IEC 9126 la serie más conocida a la que luego reemplazo la ISO/IEC 25000.

En nuestro país, si bien en los ámbitos académicos el modelo era conocido y enseñado, en el ámbito de negocios, la ley de software, al incluirlo como certificación valida juntamente con otros modelos de calidad de proceso (ISO 9000, CMM, y otros) lo popularizó. Para esta finalidad particular del estándar, a nuestro entender el tema no se expandió demasiado posiblemente por las exigencias de información previa que se requiere y otras consideraciones que escapan al tema de este artículo.

Sin embargo, y como lo reflejan varios artículos publicados en este blog, la propuesta del modelo es sumamente útil y práctica.

Quizás el “envoltorio” que le da el formato de un estándar ISO, asusta por su tamaño y formalidad, lo que hace pensar que se trata de una burocracia que solo agregará tiempo sin dejar algo práctico. No es así, la idea es sencilla y totalmente implementable.

Ahora bien, que ocurre hoy con el modelo.

Para aquellos que no lo visitan desde hace un tiempo, se ha agregado el tema de calidad de servicio con sus indicadores, se ha reemplazo prácticamente la documentación de ISO/IEC 9126, a la brevedad se publicará la nueva versión de Requerimientos de Calidad de sistemas/software (ISO/IEC 25030), un nuevo enfoque del modelo de calidad en uso y varios temas más que se fueron mejorando.

Los cambios tecnológicos y enfoques de trabajo tienen cabida en la norma en su estado actual y lo tendrán más aún en versiones futuras.

Como vemos, todo está en evolución, no nos quedemos atrás, luego no será sencillo (o posible) subirnos.

Saludos,
Raúl

@RaulMartinez582

Si me estrella contra el muro, es de calidad?... sigue la saga

A riesgo de ser pesado, sigamos con el tema anterior, que ha causado cierta reacción en Twitter, aquí y sobre todo en mí.

Imaginemos 2 stakeholders típicos (entre muchos) para un producto como el coche con su software.
La Autoridad de aplicación, por ejemplo la Autoridad de la ciudad y el Interesado. Por ejemplo yo, comprador del coche.

La Autoridad de aplicación le impone al constructor del coche/software, de aquí en más llamémoslo sistema (coche + software) sus requerimientos, que son restricciones de seguridad. Por ejemplo, ante una situación de riesgo, el sistema debe elegir el mal menor. Un caso, estrellar el coche contra el muro en lugar de atropellar a la anciana o la embarazada.

Obviamente, el otro interesado, Yo el comprador, pongo como requerimiento que el coche sea seguro y que no me mate, para decirlo rápidamente.

Ahora bien, el constructor del sistema como se manejaría con dos requerimientos tan enfrentados?

Por ejemplo que diría la promoción de su producto: “Compre este coche que es el más seguro y en la letra pequeña diría: tomaría la mejor elección para Ud. y el entorno que lo rodea.” Firme aquí. 

Leído entre líneas dirá, Ud. acepta que el coche lo estrellará contra el muro si eso es o que más conviene al entorno.

Qué le pediría seguramente su Product Manager. ”Haz esto, lo que pide la Autoridad, pero no mucho. Haz esto sin que se note. O saltéalo y si se da será un error de software”. Caso en el cual Ud. Desarrollador irá preso, pero el habrá logrado la promoción.

Bueno comparado con esto, nuestra tarjeta de crédito alcahueta mencionada en la entrada anterior será cosa de niños. :=)

Saludos,
Raúl

Nota 1: quién se atreve a opinar como uno de los 2 stakeholders????
Nota 2: el futuro nos aplasta, vean esta nota del diario El País de España:http://tecnologia.elpais.com/tecnologia/2016/07/01/actualidad/1467337732_779288.html

 Diseño de la Propuesta de valor

Es interesante ver como modelos y herramientas que tienen su origen en el “negocio” se adaptan a nuestra forma de descubrir, diseñar y probar la viabilidad de productos de software. 

Entre el cliente, inversor, usuario (interesado en general) y quien diseña y crea la solución, comienza a surgir un lenguaje común a través de modelos visuales que son comprendidos y compartidos por ambos. 

La intervención cada vez más importante de aspectos que ya no son sólo funcionales, sino emocionales –social y personal– que la solución debe contemplar es también un desafío para quien explora y diseña nuevos productos y servicios.

Nada de esto es nuevo, simplemente que ahora la tecnología y la inundación de propuestas que recibe el interesado nos lleva a la “nueva normalidad”: mejor, más barato, más rápido, más pequeño, más conveniente, más personalizable, hace que sea mucho más necesario tener estos temas en cuenta. 

Vamos despidiéndonos del famoso "usuario cautivo" de décadas atrás para construir soluciones para las personas que pueden elegirnos a nosotros o a otros. 

Ganará el mejor, quien comprendió más íntegramente los trabajos para los cuales el cliente "contrata" nuestro producto. 

Ya en la entrada de este blog Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder comenté acerca del contenido del modelo propuesto por el autor.

Ahora, en la presentación más abajo mostrada amplío la descripción del modelo con algunos de los pasos que este recorre y las herramientas que utiliza.

Value proposition design (brief presentation of A. Osterwalder new model) from Raúl Martínez

Las láminas 15 y 17 del pdf corresponde a este video: https://www.youtube.com/watch?v=NMacTuHPWFI

Espero sea de utilidad y genere en Uds. inquietud y curiosidad para seguir explorando.

Saludos,

Raúl

@RaulMartinez582

¿Los sistemas y productos de software actuales y el estándar ISO 25000 son compatibles?

Normalmente las normas y estándares parecen alejadas de los productos tan cambiantes que vemos hoy y las asociamos más con sistemas estables y en alguno casos críticos. ¿Es así? ¿Sólo sirven  para eso?. Trataremos de mostrar que no.

Cuando vemos un producto como una red social, un sitio de comercio electrónico, un juego, u otros de alta interacción con el consumidor / cliente / usuario, nos cuesta asociarlo con un estándar que habitualmente lo tenemos por algo burocrático, rígido, y pesado. Por ejemplo la familia de normas ISO 25000 de calidad de sistemas y productos de software, sucesora de la ISO 9126.

Sin embargo antes de descartar estas normas, deberíamos explorar si no contienen guías que nos permiten validar si estamos haciendo lo correcto, si contemplamos todo lo requerido, y fundamentalmente, si podemos hacer algo que luego podamos trasladar a otro producto de software o familia de productos  de software.

De todo esto trata esta presentación la presentación que adjuntamos.

Siguiendo brevemente un ejemplo, en este caso de comercio electrónico veremos como, las distintas consideraciones que tuvieron los diseñadores del software, son contempladas por la norma ISO 25000. 

Asimismo, veremos las novedades que hay a la fecha, octubre 2014, en esta importante norma.

La presentación se encuentra aquí:

Sistemas actuales e ISO 25000

Esperamos debatan y compartan estas conclusiones.

Saludos,

Raúl

@RaulMartinez582

¡Hoy volvemos al Super!

Continuemos con nuestra aventura en el supermercado  iniciada en un post anterior (Una visita al supermercado).

Como sus propietarios notaron una caída en las ventas se propusieron averiguar de cuánto era y a qué se debía dicha caída.

Más allá del indicador del monto de la caída, que era un indicador tardío, les interesaba saber si había alguna otra observación que les permitiera adelantarse a los problemas.  

Descartaron primero las obvias, precio, variedad, ubicación del local, etc., ya que en todas ellas estaban en iguales condiciones que la competencia.

Quedaba por entender entonces algo que estaba ocurriendo dentro del local, entre el cliente y la oferta de nuestro supermercado.  Pensaron varias alternativas, entre ellas:

•       Contar cuánta gente entraba y cuánta salía sin comprar nada.
•      Ver los tickets y entender en qué góndolas la gente compraba menos,  a igual precio e igual mercadería que la competencia, habría otros factores que no les convencían.
•      Detectar cuántos clientes vuelven a comprar luego de la primera compra (licencia poética).
•      Entender el tipo de cliente que normalmente atraemos y entender sus expectativas (qué le encanta y qué le disgusta).
•       .……

Podríamos seguir enumerando indicadores que le pongan valor al comportamiento del cliente y tratar de deducir de allí la experiencia  de compra que tiene.

--

Dejemos aquí al supermercadista preocupado y nuevamente hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Comencemos por la definición de requerimientos o exploración de las necesidades.

Si el comportamiento del usuario es más conocido y manejable nos permitirá la definición de requerimientos algo más precisa, si es menos conocido y manejable nos obligará a explorar.

Para ordenar el trabajo puede ser útil aquí el modelo Kano ⁽¹⁾, que nos dice habrá funcionalidad que el producto deberá tener, ya que si ellas nuestro usuario/consumidor ni siquiera lo considerará, habrá otras características que entre más tenga de ellas, más apreciará el producto y finalmente habrá otras que al descubrirlas le encantarán y eso hará que lo considere de calidad superior, y tal vez esté dispuesto a pagar más por él. Es una ayuda, al menos nos acercará a descubrir necesidades y algunas expectativas.

Pero qué ocurre cuando el producto está en operación durante algún tiempo. ¿Cómo podremos descubrirlas? Es una situación parecida a la de nuestro personaje del supermercado que quería verificar la experiencia del consumidor en su local. Buscaba medidas e indicadores que lo orientaran a qué cambiar y mejorar y a qué mantener. Nosotros también.

Dependiendo del tipo de producto/servicio que estemos tratando, algunos indicadores pueden ser parecidos, por ejemplo cantidad de visitantes convertidos en ventas.

Algunas alternativas de qué medir cuando el producto/servicio está operando las plantea la idea de calidad en uso propuesta por la ISO 25010, hoy con poco detalle todavía, pero ayuda. 

Nos hace preguntar por ejemplo:

• ¿Confía el usuario en el sistema?
• ¿Hace más cosas en menos tiempo?
• ¿Está satisfecho con el sistema?
•  ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
• ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?

En estas entradas: La calidad en uso e Indicadores accionables hay algo más sobre esta idea.

Posiblemente nuestro caso necesite algunos indicadores distintos, o más detallados, o de mayor precisión. Pero esta es una buena aproximación.

Dejamos entonces a nuestro supermercadista de la historia viendo cómo mejorar la experiencia de usuario de sus visitantes y, como él, entendamos que las expectativas al entrar al local, superadas o no, son lo que va a definir finalmente el futuro del negocio.

Viene de Equipos Multidisciplinarios
y de Una visita al supermercado

Saludos,

Raúl

TW: @RaulMartinez582

Referencias:

Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji (April 1984). «Attractive quality and must-be quality»

La ovación de pie

Es cada vez mayor el componente social en los servicios y productos de software. El aspecto de procedimiento, que debe existir y operar correctamente, va camino a ser secundario.

Una simple intranet corporativa incorpora el botón “me gusta” en su diseño para poder mostrar nuestra aceptación o no sobre lo que leímos. 
Este comportamiento que parece simple, hacer  un click en un icono, analizado, puede revelarnos aspectos que nos interesan para diseñar un sistema competitivo.

Para explicarlo con palabras sencillas el ejemplo de la “Ovación de pie” ^{(ver 1,2)} es útil.

Imaginemos que queremos tratar de entender por qué la gente aplaude de pie en algunas circunstancias y en otras no.

Una primera aproximación sería que la gente espera un nivel de calidad del espectáculo. Superado ese nivel, se levanta y aplaude, no antes.

Esta aproximación es útil, aunque demasiado simplificada. Por ejemplo asume que la gente está ubicada en un único lugar puntual, lo cual no es real. Asume también que la gente no se conoce entre sí, es decir que cada uno actúa sin considerar a su vecino, lo cual tampoco tiene que ser así.

La realidad es más compleja. La gente se distribuye en la sala y, posiblemente, si reconoce una cara familiar y puede, tratará de sentarse junto a la persona conocida. Asimismo un grupo de personas que se conocía previamente podrían ir juntos a la función.

Todo esto hace que el comportamiento de la persona sea distinto en cada situación, y podría pensar:

•       No me levanto
•      No me iba a levantar pero como se levantó el de adelante y el del costado, me    levanto y aplaudo de pie yo también
•     Me levanto y aplaudo de pie porque mi amigo lo hizo
•     Fuimos juntos y nos pusimos de acuerdo previamente en ponernos de pie en      ciertos momentos de la función
•    ...........

Y así podríamos seguir.

Bien, ¿pero para que nos sirve entender todo esto?

Por ejemplo para diseñar una sala de espectáculos e influenciar en el comportamiento de los espectadores.

• ¿Me conviene poner más palcos? 
• ¿Me conviene poner gente “amiga” que se levante y aplauda en lugares visibles, por ejemplo los palcos, o en la primera fila y así inducir a que se levante el resto?
• ............

Tener a la gente aplaudiendo de pie, haría que la obra gane buena fama en la prensa y así vender más entradas para las funciones futuras y también más caras.

La conclusión: 

Nuestro trabajo no consiste en imponer un procedimiento estricto de comportamiento, que en el caso del espectáculo sería imposible. Sino proveer una plataforma para que los intervinientes desarrollen sus acciones y tratar que se genere el comportamiento que yo espero. Dirigir esas acciones hacia nuestro objetivo, por ejemplo que una visita se convierta en venta, es lo que debemos aprovechar.

Reglas simples, levantarse o no para aplaudir, presionar o no el “me gusta”, poner o no el HT, pueden desencadenar acciones complejas entre participantes, que se conocen o no, pero que están conectados.

La calidad del sistema, medida en un indicador como el antes mencionado (convertir visitas en ventas) sólo puede verse cuando el producto esté en uso, pero seguramente las formas de inducirlas pueden estudiarse antes. 

Podemos pensar "que no es mi caso....., que yo no hago sistemas así.....", tal vez, por ahora. Recuerdan el dicho de la luz al final del túnel, puede ser la salida ...o la locomotora que viene.

Saludos,

Raúl

TW: @RaulMartinez582

Referencias:

1. Complex Adaptive Systems. Page, Miller, 2007 Princeton Univ Press

2. Is Twitter a Complex Adaptive System?. Venessa Miemis 

Exploradores

Este post de Seth Godin "Perfection or exploration" encaja exactamente con este post nuestro "Acercarnos al negocio (exploradores)"

Saludos,

Raúl

TW: @RaulMartinez582

Acercarnos al negocio (con el cliente adelante)

Continuando con la relación entre el tema de acercarnos al negocio y su relación con la calidad del producto veamos el segundo caso. 

 Aquí el usuario / consumidor (introduzco este término), opera el producto con el cliente frente a él, disponiendo de una cantidad de opciones ej. : caja en el retail, terminal de cajero en bancos, tablet del visitador médico frente al médico, o bien es directamente operado por el usuario / consumidor final, por ejemplo un home banking desde su smartphone.

La finalidad de la empresa: sin ser su actividad principal, tiene a los productos de software como un elemento vital en su negocio, porque soportan la operación y además soportan un servicio, por ejemplo, un canal de ventas / comunicación con sus clientes.

Los requerimientos: conocidos, pueden estar especificados con cierta precisión por adelantado. Habrá alguna definición sobre objetivos de atributos de calidad, siendo éstos más importantes que en el patrón de back-office.

Los usuarios: conocidos, algunos internos, con el mismo patrón que de back-office y otros externos, clientes, que disponen de un menú variado de opciones a realizar con el producto.

Los modelos de trabajo: tradicionales de desarrollo de software y administración de proyectos funcionan correctamente en este entorno para las actividades de tipo back-office y para las de interacción.

Hay atributos de calidad que deben cuidarse más y valorizarse y otro factor a considerar que es la competencia. Si bien los clientes de un home-banking no son clientes cautivos (la relación cliente / banco va más allá de la interacción con nuestro producto) aun así la competencia incide.

La calidad: en este contexto significa cumplir con los requerimientos predefinidos del producto y del proyecto, estar atentos a las observaciones que puedan llegar de los clientes a través de una mesa de ayuda y vigilar todo lo relativo a la calidad en uso, de aquí la importancia de valorizar los atributos de calidad.

Acercarnos al negocio: vale todo lo mencionado en la entrada anterior sobre conocimiento de productos, tecnología, etc., agregando que conviene incorporar indicadores accionables que muestren la relación negocio-producto. Por ejemplo, cuántos clientes abandonaron la operación de consulta de saldo?, y cuál fue el motivo? Se puede rastrear el motivo al sistema/software que atiende la consulta?.

Contexto: seguimos en complicado pero ordenado.

Para una explicación más amplia de estos contextos ver http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

Post relacionados

http://ideassobresoftware.blogspot.com.ar/2013/10/acercarnos-al-negocio-back-office.html

Saludos,

Raúl

TW: @RaulMartinez582

Fotocopiadoras, calidad y negocio

La calidad sin entender ni ayudar directamente al negocio es sólo un  ejercicio intelectual que finalmente terminará por ser abandonado.

¿Cuántos proyectos de “mejora” se abandonan, se olvidan o simplemente se ignoran?

Difícil saber el número pero seguramente son más de los que terminan con éxito.

Evitando ser negativos veamos entonces los que concluyen exitosamente y se sostienen en el tiempo (como en todo lo importante no sólo es llegar sino mantenerse).

La calidad por la calidad misma es algo vacío. Puede ser de interés intelectual, pero de poca utilidad para la empresa. Podremos sobrevivir un tiempo, pero finalmente alguien pensará: ¿Por qué estamos gastando en eso? (“eso” es nuestra mejora) y nuestro presupuesto desaparecerá para ser reasignado a otras áreas.

¿Pero por qué ocurre esto? No les interesa la calidad (la excusa más fácil que tenemos a mano).

No creo que sea eso, que no les interese, simplemente no logran conectar nuestra propuesta de calidad con el negocio de la Compañía.

Entonces, excepto que la mejora, certificación o como sea que se corporice sirva para lograr un beneficio (por ejemplo una subvención, baja de impuestos, ingresar en mercados donde no nos conocen y el certificado/evaluación es requisito, etc.) caso en el cual ayuda al negocio, difícilmente se mantendrá. Es un gasto, por lo tanto tratará de reducirse.

Podríamos seguir pero creo que quedó claro.

¿Cuál es entonces el camino para que realmente un movimiento de calidad se instale y permanezca en la Organización?

Mi respuesta es: entendiendo el negocio en el que estamos (no siempre todos en la empresa lo tienen en claro) y diseñar las acciones de calidad para ayudar a ese negocio.

Podemos tomar modelos pre-hechos y  adecuarlos (CMMI, ISO 9000, ISO 25000 y otros) o desarrollar  algo propio siguiendo la idea de calidad que el negocio necesita.

Pero siempre, al menos en este razonamiento, el negocio está primero y la calidad es la que requiere para competir.

Finalmente la parte dura. Nosotros o nuestro sector seremos reemplazables cuando lo que ofrecemos es lo mismo que ofrece un tercero (y hasta posiblemente más barato), pero difícilmente nos podrán reemplazar si formamos parte del negocio, lo entendemos y lo ayudamos.

Pero eso hay que ganarlo, si seguimos encerrados en nuestra zona de confort técnica y pensando que la responsabilidad del negocio es de otro y no nuestra, finalmente nos van a reemplazar.

Que lo del reemplazo está lejos, puede ser, la fotocopiadora parecía y fue un excelente negocio durante bastante tiempo. Pero hoy, ¿invertiríamos en un negocio de fotocopiadoras?

               

Saludos,

Raúl

TW: @RaulMartinez582

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.

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