Testing. La otra cara de la moneda: el desarrollador. Presentación para las jornadas del VLCTesting en Valencia, el 14 de noviembre de 2013. Esta presentación abrió las jornadas sobre testeo y calidad del software.
Explica la visión del equipo de desarrollo respecto a la incorporación del equipo de test en el proyecto.
2. LA OTRA CARA DE LA MONEDA
Francisco Sánchez Cid
Jefe de proyectos – Instituto Tecnológico de Informática
3. EL TESTEO NOS RETRASA
Con lo justos que vamos de
tiempo...
4. El testeo nos retrasa
Nuestro proyecto ya está rodando
o Tenemos un plan de trabajo y unos hitos definidos
o Un equipo de programación comprometido y experimentado
o Muchas tareas por hacer y, por supuesto, poco tiempo
El equipo está a tope...
14 y 15 de noviembre de 2013 Valencia, España
5
5. El testeo nos retrasa
Y entonces llega el equipo de testeo...
14 y 15 de noviembre de 2013 Valencia, España
6
6. El testeo nos retrasa
Y llegan las preguntas dolorosas...
o ¿Tenéis documentación del proyecto?
o ¿Dónde puedo probar esto?
o ¿Porqué no me funciona?
Lo que suele traducirse en...
o Hay que revisar la documentación
o Hay que crear una infraestructura para el equipo de calidad
o Hay que dedicar tiempo a la gestión de la configuración
14 y 15 de noviembre de 2013 Valencia, España
7
7. El testeo nos retrasa mejora los procedimientos
En definitiva...
o Miran hasta debajo de la alfombra
o Efectivamente “nos retrasan”
Lo que se traduce en...
o Mejoramos la documentación del proyecto (¿porqué no con su propio aporte?)
o Creamos una infraestructura de despliegue
para pruebas, que nos será de gran utilidad en
el futuro (liberamos el equipo del programador)
o Revisamos los procesos de gestión de la
configuración, asegurando que funcionan en
entornos distintos al del desarrollador
14 y 15 de noviembre de 2013 Valencia, España
8
8. El testeo nos retrasa mejora los procedimientos
¡Ojo!
o No quiero decir que todo esto no se tenga que hacer CON o SIN el equipo de
testeo detrás...
o El equipo de testeo te GARANTIZA que TENDRÁS que hacerlo
14 y 15 de noviembre de 2013 Valencia, España
9
10. Menudas chorradas me están reportando
Cuando el equipo de calidad aterriza
o Aún no conoce bien la aplicación
o Aún no conoce qué es crítico y qué no lo es
o Sólo rascan en la superficie o en temas que consideramos “menos
importantes”
Es necesario:
o Conocimiento y práctica en la aplicación
o Preguntar mucho a los programadores...
o ...y NUNCA fiarse de ellos
14 y 15 de noviembre de 2013 Valencia, España
11
11. Menudas chorradas me están reportando
En esta situación, es común encontrarse con incidencias del
tipo:
o “El campo 22.3 no me aparece alineado a la derecha”
o “Si pulso 300 veces continuadas, a un ritmo constante de 60
pulsaciones por minuto, el 15% de las veces me salta un error”
Esto puede “incomodar” un poquito:
o Se pierde dedica mucho tiempo a analizar las
incidencias y su porqué
o Tanto si la incidencia es real como si no lo
es, en ambas cosas se “frustra” al programador
14 y 15 de noviembre de 2013 Valencia, España
12
12. Menudos chorradas bugs me están reportando
Una vez el equipo está formado e integrado:
o Las incidencias son más claras, e indican exactamente el origen del
error y la forma de reproducirlo
o Se gana el respeto del equipo de desarrollo, que se mueve de la
desconfianza inicial, al temor cada vez que los ven aparecer...
En definitiva:
o Ayudan a detectar situaciones imprevistas: flujos de trabajo no
previstos o “malusos”
o Aportan una visión distinta al equipo de desarrollo, que comienza a
trabajar pensando en esos posibles casos
14 y 15 de noviembre de 2013 Valencia, España
13
13. ¿QUIÉN ES EL TESTER?
¿Cuál es el papel de cada
cual en el proceso de test?
14. ¿Quién es el tester?
Podríamos identificar varios niveles de test
o Testeo unitario
o Testeo de integración
o Métricas de calidad
o Testeo funcional
o Testeo de aceptación
Unas preguntas:
o ¿Todos los tests unitarios los debe hacer el equipo de desarrollo?
o ¿Y los test de integración?
o ¿Quién revisa e interpreta las métricas de calidad?
14 y 15 de noviembre de 2013 Valencia, España
15
15. ¿Quién es el tester?
Podríamos identificar varios niveles de test
o Testeo unitario (desarrollo, equipo de calidad)
o Testeo de integración (desarrollo, equipo de calidad)
o Métricas de calidad (desarrollo, equipo de calidad)
o Testeo funcional (equipo de calidad)
o Testeo de aceptación (equipo de calidad)
Las claves:
o El programador siempre tiene algo más divertido que hacer
o El tester no se mancha las manos...
14 y 15 de noviembre de 2013 Valencia, España
16
16. ¿Quién NO es el tester?
Todos deben involucrarse
o Un ingeniero de test puede incrustarse en un equipo de desarrollo, y transferir técnica y
tecnología
o Un ingeniero de desarrollo debe ayudar a orientar los casos de test, aunque no los
ejecute
o El jefe de proyecto debe coordinar ambos equipos y procurar que ambos estén
informados (versiones, cambios, tiempos): comunicación bidireccional
El equipo de test aportará:
o No sólo los tests, sino la forma de identificarlos
o No sólo los tests, sino la forma de estructurarlos
o Metodología y herramientas, ligadas a la metodología de desarrollo
Sonar/Testlink vs Jenkins/Trac
14 y 15 de noviembre de 2013 Valencia, España
17
18. No podemos dedicar tanto esfuerzo al test
Siempre hay problemas para ajustar tiempo y esfuerzo en la
planificación
Mi perspectiva:
14 y 15 de noviembre de 2013 Valencia, España
19
19. No podemos dedicar tanto esfuerzo al test
Siempre hay problemas para ajustar tiempo y esfuerzo en la
planificación
Mi perspectiva:
14 y 15 de noviembre de 2013 Valencia, España
20
20. No podemos dedicar tanto menos esfuerzo al test
El esfuerzo correcto es muy difícil de medir a priori, pero depende de varios
factores:
o La naturaleza de la aplicación: producto o desarrollo experimental
o El tamaño de la aplicación
o La criticidad de los datos que trata la aplicación
o La interacción con otras aplicaciones o sistemas
14 y 15 de noviembre de 2013 Valencia, España
21
21. No podemos dedicar tanto menos esfuerzo al test
El esfuerzo correcto es muy difícil de medir a priori, pero depende de varios
factores:
o La naturaleza de la aplicación: producto o desarrollo experimental
o El tamaño de la aplicación
o La criticidad de los datos que trata la aplicación
o La interacción con otras aplicaciones o sistemas
Según estos factores...
o 10% del esfuerzo total del proyecto: comprobar el funcionamiento básico
o 20% del esfuerzo: permite además hacer iteraciones, comprobando correcciones y
diseñando un plan más detallado
o 30% del esfuerzo: aplicaciones con una funcionalidad amplia y compleja, con tantas
iteraciones como sean necesarias para asegurar la calidad final del SW
o 40% del esfuerzo: aplicaciones críticas o de máxima difusión (e.g. Chrome)
o 50% del esfuerzo: ... alguna habrá, ¿no?
14 y 15 de noviembre de 2013 Valencia, España
22
22. ¿EN QUÉ NOS BENEFICIA
TODO ESTO?
Los beneficios que
percibimos
23. ¿En qué nos beneficia todo esto?
Depende del tipo de proyecto y de su criticidad, pero en
general:
o Mejora la calidad del producto final
o Nos quita responsabilidad
o Nos quita presión
Profundicemos un poco en todo esto...
14 y 15 de noviembre de 2013 Valencia, España
24
24. ¿En qué nos beneficia todo esto?
Hay situaciones en las que el beneficio es apenas perceptible:
o Fases muy tempranas del desarrollo (lo sé, esto es políticamente incorrecto)
o Aplicaciones internas, con poco uso, poca carga, o un tiempo de vida limitado
o Pruebas de concepto de proyectos I+D
Hay situaciones en las que el beneficio es realmente perceptible. Tanto, que
se hace absolutamente imprescindible:
o Desarrollos que se convertirán en producto final
o Aplicaciones con un tiempo de vida esperado muy amplio
o Aplicaciones en las que los datos que se manipulan y se producen son críticos
o Aplicaciones que interactúan con otros sistemas o aplicaciones
o Aplicaciones que conviven con otras, en el mismo entorno (e.g. en el mismo servidor)
14 y 15 de noviembre de 2013 Valencia, España
25
25. ¿En qué nos beneficia todo esto?
Cuesta reconocerlo pero...
o La presión:
La presión del tiempo / entrega ya no sólo reside en el desarrollo.
Es calidad quien da el OK... nosotros no podemos hacer nada...
Las entregas tardías ya no se hacen al cliente, se hacen a calidad
o La responsabilidad
Alguien independiente vela por la calidad del producto
Alguien independiente da el visto bueno (o nos paraliza) para la entrega
“Yo, no iría a producción, por estas métricas o resultados”
14 y 15 de noviembre de 2013 Valencia, España
26
26. ¿En qué nos beneficia todo esto?
“Creo que ya está listo. ¿Puedo pedir a testeo que lo pruebe?”
un desarrollador
14 y 15 de noviembre de 2013 Valencia, España
27
27. ¿En qué nos beneficia todo esto?
“Creo que ya está listo. ¿Puedo pedir a testeo que lo pruebe?”
un desarrollador
14 y 15 de noviembre de 2013 Valencia, España
28
28. Francisco Sánchez Cid
Jefe de proyectos - ITI
Francisco es Ingeniero en Informática y DEA por la Universidad de Málaga.
Actualmente trabaja tanto desarrollo tecnológico como en investigación
aplicada, especializado en tecnología Java. Ha participado en numerosos
proyectos de I+D nacionales e internacionales, y tiene una dilatada
experiencia en campos como la arquitectura software, la integración de
sistemas, la securización de aplicaciones, o sistemas expertos.
Datos de Contacto
T: +34 963 879 102
M: +34 679 419 814
email: cid@iti.es
@ http://web.iti.upv.es/~fsanchez
Twitter: @_Francisco_1978
14 y 15 de noviembre de 2013 Valencia, España
29