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

¿Más es mejor?

Anteriormente comenté sobre cómo pensar qué probar. Seguramente, la mayoría dirá que basándonos en el conocimiento (cuanto mayor mejor) del dominio y el producto, riesgos y amenazas, especificaciones disponibles de todo tipo, además de nuestra experiencia.

Con los objetivos de:

- Cuestionar y evaluar el producto.

- Focalizar los riesgos, entender y gestionar los cambios.

En muchas ocasiones, en los emprendimientos de pruebas, los testers nos encontramos ante la solicitud de entregar los casos de prueba preparados, o mostrar alguna evidencia de los mismos.

Lamentablemente, en algunas ocasiones, quienes lo solicitan no necesariamente tienen en claro qué significa planificar una prueba, por lo que puede existir la idea de que a más casos de prueba mostremos y ejecutemos, mejor será la prueba.

Pero sabemos que la prueba completa no es posible, como tampoco lo es un producto con cero defectos, por lo que aparecen importantes disyuntivas cuando pensamos nuestra estrategia de pruebas, el alcance de las mismas, y fundamentalmente cómo lograr el cumplimiento de los objetivos específicos, dentro de las restricciones existentes de calendario y recursos.

Una vez hayamos consensuado el alcance deseable y posible, cuando encaremos el diseño de las pruebas, tengamos o no que detallar los casos de prueba, la siguiente disyuntiva aparecerá continuamente durante el diseño: ¿Cuántos casos de prueba necesitamos?, ¿Hay una cantidad óptima? ¿Cuál es? ¿A más casos de prueba, mayor cobertura?

Algunas respuestas

Ha habido diversas investigaciones y se han elaborado modelos matemáticos para analizar la cantidad óptima de casos de prueba [1], o sobre la relación entre cantidad de casos de prueba ejecutados y cobertura de código lograda [2], o para elaborar métricas [3]. Valgan esos pocos ejemplos. Incluso se trabaja y ha trabajado en la generación automática de casos de prueba en base a heurística, ejemplo [4].
Pero algunas investigaciones proveen resultados sólo aplicables a casos puntuales, no fácilmente generalizables, o bien los resultados obtenidos muestran que la hipótesis planteada no es válida, o requieren un nivel muy detallado de análisis y mediciones, no siempre viable en el día a día.

Por lo tanto, volvamos al análisis que habitualmente hacemos los testers, sobre la información disponible, a partir de experiencia y técnicas.

Para pruebas de caja negra, las combinaciones posibles de comportamiento y datos que podemos calcular para un requerimiento expresado en casos de uso, se dan en función de las cantidades de casos de uso y sus pasos, las interfaces gráficas y las estructuras de datos relacionadas:

