¿Qué es un desarrollador en prueba? [cerrado]

Recientemente estuve hablando con un reclutador que quiere ponerme en una empresa para un puesto de Desarrollador en Prueba. Básicamente, lo hizo sonar como una posición en la que puedes jugar con nuevas técnicas de programación y probar errores y mejoras en el software, pero donde no tienes que preocuparte por los plazos estándar. Llegas a ser muy creativo en tu trabajo.

Pero esa descripción todavía era un poco vaga para mí. He sido desarrollador web durante varios años, principalmente trabajando en PHP. Así que quería saber si otros miembros de la comunidad saben más sobre lo que generalmente implican estos puestos.

Sé que este podría no ser un tema apropiado para este foro, pero fue la mejor opción que pude encontrar entre Stack Exchange y realmente agradecería si esto no estuviera cerrado ya que realmente no hay otro lugar aquí para preguntar al respecto .

He intentado buscarlo en Google, pero no hay mucha información disponible. Entonces, ¿qué es exactamente un desarrollador en prueba?

Soy Ingeniero de Desarrollo de Software en Test, y he estado en 2 compañías separadas. Actualmente trabajo para Microsoft.

En términos generales, Bryan Oakley tiene razón: usted escribe software que prueba el software.

Más allá de eso, depende de su nivel de experiencia, el alcance de sus responsabilidades y el tipo de software que produciría el empleador. Una posición SDET puede incluir escribir cualquier cosa, desde los conceptos básicos de las pruebas de verificación de nivel de característica, hasta escribir y mantener la infraestructura de prueba para ejecutar esas pruebas. Tampoco es raro tener SDETS que se especializan en pruebas enfocadas para ciertos tipos de requisitos (seguridad de prueba, rendimiento / escala, usabilidad, etc., son ejemplos que inmediatamente se me ocurren).

La descripción que recibió del reclutador suena como una mala técnica de venta.

• No estás jugando; tiene n días para obtener cobertura de prueba automatizada sobre x funciones implementadas en y diferentes entornos compatibles en z idiomas.
• Ah, por cierto: esas pruebas tienen que ejecutarse lo suficientemente rápido como para que los desarrolladores tengan un ciclo rápido de desarrollo / prueba porque ...
• No hay plazos estándar? Usted está a cargo de la calidad del producto y la fecha de lanzamiento fue establecida por marketing hace 6 meses. El equipo de desarrollo lleva 6 semanas de retraso entregando una versión estable a su equipo de prueba, y la compañía no está presionando esa fecha de lanzamiento (nuevamente). ¿Es el producto o servicio lo suficientemente estable como para lanzarlo a un par de millones (miles de millones) de personas, el mismo día?
• ... y si ( cuando ) los clientes llaman con problemas ... "¿Por qué (demonios) no lo entendiste primero?"

Espero que eso les dé un pequeño ejemplo de cómo es ser una SDET.

"Desarrollador en prueba" generalmente significa que usted está en el departamento de control de calidad o en un rol de control de calidad, pero el enfoque está en escribir pruebas automatizadas en lugar de crear y ejecutar casos de prueba manuales. Cosa de ello como software de escritura para probar el software. Puede ser una elección de carrera particularmente desafiante porque requiere habilidad de programación y una buena comprensión de las pruebas de software.

Sin embargo, diferentes títulos significan diferentes cosas para diferentes compañías, por lo que la respuesta definitiva debe provenir del reclutador.

Un rol SDET es más o menos lo que haces, como lo demuestran todos sus diferentes nombres: QA / Developer, QA Engineer, Automation Developer. Mi título actual es en realidad Ingeniero de pruebas, que nunca había escuchado antes de tomar este trabajo. Independientemente del título específico, es una nueva posición en la mayoría de las empresas, por lo que las expectativas pueden ser flojas. "Ayúdanos a automatizar nuestras pruebas y esas cosas ...". El material podría incluir herramientas de CI, pruebas de API, servicios en la nube, integración con sistemas internos, etc.

Otro aspecto del trabajo que no veo en este hilo es la mejora del proceso. Los SDET típicamente han estado haciendo QA por un tiempo, y nuevamente, típicamente, son más técnicos que el resto del equipo de QA, incluido su gerente. Saben mucho sobre el sistema bajo prueba, es decir, "dónde están enterrados los cuerpos". Por estas razones, los SDET tienden a ser escuchados por la administración y pueden tener mucha influencia en el proceso, no solo en el proceso de prueba, sino también en cómo se construye el producto. Lo que puede ser genial, si te gusta eso.