¿Por qué las pruebas de software se consideran menos “prestigiosas” que la ingeniería de software?

Depende de cómo esté conectada su mente y cuáles sean sus pasiones.
Soy programador, me encanta el análisis, me encanta crear diagramas de flujo del programa y cómo se relaciona una parte con otra.
En mi perspectiva y opinión,
Las pruebas de software son divertidas y requieren especialidad para realizarlas correctamente, la pregunta es incorrecta, la ingeniería de software es un ciclo completo y la prueba de software es parte de ella. Puede estar refiriéndose a la programación de computadoras.

Algunos consideran que las pruebas de software son menos prestigiosas (no lo hago) porque la forma más desenfrenada de pruebas de software es la fase de “Ejecución”.
En donde la gente simplemente leerá cientos de oraciones llamadas “guiones de prueba” previamente escritos por arquitectos de prueba de software y realizará acciones basadas en la descripción en el guión de prueba. Me gusta
“presione el botón A, la etiqueta B debe ser de color” rojo “. Si tiene que leer cientos de oraciones así y realizar acciones repetidas … eso sería realmente muy aburrido … Puedo escribir miles de líneas de códigos y no aburrirme porque Necesito pensar y analizar, no es necesario un análisis en la ejecución de la prueba … es solo seguir un script … incluso los datos de la prueba se dan, así que … sí.

Escribir planes de prueba y guiones de prueba es la parte divertida de las pruebas de software, puede interactuar con un analista de negocios para discutir los requisitos, tiene una visión de lo que un sistema tiene que realizar y puede escribir técnicas y vías para detectar un error … eso es divertido, eso es desafiante y, por lo tanto, también vale la pena el título de prestigio.

Al final del día, no se trata del prestigio que tenga su trabajo … si está contento con lo que está haciendo, entonces está bien. De lo contrario, turno!

La mejor de las suertes.

Creo que muchas personas ven las pruebas como jugar con el software y ver si algo se rompe. No creen que haya ninguna habilidad involucrada y cualquiera puede hacer este trabajo. Y tienen razón en algunos casos. Los puestos de prueba manual de nivel de entrada no requieren que conozca el código ni que formule una estrategia de prueba. Solo buscan a alguien que pueda analizar casos de prueba preescritos y registrar defectos.

Si USTED piensa que es menos prestigioso y es un probador, le animo a que cambie su punto de vista agregando valor al proceso de prueba. Formule la estrategia de prueba, piense en las pruebas que realizará con anticipación y explore las diversas posibilidades de las acciones que puede realizar para cada función. Piense en los defectos que los usuarios van a encontrar en lugar de los obvios que los desarrolladores deberían haber encontrado durante las pruebas unitarias. Cuando comienzas a mostrar a los desarrolladores que lo que haces es mejorar su producto, se te considerará parte del equipo en lugar de solo pensarlo más tarde en el proceso de desarrollo.

He contratado y administrado personal de control de calidad en varios puntos de mi carrera. Siempre los he valorado mucho; Al mismo tiempo, he observado algo del prestigio menor que han disfrutado.

La razón más importante que he observado es que es más comúnmente una posición de nivel de entrada. Las personas son contratadas con una experiencia de programación de cero a limitada. A menudo tienen la mentalidad de que la posición es un trampolín en la programación, y puede ser una buena manera. Una buena base en QA es una habilidad valiosa para cualquier desarrollador.

A su vez, esto a menudo significa que no se quedan mucho tiempo en el campo. Nuevamente, esto va en contra del prestigio para el papel. Si se quedan, puede ser como gerente, en lugar de como ingeniero de control de calidad.

Creo que todos los demás factores: control de calidad visto como un obstáculo, menos habilidoso, etc. palidecen en comparación con este factor.

No creo que así sea. Pero mientras los ingenieros de control de calidad carezcan de prestigio, y eso no ha cambiado mucho en los últimos 40 años, será difícil contratar personas que estén realmente comprometidas con el desarrollo de una carrera de control de calidad.

He conocido algunos. Tienden a gravitar hacia campos donde el control de calidad tiene un prestigio real. Por ejemplo, áreas críticas para la seguridad. Tareas como la certificación de software de navegación para aeronaves.

En áreas menores, lo que me gusta ver en un ingeniero de control de calidad es el liderazgo. Un defensor de la calidad, con conocimiento de técnicas y herramientas y metodologías para lograr la calidad, y la capacidad de llevar a los desarrolladores a adoptarlas.

Ese es un gran desafío para un ingeniero junior. Pero ese es el camino hacia el prestigio.

Porque al final una empresa elegirá poner dinero en el equipo que hace que el widget esté por encima de todos los demás. Dado que hay muy pocas pautas y sanciones duras como en la ingeniería física para fallas, puede patinar en las pruebas. Esto se debe a que sin características, no tiene software y sin software no tiene ingresos (en muchos casos).

