¿Cuál es la mayor amenaza que enfrentan los probadores de software hoy en día en sus trabajos?

En esta era de especulación y optimización de costos, algunos roles están destinados a ser eliminados. He visto la posición de Test Manager casi desaparecida en estos días. Solo hay un Project Manager que supervisa el desarrollo y prueba ambos. Apenas encontrarás Test Manager para un proyecto en estos días.
Si tengo que identificar uno, no es pensar desde el punto de vista del usuario final para el software que se está desarrollando / probando. Tenemos que mirar continuamente tanto dentro como fuera de la declaración del problema / requisito comercial. No solo tenemos que leer / comprender los requisitos comerciales, sino también pensar por qué se desarrolla este software e intentar encontrar / sugerir una ruta alternativa para abordar el problema. Ser inquisitivo todo el tiempo en el trabajo. Veo que esto falta en la mayoría de mi fraternidad.

El siguiente círculo vicioso:

1. El ejecutivo saca la fecha de su trasero.
2. Los gerentes de ingeniería “se comprometen” hasta la fecha, sabiendo que no es razonable.
3. Los gerentes de producto incluyen demasiadas funciones en el producto.
4. El equipo de desarrollo, corriendo detrás, corta esquinas.
5. El control de calidad no tiene suficiente tiempo.
6. El ejecutivo dice enviarlo de todos modos.
7. El producto es una mierda, nadie lo compra, la empresa se destroza en la prensa.
8. Despidos.
9. Nuevo ejecutivo contratado para “revitalizar la empresa”.
10. Ir al paso 1.

Que yo, el desarrollador, realmente comprenda las especificaciones y los requisitos y lo que se puede lograr (razonablemente, desde el punto de vista comercial, pragmáticamente) mejor que el probador que simplemente se sienta en una terminal tonta haciendo un trabajo de terminal tonta.

Cuando envío el código, espero que un “probador” detecte excepciones que no he detectado.

Por ejemplo: solo hoy, solo, llevé una aplicación móvil de primer esfuerzo a un usuario final (vendedor) para un cliente que tenía. Me rompió la mierda. Eso es mejor de lo que podría haberle pedido a mi dedicado chico de pruebas. Y estoy muy agradecido de que haya sido para el vendedor antes que para el tipo de prueba. (Soy el desarrollador, y estoy agradecido de que el vendedor haya roto mi software antes de que el sujeto de prueba pudiera cumplir con las especificaciones que le envié o discutí con él más o menos).

Línea de fondo.

Los probadores de software están demasiado preocupados con las “especificaciones”, mientras que conocer la lógica del dominio comercial es mucho más valioso que cumplir con ese rol “específico”.

Esto NO ES negar el valor en un régimen específico de “probador” … sino que la lógica de negocios específica y las pruebas de interfaz de usuario COMPLEMENTAN UNO AL OTRO.

(Y, como programador, no quiero que mi vendedor que diga “UI” o mi persona de “Pruebas” que diga “esto es lo que dice la especificación” compiten o entran en conflicto entre sí: necesito comentarios válidos DE AMBAS DIRECCIONES para hago lo mejor que puedo por el resultado final: un cliente / cliente).

En última instancia, soy pragmático sobre todo esto y no tomaré partido.

PERO, la amenaza “definitiva” a la que se enfrenta un “probador de software” está siendo obsoleta por usuarios finales tecnológicamente expertos (incluidas las personas de ventas que conocen las capacidades organizativas) … cuando todo lo que piensa un probador de software es una especificación específica, y no el negocio final y / o lógica de interfaz de usuario detrás de la implementación.

( Los probadores de software pueden beneficiarse en última instancia de aprovechar el conocimiento / experiencia fuera de las especificaciones técnicas específicas, si pueden sacar sus cabezas de sus traseros. – Estoy personalmente agradecido de tener ventas y probadores en ambos extremos, e irritados hasta el infinito cuando no pueden unirse en un conflicto burocrático por una mierda insignificante ) .