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.

1. Conferencia
14/11/2013

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

9. MENUDAS CHORRADAS
ME ESTÁN REPORTANDO
Calidad acaba de aterrizar

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

17. NO PODEMOS DEDICAR
TANTO ESFUERZO AL TEST
¿Cuál es la chispa
adecuada?

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

29. Organiza
Patrocinan
Colaboran