¿Cómo es ser un SDET en Microsoft, particularmente para alguien con un título en ingeniería informática?

Repitiendo mi respuesta a
Microsoft: ¿Cuáles son los roles y responsabilidades de una SDET?

Si le gusta la programación, los algoritmos y el desarrollo, es posible que no le guste la posición SDET. A pesar de las mentiras que los reclutadores y los gerentes de contratación le dirán, a menudo implica muchas pruebas manuales (tal vez, de un cuarto a un tercio de su carga de trabajo, y créanme, eso puede ser insoportable). Cualquier cookie inteligente de una buena universidad o programa EECS encontrará este tipo de cosas mucho más intolerable y aburrido para alguien con un cociente de inteligencia de tres dígitos para manejar.

Únase al hecho de que está obteniendo algo de experiencia de Microsoft, que se ve bien en su currículum y verifique qué tan bueno o malo es el trabajo. Si te gusta, espera. Si no, simplemente puede levantarse e irse si no le dan un rol o equipo de su elección. Si está sentado en India, hay un montón de compañías en Hyderabad, Mumbai, Bangalore y Delhi que le brindarán un mejor trabajo y pago que Microsoft IDC.

Y si estás en Redmond, bueno, entonces estás sentado en la tierra de las oportunidades, todo lo que tienes que hacer es enviar tu currículum a las empresas y reclutadores en el Valle.

Si ya tiene una oferta que le parece más interesante que la función SDET de Microsoft, continúe y asúmela. La verdad es que un SDET es un probador glorificado al final del día, independientemente de lo que quieran creer quienes hacen el trabajo. Y, francamente, incluso si se trata de una SDE que construye una IU aleatoria, o que se barajan los botones (lo que mantiene ocupada a gran parte de Microsoft), no vale la pena hacer el trabajo a menos que no tenga otras ofertas interesantes.

Si se encuentra en India y tiene una oferta SDET para Redmond, acéptela por todos los medios (* a menos que tenga una mejor oferta de alguna otra empresa con sede en los EE. UU. Como Google o Facebook o alguna startup en el Valle). Vaya a Redmond, tómese su tiempo, explore el lugar, tómese unos meses para decidir si el trabajo hace clic con usted o no; si no es así, puede comenzar a postularse en mejores lugares. No escuche a sus gerentes o líderes que tratarán de convencerlo de que se quede durante 18 meses o tal vez un ciclo completo de envío. En sus primeros años fuera de la universidad, se le debe dar más importancia a su carrera profesional que a preocuparse por los puentes que quema.

Acabo de cambiar de SDET a SDE en Microsoft después de 5 años en el puesto de prueba. Aprendí mucho en el rol de SDET, pero creo que hubiera disfrutado y aprendido más en el rol de SDE, sea cual sea la organización en la que estuve. Lo que aprendes con SDET es diseñar casos de prueba, buscar errores, automatizar pruebas con código malo. depende principalmente de la barra que tienes. En muchos equipos, a nadie le importan sus habilidades de codificación, lo único que importa es producir resultados y “comunicarlos en exceso”. También aprenderá algunas cosas interesantes como las pruebas de seguridad, el rendimiento, la venta, la preparación mundial, la telemetría, la accesibilidad, etc. Asumirá roles de conductor e interactuará con los equipos asociados para mejorar la calidad del producto. Puedes decidir escribir herramientas (lo que he hecho muchas veces), pero esas no son recompensadas como deberían. En el mejor de los casos, puede tener como 1000 usuarios si realmente tiene éxito. Terminarás aprendiendo por tu cuenta. Sin embargo, si te unes a un equipo de desarrollo, terminarás diseñando características que deberían escalar y ser utilizadas por al menos miles de clientes. También aprenderá muchas habilidades de los desarrolladores senior. Hay algunas clavijas en Microsoft que están convirtiendo SDET en SDE. Algunos otros equipos están reconsiderando la función SDET de la siguiente manera: los desarrolladores tendrán que probar las áreas en busca de funcionalidad y automatizarla. Los evaluadores harán pruebas de integración y escenarios, luego las automatizarán. Los probadores también serán dueños de monitorear el servicio con sondas, etc.

