Machine Translated by Google

Cómo las grandes tecnologías garantizan la calidad (QA)

La mayoría de las grandes empresas tecnológicas no tienen funciones dedicadas de SDET, control de calidad o tester. ¿Cómo producen

software de calidad? Una mirada a cómo lo hacen Microsoft, Google, Meta, Apple, Amazon, Uber y Netflix.

GERGELY OROSZ

19­09­2023 ∙ PAGADO

123 9 11 Compartir

Hola, soy Gergely con un problema exclusivo para suscriptores. del Boletín de Ingenieros Pragmáticos.

En cada número, cubro los desafíos de las grandes empresas tecnológicas y las nuevas empresas a través de la lente de

gerentes de ingeniería e ingenieros senior. Para recibir artículos como este en su bandeja de entrada semanalmente, suscríbase:

Nota de programación: viajaré durante 3 semanas en noviembre, dirigiéndome a los EE. UU. – SF y
Nueva York –, con menos tiempo del habitual para escribir. Estoy buscando escritores invitados para ayudar durante este

tiempo. Si es ingeniero o gerente de ingeniería y tiene experiencia práctica para compartir, indique su interés aquí.

En este número, analizamos cómo las principales empresas producen software de calidad, abarcando:

1.Microsoft _

2.Google _

3.Meta _

4. manzana

5. Amazonas

6. Úber

7.Netflix _
Su cuenta ya está configurada
Reuní detalles
puede dejarsobre el enfoque
a los gerentes dede control
cada unadedecalidad de ingenieros e ingenieros actuales o anteriores. Ahora tiene un perfil y
estas empresas
para confirmar los hallazgos; gracias a todos los que ayudaron. comentarios sobre todas sus suscripciones.

Tenemos mucho por lo que pasar, así que vayamos a ello:

1.Microsoft ver perfil

Machine Translated by Google

El gigante tecnológico con sede en Redmond, Washington, ha desempeñado un papel enorme en el desarrollo y la
importancia del control de calidad en toda la industria. Microsoft fue la primera empresa importante en crear una
función de prueba especializada que iba mucho más allá de las pruebas manuales.

El papel de la SDET

El rol de SDET (Ingeniero de desarrollo de software en pruebas) fue uno en el que Microsoft fue pionero en toda
la industria tecnológica. Son ingenieros de software que se centraron en escribir pruebas automatizadas; Construir y
mantener sistemas de prueba. La única diferencia entre un SDET y un ingeniero de desarrollo de software (SDE) es
que los SDET generalmente no escribían código de producción: escribían código de prueba y trabajaban en el
mismo equipo que los SDE.

No pude rastrear la introducción exacta del papel, pero lo más probable es que haya sido en la década de
1990. Por ejemplo, aquí hay una publicación de 2004. de un miembro del equipo de Microsoft Exchange que explica
lo que significa ser un SDET en su organización:

“Un SDET es un desarrollador que trabaja en un equipo de prueba y no en un equipo de desarrollo. El SDET tiene
un agudo sentido de probador, pero le encanta escribir código, y mucho.

El SDET proporciona al equipo de pruebas las herramientas y procesos que deben implementarse para que los
evaluadores hagan lo que mejor saben hacer... probar el producto a plena luz del día y encontrar tantos errores
como sea posible antes de que salga al mercado.

Un SDET tiene la capacidad de analizar la funcionalidad y arquitectura de un Producto y así diseñar e

implementar herramientas que ayuden a los testers a probarlo.

El SDET disfruta de ciclos de vida de proyectos cortos, diseña e implementa muchas herramientas y marcos

de prueba en un solo año, utiliza la última tecnología y tiene mucho espacio para
innovación.

Aunque la calidad del producto es una preocupación principal, el SDET no tiene los días estresantes que tienen
los desarrolladores durante el final del ciclo de vida de un producto. En términos sencillos... una parte trasera del
SDET rara vez está en juego :)”
Su cuenta ya está configurada. Microsoft
tenía una trayectoria profesional formal para el puesto de SDET. De la misma publicación:
Ahora tienes un perfil y puedes dejar
comentarios en todas tus suscripciones.
“Hay mucho espacio para crecer [en el puesto SDET]. Si te encanta hacer lo que haces como SDET, entonces
puedes crecer hasta convertirte en Arquitecto de pruebas. Si desea involucrarse en la gestión, puede avanzar
hasta convertirse en líder de SDET y luego en director de pruebas.
Machine Translated by Google

Si solo desea codificar y no participar en las pruebas, puede tomar el camino de convertirse en desarrollador. Mucha

gente toma este camino. Si te das cuenta de que tu corazón pertenece a las pruebas, entonces puedes convertirte en un

evaluador”.

Una relación SDE:SDET de 2:1 era común en Microsoft hasta aproximadamente 2014. Fue el caso en

mi equipo en Skype para Xbox One, en 2012, cuando se formó el equipo. Así es como estaba compuesto nuestro equipo, según la

plantilla:

12x SDE (ingenieros de desarrollo de software)

6x SDET (ingeniero de desarrollo de software en prueba)

2x PM (gerentes de producto)

1x EM (gerente de ingeniería)

1x cable SDET

En nuestro proyecto, el equipo SDET fue responsable de todas las partes de las pruebas:

Verificar manualmente que las funciones creadas por los desarrolladores funcionaran como se esperaba, incluidos los casos extremos que

puede que no haya considerado

Creación de integración y pruebas de un extremo a otro para automatizar las comprobaciones

Crear planes de pruebas manuales y ejecutarlos antes de los hitos importantes.

Estar involucrado durante la fase de planificación de funciones, aportando ideas sobre casos extremos y
cómo se validaría el trabajo

Desarrollar soluciones para problemas complicados, como cómo realizar evaluaciones comparativas de

rendimiento confiables para nuestro producto Skype en el hardware de Xbox.

Las pruebas unitarias fueron una fuente de tensión desde el principio. ¿Quién debería escribirlos? Varios desarrolladores

