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

Desarrollar software hoy

Desarrollar software hoy. Sólo controlamos lo encerrado en el círculo.
Partes tomadas de bi-modal IT del Gartner Group.


Raúl Martínez‏@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

Pensando qué probar

Anteriormente comenté sobre nuestra misión como testers. Entre las cosas que tenemos que hacer, obviamente unas muy importantes son:

- Cuestionar y evaluar el producto.

- Focalizar los riesgos, entender y gestionar los cambios.

Y pensando en cómo cuestionar y evaluar el producto, hay mucho que podemos leer, discutir, hacer o dejar de hacer, en relación a planificación, diseño, exploración, preparación de condiciones y casos de prueba, no preparación, no diseño, etc. 

Sabemos que hay muchas opiniones y criterios a este respecto, y diferentes “escuelas” o tendencias, pero, en definitiva, escribamos o no las condiciones y casos de prueba, las escribamos a un gran nivel de detalle o no, lo primero que aparece es la necesidad de entender en qué consiste el producto que tenemos que cuestionar y evaluar, y cómo focalizamos los riesgos que hayamos identificado en el marco de nuestra misión.

O sea, tanto cuando nos sentemos a explorar un producto, como cuando nos sentemos a diseñar condiciones y casos de prueba formalmente, tendremos que seguir algún orden o lineamiento para encarar estas actividades.

Algunos lineamientos

Algunos  obvios y probablemente explicitados, otros no tan obvios, o no tan fácilmente identificables, y en muchos casos no cuantificados (los números no implican orden):

1.    Requerimientos que el producto tiene que satisfacer: lo que dice “la caja”, los manuales o las especificaciones funcionales, otros requerimientos regulatorios o normativos.

2.    Usos típicos que el producto va a tener: lo que los usuarios tienen que poder hacer, en los distintos escenarios posibles; interacciones con procesos manuales, interacciones con otros sistemas.

3.    Atributos de calidad establecidos para el producto, muchos relacionados con requerimientos no funcionales, por ejemplo, los caracterizados por las normas ISO de calidad de producto (Norma IRAM ISO IEC 14598, la serie ISO 9126, y la norma ISO 25000 actualmente en desarrollo), o simplemente, las restricciones que puede imponer un pedido de usuario en relación a una arquitectura técnica. Entre otros, performance, usabilidad, mantenibilidad, escalabilidad.

4.    Posibles fallas, o cómo imaginamos, en base a experiencia, características del producto, arquitectura, catálogos de fallas conocidos, etc., que el producto puede fallar. Si bien esto es base de la técnica Risk Based Testing – RBT, implica, a nuestro criterio, más que una simple técnica: debe ser central a nuestras políticas y estrategias de prueba.

Qué nos sirve de base para pensar más allá de la especificación

1.    El requerimiento.
Si no está escrito, cuál podemos imaginar o relevar que es, desde el punto de vista del negocio.

2.    El contexto.
Qué parte de una función de negocio estamos viendo, en qué casos se utilizará, por qué tipo de usuario.

3.    Interfaces posibles.
Con otros sistemas, con otras transacciones, con otros aspectos del negocio, dentro o no del sistema que estamos probando.

 Cómo analizamos la especificación

• Pensándola como Caso de Uso (aunque no esté expresada así):

a.    Requerimiento que contribuye a resolver.
¿El CU corresponde a un requerimiento completo o a parte de él?
¿Cuáles son las demás partes?
¿Las vemos de alguna forma?
¿Podemos graficar las interacciones?

b.   Actores.
¿Quiénes, con qué permisos, tenemos que probar expresamente seguridad
(de acceso, funcionalidad, de acceso a datos)? 
¿Cómo llega el actor a esta funcionalidad?
¿Hay varios caminos posibles?
¿De qué dependen?

c.    Precondiciones.
Qué se tiene que cumplir para entrar al curso normal del CU.
¿Qué pasa si no se cumple alguna precondición?
¿Todas son obligatorias?  Si no, ¿está claro por qué o cuándo se requiere cada una?

d.   Poscondiciones.
¿Qué se tiene que cumplir para considerar que el CU terminó bien?
¿Qué pasa si esto no ocurre?
¿Cuál debe ser el estado final si se produce algún error?  ¿Está claramente expresado?
¿Qué pasa si no se cumple alguna poscondición?
¿Todas son obligatorias? Si no, ¿está claro cuándo puede faltar cada una?

