¿Crees que es una buena idea que los ingenieros de software tengan que trabajar como ingenieros de control de calidad durante algún tiempo? [cerrado]

Yo creo que si. ¿Por qué?

1. Me he encontrado con muchos ingenieros de software que creen que de alguna manera son superiores a los ingenieros de control de calidad. Creo que puede ayudar a calmar esta creencia si hacen el trabajo de un ingeniero de control de calidad durante algún tiempo y se dan cuenta de que es un conjunto de habilidades único y valioso.

2. Cuanto mejor sea un ingeniero de software para probar sus propios programas, menor será el costo de tiempo en el que incurre su código al pasar por el resto del ciclo de vida de desarrollo de software.

3. Mientras más tiempo pase un ingeniero de software pensando en cómo se puede romper un programa, más a menudo considerarán estos casos a medida que los desarrollen, reduciendo así los errores en el producto final.

4. La definición de "completo" de un ingeniero de software siempre es interesante ... si han pasado un tiempo como ingenieros de control de calidad, tal vez esta definición coincida más estrechamente con el diseñador del software.

Tenga en cuenta que hago la sugerencia anterior con un pequeño período de tiempo en mente, ya que sé que tener a alguien trabajando en un puesto que no es el puesto para el que son contratados definitivamente es una receta para perder a ese desarrollador.

¿Qué piensan todos ustedes?

1. Me he encontrado con muchos ingenieros de software que creen que de alguna manera son superiores a los ingenieros de control de calidad. Creo que puede ayudar a calmar esta creencia si hacen el trabajo de un ingeniero de control de calidad durante algún tiempo y se dan cuenta de que es un conjunto de habilidades único y valioso.

Una buena ingeniería de software tiene experiencia en calidad, incluidas pruebas, métricas y estadísticas. Cualquier persona que realice algún tipo de desarrollo de software debe ser consciente (si no está familiarizado) de mantener un código fuente de calidad y producir / mantener casos de prueba efectivos. Con el tiempo, sospecharía que cualquier desarrollador de software comprendería las diferentes facetas de la calidad: calidad de código, portabilidad, mantenibilidad, comprobabilidad, usabilidad, confiabilidad, eficiencia y seguridad.

Los ingenieros de software pueden centrarse en un aspecto particular del ciclo de vida: ingeniería de requisitos, arquitectura y diseño, construcción, pruebas y mantenimiento. Sin embargo, independientemente de su enfoque (ya sea como trabajo o en la fase actual del proyecto), es importante recordar la calidad.

2. Cuanto mejor sea un ingeniero de software para probar sus propios programas, menor será el costo en tiempo en que incurre su código al avanzar en el resto del ciclo de vida de desarrollo de software.

Eso puede ser cierto. Pero algunos problemas se ven mejor más adelante en el desarrollo. Por ejemplo, los problemas de rendimiento y eficiencia podrían no verse hasta la integración. Tener un código bueno y sólido y pruebas unitarias efectivas son solo el comienzo. La calidad debe comenzar con los requisitos y seguir hasta las actividades de mantenimiento.

3. Cuanto más tiempo pase un ingeniero de software pensando en cómo se puede romper un programa, más a menudo considerarán estos casos a medida que los desarrollen, reduciendo así los errores en el producto final.

Esa es una afirmación totalmente cierta. Pero, de nuevo, también depende de los ingenieros de requisitos verificar que no haya conflictos en los requisitos, los arquitectos deben asegurarse de que el diseño realmente aborde los requisitos, y así sucesivamente. Todos deberían tratar de hacer agujeros en su trabajo y luego trabajar con las personas apropiadas para sellarlos de manera agradable y firme.

4. La definición de "completo" por parte de un ingeniero de software siempre es interesante ... si han pasado tiempo como ingenieros de control de calidad, tal vez esta definición coincida más estrechamente con el diseñador del software.

"Completo" solo se puede medir con los requisitos. O se cumplen los requisitos y el proyecto está completo, o hay requisitos incompletos y el proyecto no está completo. Cualquier otra medida de completar es inútil.

Hacer que los programadores sean responsables de su código y exigirles que corrijan sus propios errores puede encargarse de esto. Eso y una pérdida de bonificación y / o trabajo.

No es que esta experiencia no ayude, pero ¿hasta dónde puede llegar con esta línea de pensamiento? Soporte técnico, ventas, usuario beta, fregar los inodoros (sería una experiencia humillante).