experimentados procedían de los juegos, donde los desarrolladores normalmente no escriben pruebas automatizadas, y su opinión

era que cualquier automatización, incluidas las pruebas unitarias, debería ser realizada por los equipos de SDET. Nosotros

cubrirá más sobre cómo se crean los juegos en Conceptos básicos del desarrollo de juegos, y ser muy práctico en el

problema, Construyendo un juego simple.

Su cuenta ya está configurada
Aquellos de nosotros
sentimos que
que ahora anteriormente
tiene habíamos
un perfil y puede creado
dejarlo aplicaciones o hicimos desarrollo impulsado por pruebas (TDD)
. Este
enfoque era incorrecto
comentan en todas.yde
que
tuslos desarrolladores
suscripciones. las deberían escribir sus propias pruebas unitarias porque las unidades
pruebas y el código están estrechamente acoplados. Yo estuve en este campamento.

Tener SDET dedicados convirtió en una opción tentadora para los desarrolladores "subcontratar" la redacción de pruebas

unitarias. Sólo voy a decirlo ahora: sin un equipo SDET, la pregunta de quién
Machine Translated by Google

escribe pruebas unitarias no habría sido objeto de debate: nosotros, los desarrolladores, habríamos tenido que escribirlas.

Este es un debate recurrente que he visto en todos los equipos con SDET asignados. Sorprendentemente, incluso este año oí hablar

de una empresa con sede en Silicon Valley donde un equipo de desarrolladores tiene el equipo de pruebas.

¡escribe pruebas unitarias!

En nuestro caso, nos decidimos por que los desarrolladores escribieran pruebas unitarias y el equipo SDET hiciera todo lo

demás. Este enfoque funcionó bastante bien, pero hubo algunas características memorables de esta configuración:

Una dinámica de “nosotros y ellos” que creó división. Cuando nosotros, los desarrolladores, terminamos una función,

se la entregamos a un SDET, que generalmente encontraba problemas, por lo que la función regresaba a los desarrolladores

para solucionarla. Esto resultó molesto para los desarrolladores, ya que creaba trabajo que quizás no hubiéramos

tenido en cuenta. Con el tiempo, empezó a parecer que había dos equipos, con objetivos diferentes, que no siempre

remaban en la misma dirección.

Ticket de ping­pong entre desarrollador y prueba. Termino de trabajar en mi función y la envío para probarla (ping). El

evaluador encuentra un error y me lo envía al día siguiente (pong). Soluciono el error y lo envío nuevamente en unos días

(ping). El evaluador encuentra otro error y lo devuelve.

para mí... ¡y este ida y vuelta sucedió más veces de las que estaría dispuesto a admitir!

Los desarrolladores eran buenos construyendo sistemas complejos y podían ayudar mucho a SDET. Nuestro equipo SDET

había estado construyendo un sistema de pruebas de integración durante meses y el progreso era lento.

Nuestro equipo realmente necesitaba este sistema, ya que las pruebas manuales llevaban demasiado tiempo. Finalmente,

uno de los ingenieros senior propuso que los desarrolladores se unieran para ayudar a construir este sistema, como un solo

equipo. Dos semanas después, con la dirección de desarrolladores experimentados, un sistema estaba en funcionamiento.

Esto me hizo pensar; ¿No funcionaría mejor el equipo sin la división de desarrollo/pruebas? Acabábamos de demostrar que
así era.

El elefante en la habitación: algunos desarrolladores menospreciaron el papel de SDET. Aunque no todos lo hicieron,

estaba claro que muchos desarrolladores consideraban que el trabajo de SDET era menos desafiante que el suyo. Los

SDET también sabían que podrían tener mejores opciones profesionales si pasaban a un puesto de desarrollo.

Bueno, resulta que no tuvieron que esperar tanto para avanzar.

Su cuenta ya está configurada

Retirar el rol de SDET
Ahora tienes un perfil y puedes salir. A principios de 2014,
me uní a un nuevo equipo llamado Skype para Web. Este equipo era diferente de la mayoría de los comentarios de equipos en
todas sus suscripciones. en Skype, ya que
enviaban una nueva versión del software todos los días, no todos los meses.

El equipo estaba formado por 6 SDE y 3 SDET, en papel. En realidad, éramos 9 SDE, gracias al gerente de ingeniería y al líder de

pruebas que silenciosamente decidieron que no tenía sentido tener una función de prueba dedicada, cuando enviamos

nuevas funciones todos los días. Escribo sobre este cambio que el
Machine Translated by Google

El liderazgo del equipo no transmitió en el número Cómo las grandes tecnologías ejecutan proyectos tecnológicos y la curiosa
ausencia de Scrum:

“Cuando me uní al equipo de Skype para Web, inicialmente hicimos sprints de dos semanas y seguimos los procesos

habituales de Scrum. También teníamos una división de ingenieros de software e ingenieros de control de calidad.

Sin embargo, nuestro ritmo de envío era cada dos semanas, pero queríamos realizar envíos con más frecuencia.

Lo primero que hicimos fue convertir el control de calidad en parte de la ingeniería. En el “viejo mundo”, un ingeniero

terminaría su trabajo, se registraría en su sucursal, actualizaría un ticket y le informaría al control de calidad que está listo

para su revisión. El control de calidad tomaría este ticket uno o dos días después, lo revisaría y lo volvería a abrir si

encontraba problemas. Fue un largo retraso.

Hicimos un cambio silencioso y no oficial en el que todos los SDET también crearon software de producción y todos los

ingenieros de software se hicieron responsables de probar su propio código. Ahora, ya no teníamos que esperar días para

recibir comentarios antes de enviar el código a producción. Sin embargo, los sprints quincenales y los numerosos rituales

Scrum se convirtieron en el siguiente problema”.

¡Nos volvimos mucho más productivos al eliminar el rol de SDET de nuestro equipo! Los SDET todavía se centraban

principalmente en trabajos relacionados con las pruebas, pero también asumieron tareas de desarrollo. ¡Igual de

importante es que nos emparejamos mucho! Recuerdo haberlo emparejado con SDET para crear una función. yo era bueno en

pensando en cómo hacer que algo funcione, y el SDET fue realmente bueno señalando las ventajas

casos que no había considerado. En lo que respecta a la depuración, el ingenio de los SDET sorprendió
a mí.

En la mayoría de los equipos de Microsoft, los SDET dedicaron mucho tiempo a probar cosas manualmente y escribir pruebas

de integración. Pero en nuestro equipo había muy pocas pruebas manuales y todos construimos una infraestructura de prueba

de integración e infraestructura de monitoreo. Cuando un desarrollador o un SDET tomaban un trabajo, escribían todas las

pruebas (unitarias y de integración) que tenían sentido.

La mejor parte de este cambio fue que ya no existía el “nosotros contra ellos”. Cesaron las discusiones sobre si debíamos

corregir un error que había descubierto un SDET, ya que ahora hicimos nuestras propias pruebas y solucionamos los errores

que descubrimos, antes de enviarlo a producción.

Su cuenta ya está configurada

Los equipos web de Microsoft comenzaron a eliminar silenciosamente la función SDET. En 2014, nuestro equipo Ahora
tienes un perfil y puedes salir de la web en la oficina de
Skype de Londres se sintió "especial", ya que fueron los únicos otros equipos que fusionaron los comentarios SDET en todas
tus suscripciones. función eran equipos basados
en la web, de los cuales no había muchos. En todos los demás equipos, los SDET

Siguieron trabajando como siempre lo habían hecho.

Sin embargo, no fueron sólo los equipos web dentro de la división de Skype los que fusionaron estos roles para mejorar la

eficiencia. Los equipos web llegaron de forma independiente a la conclusión de que fusionar SDET y funciones de desarrollo
Machine Translated by Google

los hizo moverse más rápido, ¡y esto sucedió en todo Microsoft!

A mediados de 2014, Microsoft retiró formalmente la función SDET e introdujo la función SE.

Al parecer, la inspiración fue un equipo web más grande de Microsoft, Bing. Desde Ars Technica, en 2014:

“En Bing, la tarea de crear pruebas programáticas se trasladó a los desarrolladores, en lugar de a los evaluadores

dedicados. El control de calidad todavía existe y sigue siendo importante, pero realiza pruebas del "mundo real" al estilo

del usuario final, no pruebas automatizadas programáticas. Esta prueba ha sido exitosa para Bing, mejorando la

capacidad del equipo para enviar cambios sin dañar la calidad general del software”.

En julio de 2014, Microsoft anunció que ejecutaría sus mayores despidos hasta esa fecha, despidiendo a 18.000 de los 127.000

empleados de la empresa. 12.500 de los recortes fueron para la división Nokia. Como parte de este despido, también se eliminaron

una gran cantidad de puestos del SDET. Esto sucedió casi al mismo tiempo que se anunció que se retiraría la función

de SDET y los SDET existentes debían pasar a la carrera de ingeniero de desarrollo de software (SDE) durante los próximos

meses. La función SDE también pasó a llamarse SE – Ingeniero de software.

¿Cómo resultó esta transición? Por lo que tengo entendido, todo salió bien. El cambio tuvo mucho sentido para los equipos que

realizan envíos a diario. Y los equipos dentro de Microsoft que realizan envíos semanales o mensuales son cada vez

más raros, ya que Microsoft también se inclina hacia el modelo de software como servicio (SaaS). Por supuesto, Microsoft

sigue siendo proveedor de la familia de sistemas operativos Windows y de la tableta Surface. Ambas son áreas donde el enfoque

de la calidad debe ser diferente al de los productos SaaS.

Buena cuenta del cambio provino del equipo de Visual Studio Team Services en 2017, tres años después de este cambio.

Reflexionando sobre ello, Brian Harry — actualmente miembro técnico de Microsoft —

escribió:

“Hace dos años [en 2015], tuvimos decenas de miles de pruebas. Fueron escritos por "probadores" para probar el código

escrito por "desarrolladores". Si bien este modelo tenía algunas ventajas, como una inversión claramente medible y

controlable en pruebas, experiencia y crecimiento profesional en la disciplina de pruebas, etc., también había muchas

desventajas: falta de responsabilidad por parte de los desarrolladores, ciclos de retroalimentación lentos (introducción de

errores, encontrar error, corregir error), los desarrolladores tenían poco Su cuenta ahora está configurada con motivación
para hacer que su código sea "comprobable",
divergencia entre la arquitectura del código y la prueba Ahora tiene un perfil y puede dejar la arquitectura hecha,
refactorizar y girar muy difícil/costosa , y más. (...)
comenta todas tus suscripciones.

Las pruebas completas tomarían casi un día para ejecutarse, muchas más horas para “analizar los resultados” para

identificar fallas falsas y días o semanas para reparar todas las pruebas que fallaron debido a algún cambio legítimo en el

producto. (...) Hace dos años, iniciamos el camino para rehacer completamente las pruebas.
Machine Translated by Google

Combinamos las organizaciones de desarrollo y prueba en una organización de "ingeniería" consolidada. En su mayor

parte, eliminamos la distinción entre personas que codifican y personas que realizan pruebas. Eso no quiere decir que

cada persona haga la misma cantidad de cada cosa, pero cada persona hace algo de todo y es responsable de

la calidad de lo que produce. También nos propusimos desechar por completo nuestras decenas de miles de

pruebas que tardaron 8 años en crearse y reemplazarlas con nuevas pruebas que se realizaron de manera completamente

diferente”.

Este equipo hizo un balance del tipo de pruebas que tenían implementadas y decidió que no les gustaba que hubiera pocas

pruebas unitarias pequeñas, pero sí muchas pruebas complejas y difíciles de mantener de un extremo a otro. Entonces ellos

cambió esto:

Su cuenta ya está configurada

Ahora tienes un perfil y puedes dejar

comentarios en todas tus suscripciones.
Machine Translated by Google

Su cuenta ya está configurada

Ahora tienes un perfil y puedes dejar
comentarios en todas tus suscripciones.
El cambio en la cantidad y el tipo de pruebas que experimentó Visual Studio Team Services
después de fusionar los equipos de desarrollo y prueba. Antes de la fusión: dominaban las pruebas de
extremo a extremo, pero las pruebas unitarias y de integración eran raras. Esto cambió después de la
fusión. Fuente de datos: blogs de desarrolladores de Microsoft
Machine Translated by Google

Aquí hay otra visualización de cómo cambiaron las pruebas del equipo durante un período de dos años:

En 2 años, casi todas las pruebas "antiguas" de cuando la prueba estaba separada del desarrollo desaparecieron.
Las nuevas pruebas también se volvieron más granulares. Fuente de datos: blogs de desarrolladores de Microsoft

Entonces, ¿al final valió la pena todo este trabajo? Según Brian, sí lo fue. Escribiendo en ese momento, dijo:

"Estamos empezando a cosechar los beneficios de una mayor calidad, agilidad y satisfacción de los ingenieros".

2.Google
Google es una empresa lo suficientemente grande como para que no sea posible generalizar a todas las divisiones, como

Búsqueda y Documentos, y divisiones de hardware como Nest, etc.

Sin embargo, en la mayoría de los equipos de software, los ingenieros son responsables de la calidad, para lo cual utilizan

pruebas unitarias. Los equipos pueden crear otras pruebas automatizadas según sea necesario, como integración, de un

extremo a otro, pruebas de carga, etc.

EngProd es una división especializada dentro de Google responsable de la productividad de ingeniería. Su cuenta

Asíahora estálaconfigurada
es como en infraestructura.
empresa describe it: ahora tiene un perfil y puede
abandonar “[EngProd es] una disciplina de ingeniería
basadapueda
Google en datos enfocada
ofrecer en optimizar
experiencias los comentarios
increíbles a de ingeniería en todas sus suscripciones. proceso para que

nuestros usuarios, más rápido”.

El enfoque de esta organización es:

Machine Translated by Google

Análisis de sistemas: identificación de brechas en el proceso de ingeniería, donde las nuevas herramientas podrían

mejorar la excelencia y la velocidad de la ingeniería.

Instrumentación: es difícil mejorar algo que no se mide. Google se obsesiona con las métricas y comienza a instrumentar

herramientas y procesos para poder medir cualquier cambio en la eficiencia.

Herramientas e infraestructura: creación de infraestructura como pruebas, CI/CD y todo lo demás que pueda ayudar a los

ingenieros a avanzar más rápido y con mayor calidad.

Trabajar dentro de equipos de productos: los ingenieros de EngProd pueden integrarse en equipos de productos y

ayudarlos a trabajar de manera más rápida y eficiente.

En la red anónima Blind, un empleado de Google que trabaja en EngProd describió el enfoque de la división en

probando así:

“Un tema común en el que interviene EngProd son las pruebas, los marcos de prueba y la infraestructura de pruebas. Los

equipos de ingeniería realmente no quieren escribir nuevos marcos de prueba, no tienen el ancho de banda ni la experiencia.

Pero a medida que sus productos evolucionan, realizar cambios incrementales en la forma en que funcionan las pruebas puede

hacer más daño que bien.

Los equipos de EngProd pueden ayudar siendo dueños de la estrategia de prueba, asesorando sobre la arquitectura para

optimizar la capacidad de prueba y creando nuevas herramientas según sea necesario. Y como los equipos de producto no

necesitan dedicar demasiado tiempo a pensar en estos problemas, pueden actuar más rápido.

Hay muchos otros problemas además de probar ese tipo de trabajo de la misma manera, donde unos pocos ingenieros

pueden abordar un problema que afecta a cientos o miles de personas y realizar cambios significativos”.

La ingeniería de pruebas es una función en Google, que normalmente corresponde a los equipos de hardware. La empresa
describe este rol así:

“Los ingenieros de pruebas de Google no son evaluadores manuales: escriben scripts para automatizar las pruebas y crean

herramientas para que los desarrolladores puedan probar su propio código. Como ingeniero de pruebas, usted navega

porcuenta
Su la enorme
ahorabase
estáde código de para
configurada Google, identifica puntos débiles y diseña constantemente de manera mejor y más creativa.
romper
el software e identificar problemas potenciales. Tendrás un gran impacto en la calidad del creciente conjunto de productos
y servicios de Google”. comentarios sobre todas sus
suscripciones.

Google contrata ingenieros de pruebas para equipos como:

Productos de realidad aumentada

Machine Translated by Google

Productos Fitbit

Teléfono inteligente de píxeles

Productos inalámbricos y de redes

Google Cloud contrata ingenieros de pruebas de rendimiento de hardware e ingenieros de pruebas de sistemas: ambos

de estos con un enfoque de hardware.

Emplear probadores mediante contrato es una cuestión de Google, caso por caso. Esto es común para proyectos u organizaciones

complejos. Por ejemplo, hablé con un ingeniero senior cuya organización empleaba algunos probadores contratados en una

organización donde más de 30 equipos implementaban más de 50 funciones en producción por mes.

Los evaluadores contratados o independientes generalmente se contratan para asumir:

Pruebas de humo antes de un lanzamiento. Esto también se llama prueba de verificación o prueba de confianza.

Suele ser manual, aunque los pasos manuales se pueden automatizar.

Escriba pruebas de un extremo a otro antes de una primera versión o una versión importante.

Lo que los probadores contratados no hacen es escribir pruebas unitarias o de integración, como lo hacen los equipos de ingeniería.

estos.

Un libro que ofrece una útil descripción general de cómo Google solía realizar pruebas hace una década es Cómo Google

