Хто ти — Automation Engineer чи SDET? І чи справді автоматизатори більше не потрібні

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

Всім привіт і Слава Україні! Я SDET lead в продуктовій компанії Corva. Працював у великих аутсорсах, аутстафах і трохи в консалтингу, отже бачив різні команди і різні підходи щодо автоматизації тестування. Відтак у мене сформувалося своє бачення цих посад, щодо яких я і пропоную подискутувати.

Disclaimer: моє бачення — то є моє бачення, яке не претендує на істину в останній інстанції, але заохочує на диспут, адже тільки так можна докопатися до тієї самої істини. Також мої висновки базуються на моєму досвіді та досвіді моїх знайомих, тож конкретно твоя думка, друже, може кардинально відрізнятися від моєї, і це нормально :)

Хто такий автоматизатор тестування в принципі зрозуміло, а ось що то таке SDET — вже не зовсім. Принаймні тому, що, погугливши саме англомовні джерела, я знайшов багато різних трактувань і всі вони були досить різними. І, так, моя думка, що автоматизатори не потрібні. Але «не всьо так однозначно». Тому почекайте кидати помідори і давайте розбиратися.

Test Automation Engineer

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

Але тут важливий досвід саме UI автоматизації і способи розв’язання типових проблем, на кшталт правильно дочекатися елемента чи ввести текст так, щоб не зникали літери. Звичайно, треба ще побудувати automation solution.

Найімовірніше там будуть page objects в якомусь вигляді і, можливо, на цьому все. Дуже просте рішення з купою наслідування, яке на дистанції призводить до того, що щось зробити неможливо, або дуже довго через обмеження дизайну рішення, крім того, щось постійно не працює і зелені джоби — то свято. Фіксиш в одному місці — падає в іншому. У кого ніколи не було такого досвіду — поділіться своєю історією :)

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

То хто ж буде починати? Девелопер? Ні, в нього купа роботи, йому деліверити треба, он мануальщик сидить без діла, нехай він і зробить. Мануальщик без досвіду (або з дуже малим досвідом «для себе з цікавості») в програмуванні і автоматизації з радістю кидається в бій, менеджери отримують результат, який їм подобається, наймаються ще люди. Але основа, закладена тим самим мануальником, виявляється не дуже гарною і тому потрібно все більше і більше людей на підтримку і все це перетворюється на величезну снігову кулю.

Мій перший проєкт з автоматизації починався приблизно так само, і навіть люди, яких брали потім, не мали серйозного досвіду з JS (на якому був написаний проєкт). Тоді тільки з’явився ES6 і я пам’ятаю натхненні розмови типу «я знаю різницю між map та forEach!». То були цікаві часи :) Поділіться своїм першим досвідом в автоматизації, дуже цікаво!

Як підсумок такого підходу маємо багато автоматизаторів, багато автоматизованих тестів, одну, або декілька людей, які займаються виключно підтримкою, і нескінченно довгі джоби. Звичайно, такий підхід комусь вигідний, тому що треба багато людей і у проєкту є декілька «крутих», але не зовсім правильних метрик у вигляді кількості тестів і покриття авто тестами мануальних кейсів.

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

Software Development Engineer in Test (SDET)

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

З назви посади зрозуміло, що навички такого спеціаліста мають починатися в першу чергу саме в програмуванні і спрямовані на автоматичні тести. Це означає, що спеціаліст може сам визначити, до якого рівня піраміди тестування відноситься тест і сам його імплементувати, лишаючи UI рівню мінімальну кількість end-to-end flow.

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

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

Також в обов’язки входить зміна коду додатка, якщо його неможливо або дуже складно протестувати. Якщо у нас вже є такі навички, то додати собі локатори у front-end коді не викликає труднощів.

У мене було інтерв’ю, де front-end девелопер попросив мене написати складний локатор. Я сказав, що навіть не буду з цим морочитися, а просто зроблю собі зручний тестовий id в потрібному місці. Інтерв’юер відповів, що мої шанси на офер значно зросли. Насправді, саме це — досить простий скіл, який значно спрощує написання тестів і це кратно швидше і простіше, ніж просити девелоперів ставити локатори.

А тепер перейдемо до складніших речей, а саме дизайн-архітектури automation solution. Чим він простіший (тільки page objects на наслідуванні) тим, на жаль, менше можливостей і більша складність у підтримці. А задля того, щоб зробити гнучку систему, яку буде легко підтримувати та розширювати, треба мати добрі навички в програмуванні. Ну, і позаяк SDET — це повноцінний розробник, то він має вирішувати будь-які задачі, пов’язані з тестуванням без обмежень.

Необхідні навички: знання та досвід мануального тестування, знання і розуміння мови програмування на рівні «девелопери звертаються по допомогу», знання і вміння правильно застосувати патерни програмування, вміння писати код так, щоб його розуміли джуни, досвід автоматизації тестування, розуміння front-end/back-end технологій на рівні «можу писати юніт тести та фіксити баги».

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

Підсумки

1. Задача автоматизатора — написати якомога більше автотестів, тоді як задача SDET — написати якомога менше тестів, але так, щоб вони принесли якнайбільше користі.
2. Одного разу на співбесіді кандидат на позицію senior сказав, що якби він знав відповіді на мої питання, то був би розробником.
3. Наразі на українському ринку для SDET роботи менше, бо і коштує такий спеціаліст більше і, знов-таки, багато кому треба просто накидувати тестів.
4. І відповідь на головне питання: навряд чи професія автоматизатора колись зникне, але частка SDET буде поступово зростати. В Україні це зростання може бути трохи швидшим за умови вектора розвитку ринку в продукт.

Порівняльна таблиця

На додачу

Мене часто запитують про кількість тестів і мені цікаво, що дає ця метрика. Бо можна написати один е2е тест, який розріже весь додаток і буде мати велике value, а можна наплодити 100500 тестів, які будуть перевіряти, що елементи є на сторінці, або щось типу того.

Які метрики ви збираєте і вважаєте доцільними? Прошу у коментарі :)

Ще чув, що є окремі позиції TestOps. Хто на такій працює, розкажіть про себе :)

Дякую, що дочитали, все буде Україна!