¿Las pruebas de software son más fáciles que el desarrollo de software?

La prueba de software es diferente del desarrollo de software, no es más fácil. Al menos para los SDET.

Para usar el lenguaje de Microsoft: el desarrollo de software lo realizan ingenieros de desarrollo de software (SDE). La prueba de software la realizan ingenieros de prueba de software (STE) e ingenieros de desarrollo de software en prueba (SDET). Estas divisiones funcionales se han ido en su mayoría ahora, pero aún se aplican en otros lugares.

Las empresas estatales tienden a realizar pruebas manuales que eran demasiado caras para automatizar. Por ejemplo, configurar un conjunto de 20 máquinas en una variedad de topologías de red diferentes y probar su conectividad de extremo a extremo con herramientas programables, de forma manual o con las herramientas que los SDET escribieron para ellas.

Las SDET escribieron código para probar programas. Por ejemplo, si alguien escribió un conjunto de API, un SDET escribió pruebas exhaustivas para la API de forma individual y colectiva. También escribirían pruebas de estrés, pruebas de rendimiento, verificar el consumo de recursos, la corrección, etc.

Las SDE escriben código que se envía al cliente o que se ejecuta en servicios utilizados por el cliente o en su nombre.

El código SDET se escribe como código de “caso feliz”. Si llega a condiciones inesperadas (como falta de memoria), simplemente vuelva a ejecutarlo. El código SDE, por otro lado, a menudo se espera que se ejecute indefinidamente sin reiniciar, para sobrevivir a problemas inesperados y para comportarse de manera proscrita en cada circunstancia. El código SDET está más cerca de la calidad del código prototipo, mientras que se espera que el código SDE sea a prueba de balas.

¿Cuál de las dos tareas a continuación es más difícil?

  • (SDE) Escribir un controlador de sistema de archivos para Windows
  • (SDET) Verifique que un sistema de archivos determinado funcione correctamente en todos los casos.

Sí, yo tampoco lo sé. Pero tendería a pensar en escribir el controlador real.

¿Cuál de estos es más difícil?

  • (SDE) Escriba una API que devuelva un número pseudoaleatorio.
  • (SDET) Determine si esa API está haciendo su trabajo.

Si no respondió el trabajo de SDET para este, bueno, es por eso que no es un SDET y por qué lo necesita.

Los desarrolladores generalmente profundizan en un área. Los desarrolladores de pruebas generalmente son amplios y de profundidad media, aunque a veces son profundos solo por diversión.

Ninguno de los trabajos es intrínsecamente más difícil. Requieren diferentes tipos de pensamiento y diferente énfasis en los artefactos de código. Cualquier dificultad tiene más que ver con la tecnología específica (por ejemplo, sistemas de archivos vs. interfaces de script) que con el rol general.

¿Qué puedo agregar a la gran respuesta de John L. Miller? Solo una pequeña nota sobre pruebas automatizadas.

Creo que en las pruebas automatizadas a menudo es más difícil que el desarrollo real de la base del código principal:

  • Las pruebas tienden a causar mucha más duplicación de código, lo que debería manejarse.
  • Las pruebas tienden a causar muchas más situaciones que parecen duplicación de código, pero en realidad no lo son. A veces, varias pruebas que tienen un código casi idéntico es solo una coincidencia, pero si simplemente mueve todo el código común a métodos separados, puede tener problemas una vez que encuentre otro caso similar que requiera un comportamiento diferente.
  • Las pruebas a menudo tienen que configurar el entorno para la aplicación principal y tratar con tecnologías ausentes en la aplicación principal. Por ejemplo, si escribe un código que envía paquetes a través de la red, coloca algunos errores de manejo para los casos en que la red es lenta, solo un montón de declaraciones if-else. Pero una vez que comienza a escribir pruebas automatizadas para verificar el comportamiento de extremo a extremo, rápidamente se encuentra con problemas de configuración de firewall o emulador de red.
  • Los problemas en las pruebas se sienten durante cada construcción. ¿Tienes algunas pruebas inestables que fallan de vez en cuando y tienen que volver a ejecutar cada compilación 3 veces debido a eso? Esto puede causar mucho más dolor que la base de código de la aplicación principal.
  • Las pruebas pueden tener mucho más código que la aplicación principal.
  • Las pruebas pueden tener problemas de escalabilidad que son difíciles de manejar. Después de 6 meses de desarrollo, puede finalizar fácilmente con alrededor de 1000 pruebas que demoran 10 minutos en completarse. Entonces, después de corregir una información sobre herramientas en el código, debe esperar 10 minutos para que pasen todas las pruebas o rezar para no romper nada.
  • Algunos casos son más fáciles de desarrollar que probar. Por ejemplo, es relativamente fácil escribir un pequeño fragmento de código concurrente, pero verificar el comportamiento puede llevar mucho tiempo.

