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

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

Probamos, pero… ¿evolucionamos?

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

Y recalco el colaboramos: todo el equipo de proyecto es responsable de la calidad del producto generado o modificado, de que se entregue a satisfacción de los interesados, y con una calidad suficiente para lograrla.

Componentes fundamentales en la calidad de nuestro servicio serán la continua capacitación de nuestros testers, y lograr que ellos evolucionen en sus procesos mentales, para ser cada vez más eficaces y eficientes.

Revisando algunas definiciones históricamente aceptadas de qué es probar, de qué es un tester, o qué es calidad, vemos que existe una importante evolución en esas definiciones o conceptos.  Esa evolución está muy bien resumida en, y tiene correlato con, las llamadas “fases mentales del tester”  que describe Beizer en su clásico libro "Software Testing Techniques":

• Fase 0: El testing y el debugging son aproximadamente lo mismo. El propósito único del testing es ayudar a hacer debugging.        
• Fase 1: El propósito del testing es mostrar que el software funciona.
• Fase 2: El propósito del testing es mostrar que el software NO funciona.
• Fase 3: El propósito del testing no es mostrar que funciona o no funciona, sino reducir los riesgos percibidos a un valor aceptable.
• Fase 4: El testing no es un acto, es una disciplina mental que resulta en software de bajo riesgo, sin demasiado esfuerzo en hacer pruebas. 
        

Cómo nos impactan estas fases

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

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

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

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

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

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

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

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