En el artículo se muestra un caso práctico y el análisis del mismo.
El articulo en español lo pueden encontrar en
Software Product Quality Más allá de los defectos
sábado, 3 de agosto de 2013
Software Product Quality - Más allá de los defectos
En el artículo se muestra un caso práctico y el análisis del mismo.
El articulo en español lo pueden encontrar en
Software Product Quality Más allá de los defectos
viernes, 2 de agosto de 2013
Probamos, pero… ¿evolucionamos?
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
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.
viernes, 12 de julio de 2013
Sobre nuestra misión como testers
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:
Nota: Originalmente publicado en excelza el 18/10/2009
Suscribirse a:
Entradas (Atom)