Testing. La otra cara de la moneda: el desarrollador

Conferencia14/11/2013

LA OTRA CARA DE LA MONEDA

Francisco Sánchez CidJefe de proyectos – Instituto Tecnológico de Informática

EL TESTEO NOS RETRASA

Con lo justos que vamos de tiempo...

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

El testeo nos retrasa

Nuestro proyecto ya está rodandoo Tenemos un plan de trabajo y unos hitos definidoso Un equipo de programación comprometido y experimentadoo Muchas tareas por hacer y, por supuesto, poco tiempo

El equipo está a tope...



Y entonces llega el equipo de testeo...



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óno Hay que crear una infraestructura para el equipo de calidado Hay que dedicar tiempo a la gestión de la configuración


El testeo nos retrasa mejora los procedimientos

En definitiva...o Miran hasta debajo de la alfombrao 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


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

MENUDAS CHORRADAS ME

ESTÁN REPORTANDOCalidad acaba de aterrizar


Menudas chorradas me están reportando

Cuando el equipo de calidad aterrizao Aún no conoce bien la aplicacióno Aún no conoce qué es crítico y qué no lo eso Sólo rascan en la superficie o en temas que consideramos “menos importantes”

Es necesario:o Conocimiento y práctica en la aplicacióno Preguntar mucho a los programadores... o ...y NUNCA fiarse de ellos


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


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

¿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 testo Testeo unitarioo Testeo de integracióno Métricas de calidado Testeo funcionalo 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?


¿Quién es el tester?

Podríamos identificar varios niveles de testo 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 hacero El tester no se mancha las manos...


¿Quién NO es el tester?

Todos deben involucrarseo Un ingeniero de test puede incrustarse en un equipo de desarrollo, y transferir técnica

y tecnologíao 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 identificarloso No sólo los tests, sino la forma de estructurarloso Metodología y herramientas, ligadas a la metodología de desarrollo

Sonar/Testlink vs Jenkins/Trac

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 perspectiva:


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 experimentalo El tamaño de la aplicacióno La criticidad de los datos que trata la aplicacióno La interacción con otras aplicaciones o sistemas


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 experimentalo El tamaño de la aplicacióno La criticidad de los datos que trata la aplicacióno La interacción con otras aplicaciones o sistemas

Según estos factores...o 10% del esfuerzo total del proyecto: comprobar el funcionamiento básicoo 20% del esfuerzo: permite además hacer iteraciones, comprobando correcciones y

diseñando un plan más detalladoo 30% del esfuerzo: aplicaciones con una funcionalidad amplia y compleja, con tantas

iteraciones como sean necesarias para asegurar la calidad final del SWo 40% del esfuerzo: aplicaciones críticas o de máxima difusión (e.g. Chrome)o 50% del esfuerzo: ... alguna habrá, ¿no?

¿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 del producto finalo Nos quita responsabilidado Nos quita presión

Profundicemos un poco en 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 limitadoo 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 finalo Aplicaciones con un tiempo de vida esperado muy amplioo Aplicaciones en las que los datos que se manipulan y se producen son críticos o Aplicaciones que interactúan con otros sistemas o aplicacioneso Aplicaciones que conviven con otras, en el mismo entorno (e.g. en el mismo servidor)



Cuesta reconocerlo pero...oLa 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

oLa 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”



“Creo que ya está listo. ¿Puedo pedir a testeo que lo pruebe?”

un desarrollador


Francisco Sánchez CidJefe 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: [email protected] @ http://web.iti.upv.es/~fsanchez Twitter: @_Francisco_1978

Organiza

Patrocinan

Colaboran

Testing. La otra cara de la moneda: el desarrollador

Documents

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