Entonces, si las corporaciones pagaran el 120% del objetivo de desarrollo para el control de calidad (en lugar de lo contrario), obtendrían los mejores desarrolladores trabajando en esas cosas y las personas que ahora se consideran adecuadas para ser SDET que trabajan en funciones. La prueba tiene problemas más difíciles de resolver que el desarrollo primario en casi todos los componentes no triviales, por lo que sería genial. Sin embargo, los desarrolladores son lo que las empresas priorizan (en términos de fabricantes de widgets) porque los widgets hacen dinero … y el prestigio (y la habilidad) sigue el grado de pago. En Microsoft, viste esto como una diferenciación de nivel, ya que el pago era el mismo para los mismos niveles en todas las disciplinas. Creo que en un momento calculé que en toda la división de Windows en Microsoft había una clara separación de banda de nivel completo entre Test y Dev para personas equivalentes. Una banda sénior SDET sería un desarrollador principal, si fueran un desarrollador. De hecho, creo que hay dos Principios ic en toda la organización de prueba frente a cien en las organizaciones de desarrollo y pm. Para llegar a ese nivel como probador, tenía que ser un gerente. Esto, por supuesto, fue antes de que Microsoft abandonó la farsa hace unos años y eliminó la disciplina de prueba. Por lo que están pagando con un software más defectuoso y una pérdida de conocimiento institucional sobre las pruebas, pero probablemente ciclos de envío más rápidos (más tiempo de desarrollo disponible).

La ingeniería de SW crea los problemas. QA simplemente los encuentra. Obviamente la creatividad es más prestigiosa. (tos)

Bromas aparte, he conocido personas de control de calidad que eran más analíticas, sistemáticas y creativas que los malos programadores (¡y diseñadores inexistentes!) Que estaban limpiando después.

Además, Agile como metodología no es elite. Permite que demasiados programadores perezosos y escamosos sustituyan la calidad por una respuesta rápida. A veces son los limpiadores de gran potencia los que tienen un buen valor en comparación con los (con suerte pocos) ingenieros de SW de acceso directo escamosos o flojos.

Estoy de acuerdo en que esta puede ser más o menos la visión en el mercado, pero especialmente depende de qué tipo de QA sea.

Si no está integrado en el equipo y es visto como un portero o una persona que levanta la bandera roja, puede experimentar que no tiene tanto prestigio en el equipo.

Pero si ingresa a SDLC en una etapa muy temprana y trabaja para desarrollar la calidad en lugar de solo realizar pruebas, crear marcos de automatización, mejorar procesos y ayudar a liberar su prestigio podría ser más alto que los desarrolladores de SW.

Como nota al margen, para algunos proyectos, un control de calidad es solo otro desarrollador de software que defiende la calidad. La calidad es responsabilidad de todos los miembros del equipo, pero como la mayoría de las prácticas y valores, podría necesitar un campeón.

En primer lugar, el control de calidad se considera, y a menudo es, una función principalmente burocrática. Y aquellos de nosotros que tenemos experiencia en hardware o sistemas, no nos lo tomamos tan en serio, después de todo, MTBF es matemática divertida que nadie cree, así que ¿quién realmente toma en serio a las personas que escriben esos números?

Por otro lado, la “ingeniería de prueba”, dependiendo del campo, puede tener un prestigio serio. Cuando se habla de sistemas críticos para la vida / seguridad / misión, digamos en defensa o aeroespacial, las pruebas son un gran problema, las personas que diseñan y realizan pruebas son ingenieros serios, y se toman en serio.

Y luego están los productos farmacéuticos, donde el control de calidad es tanto una cuestión de bioquímica como de análisis estadístico en profundidad, con mucho dinero en juego. QA la gente se toma en serio. (Corrolario, si quiere que lo tomen en serio en la intersección del control de calidad y el software, escriba el software de control de calidad para la industria farmacéutica).

Las personas reciben premios por hacer cosas, no asegurarse de que las cosas funcionen y encontrar problemas.

Pero las personas que realmente entienden la ingeniería de software saben que aquellos que realizan pruebas de software correctamente en un proyecto grande tienen una comprensión mucho más amplia del proyecto y del producto que cualquier desarrollador individual.

Debido a que la mayoría de los QA solo hacen pruebas manuales de blackbox, está claro por qué las personas lo verían de esa manera. No importa cuán importante sea el rol de QA en el campo de la ingeniería de SW, la gente aún terminaría con la idea de que QA es menos prestigioso que SW-dev. Quiero decir, ni siquiera necesitas un título universitario para probar un producto directamente. Si el ingeniero de software fuera lo suficientemente inteligente, crearía la aplicación para que cuando los usuarios beta encuentren un error, se le envíe un informe automáticamente.

Las cosas serían diferentes si los QA comienzan a usar pruebas unitarias, pruebas de extremo a extremo o cualquier otra forma de prueba automatizada para hacer las cosas.

