¿Cuáles son los principales desafíos que ha enfrentado como probador de software? ¿Cómo los has superado?

Comprender los requisitos a veces es un obstáculo. Esto generalmente se debe a que los requisitos no están claramente definidos. He hecho documentos de diseño y puedo decirle que el cliente no siempre expresa sus necesidades con claridad, por lo que es su trabajo investigar y hacer preguntas.

Otros desafíos:
1. Volver a probar el mismo código una y otra vez, puede ser agotador
2. Tener que lidiar con servidores que suben y bajan, lo que lo pone atrasado en las pruebas
3. Tratar con los programadores.

¿Retos principales? No estoy seguro de qué define main. Supongo que cualquier cosa que haya bloqueado el progreso de una persona por un tiempo lo convierte en un estado “principal”.

Como probador de software, el principal desafío para mí en el pasado fue siempre acerca de cómo me comunico de manera efectiva y cómo influyo en un proyecto.

Si dejo de influir en un proyecto, a las personas les resultará fácil ignorar cada gran información que les proporcione y, por lo tanto, todas mis habilidades se volverán inútiles.

Los principales desafíos que he enfrentado como probador de software son:

Tener la sensación de que hay una cantidad imposible de trabajo por hacer, que nunca lo haré y que me criticarán por no hacer un trabajo infinito.
Lo superé con la ayuda de James Bach. Tomé su curso de prueba rápida de software en 2000 y descubrí el secreto: Do My Best . Si hago lo mejor que puedo y explico lo que estoy haciendo y reporto mis resultados honestamente, entonces nadie puede quejarse de mi trabajo. Debo hacer compensaciones, pero puedo hacer mi mejor esfuerzo para hacer compensaciones inteligentes, y ser abierto y honesto sobre ellas, y nadie se quejará.

Tener la sensación de que soy responsable de todos los errores en el producto.
Superé el segundo con la ayuda de James Bach, quien puso en mi mente la idea de que la calidad viene del equipo , y todos los compañeros y gerentes que aceptaron la idea loca. Comencé a tratar la mala calidad como un problema de equipo, no como un problema de prueba, en la forma en que reporté errores y solicité comentarios sobre cómo prevenirlos en lugar de simplemente detectarlos. Introduje fiestas de usuarios regulares donde todo el equipo se reunió para simular el uso de los productos y el juego de roles durante la noche. Convertí la calidad viene del equipo en sentido común en mi contexto.

Hacer que los tomadores de decisiones en el proyecto me ignoren.
Obtuve más del tercero al encontrar grandes errores terribles e informarlos. Eso llamó su atención.

El principal desafío que he tenido, y todavía tengo, es convencer a la gente de que las pruebas de software son más que escribir automatización.

EDITAR: No estoy seguro de haber superado realmente ese desafío. He podido demostrar que hay un valor en el tipo de prueba que hago cuando la gente realmente lo ve, pero cuando crees que puedes hacer pruebas lo suficientemente buenas solo con la automatización, es una venta realmente difícil.

Para mí los grandes desafíos son: –

1 pruebe un software una y otra vez y, en algún momento, el problema que encontrará e intentará mostrarle al desarrollador que desaparecerá.

2. cuando encuentras algún error y le das al desarrollador, ellos piensan que estoy tratando de demostrarles que estoy equivocado, pero es mi trabajo. No sé por qué se enojan.