Libro de Tests Software de James Whittaker, Jason Arbon y Jeff Carollo, publicado en 2012.

Este libro presenta al ingeniero de software en pruebas y los roles de ingeniero de pruebas:

“Los ingenieros de software en pruebas (SET) de Google son desarrolladores de pruebas, responsables de ayudar a las SWE con la

parte de prueba unitaria de su trabajo y también a escribir marcos de pruebas más amplios para ayudar a las SWE a escribir

pruebas pequeñas y medianas para evaluar preocupaciones de calidad más amplias.

Los ingenieros de pruebas de Google (TE) son desarrolladores de usuarios, responsables de tomar las perspectivas de los

usuarios en todo lo que tiene que ver con la calidad. Desde una perspectiva de desarrollo, crean automatización para escenarios de

usuario y desde una perspectiva de producto, evalúan la cobertura general y la efectividad del conjunto de actividades de prueba

realizadas
práctica. por tienes
Ahora los otros
unroles
perfilde ingeniería.
y puedes irte No es una utopía, pero es nuestro mejor intento de lograrlo de una manera

donde las preocupaciones del mundo real tienen una manera de perturbar las mejores intenciones en los comentarios más
imprevistos en todas tus suscripciones. . e implacable”.

3.Meta
Machine Translated by Google

Meta no ha tenido una función formal de control de calidad o SDET, hasta donde yo sé. Los ingenieros de software (SWE), los

ingenieros de producción (PE), los ingenieros de soluciones (SE) y los ingenieros empresariales (EE) se encargan de todas las pruebas

del software que poseen sus equipos. Cubrimos estos roles con más detalle en el número Dentro de la cultura de ingeniería de

Facebook.

Mientras que Meta solía tienen la reputación de no ser grandes en pruebas unitarias y, en cambio, de depender de un sistema

automatizado de implementación/reversión de clase mundial, esto parece estar cambiando en organizaciones como infra. Dentro

de infra, varios equipos utilizan un enfoque de desarrollo basado en pruebas (TDD) para el desarrollo de software, escribiendo pruebas

primero y luego código de producción. Para productos más maduros, se espera que los casos de prueba cubran todos los

cambios.

Cada equipo decide su enfoque de prueba. Es importante enfatizar esto. Por ejemplo, cuando Meta creó la aplicación Threads en

cinco meses con un equipo pequeño, no se preocuparon por la automatización.

pruebas para el lanzamiento inicial. Encontrar el ajuste entre el producto y el mercado era mucho más importante.

DevInfra es una organización dentro de Meta que es muy similar a EngInfra de Google. Así es como la empresa describe el enfoque

de esta organización:

“DevInfra posee la mayor parte del ciclo de vida de la codificación en Facebook, desde el momento en que el código sale

de la mente de un ingeniero hasta que llega a las personas que usan nuestras aplicaciones. Nuestra misión es aumentar la

eficiencia de los desarrolladores para que podamos continuar enviando productos increíbles rápidamente.

Lideramos la industria mediante la creación de herramientas de desarrollo innovadoras e infraestructura de automatización que

son confiables y rápidas, garantizando que cada segundo de tiempo de ingeniería se dedique a las cosas.

ese asunto."

El equipo de DevInfra hace el trabajo pesado, tanto para la creación de herramientas de desarrollador como para la infraestructura

de prueba. Aquí hay un par de soluciones interesantes que creó este equipo:

Pruebas autónomas de servicios, hecho a escala. Esta es una extensión además de la infraestructura de pruebas de

integración de Meta.

Un enfoque de prueba de vacío para la resiliencia: verificar la recuperación ante desastres en entornos complejos

Su cuenta ya está configurada

Ahora tienes
Detección un perfil
automática y puedes
de pruebas dejar También conocido como: "¿Cómo pruebas tus pruebas?"
deterioradas.

comentarios en todas tus suscripciones.

El control de calidad dedicado existe dentro de Meta. Sin embargo, sólo he oído hablar de este papel en relación con productos

de hardware, dentro de Reality Labs.

El enfoque de Meta en el envío es bastante único en toda la industria. Esto es especialmente cierto para el producto principal de

Facebook, que es un enfoque sofisticado que pocas empresas siguen. Código

Machine Translated by Google

se despliega a través de 4 (!) entornos diferentes de forma automatizada, con reversiones automáticas cuando las cosas se ven mal. Tocamos más detalles

en el tema Envío a producción.

4. manzana

Entre todas las grandes tecnológicas, Apple es la que se ha centrado más en el control de calidad dedicado. Hasta donde yo sé, también es la última

gran empresa tecnológica que queda con un nivel de director.

Rol de control de calidad.

Dentro de la empresa, muchos equipos de productos cuentan con controles de calidad dedicados que realizan pruebas tanto manuales como

automatizadas. Apple también tiene una organización centrada en la entrega de sistemas operativos (MacOS, iOS). Este equipo opera a escala 365/24

en todo el mundo; lo que significa que la organización está disponible todo el día, todos los días del año. El enfoque de esta organización

incluye clasificar los errores reportados verificando que ocurran y enviándolos a los equipos adecuados para que los resuelvan.

Para tener una idea de las expectativas en este puesto, analicé algunos puestos de ingeniero de control de calidad listados recientemente;

uno para la organización de Software y servicios, un equipo de Safari y Webkit, uno para Apple Pay; y uno para IA generativa (Sí, ¡Apple también participa

activamente en este campo!) Las expectativas comunes de estos roles incluyen:

Escriba código utilizando el lenguaje que utiliza el equipo. Esto puede variar según el equipo; los mencionados en estas posiciones fueron

Python, Swift, Objective C, JavaScript y lenguajes de secuencias de comandos.

Familiarícese con la automatización de pruebas, con herramientas como XCTest y CI/CD.

Familiaridad con enfoques de prueba como pruebas unitarias, de integración, de rendimiento y funcionales.

