¿Cree que es una buena idea que los ingenieros de software tengan que trabajar como ingenieros de control de calidad durante un período de tiempo? [cerrado]

12

Creo que lo es. ¿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 apagar esta creencia si hacen el trabajo de un ingeniero de control de calidad por un tiempo, y se dan cuenta de que es un conjunto de habilidades único y valioso por sí mismo.

  2. Cuanto mejor es un ingeniero de software para probar sus propios programas, menor es el costo en el tiempo en que incurre su código cuando se abre paso a través del resto del ciclo de vida del desarrollo de software.

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

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

Tenga en cuenta que hago una sugerencia anterior con un pequeño marco de tiempo en mente, ya que soy consciente de que alguien que trabaje en una posición que no sea la posición para la que fueron contratados es definitivamente una receta para perder a ese desarrollador.

¿Qué piensan todos ustedes?

    
pregunta Macy Abbey 27.11.2010 - 02:03

8 respuestas

13
  

1. Me he encontrado con muchos ingenieros de software que creen que son superiores a los ingenieros de control de calidad. Creo que puede ayudar a apagar esta creencia si hacen el trabajo de un ingeniero de control de calidad por un 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 cualquier tipo de desarrollo de software debe ser consciente (si no está familiarizado con) el mantenimiento del código fuente de calidad y la producción / mantenimiento de casos de prueba efectivos. Con el tiempo, sospecharé que cualquier desarrollador de software obtendría una comprensión de las diferentes facetas de la calidad: la calidad del código, la portabilidad, la capacidad de mantenimiento, la capacidad de prueba, la facilidad de uso, la confiabilidad, la eficiencia y la seguridad.

Los ingenieros de software podrían 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 un trabajo o en la fase actual del proyecto), es importante recordar la calidad.

  

2. Cuanto mejor es un ingeniero de software para probar sus propios programas, menor es el costo en el tiempo en el que incurre su código cuando se abre paso por el resto del ciclo de vida del desarrollo de software.

Eso podría 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 buen código sólido y pruebas efectivas de unidades son solo el comienzo. La calidad debe comenzar con los requisitos y seguir todo el camino a través de las actividades de mantenimiento.

  

3. Cuanto más tiempo dedique un Ingeniero de software a pensar cómo se puede romper un programa, más a menudo tienen que considerar estos casos a medida que los desarrollan, lo que reduce los errores en el producto final.

Esa es una afirmación totalmente verdadera. Pero, una vez más, también depende de los ingenieros de requisitos verificar que no haya conflictos en los requisitos, los arquitectos se aseguren de que el diseño realmente aborde los requisitos, etc. Todos deberían intentar abrir agujeros en su trabajo y luego trabajar con las personas adecuadas para sellarlos bien y con fuerza.

  

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

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

    
respondido por el Thomas Owens 27.11.2010 - 03:43
6

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, restriega los inodoros (eso sería una experiencia humillante).

    
respondido por el JeffO 27.11.2010 - 02:56
6

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

Soy un desarrollador de software. Considero que es parte de mi trabajo ser también un ingeniero de control de calidad, aunque tenemos un departamento de control de calidad. Mi trabajo es entregar software que logre ciertas cosas y, para ello, tengo que escribir pruebas unitarias y asegurarme de que el software las pase.

Estoy asociado con nuestro departamento de control de calidad. Mi objetivo es hacer que su trabajo sea más fácil, al igual que su trabajo es ayudarme a cumplir mi objetivo de entregar un software que haga lo que debería, y así facilitar mi vida. 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 acercara y me dijera que no podía hacer eso y tenía 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 puedo estar con mi código, pero el proceso creativo y el rompecabezas / desafío de la programación es extremadamente importante para mí. Preferiría volver a conducir carretillas elevadoras si no puedo escribir código porque estar en un entorno corporativo sin la ventaja de ser creativo y ser desafiado de la forma en que estoy sería un verdadero infierno para mí.

En general, las opciones que presentas son muy contradictorias y me dejan preguntándome si has tenido algunas experiencias realmente malas con algunos desarrolladores terribles. En mi opinión, un desarrollador SIEMPRE debe estar al tanto de los problemas de calidad y las pruebas, y debe estar lo suficientemente orgulloso de su trabajo como para que no lo consideren terminado hasta que pase las pruebas rigurosas en sus pruebas de unidad como lo que usará el departamento oficial de control de calidad. Si tuviera un compañero, o fuera técnico en un equipo y tuviera un desarrollador que mostrara alguna "tudeza" hacia el control de calidad, me encontraría llevándolo para una corrección de actitud. Si ambos lados de la moneda de entrega de software no pueden cooperar y actuar como un equipo, existe un verdadero problema cultural. No querría trabajar allí y RR.HH., junto con la alta dirección, tendrían que estar al tanto.

    
respondido por el the Tin Man 27.11.2010 - 05:05
5

