- Они придумали SDET
- Как это было в команде Skype
- Отказ от роли SDET
- Официально
- На примере Visual Studio Team
- Видео-постскриптум
«Microsoft сыграла огромную роль в развитии и повышении значимости Quality Assurance во всей IT-отрасли. Microsoft была первой крупной компанией, которая предложила специальную роль в QA, выходящую далеко за рамки ручного тестирования — а именно SDET.
Далее подробно рассмотрим эту роль в Microsoft, и как они отказались от этой практики.
Они придумали SDET
Роль SDET (Software Development Engineer in Test — разработчик на должности тестировщика / выполняющий функции тестировщика) была впервые введена компанией Microsoft. Это были инженеры-программисты, которые занимались написанием автоматизированных тестов, а также созданием и поддержкой специальных систем для тестирования.
Единственное отличие SDET от SDE (просто Software Development Engineer) заключается в том, что SDET обычно не пишут production-код: они пишут лишь код тестов, работая в одной команде с SDE.
Я не смог проследить точное время введения этой роли, но, скорее всего, это произошло в 1990-х годах. Например, вот пост 2004 года члена команды Microsoft Exchange, объясняющее, что значит быть SDET в их команде:
«SDET — это разработчик, который работает в команде тестирования, а не в команде разработки. SDET обладает острым чутьем тестировщика и при этом любит писать код, причем много кода.
SDET обеспечивает команду тестировщиков инструментами и процессами, необходимыми для того, чтобы тестировщики могли делать то, что у них получается лучше всего — тестировать продукт и находить в нем как можно больше ошибок, прежде чем он поступит на рынок».
SDET обладает способностью анализировать функциональность и архитектуру продукта и, таким образом, разрабатывать и внедрять инструменты, помогающие тестировщикам тестировать продукт.
SDET работает в условиях коротких жизненных циклов проектов, разрабатывает и внедряет множество инструментов и тестовых фреймворков в течение одного года, использует новейшие технологии и открывает другим простор для инноваций.
Несмотря на то, что качество продукта является первостепенной задачей, SDET не испытывает того уровня стресса, который испытывают разработчики в конце жизненного цикла продукта. Говоря простым языком, SDET редко находится в первом ряду».
В Microsoft существует формальная карьерная лестница для роли SDET. Из того же поста:
«На позиции SDET есть простор для карьерного роста. Если вам нравится заниматься своим делом в качестве SDET, то вы можете стать Test Architect. Если вы хотите участвовать в управлении, то можете стать SDET Lead, а затем Test Manager.
Если же вы хотите просто кодить и не заниматься тестированием, то можно пойти по пути разработчика. Многие люди идут именно по этому пути. Если же вы понимаете, что ваше сердце принадлежит тестированию, то вы можете стать тестировщиком».
В команде Skype
Соотношение 2:1 для ролей SDE:SDET было обычным для Microsoft примерно до 2014 года. Так было и в моей команде в Skype для Xbox One в 2012 году, когда команда была сформирована. Вот как выглядела наша команда с точки зрения численности:
- 12x SDE (software development engineers)
- 6x SDET (software development engineer in test)
- 2x PM (product managers)
- 1х EM (engineering manager)
- 1х SDET Lead
В нашем проекте команда SDET владела всеми операциями тестирования:
- Ручная проверка того, что функции, созданные разработчиками, работают так, как ожидалось, в том числе и в тех edge cases, которые мы могли не учесть
- Создание интеграционных и сквозных тестов для автоматизации рутинных проверок
- Создание планов ручных тестов и их выполнение перед major milestones.
- Участие на этапе планирования функций, внесение идей по edge cases и методам валидации
- Создание решений для сложных проблем, например, как провести надежный бенчмаркинг производительности нашего продукта (Skype) на платформе Xbox
Напряжение
С самого начала юнит-тесты были источником напряжения. Кто должен их писать? Несколько опытных разработчиков пришли из игровой индустрии, где разработчики обычно не пишут автотесты, и их мнение заключалось в том, что любая автоматизация, включая юнит-тесты, должна осуществляться командами SDET.
Те из нас, кто ранее создавал приложения или занимался разработкой, управляемой тестами (TDD), считали, что такой подход неверен и что разработчики должны сами писать модульные тесты, поскольку модульные тесты и код тесно связаны. Я был в этом лагере.
Наличие специальных SDET-разработчиков сделало заманчивым для разработчиков вариант отдать написание юнит-тестов SDET’ам как бы на аутсорсинг. Скажу сразу: без SDET-команды вопрос о том, кто пишет модульные тесты, не обсуждался бы: их должны были бы писать мы, разработчики. Это давний спор, который я наблюдал в каждой команде с ролями SDET. Удивительно, но даже в этом году я слышал о компании из Силиконовой долины, где dev-команда заставляет QA-команду писать модульные тесты.
Временный компромисс
В нашем случае мы остановились на том, что разработчики пишут модульные тесты, а команда SDET делает все остальное. Такой подход работал достаточно хорошо, но было несколько запомнившихся моментов:
- Ситуация «мы и они», которая создавала разделение. Когда мы, разработчики, заканчивали работу над функцией, мы передавали ее SDET, который обычно находил проблемы, и функция возвращалась разработчикам для исправления. Это раздражало разработчиков, так как приводило к появлению работы, которую мы не могли предвидеть. Со временем стало казаться, что существует две команды с разными целями, которые не всегда движутся в одном направлении.
- Тикеты летают между отделами разработки и тестирования. Я заканчиваю работу над своей фичей и отправляю ее на тестирование (туда). Тестировщик находит ошибку и на следующий день отсылает ее мне (сюда). Я исправляю ошибку и через несколько дней отправляю ее снова (туда). Тестировщик находит еще одну ошибку и снова присылает ее мне… И такая ситуация возникала постоянно.
- Разработчики умели создавать сложные системы и могли оказывать SDET большую помощь. Наша команда SDET несколько месяцев создавала систему интеграционного тестирования, но дело продвигалось медленно. Наша команда очень нуждалась в такой системе, поскольку ручное тестирование занимало слишком много времени. Наконец, один из наших сеньоров предложил разработчикам из dev-команды присоединиться к нашей команде и помочь в создании такой системы. Через две недели под руководством опытных разработчиков система была готова к работе. Это заставило меня задуматься: а не будет ли команда работать лучше без разделения на разработчиков и тестировщиков?
- Слон в комнате: некоторые разработчики свысока смотрели на SDET. Хотя и не все, но очевидно, что многие разработчики считают работу SDET менее сложной, чем свою собственную. SDET-специалисты также знали, что, перейдя на роль разработчика, они могли бы получить лучшие карьерные возможности.
Оказалось, что им не пришлось долго ждать продвижения по карьерной лестнице.
Отказ от роли SDET
В начале 2014 года я присоединился к новой команде под названием Skype for Web. Эта команда отличалась от большинства команд в Skype тем, что они поставляли новую версию программного обеспечения каждый день, а не каждый месяц.
На бумаге команда состояла из 6 SDE и 3 SDET. В реальности же нас было 9 SDE, благодаря нашему Engineering Manager и Test Lead, которые спокойно решили, что нет смысла выделять роль тестировщика, если мы каждый день поставляем новые фичи.
(Об этом изменении, о котором руководство команды не сообщало, я пишу в статье «Как в Big Tech управляют проектами и почему иногда игнорируют Scrum»).
«Когда я присоединился к команде Skype for Web, мы изначально проводили двухнедельные спринты и следовали обычным Scrum-процессам. У нас также существовало стандартное разделение ролей на инженеров-программистов и QA-инженеров. Темп релизов был один раз в две недели, но мы стремились, чтобы это чаще.
Первое, что мы сделали — сделали QA частью разработки. В былые времена разработчик заканчивал свою работу, заходил в свой бренч, обновлял тикет и сообщал QA, что он готов к ревью. Через день или два QA брал этот тикет, проверял его и снова открывал, если находил проблемы. Возникала ощутимая задержка.
Мы провели тихое, неофициальное изменение, в результате которого все SDET стали билдить прод-код, а все обычные SDE-программисты стали отвечать за тестирование собственного кода. Теперь нам больше не нужно было ждать фидбэка в течение нескольких дней, прежде чем отправить код в прод. Однако двухнедельные спринты и многочисленные Scrum-ритуалы стали нашей следующей проблемой».
Мы стали работать гораздо продуктивнее, исключив из своей команды роль SDET. SDET по-прежнему занимались в основном тестированием, но при этом брали на себя и некоторые задачи по разработке. Что не менее важно, мы стали чаще работать в паре! Я помню, как мы в паре с SDET создавали какую-то функцию. У меня хорошо получалось думать о том, как сделать так, чтобы что-то работало, а у SDET хорошо получалось указывать на edge cases, которые я не учел. Когда дело дошло до отладки, сообразительность SDET приятно удивила меня.
В большинстве команд Microsoft SDET тратили слишком много времени на ручное тестирование и написание интеграционных тестов. Но в нашей команде ручного тестирования было очень мало, и мы все сообща создавали инфраструктуру интеграционного тестирования и инфраструктуру мониторинга. Когда разработчик или SDET брались за работу, они писали все тесты — и модульные, и интеграционные, что было вполне логично.
Самое приятное в этом изменении то, что больше не возникала ситуация «мы против них». Прекратились споры о том, нужно ли исправлять ошибку, которую обнаружил SDET, поскольку теперь мы сами проводили тестирование и исправляли обнаруженные ошибки, прежде чем отправить их на прод.
Веб-команды Microsoft начали потихоньку избавляться от роли SDET. В 2014 году наша веб-команда в лондонском офисе Skype чувствовала себя «особенной», поскольку единственными другими командами, объединившими функции SDET, были веб-команды, которых было не так много. Во всех остальных офисах SDET продолжали работать так же, как и раньше.
Однако не только веб-команды в подразделении Skype объединили эти функции для повышения эффективности. Веб-команды самостоятельно пришли к пониманию того, что объединение ролей SDET и разработчиков позволяет им двигаться быстрее, и так произошло во всей Microsoft!
Официально
В середине 2014 года компания Microsoft официально отказалась от роли SDET и ввела роль SE. Вдохновителем, по всей видимости, стала более крупная веб-команда Microsoft — Bing. Из статьи Ars Technica, 2014 г:
«В Bing задача создания тестов была возложена на разработчиков, а не на выделенных тестировщиков. QA-отдел контроля качества по-прежнему существует и играет важную роль, но он проводит тестирование в «реальном стиле» конечных пользователей, а не классическое автоматизированное тестирование. Такой подход оказался успешным для Bing, повысив способность команды внедрять изменения без ущерба для общего качества продукта».
В июле 2014 года Microsoft объявила о самом крупном на тот момент сокращении штата, уволив 18 000 сотрудников из 127 000 работающих в компании. 12 500 из них были сокращены в подразделении Nokia. В рамках этого сокращения также было ликвидировано большое количество должностей SDET. Это произошло примерно в то же время, когда было объявлено об отмене роли SDET, и существующие SDET должны были перейти на должность Software Development Engineer (SDE) в течение следующих нескольких месяцев. Роль SDE была переименована в SE — Software Engineer.
Как прошел этот переход? Насколько я понимаю, все прошло хорошо. Это изменение имеет большой смысл для команд, которые выпускают релиз ежедневно. А команды в Microsoft, выпускающие еженедельно или ежемесячно, становятся все более редкими, поскольку Microsoft постепенно переходит на модель «программное обеспечение как услуга» (SaaS). Конечно, Microsoft продолжает оставаться поставщиком семейства Windows и планшетов Surface. В этих сферах подход к QC должен быть несколько иным, чем в случае с SaaS-продуктами.
В Visual Studio Team
Хороший рассказ об этих изменениях — от команды Visual Studio Team Services в 2017 году, через три года после этих изменений. Вспоминая об этом, Брайан Харри — в настоящее время Technical Fellow в Microsoft — писал следующее:
«Два года назад [в 2015 году] у нас были десятки тысяч тестов. Они были написаны «тестировщиками» для тестирования кода, написанного «разработчиками». Хотя у этой модели были некоторые преимущества — например, четко измеряемые и контролируемые затраты на тестирование, экспертиза и карьерный рост в тестировании и т.д., было и много недостатков — отсутствие ответственности разработчиков, медленные циклы обратной связи (внедрить ошибку, найти ошибку, исправить ошибку), у разработчиков было мало мотивации делать свой код «тестируемым», расхождение между архитектурой кода и архитектурой тестов делало рефакторинг и пивот очень трудным и дорогим, и многое другое. (…)
Проведение полноценного тестирования занимало большую часть дня, еще много часов уходило на «анализ результатов» для выявления ложных отказов и несколько дней или недель на исправление всех тестов, которые были красными в результате каких-то изменений в продукте. (…) Два года назад мы встали на путь полного переосмысления тестирования.
Мы объединили отделы разработки и тестирования в единый «инженерный» отдел. По большей части мы устранили различие между людьми, которые пишут код, и людьми, которые тестируют. Это не значит, что каждый человек делает одинаковое количество работы, но каждый человек делает что-то из этого и отвечает за качество своей работы. Мы также решили полностью избавиться от 10 тысяч тестов, на создание которых ушло 8 лет, и заменить их новыми тестами, которые были написаны совершенно по-другому».
Команда провела анализ имеющихся тестов и решила, что им не нравится то, что у них мало небольших юнит-тестов, но много сложных и трудно поддерживаемых сквозных тестов. Поэтому они изменили ситуацию:
Вот еще одна визуализация изменения результатов тестирования команды за два года:
Так нужны ли были в итоге все эти изменения? По мнению Брайана, да. В то время он писал:
«Мы уже ощущаем выгоды в виде повышение качества, гибкости процессов, и удовлетворенности разработчиков».
Постскриптум
В виде мега-зума Лилии Урмазовой, Леши Маршала и АнтонаQA с участием бывшего сотрудника Microsoft.
