Algunos retos del testing

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.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Algunos retos del testing”

  1. 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í.

  2. – 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

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *