Фантастичні SDET'и та де їх шукати

Highway to ... success?

Напевне кожна друга людина, що починає працювати у тестуванні або в автоматизації, чує про те, що "ось круто було б стати SDET'ом"! "Це вершина розвитку кар'єри тестувальників та єдиний спосіб вибитися в люди та здобути визнання та гроші."

Але хто такі ті SDET`и? Що вони роблять? Як ними стати? Та найголовніше - чи варто взагалі?

Сьогодні я коротко хочу про це поговорити. Бо я сам був таким, особливо на початку своєї кар'єри :).

Історія SDET`ів

Давайте спочатку розберемося, хто такі SDET`и.

Наскільки мені відомо, то першими такі позиції почали відкривати ще наприкінці 1990х та на початку 2000х у Microsoft. Позиція розшифровувалася, як Software Developer Engineer In Test. Тобто такі інженери, які були ніби програмістами, але займалися тестуванням. З глибоким технічним бекграундом та підходами.

Навіть співбесіди на звичайного розробника та SDET`а були відсотків на 80 ідентичними. Єдина суттєва відмінність була у тому, що SDET`ів просили дуже ретельно описувати, як вони свій код будуть тестувати та якими методами. Тобто був блок "тестування" як частина інтерв'ю.

Більше про те що такі інженери робили - написано у книзі "How we test at Microsoft". Скажу чесно, я починав читати цю книгу, але щось не зайшло. Можливо потім повернуся до неї.

З часом, моду на SDET`ів почали запозичувати інші великі IT компанії, зокрема Google. Там вже виділяли окремо SET (Software Engineer In Test) та Test Engineer. (Читайте більше про це в "How Google Tests Software" або у Google Testing blog)

Задачею SDET'ів було забезпечення тестабіліті продукту та написання інструментів тестування.
Завданням тест інженерів було саме тестування - більше на рівні end-to-end та за допомогою інструментів, що створили для них у тому числі SDET`и.

Для цих інженерів навіть проводилися окремі конференції, типу GTAC. Для свого часу це була дуже крута конференція - там можна було побачити підходи та рішення з автоматизації у дійсно великих компаніях. Щось більше, ніж модний Selenium WebDriver на півтори сторінки.

З часом, SET інженери навіть домоглися зміни свого тайтлу на той, що більше відображає специфіку їх роботи: Software Engineer - Tools and Infrastructure.

Так хто такі SDET'и та що вони роблять?

Важливі ремарки

По-перше. SDET в тому значення, який у нього закладався на початку створення тайтлу - то дуже й дуже специфічний інженер. Інженери такого роду потрібні більше у продуктах та у дуже малій кількості.

По-друге. В силу своєї специфіки, поняття та вимоги до SDET`ів у кожній компанії різні. Десь, це буде інженер, що пише тільки фреймворки. Десь - ще деякі види тестів. Десь - займається виключено тестовою інфраструктурою. Десь - усім цим плюс тестує руками (так, так буває, уявіть!). Причому тайтл такі люди можуть просто - automation engineer.

По-третє. Останнім часом стало "модно" створювати SDET направлення, як окрему гілку в аутсорсі. Не знаю, чи це успішно, але на перший погляд виглядає наче просто ще один спосіб подовше залишити інженера в компанії та "мотивованим" досягти ще однієї нової ступені розвитку. Чи робить він чи вона при цьому корисні речі (відмінні від автоматизації кейсів) - то інше питання.

Базові завдання типового SDET`а (на мій погляд):

побудова та підтримка рішень для автоматизації тестування
створення окремих сервісів та інструментів для тестування та оцінки якості (для усіх інженерів та менеджерів, включно з розробниками)
інтеграція існуючих інструментів для забезпечення якості в загальний delivery pipeline
створення інструментів збору метрик та візуалізації результатів тестів (Grafana репорти та інше)
створення та підтримка інфраструктури запуску тестів (CICD інструменти, гріди, ферми девайсів)

Тобто, фактично, SDET - це розробник, що концентрується на покращенні якості та тестабіліті продуктів.

Як стати SDET`ом?

Я бачу два шляхи: важкий та не дуже важкий.

Важкий. Ви стаєте автоматизатором, вивчаєте базу тестування (а може й працюєте якийсь час тестувальником), купу інструментів. Потім накопичуєте розробницьких знань та стаєте SDET'ом.
Не дуже важкий. Стаєте розробником, цікавитеся тестуванням та якістю, пишете корисні інструменти сам або питаєте у своїх тестувальників, яких інструментів їм не вистачає. Вуа-ля - ви SDET!

Головний момент у тому, що для SDET'а дійсно потрібно знайти та вміти 80-90% усього, що потрібно звичайному розробнику: мова програмування, IDE, засоби зборки, паттерни, деплоймент, Git, бази даних, message queues, ще багато чого. Просто задачі у вас будуть трохи інші.

У звичайного розробника вплив звичайно більший - бо результати його роботи бачать мільйони та мільярди людей. Роботу SDET`а бачать в більшості випадків тільки всередині компанії.

Але й роботу тестувальників не бачить ніхто. (Якщо баги знайдені та виправлені до релізу ...) Бо це все робота команди.

Що далі?

Ще у кінці книги "How Google Tests Software" 2012 року автори зауважують, що не бачать майбутнього в SDET`ах в Google. Частково робота таких інженерів буде покриватися самими розробниками, частково - тест інженерами. Про це також пише той самий Alan Page.

Так, за останні десять років, з'явилося багато інструментів, що полегшують тестування та збірки продукту для розробників. Та й самі розробники вже більше й більше приділяються увагу тестуванню та якості. Але SDET`ів ще наймають. Навіть у топових компаніях. Можливо вони називаються Software Engineer - Tools and Infrastructure, або Software Engineer - Developer Productivity. Але задачі дуже й дуже схожі між собою.

То ж, напевне не все ще так погано. Роботи ще достатньо. Плюс не завжди тайтл відповідає задачам.

Епілог

Для мене не важливо, як називається та чи інша позиція у компанії. Головне, щоб задачі були цікаві, вплив на процеси був помітний та й компенсація була достатня.

У нас в компанії нещодавно усіх зробили SDET`ами. Але ми не цураємося перевіряти багато чого руками - бо інакшого способу поки немає. Інструменти для автоматизації чогось кардинально нового потрібно спочатку написати.