En estos días se ha celebrado en Orlando la STAREAST 2011, una destacada conferencia sobre software testing. De entre los varios resúmenes que hay por la Web sobre las ponencias de la conferencia, quería destacar, y también re-resumir, los principales retos a los que, según la ponencia de Lloyd Roden, aun debe enfrentarse el testing:
– Prohibir el uso de la frase “best practice”, ya que lo que puede funcionar bien en un contexto puede no hacerlo en otro. Las buenas prácticas no debieran seguirse al pie de la letra.
– Enfocarse en la calidad más que en la cantidad de casos de prueba, ya que no debiera juzgarse la productividad de los tester por el número de casos de prueba ejecutados, olvidando la calidad de las pruebas.
– No mentir usando métricas, ya que hay veces que desde datos estadísticos obtenidos de numerosas métricas se puede justificar cualquier cosa.
– Adaptar la información al receptor, ya que la información extraída del testing debe adaptarse según a quien vaya dirigida, no necesita la misma información un jefe de proyecto que un director de informática.
– Los responsables del testing deberían participar en el testing, ya que es muy recomendable para ellos tomar contacto con la realidad, ganar así credibilidad, etc.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Yo la verdad es que me quedo fundamentalmente con dos comentarios
Prohibir el uso de la frase «best practice»: Aquí se nota que la gente va aprendiendo de experiencias pasadas. No sería nada bueno que el testing se convirtiera en el enésimo intento de «bala de plata» para esta profesión. Con todo y con eso a mí me cuesta imaginar un desarrollo de software de largo alcance, en el que se prevea un largo tiempo de mantenimiento perfectivo, sin una buena batería de tests automatizados.
No mentir usando métricas: Esta es una cuestión más para ahondar en otros posts. En general, cuando las métricas se emplean como indicadores del estado del desarrollo del sistema para todos los intervinientes en el mismo, son una excelente idea. Cuando las métricas se establecen por parte de unos, para controlar el trabajo de otros (de los que a priori evidentemente no se fían) las métricas se terminan convirtiendo en una mentira sí o sí.
– Enfocarse en la calidad más que en la cantidad de casos de prueba
Esta si que es buena. Me acuerdo en cierto proyecto cuando localize mil bugs con 4-5 casos de prueba y otros ejecutando 40 y todo casi perfecto.
Imagina a quien le dieron el ‘toque’…
Claro que asi va el proyecto… jejej