Control de Calidad en Software Libre
III Congrés de Programari Lliure - Comunitat Valenciana
Noviembre 2008
Juan J. Martínez
[email protected]
Project Manager
Responsable de Infraestructuras en Open Sistemas
Investigador especializado en Control Calidad y
Testeo de Software
compañía española especializada en ofrecer
soluciones de tecnología
basadas en Open Source y plataformas Linux
Contenidos de la ponencia
¿Qué es 'Control de Calidad'?
Mecanismos y estrategias
Caso de estudio
Conclusiones
3
Control de Calidad en Software
Realización de pruebas para detectar defectos,
bloqueando la publicación de productos defectuosos y
mejorando el resultado en diferentes iteraciones del ciclo
de entregacertificación.
Software Quality Control
¿Qué es 'Control de Calidad'?
4
Control de Calidad en Software
Comercial/preventa
Cliente
Reunión inicial
Propuesta
Entregable
Requisitos
Alcance
Proyecto
ganado
Ciclo
implementación
n
n+1
Revisión
Certificacón
Desarrollo
Control de
Calidad
¿Qué es 'Control de Calidad'?
Ciclo entregacertificación
5
Control de Calidad en Software
Quality Control (QC)
≠
Quality Assurance (QA)
¿Qué es 'Control de Calidad'?
6
Control de Calidad en Software
Son los mecanismos que se implican en el proceso de
desarrollo, verificando que se sigue unos estándares y
procedimientos, y asegurando que los problemas se
encuentran y se tratan adecuadamente.
Software Quality Assurance
¿Qué es 'Control de Calidad'?
7
Control de Calidad en Software
''Evitar publicar con defectos''
≠
''Hacer las cosas bien a la primera''
¿Qué es 'Control de Calidad'?
8
¿Cómo encaja el Software Libre?
Modelo Bazar (componentes de diferentes fabricantes)
En determinados casos: componentes empaquetados
por un distribuidor (actor extra)
Software ''AS IS'', sin garantías
Hay Dependencias, ciclos de desarrollo desiguales en
los componentes, diferentes puntos de fallo, etc.
Entonces, ¿podemos aplicar QA a
nuestro producto?
¿Qué es 'Control de Calidad'?
9
Mecanismos: calidad de desarrollo
No hay grandes diferencias respecto a proyectos
cerrados:
Estilo y buenas prácticas
Auditorías de código
Tests unitarios
Tests de integración
Tests de regresión
Dentro del departamento de desarrollo
Ayuda a desarrollar: detección temprana de defectos
Mecanismos y estrategias
10
Mecanismos: ciclos de testing
Tampoco hay grandes diferencias respecto a proyectos
cerrados:
Checklist
Test case
Especificación del producto
Precondiciones
Eventos implicados
Pasos a seguir
Resultado esperado
Resultado
obtenido
OK
ERROR, descripción en incidencia
Mecanismos y estrategias
11
Mecanismos: ciclos de testing
Se programan ''entregas'' al Departamento de Calidad
previas a la versión que se entregará al cliente:
Depende del modelo de planificación
Cada entrega tiene un objetivo claro, y se puede
repetir si no alcanza unos resultados concretos
Departamento independiente, desarrollo no interfiere
Mejora producto: se detectan errores antes de publicar
Mecanismos y estrategias
12
Mecanismos: ciclos de testing
Ejemplo de planificación de entregas al Departamento
de Calidad:
Fase 1
Fase 2
funcionalidades
incrementales
Fase n
Versiones públicas
Producción
Beta
RCn
n+1
¿Certificado?
Final
Mecanismos y estrategias
13
Mecanismos: automatización
Gran cantidad de frameworks para automatizar todo tipo
de pruebas:
Más pruebas en menos tiempo
La linea entre desarrollo y calidad se difumina
Pruebas nocturnas (AKA ¿funciona el código del
repositorio?)
En general es positivo (¿quién prueba a los que
prueban? y... requiere una inversión de tiempo difícil de
justificar)
Mecanismos y estrategias
14
Mecanismos: bugtracking público
Estamos hablando de Open Source (mantra: release
early, release often):
Cualquier versión nofinal debería estar abierta al
público: integrar al usuario en el ''ciclo de testing''
Debe ser fácil para el usuario apuntar a un defecto
El usuario no es el Departamento de Calidad: nos dice
qué algo falla, pero sus informes no serán de calidad
Pasar a una nueva entrega nunca debe ser traumático
División del área de Calidad dedicada a los informes
de usuario
Mecanismos y estrategias
15
¿De quién es este bug?
En muchos proyectos, no está claro:
¿Es nuestro?
¿Es un fallo de integración?
Y lo más importante:
¿corresponde al upstream?
Es imprescindible para saber
quién lo debe corregir...
Caso de estudio
16
Ejemplo: distribución GNU/Linux
Características:
Se basa en otra distribución (que a su vez empaqueta
otros proyectos)
Incorpora una serie de paquetes diferenciadores
En sus paquetes se puede incluir desarrollos propios
Caso de estudio
17
Ejemplo: distribución GNU/Linux
Puntos clave:
No reinventes la rueda, hay que reutilizar todo lo que
se pueda de la distribución base
Equilibrio entre integración y ''añadidos'', la integración
se debe enviar a upstream
Si se corrige un bug que no es nuestro, es muy
importante que se incluya esa corrección en upstream
Sincronizar ciclos de desarrollo
Caso de estudio
18
Ejemplo: distribución GNU/Linux
Seguimiento de un bug:
Es vital poder hacer seguimiento de los defectos,
aunque no sea competencia nuestra resolverlos
Ejemplo de Ubuntu con Launchpad:
CVE Bugs: 96 (Common Vulnerabilities and Exposures)
Bugs fixed elsewhere: 1403
Total open: 47966
Distinción: problemas de seguridad, errores upstream y
otros errores.
Caso de estudio
19
Ejemplo: distribución GNU/Linux
Bug #112102: Too easy to accidentally kill dbus from
Services settings and lock yourself out of services
Launchpad (UBUNTU)
Bugzilla (GNOME)
Caso de estudio
20
Control de Calidad y Software Libre
Desde nuestro desarrollo:
Integrar estrategias de control de desarrollo (tests
unitarios, de integración y de regresión)
Desde Control de Calidad:
Ciclos entregacertificación no demasiado largos
Integrar al usuario en los ciclos de testing
Gestionar adecuadamente los errores (comunicación y
colaboración con el upstream)
Conclusiones
21
¿Alguna pregunta?
Gracias por venir
Juan J. Martínez
[email protected]
Empresa: http://www.opensistemas.com/
Blog personal: http://blackshell.usebox.net/
22
Crear cuenta
Comentarios de: Control de Calidad en Software Libre III - Congrés de Programari Lliure (0)
No hay comentarios