Your SlideShare is downloading. ×
0
Conferencia
14/11/2013
LA OTRA CARA DE LA MONEDA
Francisco Sánchez Cid
Jefe de proyectos – Instituto Tecnológico de Informática
EL TESTEO NOS RETRASA

Con lo justos que vamos de
tiempo...
El testeo nos retrasa
 Nuestro proyecto ya está rodando
o Tenemos un plan de trabajo y unos hitos definidos
o Un equipo d...
El testeo nos retrasa
 Y entonces llega el equipo de testeo...

14 y 15 de noviembre de 2013 Valencia, España

6
El testeo nos retrasa
 Y llegan las preguntas dolorosas...
o ¿Tenéis documentación del proyecto?
o ¿Dónde puedo probar es...
El testeo nos retrasa mejora los procedimientos
 En definitiva...
o Miran hasta debajo de la alfombra
o Efectivamente “no...
El testeo nos retrasa mejora los procedimientos
 ¡Ojo!
o No quiero decir que todo esto no se tenga que hacer CON o SIN el...
MENUDAS CHORRADAS
ME ESTÁN REPORTANDO

Calidad acaba de aterrizar
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 c...
Menudas chorradas me están reportando
 En esta situación, es común encontrarse con incidencias del
tipo:

o “El campo 22....
Menudos chorradas bugs me están reportando
 Una vez el equipo está formado e integrado:
o Las incidencias son más claras,...
¿QUIÉN ES EL TESTER?

¿Cuál es el papel de cada
cual en el proceso de test?
¿Quién es el tester?
 Podríamos identificar varios niveles de test
o Testeo unitario
o Testeo de integración
o Métricas d...
¿Quién es el tester?
 Podríamos identificar varios niveles de test
o Testeo unitario (desarrollo, equipo de calidad)
o Te...
¿Quién NO es el tester?
 Todos deben involucrarse
o Un ingeniero de test puede incrustarse en un equipo de desarrollo, y ...
NO PODEMOS DEDICAR
TANTO ESFUERZO AL TEST

¿Cuál es la chispa
adecuada?
No podemos dedicar tanto esfuerzo al test
 Siempre hay problemas para ajustar tiempo y esfuerzo en la
planificación
 Mi ...
No podemos dedicar tanto esfuerzo al test
 Siempre hay problemas para ajustar tiempo y esfuerzo en la
planificación
 Mi ...
No podemos dedicar tanto menos esfuerzo al test
 El esfuerzo correcto es muy difícil de medir a priori, pero depende de v...
No podemos dedicar tanto menos esfuerzo al test
 El esfuerzo correcto es muy difícil de medir a priori, pero depende de v...
¿EN QUÉ NOS BENEFICIA
TODO ESTO?

Los beneficios que
percibimos
¿En qué nos beneficia todo esto?
 Depende del tipo de proyecto y de su criticidad, pero en
general:

o Mejora la calidad ...
¿En qué nos beneficia todo esto?
 Hay situaciones en las que el beneficio es apenas perceptible:
o Fases muy tempranas de...
¿En qué nos beneficia todo esto?
 Cuesta reconocerlo pero...
o La presión:
 La presión del tiempo / entrega ya no sólo r...
¿En qué nos beneficia todo esto?
“Creo que ya está listo. ¿Puedo pedir a testeo que lo pruebe?”
un desarrollador

14 y 15 ...
¿En qué nos beneficia todo esto?
“Creo que ya está listo. ¿Puedo pedir a testeo que lo pruebe?”
un desarrollador

14 y 15 ...
Francisco Sánchez Cid
Jefe de proyectos - ITI

Francisco es Ingeniero en Informática y DEA por la Universidad de Málaga.
A...
Organiza

Patrocinan

Colaboran
Upcoming SlideShare
Loading in...5
×

Testing. La otra cara de la moneda: el desarrollador

186

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
186
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Testing. La otra cara de la moneda: el desarrollador"

  1. 1. Conferencia 14/11/2013
  2. 2. LA OTRA CARA DE LA MONEDA Francisco Sánchez Cid Jefe de proyectos – Instituto Tecnológico de Informática
  3. 3. EL TESTEO NOS RETRASA Con lo justos que vamos de tiempo...
  4. 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. 5. El testeo nos retrasa  Y entonces llega el equipo de testeo... 14 y 15 de noviembre de 2013 Valencia, España 6
  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. 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. 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. 9. MENUDAS CHORRADAS ME ESTÁN REPORTANDO Calidad acaba de aterrizar
  10. 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. 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. 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. 13. ¿QUIÉN ES EL TESTER? ¿Cuál es el papel de cada cual en el proceso de test?
  14. 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. 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. 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. 17. NO PODEMOS DEDICAR TANTO ESFUERZO AL TEST ¿Cuál es la chispa adecuada?
  18. 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. 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. 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. 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. 22. ¿EN QUÉ NOS BENEFICIA TODO ESTO? Los beneficios que percibimos
  23. 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. 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. 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. 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. 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. 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. 29. Organiza Patrocinan Colaboran
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×