Si está buscando un equilibrio entre el trabajo y la vida, sin duda recomendaría la prueba de posición. El estrés es en su mayoría más bajo que el desarrollo y no puede hacer nada mientras se comunique en exceso (poca exageración aquí;)).

En resumen, si considera que le apasiona el diseño y la codificación, si espera codificar todos los días, ni siquiera considere la función SDET.

Me uní a Microsoft no hace mucho, supongo que solo puedo decir por lo que vi hasta ahora, un solo equipo en Bing.

Como se dijo, hay dos tipos de SDET, las que realizan pruebas de características y las que desarrollan herramientas de monitoreo y soporte de desarrollo.

Y aquellos que cuentan con pruebas en estos días, al menos en mi equipo, se están moviendo cada vez más a pruebas automatizadas en lugar de manuales.

Soy un SDET que desarrolla herramientas de desarrollo y monitoreo. Las herramientas que construimos se convierten en una parte esencial del sistema de producción (OSD) y nos despertamos a las 3 am para la investigación de problemas en el sitio en vivo, al igual que los desarrolladores de back-end.

A la gente le importa la calidad del código, especialmente las herramientas de monitoreo. Si su herramienta falla y el monitoreo se queda en blanco, o si su herramienta toma demasiados ciclos y el sistema se ralentiza, o si su herramienta no produce el tipo de información de diagnóstico necesaria para el diagnóstico, todo el sistema se verá afectado y usted se verá afectado. en el gancho

Por otro lado, las herramientas de monitoreo tienen estándares relajados para los requisitos de escalabilidad y latencia. En el código de producción, 10 ms de regresión de latencia es un gran problema. En el código de monitoreo, puedes jugar con minutos. Por lo tanto, tenemos más libertad para recopilar más información de múltiples fuentes y cosas en un análisis más sofisticado en la ruta crítica.

Como alguien dijo, depende del equipo. En general, diría que hay dos tipos de SDETS:

– Un tipo construye herramientas para apoyar al equipo de prueba / desarrollo.
– Otro tipo presenta pruebas.

si construye herramientas, el 100% de su tiempo va a la codificación, es bastante malo, pero, de nuevo, su código no se envía.

Si realiza pruebas de características, su trabajo incluirá pruebas manuales, así como cobertura de automatización, eso es cierto para la mayoría de los equipos de Microsoft. Lo que siempre me gustó es que hagas lo que tengas que hacer para encontrar errores, esto a veces implica codificar cosas locas que te ayudan a romper el código. Por otro lado, hay sdets que tienen un enfoque más profundo en las pruebas manuales, gestionan iniciativas de pruebas, programas de comida para perros, etc.

Ambos deben tener una sólida formación en ingeniería, al menos en Redmond.

Realmente depende del equipo y la organización a la que te unas. Microsoft es una gran empresa y cada equipo tiene expectativas muy diferentes de lo que hacen los SDET. Para algunos equipos, su control de calidad es principalmente manual, como pruebas, mientras que para otros es más resolver el problema de la automatización y la infraestructura para soportar productos. Por lo general, hay una combinación de ambos y le sugiero que averigüe cuánto del equipo.

Algunas de las cosas que observé mientras trabajaba allí:

• Además de ser bueno en control de calidad, debe tener habilidades excepcionales de codificación. Se convierte en parte de tu trabajo.
• Usted tiene algo que decir en el análisis de requisitos y en las discusiones de diseño.
• Se recomienda realizar pruebas de recuadro blanco y debe saber qué están haciendo las diferentes partes del código.
• Además de las pruebas de integración y rendimiento, también mantiene el marco de automatización y crea pruebas de verificación.