Menú

5 cosas que un desarrollador (y evaluador) principiante debe saber sobre las pruebas de software

5 things beginner developer

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

cómo desarrollar una aplicación java en eclipse

Toda la sala de conferencias quedó en silencio y después de esperar un par de minutos, no pude mantener la paciencia y tuve que repetir mi pregunta:

¿A quién le gustaría unirse al equipo de pruebas?

Teníamos 20 aprendices a bordo y estaban siendo capacitados en diferentes aspectos de proyectos de software. Los líderes y gerentes de diferentes departamentos, como análisis de negocios, desarrollo, pruebas y ventas, mantuvieron reuniones con esos aprendices para proporcionar el conocimiento y ayudarlos a comprender cómo y cómo es el proyecto de software real. Como líder de pruebas, les expliqué los aspectos básicos de las pruebas y la importancia del ciclo de vida de las pruebas a esas nuevas caras.

desarrollador y tester

Con entusiasmo, cuando dejé la pregunta, nunca pensé en el silencio de un alfiler. Nadie estaba listo para unirse a las pruebas. Suspiré con tristeza y retomé otra pista para educar a esta futura generación de TI.

Modifiqué mi pregunta para saber las razones detrás del rechazo. testing de software como profesión –

¿Por qué no quiere unirse a las pruebas de software?

Las respuestas fueron interesantes (y prácticas en algún momento)

  • Cualquiera puede hacer pruebas pero no desarrollo ( bueno saber )
  • A los probadores se les paga menos ( un poco cierto pero no siempre )
  • Es un trabajo ingrato ( totalmente de acuerdo, pero esa no es la razón válida )
  • No hay nada que aprender al respecto ( Hooh ... ¿quién dijo eso?)
  • No hay razón para elegir las pruebas de software como carrera ( la peor razón )

Lo que vas a aprender:

¿Por qué existen las pruebas de software?

Bien, era hora de capacitar a esas personas nuevas sobre por qué existen las pruebas de software y qué deberían saber al respecto si se van a unir al desarrollo de software.

¿Cómo cambié de opinión?

Aquí solo estoy tratando de resumir lo que hemos discutido durante esa tarde y cómo logré cambiar la opinión de al menos 20 personas, mientras aclaraba la percepción sobre las pruebas de software.

# 1. La prueba de software no es una pérdida de tiempo:

¿Qué sucede cuando tienes invitados en casa y apresuradamente les preparas limonada y les sirves? Cuando los invitados dejan los vasos sin terminar, sientes que algo debe haber salido mal y cuando pruebes la limonada, Dios mío …… se sintió mal. Desearía haber gastado solo 10 segundos más y probar la limonada antes de servir.

Mientras tienen prisa por entregar el proyecto en un cronograma, las empresas / la gerencia / cualquier persona se preparan para comprometer el tiempo de las pruebas porque la percepción sobre las pruebas de software realmente lleva mucho tiempo del requerido todavía está viva en la mente de las personas. Pero, ¿no vale la pena el tiempo necesario para realizar las pruebas en comparación con la llamada del cliente a la medianoche para informarle que cancelará la siguiente tarea, ya que la tarea actual entregada mostró más de 5 errores críticos en las primeras dos horas de uso interno? ¡¡Estallido!!

# 2. Las pruebas de software son obligatorias:

Las pruebas de software son una parte inevitable del ciclo de vida del desarrollo de software. La manera

  • Los editores ayudan a mejorar la película
  • Los correctores ayudan a mejorar un libro
  • Los guardias de seguridad ayudan a que la vida de las personas sea pacífica y segura
  • El aceite ayuda a hacer funcionar la maquinaria sin fallas

Las pruebas de software ayudan a que el software sea mejor. No creo que necesite gastar ni una palabra más para explicarlo.

#3. Examen de la unidad es responsabilidad total del desarrollador:

Cuando desarrolle algo, debe verificarlo antes de pedirle a otra persona que lo verifique. La manera

  • El chef siempre prueba y huele su receta antes de servir a los demás.

El desarrollador es completamente responsable de probar su propio código antes de enviarlo a los probadores. Los probadores están allí para ayudarlo a mejorar la calidad del código y, en última instancia, el producto, y no para descubrir los errores más tontos que cometió al escribir el código.

Además de eso, nunca asuma que la calidad es responsabilidad exclusiva de los probadores.

En el mundo ágil de hoy, se supone que los desarrolladores y probadores asumen la responsabilidad combinada de la calidad del producto. Se espera que los desarrolladores realicen pruebas en pareja con el evaluador y proporcionen información sobre qué y por qué algo puede salir mal y animen al evaluador a generar ideas de prueba basadas en sus conocimientos.

# 4. Los desarrolladores y probadores son iguales:

Cualquier trabajo / proyecto es un esfuerzo combinado de equipo y eso significa que todas y cada una de las personas son igualmente importantes. Si un desarrollador piensa que lo está haciendo mejor y se le debe dar más importancia porque está creando algo desde cero, es necesario volver a considerar el pensamiento. Sí, el desarrollador desarrolla algo desde cero, pero no puede completar la creación sin la ayuda del probador.

Tester proporciona el ojo del usuario para el producto. Un evaluador bien capacitado y experimentado puede mostrar las lagunas del producto, un desarrollador nunca puede pensar en ello. Un evaluador aporta nuevas ideas sobre cómo debería ser el producto, cómo debería verse en una instancia particular, cómo debería funcionar, cómo puede comportarse y cómo puede fallar.

La forma en que es importante agregar sal a cada receta para hacerlas comestibles, es necesario realizar pruebas para que el producto se pueda entregar.

Y, por lo tanto, los desarrolladores y probadores son igualmente importantes. Son las manos izquierda y derecha del cuerpo llamadas proyecto.

# 5. El probador debe participar desde el primer día del proyecto:

Como desarrollador, nunca debe cometer ese error al asumir que no es necesario que un evaluador se dé cuenta de algo como el análisis de requisitos, la lógica aplicada al escribir el código, las solicitudes de cambio del cliente, los comentarios del cliente, etc.

Tester es un titular de la pila y debe participar desde el inicio del proyecto. La participación inicial del equipo de prueba les da confianza, las discusiones constantes nutren un entendimiento entre el equipo de desarrollo y el de pruebas , la ayuda amable estimula su espíritu para hacer algo mejor, las demandas de sugerencias los hacen sentir valiosos.

Conclusión:

El probador no solo debe probar un módulo / producto, está allí para ayudar a entregar el mejor producto, está allí para ayudar al sugerir algunas ideas probadas sobre las expectativas de los usuarios, está allí para hacerle saber con qué frecuencia se obtiene su amado código se estrelló ... y usted, como desarrollador, realmente lo necesita, ¿no es así?

Sobre el Autor: Esta increíble publicación está escrita por Bhumika Mehta, miembro del equipo de STH. Es líder de proyecto y cuenta con más de 7 años de experiencia en pruebas de software. Ella está totalmente interesada en las pruebas y le encanta probar que todo existe.

Como siempre, esperando tucomentarios, opiniones y sugerenciassobre el tema.

Lectura recomendada

^