Software Development Engineer in Test: розвиток ролі та необхідні навички при розробці IoT-продуктів

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Вітаю, я — Олександр, SDET Manager у R&D центрі SQUAD. Цей матеріал ми підготували разом з моїм колегою Єрмєком, котрий також SDET Manager. У нас на двох майже 20 років досвіду в автоматизації тестування. І за цей час нам неодноразово доводилось доходити до висновку, що SDET — це немов самурай, у якого, як ми знаємо, немає мети, а є лише шлях.

Навколо ролі Software Development Engineer in Test (SDET) завжди виникало багато дискусій. Чи має SDET бути частиною команди розробників? Чого очікувати від інженера, який виконує цю роль у сфері Internet of Things (IoT)? Які його ключові скіли? Чим QA Automation відрізняється від SDET?

В цій статті ми хочемо поділитися власним досвідом роботи у SDET напрямку та нашим баченням тих основних навичок, якими необхідно володіти спеціалісту.

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

Народження SDET

Посаду Software Development Engineer in Test вперше презентували у компанії Microsoft на початку 2000-х років. Amazon та Apple також почали використовувати назву SDET, тоді як у Google впровадили власну версію — Software Engineer in Test (SET).

Ідея полягала у тому, щоб у гонитві за якістю продукту заповнити прогалину між Quality Assurance (QA) та Software Development Engineer (SDE). Новими спеціалістами мали стати ті інженери, що однаково ефективно виконували б роль розробника та тестувальника — брали участь в повному циклі розробки і тримали фокус на здатності продукту до тестування, його надійності, а також ефективності всіх процесів.

В Україні хайп навколо теми SDET-ів розпочався у 2017-2020 роках. Вона гаряче обговорювалася на численних конференціях з автоматизації тестування. В той самий період багато українських компаній вперше ввели цю роль, як окремий кар’єрний шлях. QA Automation спеціалісти почали переходити на новостворені позиції. Приблизно у той же час ми й доєдналися до SQUAD.

Про розвиток SDET на окремому прикладі

Трохи контексту. Ми працюємо з IoT-продуктами — hardware-пристроями та системами безпеки для «розумного дому». На стороні клієнта у нас є застосунки для iOS та Android. Інтеграція забезпечується хмарним бекендом. За останні 5 років, команда SDET-ів виросла з двох інженерів до 50+. За цей час було сформовано декілька департаментів з різним фокусом і задачами.

Спеціалізації

Зараз у наших SDET-команд є спеціалізації, але так було не завжди. На початку була одна невелика команда інженерів і декілька hardware-продуктів. Android та iOS застосунки були набагато простішими. Ми мали змогу охопити весь спектр задач без необхідності розділяти зони відповідальності.

З розвитком продукту, відбулися структурні зміни й команда SDET-ів розділилася на дві — Mobile та Cloud. Це призвело до ротації інженерів, а разом з цим і обов’язків. Треба було оперативно реагувати та перебудовувати системи й процеси.

До цього моменту у нас була єдина програмна платформа для автоматизації тестування — монолітний фреймворк, який охоплював всі сервіси бекенду та мобільних застосунків. Він складався з десятків різних модулів і залежностей. Ми почали відокремлювати ці компоненти й переносити все в окремі репозиторії. Як результат — тестування бекенду та мобільне тестування розділилися в окремі фреймворки. Cloud почав працювати з потоковим відео, функціональним та performance тестуванням сервісів. Mobile — з end-to-end і функціональним та нефункціональним тестуванням застосунків.

SDET-и у Mobile

Уявімо, що вам треба протестувати одну єдину модель hardware-пристрою. Є необхідність автоматизувати end-to-end тести, зокрема, прив’язку пристрою до користувача та його основні функції. Вам треба керувати цим пристроєм — натискати кнопки, а отже знадобиться мікроконтролер, який емулює фізичну взаємодію користувача та збирає інформацію з нього.