e.   Curso normal: ¿es único y bien definido?
¿Hay alternativas al curso normal que no sean por errores o cancelaciones?
¿Qué reglas de negocio aplican? ¿Fórmulas? ¿Decisiones?

f.     Cursos alternativos:
“Positivos”, transacciones exitosas pero que se apartan del curso normal; “Negativos” debido a errores, interrupciones, cancelaciones, timeouts, reglas de negocio que no se cumplen, etc.
¿Podemos identificar qué los hace ser diferentes, y cómo debe terminar cada uno? (datos opcionales, mensajes especiales de error, distinto output, etc).

• Pensándola como proceso: Entradas -> Actividades -> Salidas:

a.    Cómo se inicia el proceso, o qué interfaces de usuario intervienen, reglas que aplican, consistencias puntuales de datos, obligatoriedad, puntos de menú… .

b.   Actividades, ¿qué se hace sobre los datos o con ellos, qué más se consulta o lee o modifica, bajo qué condiciones se hace cada cosa?

c.    Qué tiene que dar como resultados el proceso (y qué no), qué vuelve al usuario y qué puede quedar oculto pero necesitamos validar (estadísticas, logs, archivos temporales, …).

Cómo decidimos qué se justifica probar: Pensando en los riesgos

Es casi una deformación profesional para los testers (o debería serlo), pensar en los riesgos para determinar qué se justifica probar.  El objetivo es siempre utilizar los (escasos) recursos de prueba, en pasar por las funcionalidades o no funcionalidades críticas y/o importantes para la aplicación y para los distintos interesados y usuarios. 
Normalmente trataremos de incluir en las pruebas, en base a dicha criticidad / riesgo, casos de prueba para estas situaciones / atributos:

• Cursos normales bajo entradas habituales (mínimas obligatorias por ejemplo)
• Cursos normales bajo entradas no tan habituales (todos los campos no obligatorios)
• Cursos alternativos, al menos uno de cada uno, importante según las reglas del negocio
• Situaciones que puedan no estar contempladas (fallas de HW o SW o aplicación en algún punto relacionado, entradas o resultados muy fuera de rangos, zapato sobre el teclado…)
• Performance, seguridad, volúmenes, si se considera necesario o surge alguna duda
• Procesos periódicos
• Interacciones típicas y/o inesperadas entre procesos que se comunican
• ...

Obviamente la lista puede ser ampliada y completada con muchísimas variaciones y enfoques, pero nuestro tiempo siempre será escaso, por lo que tendremos que recortarla en función a las necesidades de interesados, producto, proyecto, y a las herramientas disponibles.

Nuestra mejor recomendación: Riesgos, triage de ideas sobre qué probar, y sentido común!!!!!

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

Acercarnos al negocio (back-office)

En post anteriores se mencionó varias veces el tema de acercarnos al negocio y su relación con la calidad. ¿Pero qué significa y cómo se hace?

Básicamente es entender cómo gana plata la compañía, qué la hace crecer, etc.

El negocio final de la Compañía puede estar cerca o lejos de los productos de software, nuestros productos pueden ser el back-office del negocio, uno de los canales de venta o el negocio mismo de la compañía. Los escenarios no son excluyentes. En otra entrada veremos aquellas compañías cuyo negocio es desarrollar software para terceros.

Comencemos por el primer caso.

La finalidad de la empresa: no está relacionada con el software. (ej. Una maderera) y nuestros productos de software soportan la operación del negocio (back-office).

Los requerimientos: conocidos, pueden estar especificados con cierta precisión.

Los usuarios: conocidos, incluidos en sectores / jerarquías, su demanda de información se conforma por niveles, es decir los niveles de más abajo registran las operaciones y la información se condensa para los usuarios de la capa superior. Pueden tener herramientas de apoyo, pero están cautivos del sistema que les construimos o adquirimos.

Los modelos de trabajo: tradicionales de desarrollo de software y administración de proyectos funcionan correctamente en este entorno.

La calidad: en este contexto significa cumplir con los requerimientos predefinidos del producto y del proyecto.

Acercarnos al negocio: es entenderlo, conocer las novedades tecnológicas de nuestra especialidad para mejorar el negocio, ayudar a la empresa a adquirir el sistema más adecuado técnicamente para su fin (desarrollo o enlatado),  soportarlo y administrar la tecnología.

Contexto: 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 

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.