"... tengo que trabajar como ingenieros de control de calidad ..."? Lo haces sonar adversario o castigo.

Soy un programador de sofware. Considero que también es parte de mi trabajo ser ingeniero de control de calidad, a pesar de que tenemos un departamento de control de calidad. Es mi trabajo entregar software que logre ciertas cosas y, para hacerlo, tengo que escribir pruebas unitarias y asegurarme de que el software las apruebe.

Estoy en asociación con nuestro departamento de control de calidad. Mi objetivo es facilitarles su trabajo, al igual que su trabajo es ayudarme a cumplir mi objetivo de entregar software que haga lo que debería, haciendo que mi vida sea más fácil. Los considero mi segundo par de ojos y algo así como una red de seguridad, al igual que hago mis pruebas unitarias.

Elijo desarrollar software y quiero desarrollar software. Si algún gerente se me acerca y me dice que no puedo hacer eso y que tengo que hacer un control de calidad, les diría que necesitan encontrar un nuevo desarrollador de software Y una persona de control de calidad porque no trabajaré allí. Soy anal como puede ser con mi código, pero el proceso creativo y el rompecabezas / desafío de programación es extremadamente importante para mí. Prefiero volver a conducir montacargas si no puedo escribir código porque estar en un entorno corporativo sin la ventaja de ser creativo y ser desafiado como soy sería un infierno para mí.

En general, las opciones que presenta suenan muy adversas y me hacen preguntarme si ha tenido algunas experiencias realmente malas con algunos desarrolladores terribles. En mi opinión, un desarrollador SIEMPRE debe ser consciente de los problemas de calidad y las pruebas y debe estar lo suficientemente orgulloso de su trabajo como para no considerarlo terminado hasta que pase pruebas rigurosas en sus pruebas unitarias como lo que usará el departamento oficial de control de calidad. Si tuviera un compañero, o fuera líder tecnológico en un equipo y tuviera un desarrollador que mostrara alguna "actitud" hacia el control de calidad, me encontraría llevándolo a una corrección de actitud. Si ambas caras de la moneda de entrega de software no pueden cooperar y actuar como un equipo, existe un verdadero problema cultural. No me gustaría trabajar allí y RR.HH., junto con la alta gerencia, tendrían que estar al tanto.

Hacer que los programadores trabajen como ingenieros de control de calidad es una receta para perder a sus mejores desarrolladores. La programación y el control de calidad requieren diferentes conjuntos de habilidades y procesos de pensamiento.

Sin embargo, es importante que sus programadores sean expertos en el arte de probar y validar su propio trabajo antes de pasarlo al equipo de control de calidad. Los desarrolladores y el control de calidad tienen acceso a diferentes herramientas, conocimientos y habilidades. Los desarrolladores deben ser hábiles para recorrer su código en busca de un comportamiento inesperado, pruebas unitarias para condiciones de límite, enfatizar código roscado en busca de condiciones de carrera, etc. Es decir, pruebas desde la perspectiva del desarrollador.

QA realiza sus pruebas desde la perspectiva del usuario. Pensar como diferentes tipos de usuarios, inventar casos extraños y hacer que los problemas oscuros sean reproducibles son habilidades de control de calidad.

No necesariamente: tanto los programadores como los evaluadores deben tener habilidades diferentes. El hecho de que sea un buen programador no significa que pueda ser un buen evaluador (muchas personas no lo entienden, pero ser un programador no lo califica automáticamente para ser evaluador).

Un gran probador necesita tener habilidades realmente diabólicas, poder hacer cosas para las que el software no fue diseñado, pero puede esperar que el usuario lo haga en el mundo real. Eso requiere habilidad, paciencia, capacidad para ver qué puede salir mal, dónde, comprender la mentalidad del usuario y muchos otros factores.

Tenga en cuenta que uso las palabras programador y probador, pero si usted es ingeniero de software y aún no ha decidido si quiere ser programador o probador, entonces abarca ambas cosas y, por lo tanto, sí, debe tener experiencia en ambos al menos en los primeros años de tu vida antes de tomar la decisión.

Eso no significa que tome un programador experimentado y lo haga probar por un tiempo solo para hacerle comprender lo duro que trabajan los ingenieros de control de calidad.