Також потрібно емулювати дії користувача в мобільному застосунку — для цього знадобиться автоматизація мобільного застосунку. Взаємодія між пристроєм та мобільним застосунком відбувається на фізичному рівні (WI-FI, Bluetooth), тому треба забезпечити наявність реальних мобільних телефонів, планшетів тощо. І вся ця комплексна інфраструктура потрібна для тестування лише однієї моделі.

Інша історія: коли вам необхідно розробити та підтримувати тести для цілої низки різних пристроїв. Кожен з них має свої функціональні особливості. Було прийнято рішення розділити команду Mobile: одна частина спеціалістів зосередилась на функціональному тестуванні мобільних застосунків, а інша — почала працювати з end-to-end автоматизацією тестування, що охоплювало всі взаємодії з кожним окремим типом пристроїв.

Але на цьому виклики не закінчилися. Якщо проводити аналогії, то якийсь час наш фреймворк був схожий на будиночок на дереві, але потім почав перетворюватись на хмарочос. І чого нам точно бракувало, так це — фундаменту.

Команди розробки мали абстрактні назви, їхні обов’язки та зони відповідальності були неочевидні. Які тест-кейси належать якій команді? Які дефекти хто виправляє? Якщо з’являється нова функціональність, хто за неї відповідає? Для автоматизації це був біль і по-справжньому проблематичний досвід.

Як це було вирішено? Умовно кажучи, команда розробки AB стала відповідальною за функціональність A та B. Команда CD — за функціональність C та D. Команда E, відповідно, за E. Кожна з функціональностей мала свій контекст та технічні особливості. І це ідеальна ситуація, в якій можна було якісно передбачати та планувати співпрацю. Це і стало нашим фундаментом для автоматизації. Ми інтегрували SDET-ів у команди розробки, щоб вони могли зосередитися на потребах автоматизації. Так сформувалася нова спеціалізація — SDET-и в функціональних командах (SDETs in feature teams).

Крім того, хтось повинен був консолідувати їхню роботу в релізах, підтримувати зі звітністю, автоматизацією рутинної роботи, а також розробкою спільної функціональності для тестування. Для цього була створена окрема спеціалізація — автоматизація процесів та розробка інструментарію (process automation and tooling). Вони працюють над розвитком фреймворків і загальної функціональності для регресійного тестування мобільних застосунків, а також — автоматизують звітність. До того ж щоразу, коли потрібно провести новий тип тестування, команда відповідає за їхні R&D та впровадження.

Для тестування продукту з великою кількістю інтеграцій між фізичними пристроями та хмарами, потрібні hardware-лабораторії й сервіси для керування та взаємодії з ними. Крім того, необхідні системи для керування тестовими даними та фізичними пристроями. Розробкою та підтримкою цих речей займається окрема команда — Core & Infrastructure. Вони також працюють над специфічними рішеннями для performance та profiling тестування.

SDET-и у Cloud

З Cloud ситуація інша. Якщо у випадку з Mobile ми маємо десятки різних команд, які працюють над однією програмою з єдиним циклом релізу, то на стороні бекенду — кожна команда відповідає за один або декілька різних сервісів. Було логічно розділити автоматизацію їхнього тестування, адже кожен з цих сервісів має власний цикл релізів, а подекуди й декілька протягом тижня. Тож ми почали розділяти тести та Software Development Kit (SDK) для кожного з них. SDK допомагає проводити функціональне тестування та використовується в інтеграційному тестуванні інших сервісів.

Кожен сервіс має власний цикл розробки, тому нашим наступним завданням було інтегрувати автоматизацію у Continuous Delivery (CD), щоб забезпечити швидкий зворотний зв’язок для розробників і пришвидшити цикли релізів. Концепція полягає в тому, що окрема команда працює з окремим сервісом та відповідає за розробку, тестування, реліз і підтримку. Таким чином тестування стало частиною розробки — інженерам потрібно було писати модульні, інтеграційні, та performance тести. Так деякі SDET-и, які працювали з функціональним та performance тестуванням, перейшли на посади SDE та DevOps.