Lograr 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 tengan experiencia 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 expertos en revisar su código en busca de un comportamiento inesperado, realizar pruebas de unidad para las condiciones de límite, hacer hincapié en el código de subprocesos en busca de condiciones de carrera, etc.

QA hace 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.

    
respondido por el Michael Shaw 27.11.2010 - 11:44
3

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

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

Tenga en cuenta que utilizo las palabras programador y probador, pero si usted es un ingeniero de software y aún no ha decidido si desea ser programador o probador, esto 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 usted tome a un programador experimentado y lo haga probar por un tiempo solo para que comprenda lo difícil que son los ingenieros de control de calidad.

    
respondido por el Roopesh Shenoy 27.11.2010 - 07:12
1

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

1) Si está sugiriendo que incorpore a ingenieros de software nuevos en el departamento de control de calidad por un breve período, ¿no tendrá esto el efecto contrario? - pueden asumir 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 funcionó para ellos.

2) Ser un probador muy malo por un tiempo no necesariamente les enseñará nada valioso. Pero puede hacer que no se puedan enseñar más adelante, porque asumirán que saben todos sobre las pruebas ahora, porque pasaron 6 semanas en un departamento de pruebas una vez.

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 reciban tareas relativamente sencillas que requieran poca supervisión o comprensión, pero que mantenlos ocupados Esto solo reforzará 1 y 2.

4) Si desea evitar 1, 2 y 3, ¿cómo va a persuadir a su departamento de pruebas de que vale la pena invertir una cantidad tremenda de energía en la enseñanza y supervisión de alguien que ni siquiera está interesado en las pruebas? (Puedo decirle que se necesita una gran cantidad de tiempo y energía para trabajar con alguien que, recordemos, no ha sido seleccionado para su aptitud de prueba . No le está ofreciendo al equipo de prueba más. recurso durante unas pocas semanas, les está pidiendo que pierdan a una de sus personas más experimentadas durante unas pocas semanas, mientras le enseñan a su novato).

Habiendo dicho todo eso, creo que su objetivo general, aumentar la comprensión de las pruebas de los nuevos ingenieros de software, es realmente fantástico. Sin embargo, creo que es más probable que la sugerencia de Greg lo logre: obtén tu dev & Los equipos de control de calidad colaboran estrechamente y trabajan para romper las barreras entre los equipos. (Actualmente, estoy trabajando en una empresa donde los evaluadores y programadores están en el mismo equipo. Realmente es genial, y nunca quiero volver a trabajar en equipos separados).

Si todavía estás interesado en que los programadores realicen una temporada en el control de calidad, aquí tienes una sugerencia: predicar con el ejemplo. Ve tú mismo primero. Quizás se convierta en algo que los miembros de su equipo puedan hacer cuando ya sean buenos y quieran obtener esa ventaja adicional, dedicando un poco de tiempo cada semana a otros equipos que se especializan en áreas superpuestas: pruebas, DBA, etc. Si lo presenta así, tendrá más posibilidades de éxito.

    
respondido por el testerab 02.12.2010 - 00:57
0

He tenido una especie de trayectoria profesional que es la inversa de lo que normalmente ves. Yo empecé como soporte de software para la física científicamente desafiante, luego terminó trabajando en el Intersección de arquitectura, programación y algoritmos para una empresa de informática. Después eso funcionó. Hice la optimización del rendimiento de un importante código de ingeniería durante varios años, pero incluso ese trabajo se agotó. Ahora que me estoy acercando a la edad de jubilación, estoy haciendo un control de calidad en el mismo código. Es una combinación de desafío y pesadez. Tenemos un tipo nuevo realmente listo que trabaja al 100% en la corrección de errores, y paso mucho trabajando con él. Es una posición desafiante, y puedes aprender mucho haciéndolo. En este punto, mi principal interés 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 reaprender) cosas que serán relevantes para sus carreras, especialmente matemáticas aplicadas. Tengo una perspectiva diferente de las cosas ahora que me preocupa la validación / control de calidad, y en el último cuarto de siglo fue la velocidad, la velocidad, la velocidad a cualquier costo.

    
respondido por el Omega Centauri 27.11.2010 - 06:02
-2

Las pruebas de software son el proceso destructivo en lugar de constructivo. Pero el programador piensa en algo constructivo para su producto para asegurar que el producto se complete a tiempo y dentro del presupuesto. Si el desarrollador de software piensa como destructivo de su propio producto, entonces quién estará cerca de construir el producto. Por lo tanto, cada parte del ciclo de desarrollo del software debe ser realizada por las personas asignadas en cada parte del ciclo de desarrollo. Si participa en dos o más campos, 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.

    
respondido por el Panjiyar Rahul 13.03.2012 - 09:39

Lea otras preguntas en las etiquetas