Hay muchos niveles en esto. En teoría, no estoy de acuerdo con la premisa establecida porque desarrollar una estrategia de prueba adecuada e implementar pruebas automatizadas, incluso para escenarios que son difíciles de probar, a menudo es tan desafiante y técnico como desarrollar el programa en sí.

Dicho esto, hay una brecha entre la teoría y la realidad. Visto desde mi perspectiva (desarrollador de software en varias organizaciones grandes que tienen presupuestos de prueba enormes), los probadores que operan en el nivel que acabamos de describir son muy raros. En muchas organizaciones (incluso compañías de pruebas especializadas que venden probadores como consultores) hay muchas personas que se hacen llamar probadores que no son capaces de operar en el nivel que se acaba de describir. Son simplemente “botones” capaces de seguir manualmente los guiones (es decir, documentos de Word) y tal vez escribir dichos guiones de prueba. Muchos no tienen educación especial en las pruebas y provienen de un estilo de vida completamente diferente y se convirtieron en probadores sin capacitación. Además, ignorando la educación / capacitación, no parecen tener ninguna habilidad especial y parecen fácilmente reemplazables, su conocimiento sobre el sistema se limita básicamente a cómo lo ve un usuario final. Claramente, este no es el mejor fondo para que el trabajo de alguien sea visto como prestigioso. Además, a menudo las tareas más difíciles de automatizar la configuración de las pruebas se dejan a los ingenieros de software. A menudo, los ingenieros también tendrán que, al menos en gran medida, hacer el trabajo de descifrar la estrategia de prueba (es decir, qué casos de prueba se deben usar en función de los cambios, cómo lograr una buena cobertura, etc.), que por supuesto también es natural dado que conocen el código, pero al mismo tiempo es parte de las tareas más “avanzadas” de las que algunos probadores se enorgullecen es lo que hace que su trabajo sea desafiante. En tal configuración, los desarrolladores de software son, en mi opinión, los “profesionales de QA”, y el único papel de los probadores es ejecutar ciegamente los scripts, como la persona de QA al final de una línea de producción de widgets (que no es prestigioso como bien).

También hay otros tipos de probadores con los que me he encontrado a menudo: son desarrolladores “agotados” o quizás desarrolladores que realmente nunca hicieron el corte y, por lo tanto, se les animó a convertirse en pruebas. Nuevamente, muchas personas con estos antecedentes no estimulan la confianza en la profesión.

Pero como se mencionó, definitivamente creo que el control de calidad del software puede ser una profesión genuina con requisitos y desafíos tan duros y que merece tanto prestigio como la ingeniería de software. Pero probablemente llevará tiempo y también requiere un aumento de la barra de calidad dentro de la comunidad de pruebas antes de que esto sea ampliamente reconocido. Por ejemplo, creo que debería haber más diferenciación en los títulos para que un probador de tipo “pulsador de botón” tenga un título, mientras que un verdadero profesional de control de calidad tiene un título diferente. Hoy, ambas personas pueden llamarse a sí mismas “probadores”, lo cual es claramente injusto, dado que hay un mundo de diferencia en el nivel en el que operan.

Espero no haber ofendido a nadie, así es como lo veo todos los días 🙂

La prueba de software es un proceso de ejecución de un programa o aplicación con la intención de encontrar los errores de software. También se puede establecer como el proceso de validación y verificación de que un programa de software, aplicación o producto: Cumple con los requisitos comerciales y técnicos que guiaron su diseño y desarrollo.

Las pruebas de software tienen un futuro mejor. No era menos prestigioso que tenía su alcance. Las pruebas de software tienen buenas oportunidades de carrera. Cada software necesita ser probado para detectar errores o errores. Por lo tanto, el software nunca será menos prestigioso que la ingeniería de software.

@http: //www.softwaretesting-certi…

En mi opinión, las llamadas empresas de nivel cmm han hecho que los evaluadores sean menos creativos al hacer que los evaluadores ejecuten ciegamente casos de prueba. no quieren que sus evaluadores mejoren sus habilidades y, en cambio, entrenen en tecnologías, lo cual es útil solo internamente.

los probadores que usan el enfoque basado en el contexto junto con el caso de prueba y se capacitan en el dominio / producto son mucho mejores porque son personas que usan sus cerebros en las pruebas

Lo siento pero no estoy de acuerdo con esta oración.
En que mundo estas
Si encuentra a alguien con tal pensamiento, simplemente ignórelo porque esas personas considerarán otros trabajos también como menos superiores y usted no es para que cambien de opinión sobre esas personas.
Solo haz tu trabajo … porque creo que el trabajo habla mucho.
La prueba de software es una parte de la ingeniería de software sin la cual el ciclo no está completo.
Todas las partes de la ingeniería de software son importantes para que un proyecto o producto tenga éxito.

Probablemente tenga que ver con el hecho de que los controles de calidad simplemente prueban qué construyen los ingenieros de software desde cero.