Cantidad de combinaciones = {#casos uso x #pasos x #reglas} +
+ {#pantallas x #objetos x #estados} + {#tablas x #tuplas x #instancias}

Si debemos probar las interfaces entre aplicaciones y/o servicios (lo que se suele llamar pruebas de caja gris), se agregan:

         Cantidad de combinaciones = {#interfaces x #parámetros x #valores}

        

Claramente, estas cantidades pueden ser sumamente grandes, aún sin pensar en agregar pruebas de caja blanca. Tanto la especificación como la ejecución de esas cantidades de casos, es prácticamente imposible aún con herramientas de automatización, y sin duda innecesaria, ya que muchos casos son redundantes.

De ahí la necesidad de:

•          Entender nuestro objetivo respecto a tipos y niveles de pruebas a efectuar.
•          Entender qué restricciones existen (fundamentalmente tiempos, recursos, ambientes).
•          Entender cuáles son las condiciones de aceptación y las funcionalidades críticas para los interesados y usuarios.
•          Entender cuáles son los principales riesgos a mitigar (producto, proyecto, contexto): a mayores riesgos, se impondrán pruebas más profundas o exigentes.
•          Diferenciar la funcionalidad según su prioridad, criticidad y complejidad, y su relación con los riesgos a mitigar.
•          Aplicar las técnicas de diseño que permitan acotar las cantidades de casos de prueba para acercarlas a los mínimos necesarios + otras variaciones de interés, según la exigencia que se requiera o sea posible imponer.

Casos de prueba vs exigencia de las pruebas – Pruebas de integración

Primer nivel de exigencia: riesgo y complejidad bajos

Preparamos casos de prueba en base a los casos de uso o funciones de bajo riesgo para:

1. Ejecutar al menos una vez cada acción de un curso normal o función;
2. Ejecutar cero (si aplica), una y más veces cada acción iterable de un curso normal o función;
3. Ejecutar al menos una vez cada curso alternativo del caso de uso o función;
4. Producir al menos una vez cada posible excepción.

Segundo nivel de exigencia: riesgo y/o complejidad medios

Preparamos casos de prueba en base a los casos de uso o funciones que consideremos de riesgo y/o complejidad media, para:

Ídem primer nivel más:

5. Introducir valores límite para cada dato ingresado en cada interacción de interés (técnica de diseño de casos basada en valores límite).
6. Ejercitar al menos una vez el comportamiento asociado a cada clase de equivalencia de interés (técnica de diseño de casos basada en particiones de equivalencia).
   
   

Casos de prueba vs exigencia de las pruebas – Pruebas de sistema

Tercer nivel de exigencia: riesgo y/o complejidad altos

Preparamos también casos de prueba en base a los casos de uso que consideremos de riesgo y/o complejidad altos y para condiciones o entradas no esperadas, tratando de cubrir los casos de uso especificados y escenarios de interés, y todo tipo de requerimientos, en función al alcance de la prueba planificado: técnicos, UI, funcionales, no funcionales, otros (accesibilidad, recuperación,…):

Ídem segundo nivel más:

7. Ejercitar al menos una vez la ocurrencia de cada regla para combinaciones complejas de condiciones (variables o clases de equivalencia de entrada) y acciones aplicables (salidas o porciones de proceso) (técnica de diseño de casos basada en tablas de decisión).
8. Ejercitar al menos una vez cada combinación estado-transición posible para las entidades que puedan modelarse con ciclos de vida basados en estados y cambios de estado (técnica de diseño basada en estado-transición).
9. Ejercitar otras relaciones causa-efecto de interés: listas vacías, primer o último elementos corruptos, parámetros faltantes en interfaces, valores nulos, expiración de sesión por diversas causas, etc.

Cuarto nivel de exigencia: Escenarios de uso

Ejercitar el producto tanto desde el punto de vista de las secuencias “técnicas” de utilización por parte de sus usuarios (no se puede modificar o dar de baja un registro que no se dio de alta; qué ocurre durante la navegación al dar back a una página durante una transacción, situaciones inesperadas, etc.), como de las secuencias “procedurales” que llevan a lograr objetivos (qué quiere obtener o lograr el usuario al utilizar una determinada funcionalidad).

1. Ejercitar las secuencias exitosas de funcionalidades o casos de prueba que reproducen diversas formas en que los usuarios harán uso habitual de las funcionalidades del producto. Por ejemplo, para hacer una compra en un sitio de comercio electrónico, tendrán que recorrer un catálogo de productos on-line, seleccionar, completar datos requeridos en el carrito de compra, efectuar la compra y pagarla exitosamente.
   
2. Ídem anterior para secuencias no exitosas. Por ejemplo, iniciar una compra cuyo pago es rechazado.
   
3.  Ejercitar posibles alternativas de interés. Por ejemplo, iniciar una compra y cancelarla en algún punto, habiendo o no ingresado los datos para su pago.
   
4. Ejercitar situaciones inesperadas o de stress de interés. Por ejemplo, caída de un enlace de comunicaciones durante el pago, servidor no disponible, etc.

Para tener en cuenta

·         La cantidad de casos de prueba o de casos ejecutados por unidad de tiempo no es significativa si se desconoce el contexto al que aplican.

·         Su calidad es más importante que su cantidad: La eficacia de los casos de prueba (ayudan a detectar defectos importantes) y su eficiencia (se ejecutan utilizando pocos recursos y permiten aislar rápidamente los defectos).

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

…… Continuará……
en próximas entregas, más datos sobre los datos
y sobre las técnicas de diseño de casos específicas
J

Hasta la próxima
Pilar

Ejemplos referenciados:

[1] OPTIMAL TEST CASE SELECTION FOR MULTI-COMPONENT SOFTWARE SYSTEM - Praveen Babu Kysetti, 2004

[2] Assessing the Relation Between Quantity of Test Cases and Amount of Code Coverage - Anju Bansal, 2014

[3] Measuring the Effectiveness of a Test - Harry M. Sneed, 2004
[4] Generación automática de casos de prueba mediante búsqueda dispersa – Blanco, Díaz, Tuya, 2006

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!!!!!

Ser o parecer

Entre los elementos básicos a tener en cuenta, planificar y diseñar al gestionar un área de QC o pensar una estrategia de pruebas para un proyecto o servicio específicos, no podemos dejar de lado los ambientes y datos de prueba necesarios.

Ambientes y datos de prueba ocasionan en algunos casos preguntas como “¿Realmente se necesitan? ¿No puede ser la máquina del desarrollador / ambiente de desarrollo? ¿Por qué no Producción antes de liberar?  ¿Un equipo potente les es suficiente? ¿No pueden crear sus propios datos, o traer una base / archivos productivos? …”,
o directamente objeciones como “Nunca los hemos tenido; en nuestro caso no es necesario; saldrá muy caro…”

Afortunadamente estas preguntas y objeciones son cada vez menos frecuentes. Sin embargo, aún pueden aparecer, y es parte de nuestra misión al gestionar un área de pruebas o un proyecto / servicio dados, ocuparnos seriamente de ambientes y datos de prueba. Desde contestar adecuadamente las preguntas y objeciones, pasando por saber diseñarlos, solicitarlos y gestionarlos.
Ellos contribuirán a la fiabilidad de nuestras pruebas. En definitiva, lograremos que lleguen a Producción productos donde las pruebas realizadas serán más representativas de lo que ocurre en la realidad, deseablemente con menos fallas evidentes u ocultas.

Hemos aprendido y enseñado habitualmente que al menos tres ambientes bien diferenciados son los mínimos recomendables:

• Desarrollo. Donde trabajan los desarrolladores  con todas sus herramientas.
• Pruebas. Donde trabajan los testers con sus propias herramientas y datos.
• Producción. Donde trabajan los usuarios con sus datos y donde las aplicaciones conviven con otras.

Y que deseablemente se agrega un cuarto ambiente entre Pruebas y Producción:

• Pre-producción. Donde pueden trabajar los usuarios con copias de sus datos durante las pruebas de aceptación, existirán algunos de los sistemas con los que convivirá la aplicación, se pueden dar capacitaciones y demostraciones sobre los productos a liberar o modificados, y se pueden realizar pruebas de requerimientos no funcionales.

Y la disyuntiva que suele plantearse es la del título de este artículo:
Ser o parecer.

• ¿Puede nuestro ambiente de Pruebas ser Desarrollo / Producción / Pre-producción, tal vez utilizando distintas instancias de los datos?
• ¿Pueden nuestros datos de prueba ser directamente los datos de Producción?
• ¿Cuánto se tienen que parecer los ambientes que nos suelen ocupar, Pruebas y Pre-producción, al ambiente de Producción?
• ¿Cuánto se tienen que parecer los datos de prueba que generemos a los datos productivos?

Lamentablemente no tenemos una respuesta terminante y taxativa a estas preguntas, sólo que deberían “parecerse tanto como sea posible”.

Y esa recomendación parte del sentido común, y de la necesidad y conveniencia de llevar a cabo pruebas que realmente diagnostiquen la calidad de los productos entregados. Al margen de considerar que muchos tipos de pruebas directamente no tienen sentido en ambientes o con volúmenes o variedad y tipo de datos no similares a Producción.

Como ya he mencionado, ambientes y/o datos mal configurados o estructurados, generan riesgos respecto a la calidad de nuestras pruebas. Entonces, ¿por qué no gestionar esos riesgos como gestionamos los del producto de software que estamos probando? ¿por qué no justificar la inversión necesaria en adquirir / configurar los ambientes y generar los datos de prueba, en función al riesgo de pérdidas potenciales para el negocio que ocasionan  pruebas no fiables?

Poder pensar, planificar y luego gestionar, ambientes y datos con los que controlamos la calidad de los productos de software, ayuda a mitigar adecuadamente los riesgos identificados en relación al producto, a su contexto y a su evolución. Entonces:

• Ajustemos los diseños y estrategias a lo importante para mitigar los riesgos y potenciales pérdidas, dentro de las restricciones existentes.
• Justifiquemos y negociemos alternativas para los ambientes y datos de prueba, mostrando los riesgos de cada una.

Hasta la próxima
Pilar

Nota: imagen tomada de faro - http://www.e-faro.info/

Acercarnos al negocio (Cuando el negocio es el desarrollo)

En la primera entrada mencionamos aquellas compañías cuyo negocio es desarrollar software para terceros.

Los modelos de trabajo: 

Tradicionales de desarrollo de software, y administración de proyectos si se trabaja sobre requerimientos conocidos.

La aplicación de un modelo exploratorio llevaría a que el desarrollador permanezca asociado al producto una vez que éste está en la calle, de modo de ir incorporando las funcionalidades que se van descubriendo como necesarias. Cosa que no siempre sucede.

La calidad: en este contexto significa cumplir con los requerimientos en tiempo y forma ante el cliente, y cumplir con los objetivos de negocio ante la propia compañía de desarrollo.

Además, en este caso, no formalizar los requerimientos implica un riesgo importante ya que el desarrollador tratará de aplicar un modelo de tipo “fábrica”, es decir trabajar contra requerimientos. Si éstos no están explicitados o hay que descubrirlos, el modelo mencionado no aplica, y se gasta tiempo y dinero inútilmente, atentando contra las expectativas de calidad que se tenían del proveedor.

Contexto: complicado y ordenado.

Saludos,

Raúl

TW: @RaulMartinez582

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

Arriesgamos o no arriesgamos

Según la Real Academia Española, arriesgar es “poner a riesgo” y un riesgo es una “contingencia o proximidad de un daño” que puede ocurrir.
También sabemos que además puede conllevar oportunidades, que no tienen un resultado negativo si se concretan.

Como testers en un proyecto, y más aún si nos toca liderar las pruebas, lo que ponemos a riesgo o arriesgamos en nuestra tarea, es:

● la calidad del servicio que proveemos,

● la adecuada evaluación de la calidad del producto que se liberará,
● nuestra “imagen” profesional.

Si bien lo tercero es importante (para nosotros o nuestras áreas), para nuestro cliente será más importante lo segundo porque además lo ayudará a lograr concretar algunas oportunidades; entonces, si percibe el testing como de baja calidad, posiblemente no vuelva a comprarlo (a nosotros y/o a otro proveedor interno o externo a su Organización).

Por lo que no deberíamos arriesgar el éxito de nuestra misión como testers, que en definitiva pasa por cumplir los objetivos del cliente, no sólo los nuestros. Para ello, debemos entender:

Qué tipo de testing tenemos que ejecutar,
en qué contexto,
en qué momento del proyecto / ciclo de vida del producto,
con qué restricciones y recursos,
con qué objetivos

Y 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 ello.

Y como la calidad es un concepto relativamente subjetivo y el testing nunca puede ser completo, en cada proyecto de testing estamos “arriesgando”.

¿Cuánto queremos/podemos arriesgar? ¿Cuánto quiere/puede arriesgar el cliente que contrata el servicio? Dependerá del daño posible, de cuán “cerca” se vea ese daño y de la gravedad de sus consecuencias. También dependerá de las oportunidades que el cliente cree tendrá con el producto, por ejemplo, introducir un producto novedoso y que le permita ganar mercado entre sus competidores.

El colaboramos a obtener un producto a satisfacción y con calidad suficiente,  sin duda depende de muchas cosas, pero entre otras, es importante la evolución mental de los testers, que puede estar en distintos estadíos según su experiencia y formación, según comenté en Probamos, pero… ¿evolucionamos?

En esa evolución, uno de los estadíos que es deseable que alcancemos tiene que ver con entender que no probamos para mostrar que la aplicación tiene defectos o que no los tiene, sino para reducir los riesgos percibidos a un valor aceptable.

Y el siguiente estadío lo alcanzamos al entender que el testing no es un acto, sino una disciplina mental que resulta en software de bajo riesgo, sin excedernos en el esfuerzo (y costos) incurrido en hacer las pruebas.

En definitiva, nuestro objetivo estará relacionado con gestionar los riesgos del software de la mejor forma posible, minimizando la utilización de recursos y tiempo, y previniendo o encontrando los problemas antes de que los encuentren los usuarios o clientes y se conviertan en usuarios o clientes disconformes. Lo que implica poner todo nuestro foco sobre los riesgos, para arriesgar menos al momento de liberar un producto.

En los párrafos previos, aparece varias veces la palabra RIESGO.
Y la necesidad de reducir los riesgos percibidos a un nivel aceptable.

En esto se basa el Risk Based Testing (RBT): el software nos expone a un conjunto de riesgos; el testing nos da información sobre el estado de esos riesgos y si se han controlado o limitado, a efectos de lograr una liberación (suficientemente) exitosa, o bajar la probabilidad de que ocurran problemas graves al liberar, en aquello fundamental para los interesados.

RBT comprende tanto la estrategia de planificación de las pruebas,
como la técnica de diseño propiamente dicha

Quienes hacemos testing, intuitivamente aplicamos algunas de sus estrategias y técnicas, aunque no las llamemos formalmente RBT… No dejan de ser cosas de sentido común, aun siendo éste el menos común de los sentidos…

¿Qué tester no ha pensado cuáles son las funcionalidades o características más riesgosas del producto que tiene entre manos, o qué situaciones se han dado en el proyecto de construcción que puedan significar riesgos para la estabilidad del producto?

Sin entrar en detalles respecto a RBT, sobre el que abunda la biografía, podemos resumir su enfoque en este gráfico:

Básicamente, muy similar a un proceso planificado de prueba.

¿En qué residen las grandes diferencias? 

En:

1) La forma de determinar el alcance inicial.

2) La forma de realimentar el diseño o el plan, en la medida en que aparecen nuevos riesgos o algunos se reevalúan.

3) La forma de diseñar los casos, a partir de los riesgos identificados, las fallas potenciales, y la manera de tratar de provocarlas.

¿Entonces?

ARRIESGUEMOS

Será la mejor forma de brindar un buen servicio a nuestros clientes, siendo eficaces y eficientes

Eso sí, hagámoslo sobre bases sólidas, y a partir de una buena evaluación de situación y riesgos del producto, los proceso, el contexto.

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