Actualmente estoy estudiando académicamente algunos conceptos de Testing. Como nadie está a salvo de cometer errores, asumimos que los programas que hacemos tienen errores. Entonces se desarrollan varios tipos de técnicas para descubrir esos errores lo más pronto posible y resolverlos de forma de dejar el programa lo más libre de errores posible.
En testing también hay áreas de trabajo para ver cómo se comportará un sistema si es sobrecargado e incluso si recibe ataques de seguridad. Estás son las áreas avanzadas y son realmente muy complejas.
Pensando en el proceso de desarrollo más simple:
1)- tenemos un Cliente que le dice a nuestro Analista el programa que quiere (en el medio el Analista tiene que comprender el lugar donde el cliente usará ese programa, organización, tareas, etc.).
2)- El analista escribe los Requerimientos (que valida con el Cliente) y se los da a un Arquitecto de Software (suponiendo que lo tenemos). Generalmente allí va la información de qué debe hacer el sistema. El Arquitecto hace la Arquitectura, el diseño de alto nivel.
3)- El Arquitecto entrega la Arquitectura y asiste al Programador para hacer el diseño de bajo nivel. A partir de este diseño el Programador implementa el programa.
4)- El Programador entrega el sistema al Testeador, que revisará que el sistema cumpla con los Requerimentos pedidos.
Sé que en casos pequeños este proceso es demasiado "idealizado". Es muy probable que los roles de Analista, Arquitecto, Programador y Testeador los realice la misma persona. En ese caso, probablemente se documente poco en el camino, y haya menos errores debido a que tiene todo el conocimiento. Pero, ¿Qué pasa cuando cada uno de estos roles los cumple una o varias personas? ¿Cuántas instancias de comunicación encontramos?
Independientemente de los errores que cada integrante de un equipo puede cometer en sus tareas, muchos de los errores en software provienen de fallas en comunicación entre las personas que participan en su producción. Ahora la gran pregunta es cuáles
y cómo detectarlos(o prevenirlos)?
En Testing están apareciendo los errores de software, y además de entregar un software libre de errores, la sistematización del testing nos permite aprender a tener menos errores. Eso es válido si reflexionamos sobre los errores que cometemos...
En fin... el tema puede ser muy largo... el día gris me puso reflexiva, aunque también colaboró este sitio que encontré por ahí:
Testing Reflections
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario