El criterio es lo que usted está comprando

Las propuestas se cotizan por volumen: una cantidad de testers, una cantidad de ciclos, una cantidad de casos. Esas cifras son fáciles de poner una al lado de la otra, y por eso los proveedores arrancan por ahí. Dos equipos pueden correr la misma cantidad de casos sobre el mismo producto y salir con resultados completamente distintos, así que el conteo por sí solo no le dice casi nada a quien compra.

Lo que los separa es dónde miran. Diseñar pruebas es una seguidilla de decisiones sobre qué merece atención. Qué flujos mueven la plata. Qué integración es más probable que esté mintiendo sobre su estado. Qué combinación de datos a nadie se le ocurrió escribir. Nada de eso está en el documento de requisitos; sale de haber visto fallar software antes.

Los modos de falla viajan entre industrias mucho mejor que las industrias mismas. Un pago cobrado dos veces porque un reintento salió ante una respuesta lenta es el mismo defecto en un checkout de retail, en una prima de seguros o en una factura de servicios públicos. Una conciliación que pierde un registro en silencio cuando el lote cruza la medianoche se ve igual en logística que en banca. Un modelo de permisos que se filtra entre dos usuarios del mismo cliente tiene la misma forma en un producto de salud y en una plataforma educativa.

Quien vio la versión de retail sabe ir a buscar la de banca, y lo sabe en la primera semana y no en el tercer ciclo. Ninguna metodología enseña eso y ningún certificado lo demuestra. Sale de haber probado suficientes productos distintos como para que los patrones empiecen a repetirse.

Por eso mismo el conocimiento de dominio suele venderse por encima de lo que vale. Conocer el vocabulario de una industria ayuda a hablar con sus stakeholders, y la mayoría de los testers lo agarra en quince días. Conocer cómo se rompe el software es la parte que toma años, y es la que se lleva de un cliente al siguiente.

• El plan de pruebas argumenta sus prioridades en vez de listar cada funcionalidad con el mismo peso
• Alguien pregunta qué pasa con un flujo en cierre de mes, o con el tercero caído, antes de que nadie lo haya escrito
• Un defecto se levanta con la consecuencia de negocio explicada, no solo con los pasos de reproducción
• Se marca un riesgo que nadie pidió revisar, porque es el que va a obligar a devolver la versión
• Hay alguien dispuesto a decir «esto no está listo» sobre una fecha que ya se anunció

Antes de que exista un contrato, pídale a un proveedor que le explique cómo priorizaría su producto. No una lámina de metodología: su producto. Qué probaría primero y por qué eso y no lo de al lado. Diez minutos de eso le dicen si está comprando criterio o cabezas.

Después pregunte quién va a hacer el trabajo de verdad, y si esa persona está en la conversación que usted está teniendo ahora. En un modelo de banca de perfiles la respuesta suele ser que no, y quien aparece es el que estaba libre ese mes.

Una salvedad sobre todo esto. Un proveedor de pruebas no debería fijar las prioridades por su cuenta. Eso se acuerda con quienes saben qué no se puede permitir el negocio, es decir los expertos y los stakeholders clave del cliente. El proveedor lleva los modos de falla a esa conversación y los argumenta; no zanja la pregunta él solo.