Poseer cualidades útiles para los ingenieros de control de calidad: buenas habilidades de depuración; creatividad; organizado; motivado; y

un buen comunicador

Entusiasmo por productos de alta calidad centrados en el usuario

La mayoría de los equipos esperan que los ingenieros de control de calidad desarrollen planes de prueba, escriban casos de prueba, definan y

realicen un seguimiento de la cobertura de las pruebas, evalúen la preparación para el envío y evalúen el riesgo de errores descubiertos.

Su cuenta ya está configurada

El ingeniero de calidad de IA generativa merece una mención especial. Este campo es diferente a la ingeniería de software tradicional, al igual que las

formas de probar los modelos GenAI. Los ingenieros de calidad ahora tienen un perfil y pueden dejar comentarios en todas sus suscripciones. Se
espera que tengan sólidas habilidades de programación utilizando

herramientas deelaprendizaje
práctica en automático
uso de modelos estándar,
de lenguaje como(LLM).
grandes PyTorch, Tensorflow . y lenguajes como Python, Swift, C++. Es imprescindible tener experiencia

Este puesto parece estar buscando un ingeniero de ML con pasión por

pruebas. Mucho de esto se superpone con el conjunto de herramientas que cubrimos en el número El conjunto de herramientas de aprendizaje automático.
Machine Translated by Google

¿Están conectados los enfoques en el control de calidad y la calidad del producto? Si me hiciera responder qué empresa

lanza los productos más pulidos entre Microsoft, Meta, Google, Amazon, Netflix y Apple; mi respuesta es Apple, sin dudarlo.

¿Podría ser una coincidencia que Apple sea la que parece seguir invirtiendo más en una función de control de calidad

independiente y dedicada?

Sería fácil asumir la causalidad (que Apple tiene productos de alta calidad gracias a su función dedicada de control

de calidad), pero estoy un poco menos seguro de que este sea el caso. Mi sensación es que Apple se ha aferrado a la función

de control de calidad debido a que se centra mucho en el hardware, a diferencia de las otras cuatro empresas.

Sin embargo, en el caso de la calidad del producto exclusivamente digital, no estoy tan seguro de que esto sea válido. Tanto

Apple TV como Netflix son productos pulidos que son muy agradables de usar, y Netflix creó su oferta sin una

función de control de calidad dedicada, mientras que Apple sí tiene una.

5. Amazonas
Amazon tiene un rol SDET, que no sólo incluye una definición, sino también un marco de promoción que llega hasta el nivel

principal (L7.)

Los SDET tienden a operar en contextos más especializados, como:

Creación y mantenimiento de marcos de prueba o sistemas centrales.

Trabajar dentro de sistemas front­end específicos y complejos

Trabajar con dispositivos físicos

La mayoría de los equipos están compuestos por un PM, un SDM y SDE. En estos equipos, se espera que las SDE realicen

pruebas de sus propios productos. Hay equipos centrales que utilizan las pruebas.

frameworks utilizados por otros equipos.

Depende de los equipos locales decidir si necesitan un SDET dedicado. Esto es similar a cómo los equipos

decidir si necesitan roles de ciencia de datos o un TPM.

No existe un grupo central que yo sepa, pero hay equipos centrales que crean las herramientas que todos los demás

usan, como marcos de prueba, etc.

Su cuenta ya está configurada

Mientras buscaba ofertas de trabajo para puestos SDET En Amazon, la mayoría de estos puestos fueron para Ahora tienes
un perfil y puedes dejar productos relacionados con
hardware, y una minoría para productos con iOS, Android y Fire TV/tableta comenta en todas tus suscripciones.

aplicaciones:

Experiencia de desarrollador de Amazon Appstore

Machine Translated by Google

La división Automotriz de Amazon (tienen una y están desarrollando experiencias innovadoras de compra de

automóviles)

Amazon Kuiper: la red de banda ancha satelital de la compañía

Amazon Photos (con aplicaciones en iOS, Android, Fire Tablet, Fire TV y la web)

Transporte de Amazon (una red de cumplimiento)

Cámara exterior parpadeante

Fire TV una tableta

Timbre con vídeo

dentro del grupo Amazon Consumer Robotics; la cámara exterior Blink

Lab 126 de Amazon es una división con un fuerte enfoque en hardware. Como tal, la empresa emplea SDET dedicados, como

confirmé con un ingeniero de esta división.

Mi sensación es que, si bien cualquier equipo puede solicitar un SDET dedicado, está relacionado principalmente con el hardware.

equipos, o aquellos con una cadencia de lanzamiento más lenta, como el lanzamiento de aplicaciones, que lo hacen. Al

mismo tiempo, es importante señalar que Amazon es la única otra empresa importante, además de Apple, con una

trayectoria profesional dedicada y bien definida en control de calidad y SDET.

6. Úber
Uber no tiene equivalentes de SDET, QA o roles similares. Todos los equipos de productos y plataformas tienden a estar

formados por un gerente de producto, un gerente de ingeniería e ingenieros de software. El equipo es responsable de

la calidad de los productos que construyen. La forma de hacerlo depende del equipo que decida. En la mayoría de los

equipos en los que trabajé (y en los que conocía), los gerentes de producto eran defensores de los clientes (y de la calidad) y

muchos de los ingenieros tenían una mentalidad de producto. poner la calidad del producto y la satisfacción del usuario en un

lugar destacado de su lista de prioridades.

Los equipos de plataforma crean infraestructura de prueba para varios sectores verticales que incluyen marcos de prueba, así

como configuraciones de CI/CD que ejecutan estas pruebas. Como ejemplo de lo que estos equipos construyen como

infraestructura de prueba, he aquí un vistazo de la granja de dispositivos Pixel de Uber, construida y mantenida por el
equipo de plataforma móvil Tu cuenta ahora
está configurada de Uber :
Ahora tienes un perfil y puedes dejar comentarios en
todas tus suscripciones.
Machine Translated by Google