¿La prueba de software es más fácil que el desarrollo de software? Sí, en general, es más fácil ya que no se ocupa de las complejas necesidades comerciales en comparación con el desarrollo de software. La prueba de software es como si fuera el usuario final del producto y utilizara la aplicación de forma gratuita. Donde el desarrollo de software es una actividad para facilitar las cosas complejas y poner a los usuarios finales para mejorar la eficiencia del negocio.

Ahora todo depende del escenario. Si la aplicación de juegos de su aplicación, el probador necesita un conjunto de habilidades excelente para descifrar el código, por lo que aquí el trabajo de prueba es más difícil que el desarrollo. Otro escenario es probar la aplicación de bolsa, probar el sistema de vida, unidades de tiempo críticas, etc.

Por lo tanto, en las pruebas generales es más fácil, pero en casos específicos, las pruebas son mucho más difíciles que el desarrollo.

HTH

Depende totalmente de qué tan profundo se sumerja para probar la aplicación. Cada proyecto tiene sus requisitos que deben ser probados. Por ejemplo, una aplicación puede desarrollarse utilizando Java, .Net, etc. y así debe elegir el enfoque correcto para probar los requisitos correspondientes a una aplicación.

Considere una aplicación bancaria, donde necesita calcular el tiempo de respuesta para cargar datos en una página en particular. Esto se puede hacer manualmente usando un cronómetro si y solo si hay pocas páginas en las que este tipo de rendimiento necesita ser probado. Pero si se extiende a través de la aplicación, las pruebas de rendimiento entran en escena. Entonces, dependiendo de los requisitos, modifica su enfoque.

En lo que respecta a su pregunta, depende de su nivel de interés. Si le gusta y comprende el lenguaje de programación, hay muchas cosas que puede probar y probablemente encuentre la opción correcta que más le convenga.

Elija lo que elija, las opciones son muchas y no hay un camino fácil hacia el éxito.

Tanto los desarrolladores como los evaluadores juegan un papel importante en la entrega del proyecto y, por lo tanto, lo que es más fácil o difícil sería relativo y los encuentro a la par.

He trabajado en ambos y, para ser sincero, ninguno de los dos es fácil.

Una de las mayores diferencias es el alcance.

Los desarrolladores de software generalmente solo se centran en una sola parte de la aplicación completa y trabajan para arreglar las cosas que la afectan. Su campo de alcance se vuelve muy limitado y solo trabaja en ese componente que nunca comprende realmente ‘la imagen completa’ y se espera que escriba código limpio y organizado que no solo solucione el problema sino que no afecte el código de los demás.

Los evaluadores necesitan conocer todo el producto de adentro hacia afuera, lo que puede ser muy estresante. Debe informar problemas con el código de desarrollo y asegurarse de que se solucionen lo antes posible. Necesitas ‘monitorear’ prácticamente todos los desarrolladores

Es cierto que entrar en las pruebas es mucho más fácil que entrar en el desarrollo. Tienes que saber codificar en al menos un lenguaje de programación para hacer el desarrollo. Solo tiene que saber cómo encender una computadora para comenzar a probar.

