Frente al reto que representa el incremento en tamaño, complejidad e interoperabilidad de sistemas informáticos, ahora mas que nunca es
necesario abordar el software testing con metodologías estructuradas y cuyos terminos sean conocidos por todos los interesados, pasando por desarrolladores, testers, gerentes y clientes.
El artículo de PMOInformática me inspiró a que escribiera algunas ideas que me surgieron y que aquí les expongo, incluyendo al final la imagen del mapa mental que pueden ver y bajarse.
Tanto los que recién se inician en esta actividad como los que están afuera de ella (desarrolladores, analistas funcionales, administradores de base de datos, administradores de seguridad, gerentes de proyectos, soporte técnico, administradores de redes, clientes, y otros) se preguntan si hay alguna definición de los principales pasos que permitan realizar una «Prueba» de software, porque
quieren de alguna manera asegurar que la entrega del producto al cliente sea lo esperado por él.
Esto es básico y lógico, aunque a decir verdad no siempre se cumple bajo la línea definida por diversas razones que no vienen al caso
para este artículo.
¿Se dieron cuenta que puse «Prueba de Software», verdad?
Lo hice así porque es como suelen llamar a la actividad, así como lo hacen con la «programación» aunque desde hace unos años a esta
parte ya la denominan en muchos lugares «desarrollo» porque han visto que el programador tiene más tareas que la de programar nada más.
De la misma manera pasa con la actividad del Software Testing, ya que durante muchos años incluso actualmente, cuando hay que enfrentar un proyecto surge un momento en el que hay que hablar de las pruebas, y de cuánto llevarán, quienes las harán, cuándo iniciarlas, cuándo finalizarlas, qué necesitarán aquellos que sean asignados a esta tarea, cuánto de las pruebas la pueden/deben llevar a cabo los analistas funcionales y/o programadores, si es necesario asignar a personas exclusivamente para hacer esta tarea o caso contrario, contratar a una empresa o grupo externo, cómo sincronizarán las tareas de prueba con el resto de las tareas, cómo hacer para medir los resultados que se vayan obteniendo durante las pruebas, cómo medir el avance de las pruebas, cómo demostrarle a la empresa que la actividad de las pruebas es necesaria, cómo justificarle el costo de realizar pruebas al cliente, cómo demostrar los beneficios y
ganancias que ofrece la actividad de las pruebas, y otras.
Todas estas preguntas que alguien se hace en algún momento del proyecto dan pie a pensar en que no solo es «probar» sino que hay algo más que eso, y por ese motivo se ha incorporado desde hace un tiempo a esta parte la palabra «testear» que incluye el «probar», ya que hoy en día el «Probador» (ó Tester, también llamado) debe realizar toda una serie de tareas aparte de «probar».
MAPA MENTAL
Aquí se muestran las principales que se deberían realizar dentro de cualquier contexto y/o modelo aplicando el correspondiente criterio
para cada caso.
- Entender el software desarrollado
- Estimar esfuerzo de prueba
- Elaborar la estrategia y plan de pruebas
- Elaborar los componentes
- Diseñar la cobertura
- Ejecutar las pruebas
- Reportar el avance
- Reportar las incidencias
- Registrar los procesos
- Elaborar reportes finales