Un subconjunto del laboratorio de pruebas de dispositivos móviles de Uber. Fuente: Ty Smith / X

Dado que Uber es una empresa que prioriza los dispositivos móviles y que los lanzamientos móviles se realizan semanalmente,

aquí se realizan pruebas manuales adicionales. Se trata de una combinación de pruebas manuales que realizan los equipos

(llamadas pruebas de cordura), así como varias otras formas de pruebas:

Su cuenta ahora está configurada 'Pruebas

Ahora tienesequipos
de cordura:' un perfil y puedes dejar
de desarrolladores ejecutando pruebas manuales que han definido. Estas son pruebas que el equipo de

comentarios ennotodas
desarrolladores puede tus suscripciones.
automatizar o decide que no vale la pena automatizarlas.

Prueba interna de los empleados sobre la última versión inédita de la aplicación

Programas beta

Pruebas externas, a menudo realizadas con proveedores de pruebas externos.

Machine Translated by Google

Me uní a Uber un par de años después de haber trabajado en Skype/Microsoft, directamente con SDET. Para mí, no tener un

control de calidad dedicado solo me pareció un problema durante las tareas semanales de "pruebas de cordura" que tenía nuestro

equipo. Con el tiempo, nos frustró ejecutar estas pruebas manualmente, por lo que creamos pruebas de un extremo a otro para

algunas de ellas. Para aquellos que no pudimos automatizar (debido a que necesitábamos rutas de pago de prueba de extremo

a extremo), defendimos la contratación de una empresa externa que pudiera realizar pruebas especializadas mediante

crowdsourcing, donde los evaluadores debían estar en países muy específicos, utilizando métodos de pago regionales. .

El equipo de la plataforma ha creado otras herramientas interesantes que ayudan a los equipos de ingeniería a validar la calidad de

su trabajo, mientras se mueven rápido:

Implementación de multiinquilino en microservicios, para permitir pruebas seguras en producción

Entornos de prueba de aplicaciones de corta duración para crear y utilizar entornos de prueba efímeros bajo demanda

No tener evaluadores dedicados significa que todos los demás deben preocuparse más por la calidad del producto.

En 2016, decirle a la gente que Uber no tenía probadores dedicados provocaría miradas extrañas de los desarrolladores

acostumbrados a trabajar con gente de control de calidad. Muchas de estas personas asumieron que sin control de calidad, el

enfoque en la calidad quedaría en el olvido.

Pero, en cambio, esto es lo que sucedió:

Los diseñadores estaban muy interesados en qué tan bien funcionaba la experiencia. Hicieron pruebas de estrés en las

primeras versiones y dieron su opinión.

Los gerentes de producto, gerentes de ingeniería e ingenieros se sentirían orgullosos de desarrollar y publicar su trabajo.

El servicio de atención al cliente sacó a la luz las quejas de los clientes y las canalizó a los equipos de ingeniería a

través de la función de operaciones de producto o a los gerentes de producto.

La prueba interna del producto y hacer que fuera muy fácil señalar problemas funcionó bastante bien, dado que Uber

tenía más de 10,000 personas probando la aplicación. Esto también tiene la oportunidad de una escalada interna.

Todavía recuerdo ese error enviado por el CEO de Uber, Travis Kalanick, que Tu cuenta ahora está configurada y que mi

equipo
comotuvo que manejar, ¡lo cual hicimos
prioridad!

Ahora tienes comerciales

Las métricas un perfil yeran
puedes
cosas dejar
sobre las que los equipos mantenían un pulso en tiempo real. Cuando una métrica
comentarios en todas tus suscripciones.
empresarial comenzaba a bajar (en mi equipo, este era el porcentaje de pagos exitosos), indagábamos en la causa y si

se trataba de algo funcional o de experiencia del usuario.

Para obtener más detalles sobre por qué y cómo Uber creó equipos de plataforma, consulte el artículo La plataforma y el programa

divididos en Uber. Cubro más detalles sobre pruebas móviles automatizadas y manuales en mi
Machine Translated by Google

libro Creación de aplicaciones móviles a escala.

7.Netflix
Pregunté en Netflix si existe un concepto de funciones de control de calidad o SDET, y no lo hay.

La empresa, al igual que Uber, deja que los equipos de ingeniería garanticen que la calidad de su trabajo esté a la altura de las expectativas

de los clientes. Esta responsabilidad se dividirá entre el director de producto, el director de ingeniería y los desarrolladores.

Los únicos roles de control de calidad que he observado se encuentran en el relativamente nuevo grupo Netflix Games Studios, donde la

compañía está contratando a un gerente de control de calidad. un ingeniero de pruebas senior y un analista senior de control de calidad

Si bien no existe una función dedicada a las pruebas, Netflix ha tenido un gran impacto en la industria por la forma en que aborda la calidad.

Las pruebas del mono del caos se originan en Netflix. En 2010, la empresa publicó una entrada de blog que explicaba por primera vez el

concepto:

“Uno de los primeros sistemas que nuestros ingenieros construyeron en AWS se llama Chaos Monkey. El trabajo de Chaos Monkey es

eliminar aleatoriamente instancias y servicios dentro de nuestra arquitectura. Si no ponemos a prueba constantemente nuestra capacidad

para tener éxito a pesar del fracaso, entonces no es probable que funcione cuando más importa: en caso de una interrupción

inesperada”.

Netflix de código abierto su herramienta Chaos Monkey en 2016, y el concepto de prueba de Chaos Monkey se ha extendido a otras empresas

desde entonces. Yo diría que Chaos Monkey fue uno de los enfoques que impulsó los principios de la ingeniería del Caos. publicado

por primera vez en 2015. Ahora hay una comunidad del Caos dedicado a este tema. ¡Quizás no existiría sin Netflix!

Las pruebas A/B y la experimentación son el corazón de la empresa, como se analiza en el vídeo de 2016 sobre las pruebas de diseño en