Aquí hay algunos problemas potenciales que veo con su propuesta:

1) Si está sugiriendo que pondría a los ingenieros de software nuevos en el campo en el departamento de control de calidad por un período breve, ¿no tendrá esto el efecto contrario? - pueden suponer que el control de calidad es algo que haces cuando eres un novato y no entiendes lo que estás haciendo; después de todo, así es como les funcionó.

2) Ser un probador muy malo por un tiempo no necesariamente les enseñará nada valioso. Pero puede hacerlos incapaces de aprender más adelante, porque van a asumir que saben todo acerca de las pruebas ahora, porque pasaron 6 semanas en un departamento de pruebas en otro tiempo.

3) Dado que obviamente solo estarán allí por un corto tiempo, y el departamento de control de calidad lo sabrá, también es probable que solo se les den tareas fáciles y relativamente poco exigentes que requieren poca supervisión o comprensión, pero que los mantienen ocupados . Esto solo reforzará 1 y 2.

4) Si desea evitar 1, 2 y 3, ¿cómo convencerá a su departamento de exámenes de que vale la pena invertir una enorme cantidad de energía en enseñar y supervisar a alguien que ni siquiera está interesado en los exámenes? (Puedo decirte que lleva una cantidad de tiempo y energía aterradora trabajar con alguien que, recordemos, no ha sido elegido por su aptitud para las pruebas . No estás ofreciendo al equipo de prueba recursos adicionales durante algunas semanas, tú les pedimos que pierdan a una de sus personas más experimentadas durante algunas semanas, mientras le enseñan a su novato).

Dicho todo esto, creo que su objetivo general, aumentar la comprensión de los nuevos ingenieros de software de las pruebas, es realmente fantástico. Sin embargo, creo que es más probable que la sugerencia de Greg lo logre: haga que sus equipos de desarrollo y control de calidad colaboren estrechamente y trabaje para romper las barreras entre los equipos. (Actualmente estoy trabajando en una empresa donde los evaluadores y los programadores están en el mismo equipo; es realmente genial, y nunca quiero volver a trabajar en equipos separados).

Si todavía está interesado en que los programadores hagan un período de control de calidad, aquí hay una sugerencia: lidere con el ejemplo. Ve tú primero. Quizás lo convierta en algo que los miembros de su equipo pueden hacer cuando ya son buenos y desean obtener esa ventaja adicional, pasando un poco de tiempo cada semana con otros equipos que se especializan en áreas superpuestas: pruebas, DBA, etc. si lo presentas así, tendrás más posibilidades de éxito.

He tenido una carrera profesional que es algo inverso a lo que normalmente ves. Comencé como soporte de software para física científicamente desafiante, luego terminé trabajando en la intersección de arquitectura, programación y algoritmos para una compañía de computadoras. Después de eso, realicé la optimización del rendimiento de un importante código de ingeniería durante varios años, pero incluso ese trabajo se acabó. Ahora que me estoy acercando a la edad de jubilación estoy haciendo el control de calidad en el mismo código. Es una combinación de desafío y trabajo pesado. Tenemos un nuevo tipo muy listo que trabaja al 100% en la corrección de errores, y paso mucho tiempo trabajando con él. Es una posición desafiante, y puedes aprender mucho haciéndolo. En este punto, mi interés principal en el desarrollo profesional es para mis gemelos, que son estudiantes de primer año de la universidad. Así que tengo un nuevo interés en aprender (o volver a aprender) cosas que serán relevantes para sus carreras, especialmente las matemáticas aplicadas. Tengo una perspectiva diferente de las cosas ahora que estoy preocupado por el control de calidad / validación, mientras que para el cuarto de siglo anterior era velocidad, velocidad, velocidad a cualquier costo.

La prueba de software es el proceso destructivo más que constructivo. Pero los programadores piensan en un producto constructivo para garantizar que el producto se complete a tiempo y dentro del presupuesto. Si el desarrollador de software piensa que es destructivo para su propio producto, ¿quién será el próximo en construir el producto? Por lo tanto, cada parte del ciclo de desarrollo de software debe ser realizada por las personas asignadas en cada parte del ciclo de desarrollo. Si participó en dos o más campos, entonces es seguro que nunca será perfecto en ninguno de ellos, así que haga una cosa, ya sea programador o control de calidad o cualquier otra opción, y sea perfecto en eso.