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

Hace unos minutos puse este mensaje en @RaulMartinez582 de twitter.

Muchos lo deben conocer, pero igual es interesante http://moralmachine.mit.edu/ . Qué sería aquí calidad de producto?

Como saben varios de este grupo, estoy bastante (muy) comprometido con el tema calidad de software y por eso traigo este comentario que como digo más adelante hoy todavía parece lejano.

Lo que muestra esa encuesta/consulta del MIT del link previo, nos hace pensar entre miles de cosas más, a que llamaríamos “calidad de un producto”, en este caso el producto coche con todo su software dentro por ejemplo.

Como situación, quizás límite, dejaría de ser de calidad el coche y su software, si me estrella contra el muro de contención para no atropellar a la embarazada o a los niños? Seguramente esa no fue mi necesidad a satisfacer, una de las definiciones de calidad, al comprarlo.

Parece un problema no muy cercano y filosófico, alejado del día a día. Pero ya está aquí, en el “mainstream” como le dicen y mañana nosotros mismos nos encontraremos desarrollando el software para la tarjeta de crédito que nos preguntará ¿Está seguro que quieres comprar esa tontera con el nivel de gastos que tienes” . Tampoco fue mi intención que el plástico me interpelara pero allí está haciéndolo. Se nota que es de calidad. :=)

Saludos,
Raúl

 

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

Calidad no es testing, ni procesos, ni certificaciones

Calidad no es testing, ni procesos, ni certificaciones, es más. Es ser competitivos, en aquello que nos hará crecer. 

Parece obvio recordarlo pero calidad no es ninguna de las tres cosas enumeradas, posiblemente porque tenga que ver más con las expectativas que con los requerimientos. 

El testing nos permitirá, sobre el entregable en prueba, comprobar si este cumple o no un requerimiento. Los procesos nos dirán cuál es la mejor forma, o la más adecuada para mi organización de realizar una actividad y las certificaciones nos permitirán conocer y en algunos casos ayudarnos a aplicar buenas/mejores prácticas para llevar adelante una disciplina determinada. 

Pero una expectativa es creer o sentir que algo resultará o se comportará de una manera determinada. Difícil de moldear como requerimiento ya que es algo asociado a las personas y sus emociones. 

Ahora bien, la calidad es en gran medida percibida a través de expectativas, una de ellas es que el producto/servicio cumpla los requerimientos, pero es eso, sólo una. 

Cumplir entonces los requerimientos nos hará crecer hasta un punto, podemos llamarlo hasta lo estándar. Pero ser competitivos implica pasar ese punto y sobresalir entre los iguales.

Saludos,
Raúl
@RaulMartinez582

Sobre nuestra misión como testers

Seguramente lo primero que nos han transmitido o se nos ocurre es que nuestra misión es encontrar defectos y/o  lograr entregar aplicaciones libres de defectos. 

Pero esto es sólo una pequeña parte y es una visión muy acotada del aporte de valor que nuestro trabajo puede brindar a una Organización si es bien entendido y encarado (y recordemos que no existen aplicaciones libres de defectos, a lo sumo, si hacemos bien nuestro trabajo, estarán libres de los defectos importantes y relevantes para los interesados).

Por otra parte, fuera de considerar únicamente lo que nosotros pensamos que es testear, tenemos que tener en cuenta qué esperan de nuestro servicio o actividad quienes nos contratan o convocan, qué expectativas tienen:

• ¿Por qué una organización cree que es valioso tener un área de testing o contratar ese servicio en un proyecto?
• ¿Qué espera obtener como retorno de su inversión en el área o el servicio?
• Mejor calidad en sus productos
• Clientes o usuarios satisfechos
• Software “cero defectos”
• ….
• Todas las respuestas anteriores…
• ¿Qué espera que hagamos?
• Prueba durante el ciclo de vida de desarrollo de un producto
• Prueba de homologación de un producto adquirido
• Pruebas de atributos de calidad específicos, seguridad, performance, otros
• ….
• Todas o algunas de las respuestas anteriores…

Difícilmente podamos cumplir los objetivos de quienes nos convocan o contratan, sean clientes internos o externos a nuestra organización, si no identificamos claramente nuestra misión:

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, ….

En otras palabras, si no entendemos para qué nos llaman, mal vamos a poder cumplir las expectativas. Las expectativas y las percepciones del cliente y otros interesados podrían entonces diferir mucho, con lo que podrían concluir que hacer testing no aporta valor, o que nuestros servicios no aportan valor.

Y esto es también uno de los orígenes de la “resistencia” que encontramos en algunos proyectos y una posible fuente de malos entendidos o conflictos entre los integrantes de un equipo de proyecto. 

El “no pensé que iban a probar a este nivel de detalle” o “no pensé que iban a probar esto” o frases similares, son objeciones que típicamente aparecen cuando algunos miembros del equipo de proyecto no entienden por qué estamos ahí, pero también reflejan que los  primeros que tenemos que tener clara nuestra misión somos nosotros, para aplicar nuestras mejores técnicas, prácticas, herramientas, imaginación, conocimientos, ética, para lograr cumplir esa misión.

