Esta charla fue parte de un evento organizado por Abstracta, en el que Javier Garzas estuvo invitado y habló de gestión ágil de proyectos. Como bienvenida por parte de Abstracta, hablé algunos minutos compartiendo algunos pensamientos sobre el testing y su aporte a la calidad de software.
4. Prejuicios del
testing:
• Es aburrido
• Es repetitivo
• No tiene desafíos
• Es el trabajo para
el programador nuevo
¿Por qué trabajas en
testing?
¿No conseguiste otra
cosa mejor?
5. Prejuicios del
testing:
• El enemigo
• Los que rompen
el sistema
Ahhh vos sos de los que les
gusta criticar todo…
De los que ponen palos en las
ruedas para no salir en
producción…
10. • ¿Qué es?
• ¿Para quién?
¿Calidad?
• La totalidad (suma) de factores de
calidad.
• Suma ponderada.
• Según el público objetivo, cada factor
tendrá más o menos peso.
• Cada uno pondera distinto los factores
de calidad, cada contexto, cada
realidad.
11. • ¿Qué es?
• ¿Cómo se vincula con el concepto de
calidad?
¿Testing? ¿Pruebas?
19. Es un proceso
empírico, se basa en
la experimentación,
en donde se le
brinda información
sobre la calidad de
un producto o
servicio a alguien
que está interesado
en el mismo.
Cem Kaner
¿Qué es el testing?
20. • No se debería tratar solo
de “Encontrar errores” sino
de “Prevenir errores”
• ¿Cómo logramos esto?
• Testing desde el día 1
Pero debería
ir más allá de
eso
23. Conclusión #2
Somos parte
del mismo
equipo, con
el mismo
objetivo
Conclusión #3
Testing
involucrado desde
el primer día,
para enfocar en
prevenir más que
en corregir
Conclusión #1
No se trata
de probar
más, se trata
de probar
mejor (para
el cliente)
Opening: incluye el PoC, plantear que a nadie le gusta el testing.
He estado involucrado en testing y calidad desde hace 10 años en muchas cosas, libro, universidades, herramientas, servicios, en la universidad, con un doctorado en España
Sino está la otra actitud que es esta:
Ahhh vos sos de los que les gusta criticar todo
De los que ponen palos en las ruedas para no salir en producción
Los que se creen no sé qué para andar diciendo si algo está bien o no…
Sino está la otra actitud que es esta:
Ahhh vos sos de los que les gusta criticar todo
De los que ponen palos en las ruedas para no salir en producción
Los que se creen no sé qué para andar diciendo si algo está bien o no…
PUNTO B: los quiero convencer que la concepción de testing que tienen muchos tal vez no sea la mejor, pero no solo por los prejuicios de que es aburrido y todo esto, sino por la utilidad del testing.
WIIFY: pero mi objetivo no es que de esto que les diga se vayan pensando que está todoooo mal lo que pensaban de testing, tenemos que cambiar todo!! NO, la idea es que se con esto se queden razonando, y quizá los lleve a tomar alguna acción pequeña que los haga mejorar en su proceso de desarrollo y en la calidad con la que entregan sus productos, con muy pocos cambios.
Que digan algo como “ahh, pero … haciendo simplemente esto ya logro mejorar los resultados? Fácil, voy a probar”.
Para hablar de testing, comencemos hablando de calidad.
Cómo hacen para saber si este café les va a gustar?
Factores de calidad
Cada uno prioriza cosas distintas (a mí me gusta con aroma, a pesar que esté medio tibio, pero siempre hay un mínimo de cada factor para que sea aceptable)
Uno acá comienza a ver que hay muchas cosas para probar y comienza a darse cuenta que tiene que contratar a 20 personas para que prueben todo lo que están haciendo los desarrolladores….
Mientras más pruebo mejor, otro de los prejuicios equivocados…
Por más irónico que parezca, el buen tester es el que prueba poco. Poco, pero bien, poniendo foco en el tiempo y recursos disponibles, y en las necesidades del equipo, maximizando el valor que puede aportar el testing al equipo.
No sé si “pensamiento” o “reflexión” o qué…
El concepto de “testing independiente” triunfó demasiado, y se malinterpretó.
No significa que todas las tareas de QA las tiene que hacer el equipo de testing….pq sino el testing unitario lo tendría que hacer testing, y no es así.
Esta imagen me encanta, porque refleja que somos las mismas ratas de laboratorio, en el mismo equipo, pero con distinto foco para hacer lo mismo - construir un producto de caldiad
Hasta acá creo que no conté nada nuevo.
Lo que viene ahora es para generar un poco de controversia
Alguna imagen que hable de “prevenir es mejor que curar”
Qué deberíamos hacer?
No se trata de probar como loco, sacarle el máximo provecho al testing, analizando la calidad que le debo aportar al usuario
Considerar al testing como parte del equipo y no como la barrera entre el equipo de desarrollo y el cliente, sino como el puente.
Involucrar al tester desde el principio
Con estos tres cambios, tomados de a poco, vamos a poder cambiar mucho la forma en que vemos el testing, la forma en que obtenemos valor de esta actividad
PUNTO B: reflexionar sobre cómo entienden al testing…..la idea es que se con esto se queden razonando, y quizá los lleve a tomar alguna acción pequeña que los haga mejorar en su proceso de desarrollo y en la calidad con la que entregan sus productos, con muy pocos cambios.