Trabajo como ingeniero de control de calidad/pruebas en una pequeña empresa de software. Mis superiores me asignaron varios proyectos (7 diferentes) en los que hago pruebas, recopilación de requisitos, actualizaciones de clientes, resolución de consultas de desarrolladores/clientes, etc. Principalmente hago pruebas funcionales/de caja negra. Antes del lanzamiento a producción o mostrárselo al cliente, probé muchos buenos escenarios y encontré muchos defectos en el código. La mayoría de ellos se arreglaron. Hice mi análisis y lo envié al cliente para su aprobación. Tuve una buena estrategia de prueba. Ahora, este módulo se puso en marcha en los servidores de producción y el cliente encontró algunos errores que aparecen en condiciones específicas que él me informó. eso "
Soy un evaluador junior aquí, mis superiores y las partes interesadas no confían en mi trabajo como evaluador, ¿cómo me atrevo a decir que APROBÓ el control de calidad? Piensan que soy descuidado, que no soy digno de trabajar y que soy arriesgado.
¿Es realmente posible hacer que cualquier software esté libre de errores?
¿QA es la única persona responsable de los errores? incluso si está probando varios proyectos diferentes al mismo tiempo y actualizando varios clientes e intentando completar los proyectos en la fecha límite (donde el tiempo para probar y resolver errores no se menciona en el alcance del proyecto y ni siquiera se le cobra al cliente por el mismo)?
Solo quiero saber cómo lidiar con esta situación. ¿alguien puede sugerirme que hacer?
Está describiendo una organización inmadura, aparentemente política, un equipo de bajo rendimiento y una cultura de trabajo hostil.
No existe tal cosa como un producto o servicio 100% libre de defectos de ningún tipo. Y una organización madura con procesos y capacidades de alto rendimiento sabe esto y tiene un proceso de mejora continua mientras que también tiene contingencias para lidiar con el cuidado de la postproducción para lidiar con los defectos conocidos y desconocidos encontrados por los usuarios finales.
En una función de control de calidad, su misión sería tener procedimientos de prueba de control de calidad en constante mejora, incluidos los scripts en su caso, que permitirían una mejor identificación de defectos, pero su objetivo nunca debe ser 100% libre de defectos. Sus objetivos de posproducción deben tener algunos números contra hallazgos de defectos de gravedad alta a baja que deben distribuirse normalmente o sesgarse hacia el lado bajo. Y siempre que los defectos encontrados en la posproducción estén dentro de esa distribución, sus pruebas funcionan según lo diseñado.
¿Qué hacer? Está claro que su organización prospera al encontrar chivos expiatorios en su talento humano en lugar de centrarse en mejorar los procesos y las capacidades y tener objetivos realistas. La probabilidad de que cambies esto es casi cero, y con eso me refiero a cero.
Así que tienes la opción de simplemente encogerte de hombros y seguir trabajando y hacer lo mejor que puedas o buscar un mejor trabajo y organización. Esto no quiere decir que hiciste un trabajo estelar. No tengo idea si lo hiciste o no, pero sé que todo nuestro trabajo se puede mejorar todos los días. Eche un vistazo a sus procesos y vea si hay algo que podría haber hecho mejor, pero no tome toda la propiedad aquí.
Al igual que con todas las dificultades de gestión, el verdadero problema es la comunicación, ¡no su nivel de habilidad!
Si sus superiores lo hacen sentir incómodo, juzgan mal su rol o subestiman su nivel de habilidad, debe hablar con ellos. Como gerente de producto, le doy mucho valor a la comunicación.
Sin embargo, al descubrir defectos al principio del ciclo de desarrollo, las pruebas de control de calidad ahorrarán tiempo, dinero y frustración. Cuanto más tiempo pase desapercibido un error, más costoso será corregirlo.
Debe hacer lo que pueda para volverse útil, lo más rápido posible y al mismo tiempo causar la menor sobrecarga posible.
Creo que su trabajo actual debe ser no solo beneficioso para la empresa, sino también para usted. Si ya no te sientes feliz acerca de en quién te estás convirtiendo o del trabajo que estás produciendo, no te estás beneficiando de tu trabajo ni de ti mismo para quedarte.
Sí, es posible estar 100 % libre de defectos y sí, es responsabilidad del control de calidad no decir que está 100 % libre de defectos cuando no lo está.
La clave de esto, por supuesto, está en la definición de 'defecto'
Un defecto debe definirse como una funcionalidad que no coincide con las especificaciones.
Cada especificación debe tener una prueba acordada, que si se pasa define la especificación como cumplida.
QA debe ejecutar todas las pruebas y registrar los pases y fallas.
La única forma en que el control de calidad puede hacer mal su trabajo es saltándose las pruebas probando la versión incorrecta o algo así o mintiendo sobre los resultados. Todo lo demás, definir la especificación y las pruebas, etc., es responsabilidad compartida.
Si todas las pruebas pasan, cualquier problema que encuentre el cliente se debe a que la prueba no fue lo suficientemente buena (obtenga la aprobación y acuerde que el diseño de la prueba coincide con la especificación) o la especificación fue incorrecta (el cliente debe aprobar la especificación)
Obviamente, en el mundo real, la especificación rara vez es lo suficientemente detallada como para que las pruebas sean obvias o incluso posibles. Por lo tanto, aprobar el diseño de la prueba es EL paso más importante.
Siempre traiga algunas preguntas de casos extremos para plantear después del acuerdo (en realidad, justo antes) para que su jefe se dé cuenta de que es más difícil de lo que parece y acepte que incluso ellos pueden cometer errores.
Si parece que te están poniendo toda la responsabilidad, entonces sabes que habrá problemas en el futuro.
Si son ellos los que sugieren pruebas adicionales, entonces sabes que deberías haber trabajado más, ¡y ellos también! Pero al menos es lo suficientemente temprano en el proceso para no causar un desastre.
nvoigt