Також ми маємо справу з потоковим відео та аудіо. Автоматизувати такі бекенд-сервіси на 100 відсотків складно. Тому ми все ще проводимо мануальне тестування, щоб переконатися, що у кінцевих користувачів все працює коректно після розгортання нових версій. Щоб спробувати це автоматизувати, ми використали рішення та лабораторії, які гарно себе показали у випадку з Mobile та прошивками hardware-пристроїв. Були створені end-to-end тести з реальними пристроями, які запускаються після розгортання нових версій бекенд-сервісів. Тепер це є додатковим кроком у пайплайні для автоматичного підтвердження, що після деплойментів все працює так, як треба.

Роль та ключові навички SDET сьогодні

Тепер поговоримо про поточну роль SDET та ті основні навички, якими повинен володіти, на нашу думку, гарний інженер.

Комунікації

І перше — це комунікація. Змоделюємо ситуацію: планується виведення нового продукту на ринок, і ви відповідальні за автоматизацію тестування у рамках циклу розробки. Отже, як зрозуміти, які ключові характеристики цього продукту? Чи мають вони щось спільне з попередніми або ж ні? Як вони імплементовані — однаково або по-різному?

Вам потрібно постійно спілкуватися з розробниками, QA, продакт-менеджерами, з тими, хто відповідає за таймлайни, графіки релізів тощо. Виходячи з цього, ви будете приймати відповідні рішення — де і яким чином застосовувати тестування, як звітувати, що перевіряти, а що ні. Тому у нашому випадку — communication is key.

Quality assurance

Ще один фундаментальний скіл — це, звісно ж, забезпечення високого рівня якості. Розглянемо наступний кейс. На ринок виходить новий пристрій, клієнт купує його в магазині, приносить додому і пробує налаштувати. Цей процес мало чим відрізняється від налаштування, скажімо, вашого домашнього робота-пилососа — встановлюєте програму, скануєте QR-код, об’єднуєте свій пристрій з програмою, і керуєте ним. Прошивка при цьому оновлюється тільки після прив’язки пристрою до користувача.

У нашому випадку користувач намагається налаштувати свій пристрій і зазнає невдачі. Що могло піти не так з новим та перевіреним продуктом? Проблема полягала в тому, що з моменту випуску пристрою версії прошивки й мобільної програми могли змінитися. Зі свого боку, пристрій мав серійну версію прошивки й відтоді не оновлювався, бо не був онлайн і не був приєднаний до жодного користувача. Тож коли була встановлена остання версія застосунку з App Store чи Google Play — вона не працювала з вбудованою прошивкою.

Щоб тестувати подібні кейси, потрібно перевіряти, як мобільні застосунки працюють з усіма версіями прошивок масового виробництва. Подібний процес був запроваджений і нами для підвищення впевненості в якості продукту.

Фреймворки та інструменти автоматизації тестування

Одна з головних задач SDET-ів — розробляти нові фреймворки та інструменти. Якщо повернутися до випадку з прив’язкою пристрою до користувача — автоматизувати цей процес перевірки було непросто.

Щоб почати прив’язку, треба просканувати QR-код. Щоб це робити автоматично — було розроблено окрему програму, яка генерує QR-коди. Ми розміщуємо телефони один навпроти іншого, щоб можна було просканувати згенерований код. Після того як девайс успішно налаштований, треба впевнитися, що потокове відео передається у мобільний застосунок. Для цього перед пристроєм встановлюється напис «OK», і якщо вдається розпізнати слово — це є підтвердженням того, що налаштування пройшло успішно.

Для цього процесу були створені окремі лабораторії. До того ж всі ці пристрої та мобільні телефони перевикористовуються для різних тестів. А отже треба було створити багато інструментів і сервісів з нуля, щоб забезпечувати надійність та безперебійність автоматизованих тестів.

