¿Qué hago si mi pasantía en informática es solo una prueba manual de IU?

La mayoría de la gente en la industria realmente no sabe lo que está probando. Como resultado, las pruebas que se practican comúnmente es casi lo mismo que presionar teclas al azar en el teclado.

Para la mayoría de las personas, ‘prueba’ significa ‘no funciona como se esperaba’. En realidad, probar es pensar en cualquier cosa que pueda salir mal con el producto (vamos a eso por ahora). Eche un vistazo a este ejemplo de problemas en un carrito de compras de comercio electrónico:

1. fallas en el carrito de compras (cualitativo): XMind Share
2. fallas en el carrito de compras (componente): XMind Share

La mayoría de las personas no podrán encontrar más del 5% de esos defectos.

Eche un vistazo a esto para obtener ideas sobre cómo encontrar defectos: XMind Share

Dado que está en una pasantía, esta es una excelente manera de comprender el desafío de las pruebas de software. Conozco a muchos desarrolladores que han vivido toda su vida sin este entendimiento.

Por supuesto, no olvide continuar haciendo ‘pruebas manuales’, de lo contrario podría ser censurado. Simplemente encuentre problemas y haga preguntas de “qué pasaría si”. por ejemplo, ¿qué pasa si el usuario usa Opera (navegador)? No es compatible. ¿Qué pasa si un usuario usa una sesión de navegación privada? Mira este video sobre cómo las pruebas pueden tener un impacto:

Ahora, cuando encuentre problemas, no espere que le den las gracias. Consulte este enlace para saber cómo solucionar los defectos: BBST Bug Advocacy

También recomendaría no mostrar estas respuestas a las personas para las que trabaja.

Descargo de responsabilidad: los primeros tres enlaces son míos y apuntan a material publicado por otros. Sin interés comercial. No busco clics.

Usted hace el trabajo lo mejor que puede, obviamente.

En serio, ¿qué esperas, liderar el desarrollo del producto estrella? No tienes experiencia relevante y solo estás allí durante un par de meses, por lo que no querrán iniciarte en un camino crítico.

Sé que algunas compañías pasan tiempo inventando proyectos falsos para que los internos hagan y algunas intentan hacer que los pasantes sientan que son importantes, pero no todas las compañías pueden permitirse ese tipo de tiempo y no es necesariamente útil para el pasante. Imaginar que el trabajo está de alguna manera debajo de ti solo porque no es divertido es una excelente manera de obtener una mala reputación en la industria; todos recuerdan a los empleados con malas actitudes o que perdieron el tiempo, incluso si solo estuvieron cerca durante un par de meses, y las comunidades siempre son más pequeñas de lo que piensas.

Por lo tanto, haz tu mejor trabajo, aprende lo que puedas y demuestra que eres lo suficientemente responsable por más. Si finalmente no obtiene más, continúe al final del semestre y use su impresión de usted como referencia.

Y tome esto como una lección: en cualquier empresa, hay un trabajo aburrido. Ese trabajo siempre se asigna a la persona en la que el equipo menos quiere confiar con cualquier otra cosa. Puede sonar duro o injusto, pero las pasantías son para construir su experiencia y reputación, no para alimentar su ego.

La prueba de software es uno de los aspectos más subestimados de la ingeniería de software. La gente no se da cuenta de lo esclarecedor que es todo el proceso. Si eres un buen probador de software y luego cambias al desarrollo, lo más probable es que seas mejor que un desarrollador de software promedio.

Aquí hay algunas cosas que debes hacer mientras estás internado:

1. Cree una lista de artefactos de prueba de software que se están utilizando. Descubra por qué son importantes y su implementación.
2. Cree una lista de verificación de verificaciones de IU obligatorias para cualquier software. Haga que sus clientes potenciales lo revisen y publíquelo en toda la organización.
3. Descubra qué herramientas automatizadas pueden ayudarlo a automatizar el proceso de pruebas de IU. Investigación sobre herramientas, marcos y bibliotecas gratuitas y de pago.
4. Calcule el tiempo y no. de recursos que se utilizaron para realizar 1 sprint / fase / lanzamiento de pruebas de IU. Encuentre una manera de reducir esto documentando flujos de trabajo, creando macros o scripts automatizados para ayudarlo a usted mismo, a los miembros de su equipo y / o futuros nuevos miembros.

Todo lo mejor.

Te están entrenando como garantía de calidad. Este es un trabajo legítimo. Puede que no sea glorioso, pero es un pie en la puerta. Si no estás contento, vete y trata de encontrar otra pasantía.

En mi experiencia, la escuela es muy diferente de lo que es el mundo real. Mi educación me enseñó a esperar escribir línea tras línea de código y resolver problemas con nada más que código. No podría haber estado más equivocado. Mi pasantía me enseñó nuevas herramientas y métodos. Aprendí perfiles de software, contenedores (específicamente lxc), depuración, compiladores, herramientas de redes y redes, y mucho más. Hice muy poca programación y la programación que hice fue hacer scripts para hacerme la vida más fácil ya que estaba trabajando con múltiples versiones del mismo software y portándolo a un sistema embebido. Aprendí rápidamente que podía automatizarlo, y lo hice. De hecho, recibí un correo electrónico de mi mentor unos meses después agradeciéndome por hacer esa tarea automatizada.

Así que no se desanime si su pasantía no es lo que esperaba. Estás aprendiendo habilidades de calidad que pueden no ser las más gloriosas, pero son experiencia

1. Obtenga información sobre las pruebas de GUI automatizadas
2. Desarrollar suites de prueba
3. Escribir documentación

Estás comenzando con las pruebas manuales porque nadie ha descubierto cómo automatizarlo. Su esfuerzo por automatizar el trabajo duro será apreciado.

Puedes hacer cosas increíbles con Sikuli, Selenium y PhantomJS sin tocar el código de la aplicación. 🙂

Hazlo. Y aprende más de tu experiencia. Podría desencadenar un tema para su tesis. O una gran carrera sobre pruebas de investigación. O una carrera en pruebas de IU. O sobre metodologías de desarrollo.
O simplemente deséchelo y aproveche la oportunidad de buscar uno diferente, si es posible.

Existe la idea errónea general de que CS, o Ingeniería de Software, es solo una cuestión de escribir código. Por favor, evítalo. El mundo del software, las metodologías de desarrollo de software (Agile incluido) son mucho más que escribir en la gramática adecuada de un idioma (o pila) determinado.