El testing es un servicio. Dada esa definición, para poder brindarlo “con calidad” (o sea cumpliendo las expectativas del cliente) necesitamos:

• Entender expectativas y objetivos del cliente y otros interesados (pueden ser diferentes).
• Cuestionar y evaluar el producto.
• Focalizar los riesgos, entender y gestionar los cambios que afecten al servicio (en el proyecto, el producto, el contexto).
• Investigar, explorar, proveer feedback.
• Confirmar, comunicar.
• Aprender, seguir capacitándonos.

Así ayudaremos a completar el proyecto entregando un producto útil y exitoso para todas las partes. Para lograrlo es fundamental una buena comunicación y relación con todos los interesados por parte del equipo de proyecto, así como lo es entender el beneficio que brindará al negocio.

La buena comunicación ayudará a lograr que los interesados transmitan mejor sus expectativas y necesidades, se involucren más en el día a día del servicio y reciban finalmente un producto que perciban como de calidad, sin tantos tropiezos.

En relación a estos puntos, habría seguramente mucho más que decir y cada uno puede tener su propia visión.

Pueden ver también si les interesa el tema una discusión en el blog de James Bach, que aunque siendo de 2006, considero muy valioso leer:  

Question: Tester’s Freedom of Thought

Nota: Originalmente publicado en excelza el 18/10/2009

Sobre la belleza

Algo que los testers hemos aprendido, a veces duramente, es que "LA BELLEZA ESTÁ EN LOS OJOS DEL OBSERVADOR", y de igual manera, la calidad de un sistema o producto de software puede medirse con una vara que tiene diferente medida según el interesado al que consultemos.

Para nosotros, entonces, el dicho pasa a ser "LA CALIDAD ESTÁ EN LOS OJOS DEL OBSERVADOR".

Relacionado con la belleza, también hemos aprendido que no siempre nuestra profesión o nuestras actividades son consideradas bellas, ya sea por otros miembros de los equipos de proyecto en que trabajamos, o incluso por estudiantes y futuros profesionales, que miran el testing como una actividad de segunda categoría.

Sin embargo, para nosotros el testing ES BELLO, ES interesante, ES desafiante.

Buscando bibliografía, di hace un tiempo con este libro, que si bien no es un libro técnico, es muy interesante por la diferente y sin embargo común temática y por las definiciones de muchos especialistas de qué es BEATIFUL TESTING para ellos. O qué encuentra bello cada uno, en relación a nuestra tarea de todos los días.

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) by Tim Riley and Adam Goucher (Paperback - Oct. 22, 2009)

Según aclaran los editores, el libro no es una colección de how-to's, ni una colección de case-studies, y las regalías por su venta son donadas a una campaña de Naciones Unidas para la lucha contra la malaria en África.

Recopila ensayos de diversos profesionales, agrupados a lo largo de tres temáticas; cada ensayo es un capítulo. Las temáticas son:

·                     Los Testers, sus características y su interacción con otras áreas (capítulos 1 a 4);

·                     El Proceso, qué hace el tester y por qué (capítulos 5 a 17);

·                     Las Herramientas que ayudan a los testers a hacer su trabajo más eficazmente (capítulos 18 a 23).

Considero interesantes a nivel general, los capítulos siguientes y las definiciones de BELLEZA de sus autores:

Capítulo	Autor(es)	Título	La Belleza del Testing está en…
1	Linda Wilkinson	"Was it good for you?"	…La alegría de la exploración y el placer de la caza; Mantener esto siempre vivo en los testers, fomentarlo y premiarlo adecuadamente.
2	Rex Black	"Beautiful Testing Satisfies Stakeholders"	…Conocer a los interesados; Conocer sus objetivos y expectativas; Establecer métricas para medir objetivos y expectativas de los interesados (belleza externa); Establecer métricas para medir objetivos y expectativas de las pruebas (belleza interna).
6	Emily Chen y Brian Nitz	Bug Management and Test Case Effectiveness"	…Administrar los bugs, y medir la efectividad de los casos de prueba, de la forma más simple posible.
11	Murali Nandigama	"Change-Centric Testing"	…La eficiencia, no en el esfuerzo: entender qué se debería probar, y saber que eso es lo que se está probando.
12	Karen N. Johnson	"Software In Use"	…Que en este mundo imperfecto, la gente hace sus mejores esfuerzos para generar productos que importan, y cada uno de esos productos necesita gente que los sepa probar. (Este artículo se refiere en particular a software embebido en dispositivos médicos).
13	Chris McMahon	"Software Development is a Creative Process"	…La naturaleza artística de este trabajo: La construcción de software es un proceso estético, es la labor de interpretación de un artista, y el testing es la evaluación de esa interpretación. Por eso es bello.
18	Andreas Zeller y David Schuler	"Seeding Bugs to Find Bugs: Beautiful Mutation Testing"	…Poder experimentar con las herramientas disponibles para hacer test de mutaciones, y con ellas analizar la calidad de las pruebas automáticas utilizadas (poder hacer QA del QA).