Netflix. En él, Anna Blaylock, del equipo de diseño de Netflix, comparte cómo Netflix aprendió que lo que los usuarios piden a menudo no es lo

que realmente quieren. El enfoque basado en métricas de la compañía (de prestar atención a lo que hacen los usuarios cuando se implementa

un cambio) ayudó a Netflix a crear funciones que resultaron en un mayor uso del producto y, con suerte, en una mayor satisfacción.

Su cuenta ya está configurada

usuarios.
Ahora tienes un perfil y puedes dejar
comentarios en todas tus suscripciones.
Netflix ha creado muchas herramientas para medir la calidad de su producto, incluida una herramienta llamada Fusión de evaluación

multimétodo de video (VMAF, por sus siglas en inglés). que es una forma de medir la percepción de la calidad del streaming. Por ejemplo, en las

imágenes a continuación, las imágenes superior e inferior tienen la misma calidad objetiva, pero para el ojo humano, la imagen del zorro superior

se siente de una calidad significativamente peor:

Machine Translated by Google

El equipo de ingeniería de Netflix creó una herramienta para medir la percepción de la calidad del video.
En la imagen de arriba, el zorro parece tener una calidad mucho peor para la imagen superior
en comparación con la multitud: ¡pero son iguales, en un sentido absoluto! Fuente de la imagen: blog de
tecnología de Netflix

Al igual que Uber, Netflix también hace pruebas en producción y su equipo de ingeniería crearon una forma sencilla de
realizar pruebas en dispositivos móviles, de forma automatizada. Estos son solo algunos de los ejemplos que
encontré; hay otras herramientas de prueba y mejoras creadas por su equipo.

Su cuenta ya está configurada

Comidas para llevar
Ahora tienes un perfil y puedes dejar
Fuecomentarios enestableció
Microsoft quien todas tuspor
suscripciones.
primera vez la función SDET en la década de 1990 y, sin embargo, este

gigante de la tecnología descontinuó la posición en 2014, a medida que cada vez más equipos pasaron a una
cadencia de lanzamiento diaria, en lugar de mensual o trimestral. Ahora, son los propios equipos los que poseen la
calidad, y los ingenieros de software crean mucha automatización para garantizar que lo que lanzan funcione
como debería.
Machine Translated by Google

Apple y Amazon son las únicas dos grandes empresas tecnológicas que todavía cuentan con un puesto de ingeniero de calidad

(Apple) o SDET (Amazon) dedicado. Si bien los beneficios del control de calidad son obvios para los productos de hardware de Apple,

me pregunto qué diferencia visible tiene el enfoque de control de calidad de Apple con el software. En Amazon, los equipos que

solo utilizan software rara vez tienen SDET, aunque pueden solicitarlos para obtener ayuda específica.

Google y Meta tienen una organización centrada en la productividad de los desarrolladores: EngProd (Google) y DevInfra (Meta), y estas

organizaciones también crean herramientas de prueba.

Uber y Netflix nunca han tenido gente dedicada a QA o SDET, pero cada uno ha invertido masivamente en la construcción de infraestructura

de prueba. La herramienta Chaos Monkey de Netflix se ha extendido por toda la industria, mientras que en Uber, los equipos de la

plataforma siguen ideando mejores formas para que los ingenieros la validen.

su trabajo rápidamente en un entorno similar al de producción; ¡A veces justo en producción!

Todas las Big Tech invierten mucho para garantizar la calidad de sus productos, pero esto no suele ser en forma de pruebas

manuales o probadores manuales. Este grupo presiona fuertemente para medir

la calidad de sus productos. Una vez que pueden medir, automatizan la medición y crean ciclos de retroalimentación y pruebas automatizadas

que realizan un seguimiento de dónde están estos indicadores de calidad.

Dentro de las Big Tech, cada vez más se trata de productos de hardware y de software que avanzan a un ritmo lento.

ciclo de lanzamiento, que tienen asignado personal de control de calidad dedicado. Al mismo tiempo, los ingenieros de software

tienen mucha más responsabilidad a la hora de garantizar la calidad de los productos que construyen que las empresas más "tradicionales"

con probadores dedicados.

Espero que esta descripción general ilustre por qué estas opciones tienen sentido para cada empresa y los enfoques adicionales que

adoptan estas organizaciones para garantizar una alta calidad del producto. Como siempre, resista la tentación de copiar lo que hace otra

empresa sólo porque es "famosa" como Google o Apple.

En una edición de seguimiento, cubriremos los enfoques de prueba en una gama más amplia de empresas y observaremos que la

función de control de calidad está presente en muchas empresas y está ganando importancia en algunos lugares. También

analizaremos cómo está cambiando el papel del control de calidad en la industria tecnológica y por qué.

Cuestiones relacionadas, que se superponen con las pruebas:

Su cuenta ya está configurada
Ahora
Cómotienes un perfil
las Big Tech y proyectos
ejecutan puedestecnológicos
dejar y la curiosa ausencia de Scrum. como son los proyectos
comentarios enuntodas
organizado tiene impactotus suscripciones.
en qué tan sencillo (o no) es realizar pruebas manuales con una cadencia regular.

Prácticas saludables de guardia – Si bien no todas las grandes empresas tecnológicas tienen una función de control de calidad

dedicada, los ingenieros casi siempre están disponibles, lo que obliga a centrarse más en la calidad.
Machine Translated by Google

Envío a producción

Lidiar con una cultura de ingeniería de baja calidad en las Big Tech

¿Qué es un ingeniero de software senior en Big Tech?

123 Me gusta ∙ 11 recargas

9 comentarios

Escribir un comentario...

9 comentarios más...

© 2023 Gergely Orosz ∙ Privacidad ∙ Términos ∙ Aviso de recopilación

Substack es el hogar de una excelente escritura

Su cuenta ya está configurada

Ahora tienes un perfil y puedes dejar
comentarios en todas tus suscripciones.