¿Pero es cierto que sigue siendo más fácil? ¿Que alguien que se toma el tiempo para ser realmente bueno en esto todavía tiene tareas inherentemente más fáciles o es menos capaz que un desarrollador?

Después de pasar mucho tiempo probando y trabajando en mis habilidades de prueba, y viendo aspectos de aplicaciones y pruebas de aplicaciones en los que los desarrolladores no pensaron, he estado diciendo que no, las pruebas no son más fáciles. Es diferente. En esencia, requiere una mentalidad diferente y un conjunto diferente de habilidades. Pero no es más fácil. Al menos no es más fácil ser realmente bueno en eso.

Respuesta corta: sí y no.

Respuesta más larga: para mí, el tipo con casi una década de experiencia en pruebas de software, probar software es infinitamente más fácil que desarrollarlo. ¿Por qué? El simple hecho es que no soy muy bueno en la codificación; Esto lo aprendí hace mucho tiempo. Lo que soy muy bueno es romper el código de otras personas. Para un desarrollador de software no, probar el código no es más fácil que escribirlo y desarrollarlo.

Hay algunos individuos raros que son igualmente buenos en ambos. Puedo pensar en uno fuera de mi cabeza y es terriblemente inteligente. Si bien la mayor parte de lo que hace es pruebas, consultoría de prueba y consultoría de negocios, también lo he visto hacer refactorización de código de manera espontánea cuando quedaba un día trabajando en el sitio para un cliente y vio el claro beneficio que obtendrían obtener de él haciéndolo.

Los desarrolladores y probadores tienden a tener diferentes mentalidades, ambas creativas. El desarrollo de software es un proceso que implica un pensamiento lógico y creativo; les encanta construir cosas, modificarlas y mejorarlas. Un buen probador es creativo de una manera diferente. Pensarán “Sí, eso es muy brillante … Me pregunto de cuántas maneras diferentes puede salir mal. ¡Ahora probémoslos todos! ”🙂

la prueba de software es diferente del desarrollo de software, no es más fácil. Las pruebas de software son realizadas por ingenieros de prueba de software (STE) e ingenieros de desarrollo de software en prueba. Estas divisiones funcionales se han ido en su mayoría ahora, pero aún se aplican en otros lugares.

Para obtener más información, haga clic en el siguiente enlace:

entrenamiento de prueba de software en chennai

En general, sí, las pruebas de software son más fáciles que el desarrollo de software. Para desarrollar un software hay muchos procesos involucrados, como la recopilación de requisitos, análisis, diseño, implementación y desarrollo de software. Las pruebas de software generalmente se toman desde la perspectiva del usuario final. Sin embargo, puede haber excepciones a esto en el caso de algunas plataformas donde debe haber pruebas rigurosas y puede necesitar más esfuerzo que el desarrollo de la aplicación.

Técnicamente, puede sentir que las pruebas son fáciles. Pero requiere un pensamiento lógico para enmarcar escenarios de prueba más allá de la caja. Necesitamos idear escenarios en los que el código fallará. Necesitamos pensar más en los escenarios negativos que allanarán el camino para nuevas mejoras. Actuamos como un hacker para romper lo que ya está fuertemente construido. Es bastante interesante que dev 🙂

¿Se puede hacer fácilmente algo que a otros les parece imposible?

¿Difícilmente puedes hacer algo donde otros parecen poder hacerlo sin intentarlo?


Es si sus habilidades, experiencias, actitud se corresponden con el trabajo que realiza.

Buscando

cursos de capacitación en línea. Se brindará capacitación para el software de control de calidad. Este módulo se actualiza a medida que agregamos nuevas funciones al curso de Linux Academy View.

Hitekschool es el mejor lugar para el curso de prueba de software en línea, ya que ofrece herramientas de prueba de software, cursos, certificación y tutoría en línea.