Buscando ya no me acuerdo qué, en el disco duro “milenario”, no sé ni cómo, he acabado en una carpeta del año catapún llamada “IEEE Standards”. Bueno, ahora lo recuerdo, hace ya sus años, ya años, sí, aprovechando que trabajaba en una empresa que tenía una cuenta corporativa en la asociación IEEE (por si no te suena, IEEE, tiempos a, era una de las asociaciones informáticas más importantes) me dió por bajar todos los estándares de la IEEE relativos a “software engineering”, que por cierto, valían una pasta, y que yo bajé por si acaso, “nunca se sabe dónde los podría necesitar”.
Mi carpeta reliquia con los “IEEE Standards”
Los “IEEE Standards” son una colección de pdfs que describen documentalmente qué habría que detallar en cada una de las fases de un proyecto software, desde el mantenimiento, con su pdf, a los requisitos, con su pdf, pasando por la verificación, la validación, la adquisición, las anomalías, etc., cada uno con su pdf.
La verdad es que más de 10 años después de aquello, hoy ya sí puedo confirmar que estaba equivocado, realmente… nunca los he necesitado. Bueno, para ser justos, nunca los he necesitado aplicar en un proyecto, si bien, ciertamente, en algún momento, tiempo atrás, me sirvieron a modo de texto docente, para aprender de qué trataba cierta área de la ingeniería del software. Cuando en algún proyecto salía, por ejemplo, el tema del “software maintenance”, si estabas un poco perdido sobre a qué refería… ibas y te leías el estándar, que, como digo, a modo de texto docente, te dejaba muy clarito qué se entendía por “software maintenance” o por cualquier otra área de la ingeniería software “clásica”.
Por supuesto, no voy a poner en duda el enorme trabajo que en su día hicieron los profesionales que escribieron todos esos estándares, cuya lectura, a día de hoy, me sigue pareciendo tremendamente útil si no tienes ni idea de a qué refiere cierta área del desarrollo software. Lo que si pongo más en duda es su aplicación en proyectos, más allá de su aplicabilidad docente y formativa. De hecho, aunque pueda ser opinión subjetiva, creo que no los usé nunca en un proyecto, o si los usé… sería sólo alguno y ya no recuerdo ni dónde.
Volviendo a leer alguno de esos pdf muchos años después, con la perspectiva del tiempo y la experiencia, creo que dichos estándares, como pudo ser el caso de otras metodologías del pasado, representan fielmente la época más predictiva del desarrollo software, aquella más cercana al cascada, aquella que perseguía cerrar mediante documentos exhaustivos todas y cada una de las fases de un proyecto para evitar variaciones en la siguientes: Requisitos cerrados, diseños cerrados… y planes de pruebas cerrados.
Especificación de un plan de pruebas según los “IEEE Standards”
Y, concretamente, volviendo la vista atrás, quería detenerme en el caso concreto de los relativos a las pruebas. Tanto aquellos “IEEE Standards” como, igualmente, centenares de metodologías y procedimientos locales, escritos bajo el ámbito de multitud de empresas de tecnología, se basaban en la idea de escribir pormenorizados planes de pruebas y pormenorizados casos de prueba, para que, muy en la línea cascada, mientras un equipo de desarrollo creaba sofware, tiempo después, cuando hubieran terminado, otro equipo de testing tuviera listos los documentos, detallando todo lo que había que probar, extrayendo dicha información de los también cerrados y detallados requisitos.
Especificación de un caso de prueba según los “IEEE Standards”
Volviendo al presente… ¿dónde han quedado hoy aquellos planes de pruebas y aquellos casos de prueba súper detallados? ¿existen? ¿fueron útiles alguna vez?
Como cuando hablamos por aquí de Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos) o como hace menos tiempo veíamos en ¿Qué haces testing ágil? Comprobémoslo en en 3 min., vamos con un “checklist”, en aquellos tiempos la realidad se empeñaba una y otra vez en decirnos que una cosa es lo que se planificaba exhaustivamente en un documento y otra lo que realmente ocurría y, al igual que pasaba con otras áreas, caso especial el de los requisitos, decenas de páginas de especificación textual, y las horas que llevaba escribirlas, se acaban tiraban a la basura al enfrentarse con la realidad: requisitos que no eran los que realmente se necesitaban, casos de prueba que realmente no se podían ejecutar o que no probaban lo que había que probar.
Hoy, la visión del desarrollo pragmático por fin se ha impuesto y nos ha dejado centenares de prácticas, plantillas y documentos… para los museos del desarrollo software.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola. Nuestra empresa a vendido el software WRP que desarrollamos a un nuevo cliente el cual nos pidió algunos cambios en la funcionalidad del mismo y contrató a una tercera empresa que solo hace pruebas para que lo pruebe antes de aceptarlo. Esta tercera empresa nos ha pedido que la capacitemos en el uso actual del software, y que le informemos qué metodología utilizamos para desarrollar, qué tipo de pruebas hacemos y otras cosas más. Qué piensas Javier de estos pedidos? No deberían ellos de capacitarse por su cuenta? Si van a probar nuestro software por qué le tenemos que informar cómo nosotros hacemos las cosas? Nuestro jefe piensa que nosotros solo le tenemos que dar la caja y que ellos la prueben y que nuestro cliente le de la información de requisitos, etc. Qué piensas?
Hola,
se que son años que nos separan, pero obviamente tienes que entregar la informacion, si el software es tuyo, los requerimientos funcionales, los hicistes tu. Osea quieren hacer qa de tu software porque no estan seguras de la calidad de el y tu te haces esa pregunta???.
gracioso.
Hola javier podrias especificar en que norma ieee se habla lo que tiene que tener los casos de pruebas
Javier,
es muy tarde para mi respuesta, pero despues de pasar de agil a tradicional y de tradicional ha agil, creo que estas muy equivocado, uno de los padres de la metodologia agil tambien lo dijo, no todo puede ser agil. Si tu dices «requisitos que no eran los que realmente se necesitaban, casos de prueba que realmente no se podían ejecutar o que no probaban lo que había que probar.», es que el analisis de requerimientos fueron hecho mal, tu verdad no es la verdad universal, es tu vivencia, para trabajar agil, deben estar todos de ceder un poco de mando, el de interpretar un papel y eso cuesta.
saludos Lilia.