Це лиш один з багатьох прикладів необхідності у фреймворках та інструментах для автоматизації тестування.

Лабораторії та інфраструктура

Майже всі рішення в автоматизації в нашому випадку потребують фізичних лабораторій. Обладнання цих лабораторій потребує значних інвестицій. Тому важливо вміти правильно використовувати, розвивати та підтримувати їх.

В нашому випадку не існує повністю готових рішень, як от для управління мобільними телефонами або пристроями, які ми маємо у виробництві. У цьому випадку саме SDET-и відповідають за розробку та управління інфраструктурою лабораторій, а також створюють інструменти для моніторингу їхньої роботи.

Це необхідно, щоб бути впевненими, що сотні різних пристроїв справні та готові до перевірки або участі у будь-яких інших тестувальних активностях.

Дослідження та випробування

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

Наприклад, вам потрібно перевірити протокол зв’язку між мобільним телефоном і hardware-пристроєм. Іноді буває складно відтворити певні негативні сценарії та edge-кейси з фізичним обладнанням. Як це зробити? Ми мали схожу проблему і вирішили її, створивши власний емулятор hardware-пристрою. Відтак у нас з’явилась можливість перевіряти протокол зв’язку будь-яким способом, який нам потрібен.

Навчання та менторство

Продукт з яким ми працюємо — комплексний та прогресивний. Нам потрібно швидко розробляти та впроваджувати нову функціональність для користувачів. І це неминуче відображається в значному обсязі тестів. Щоб забезпечити потрібний рівень якості, реліз кожної нової версії застосунку займає тривалий час.

Автоматизоване тестування допомагає пришвидшити регресію, але для того, щоб воно приносило користь — потрібно забезпечити високе покриття тестів автоматизацією. В нашому випадку, ми ставимо певні критерії з покриття автоматизацією для кожної нової функціональності, що поставляється. Команди несуть відповідальність за якість, а значить і за автоматизацію.

Саме тому ми викладаємо автоматизацію тестування нашим інженерам. Це забезпечує набагато кращу комунікацію між командами SDET і QA, ніж ми мали 3 роки тому. Вони працюють над тест-кейсами, маючи на думці подальшу автоматизацію. А також — пишуть сценарії автоматизації тестування.

За останні два роки троє QA-спеціалістів підвищили свій технічний рівень та змогли змінити спеціалізацію на SDET. У них вже є глибоке знання про продукт та вони в контексті всіх процесів. Тож після здобуття технічних навичок, QA стають хорошими SDET-ми.

У зв’язку з цим виникає питання: яка різниця між роллю SDET, QA і QA Automation?

Куди подівся QA Automation

Багато SDET-ів починали як QA Automation або QA. Але у нас в компанії, наприклад, немає позиції QA Automation. Хто ж тоді автоматизує тести?

SDET-и дуже близькі до розробників, тому що основна їхня діяльність — це робота з кодом. Коли ви працюєте як SDET — ви повинні мати уявлення про те, як працює кожен з компонентів системи, як вони інтегруються і як вона функціонує в цілому. Треба вміти створювати нові системи, інструменти та фреймворки для автоматизації тестування.

В автоматизацію тестів залучені як QA, так і SDET-и. При цьому QA використовують готові рішення для написання тестових сценаріїв і автоматизації тестових кейсів. Своєю чергою сфера впливу SDET-ів знаходиться десь між SDE, QA та DevOps, оскільки вони більш сфокусовані на створенні та підтримці інфраструктури для автоматизації тестування.

Насамкінець

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

Мабуть, ніхто ще не прокидався рано вранці з мрією стати SDET-ом. Скоріш за все, це не ви обираєте цей шлях, а він обирає вас. Але завдяки йому ви отримуєте необмежені можливості впливати на розвиток продукту, здобуваєте нові знання та безперервно еволюціонуєте у технічному плані.