Hola desde Argentina provincia de Córdoba,
me gustaría iniciar mi participación respondiendo con mi experiencia real en la compañía que actualmente participo:
• ¿En tu organización se realizan planes de prueba? (Nunca –A veces - Siempre)
A veces. Solo confeccionamos planes para proyectos de mediana o gran envergadura. Cuando ejecutamos proyectos de mantenimiento es posible que prescindamos de tales planes y trabajemos únicamente con pruebas exploratorias.
• ¿Que herramientas utilizan para realizar su planes de prueba? (Ninguna – MS Project)
Utilizamos solamente MSProject para transmitir la planificación a La Gerencia y otros interesados, pero nuestra planificación central la hacemos utilizando metodología Scrum.
• ¿Cómo actualizas el plan? (Ni idea - Hago otro)
Normalmente los planes de pruebas se actualizan para proyectos que implican cambios de versión (cambios significativos) mientras que para cambios de Build, utilizamos planes nuevos a escalas reducida. Inclusive es posible que ni siquiera tengamos en cuenta los planes de pruebas generados originalmente para los proyectos y esto es más que nada una decisión política para dar soporte a aspectos técnicos que dicen que así debemos hacerlo.
• ¿Como estimas tus tiempos? (Mandrake - Experiencia)
Inicialmente utilizamos fórmulas para ejecutar "cálculos duros" en base al esfuerzo de desarrollo, pero luego que se tiene más conocimiento del negocio y mayor conciencia del sistema, ejecutamos ajustes que se apoyan más en el juicio experto de los analistas de pruebas antes que cualquier fórmula.
• ¿Como defines la criticidad del software a probar? (Cantidad de Líneas de código – Impacto en la organización)
La criticidad queda definida en fases de elaboración, es decir pos iniciación y pre construcción, y debido a que gestionamos con Scrum, definimos la criticidad del sistema según aspectos del negocios (intereses del cliente), aspectos de complejidad funcional (intereses de los desarrolladores), entre otros aspectos. No utilizamos métricas automáticas para definir criticidad sino reuniones de proyectos que definen las distintas iteraciones (Sprint).
• ¿Cuantos ciclos de prueba estimas conveniente? (1 – Siempre 3 – Depende de los casos)
La velocidad de respuesta que nos exigen nuestros gerentes nos obligan la mayoría de las veces a ejecutar solo un Ciclo de Pruebas Funcionales y luego los ciclos necesarios para verificaciones de correcciones de defectos detectados. Personalmente aconsejo que se ejecuten tantos ciclos como sea posible siendo mandatario el tiempo establecido para cumplimentar todos los ciclos. Para ser más claro, descreo de la estabilidad y fiabilidad de cualquier sistema que no haya sido probado por una X cantidad de tiempo definida para garantizar estos dos aspectos, estabilidad y fiabilidad, por lo que un ciclo, dos, tres o más no es tan importante como la cantidad de tiempo que se designa para la corrida de cada ciclo o el conjunto de ciclos. Es decir que la estrategia es lo más importante.
• ¿Cuántas personas realizarán las pruebas? (2 – 3 – Yo solito hago todo, yo soy el área de pruebas
)
La cantidad de personas involucradas varía según las necesidades de cada proyecto. Los equipos son netamente dinámicos. Nuevamente la estrategia es lo más importante
• ¿Quiénes realizaran las pruebas? (Yo - Tu)
Los equipos dinámicos deben crecer en cantidad según la necesidad de cada proyecto, pero deben decrecer hasta un mínimo de integrantes definido organizacionalmente, según la criticidad de los sistemas. Por ejemplo, mi equipo de Testing tiene un fijo mínimo de tres (3) integrantes permanentes y crece dinámicamente hasta un máximo de 15 integrantes.
• ¿Qué capacidades o experiencias deben tener los Testers? (Ninguna – Experiencia en Testing – Exp en Testing y en el negocio)
En nuestro caso las habilidades técnicas son de gran importancia, pero lo son menos que la experiencia en el negocio. Esto es así por el tipo de sistemas que proveemos a nuestros clientes.
Saludos,
Javier Santillán