Y en particular, creo que el Capítulo 1, de Linda Wilkinson, "Was it good for you?", debería ser leído por todos los líderes involucrados en proyectos, sean o no líderes de testing, y por los responsables de áreas funcionales de QA/QC.

Otros capítulos pueden resultar igualmente interesantes, en función al tema / proceso / herramienta que particularmente tratan y nuestro contexto inmediato.

¿Qué más encuentran bello en nuestro trabajo como testers?

Post originalmente publicado en excelza - 21-04-2010

 

¿Hace falta un terremoto?

Al leer tiempo atrás conceptos de BCM (Business Continuity Management) y de ITSCM (IT Service Continuity Management), no pude dejar de relacionar el tema con algunos aspectos de las pruebas de software, la evaluación y mitigación de riesgos y la gestión de servicios en general. 

Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en los estándares ISO/IEC 25000 SQuaRE de calidad de productos de software y su predecesor ISO 9126, el que pueden evaluarse según el proceso descripto por la norma ISO 14598, con los estándares ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI y con la evaluación de expectativas vs percepciones de la calidad de los servicios que analiza ServQual (Ver Referencias [5]).

En definitiva, esos aspectos se relacionan con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos, que deberían reflejar las expectativas de clientes y otros interesados y deberían ser posibles de cumplir vía el diseño de las aplicaciones. 

Lamentablemente, en muchas ocasiones, estos aspectos son ignorados o postergados en los proyectos de construcción de software, hasta que ocurren desastres, accidentes, ataques u otros incidentes más o menos críticos, que no siempre necesitan ser de la gravedad de un terremoto, pero que afectan a la disponibilidad de los servicios de TI, o incluso a la posibilidad o forma de restaurar esos servicios luego de algún evento que ha afectado a su continuidad.

¿Por qué digo que lamentablemente estos aspectos son ignorados o postergados?

Porque suele ocurrir que:

·         Los RNFs no están especificados, detallados y/o cuantificados.
·         Se considera que no es momento de probarlos, porque se puede hacer más adelante, o no son riesgosos, o no hay tiempo antes de salir a producción.

·         Se considera que no es momento de incluirlos en el análisis o diseño de la solución, porque se pueden agregar más adelante.
·         No se ha considerado qué puede ocurrir en ambientes productivos, con mayor interacción de componentes de HW / SW que en los ambientes de prueba.
·         No se ha previsto qué pasa con el crecimiento de tamaño de entidades de datos, y/o no se han previsto mecanismos de depuración de las mismas.
·         No se han previsto mecanismos de recuperación ante caídas, o lo más grave aún, no se ha analizado o diseñado para gestionar transacciones en las aplicaciones que lo requieren. También se considera que esto es algo que puede agregarse más tarde, o que lo provee el software.
·         No se ha planificado quién, cuándo, cómo se actúa ante algún incidente o desastre, o cómo se restaurará la operación normal del sistema, o en qué condiciones de pérdida de información podrá hacerse, o se desconoce incluso si toda la información necesaria está respaldada.
·         No se ha analizado si en función a las características y tipo de solución de software o de servicio ofrecido, existen disposiciones legales o regulatorias que apliquen a la misma.
·         Se considera que todo se resuelve agregando más o mejores servidores / disco / memoria / hardware de comunicaciones.
·         … y seguramente cada uno tiene un conjunto más de ítems que agregar a esta lista, a partir de su experiencia en diversos proyectos y organizaciones…

Mi opinión

Desde nuestro rol en las áreas de Calidad o como líderes de práctica, líderes de equipos, o como testers, es nuestra responsabilidad llamar la atención sobre estos temas al líder de proyecto, cuando consideramos que pueden haber sido descuidados, o no los encontramos representados en los planes de proyecto y/o de prueba. Al menos preguntar. 
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar, y finalmente a la satisfacción de las expectativas de los interesados. 

Está claro que los requerimientos no los ponemos nosotros, ni podemos constituirnos en los "guardianes de la calidad" impidiendo que se entreguen a producción productos que creemos no están totalmente probados o todavía presentan defectos… por algo hablamos de pruebas basadas en riesgos, de entregar productos con un nivel suficiente de calidad, de priorizar defectos y no corregirlos, de involucrar a referentes usuarios en esa priorización, etc…

Pero también considero que está totalmente en línea con nuestra misión como testers, capacitarnos y "evangelizar" sobre estos conceptos… antes de que nos golpee algún terremoto.

Post originalmente publicado en http://excelza.blogspot.com.ar/ - 11-10-2011

Referencias

1.    www.iso.org

2.    ISO/IEC 25000 SQuaRE
Software Engineering - Software product Quality Requirements and Evaluation

3.    www.itil.org

4.    Implementing ISO/IEC 20000 Certification - The Roadmap (ITSM Library) - Van Haren Publishing

5.    SERVQUAL: A Multiple-Item  Scale for Measuring Customer Perceptions of Service Quality  

6.    ISO/IEC TR 9126-3:2003 - Software engineering — Product quality — Part 3: Internal metrics.