«Головне — зрозуміти основи, далі буде легше»: скільки мов програмування потрібно знати тестувальнику

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

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

На IT-конференції NIX MultiConf я розповідав про програмування як один із можливих інструментів для QA-інженера, а тепер готовий поділится своїм досвідом з читачами Highload.

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

Якщо я QA, то навіщо мені глибоко занурюватися в програмування?

Опанування будь-якої мови допоможе вам розібратися в усіх базових концептах програмування — змінних, типах даних, циклах, умовних операторах, об’єктах тощо.

Це чудова точка входу в автоматизацію тестування, а звідси — зовсім недалеко до складніших умінь на кшталт читання коду розробників.

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

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

Окей, але невже лише однієї мови вистачить?

Для старту — цілком. Коли ви повноцінно вивчите та зможете використовувати одну мову програмування, то можна і потрібно братися практично за будь-яку іншу.

Більшість мов створено за одним лекалом. Базові концепти скрізь однакові, відрізняється лише синтаксис та мінорні моменти. У будь-якій мові змінні залишаться змінними, цикли — циклами, а класи — класами.

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

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

Серед найпопулярніших сьогодні — Java, Python, JS, C#, а з найменш — Ruby та Groovy.

Якщо умовно намагатися оцінити їх потужність (наявність інструментів в рамках мови), популярність (що безпосередньо впливатиме на легкість знаходження відповідей на питання) і простоту використання, то може вийти приблизно такий графік:

Моя порада проста: беріть будь-яку мову, яка вам подобається, й опановуйте базу.

Коли QA може знадобитися знання ще однієї мови програмування?

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

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

Вимоги клієнта

Доволі часто клієнти просять, щоб автоматизація у їхніх проєктах виконувалася певною мовою. Причини можуть бути абсолютно будь-якими: від «Всі наші команди використовують цей фреймворк для автоматизації» до «Я чув, що цей фреймворк найкращий, і його точно треба спробувати». Звичайно, ви можете заперечити рішення замовника, але далеко не завжди це спрацює. В реальності доведеться адаптуватися під умови клієнта.

Специфіка проєкту

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

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

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

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

Крім цього, в проєкті можуть використовуватися специфічні технології, які не вдасться тестувати аби якою мовою. Наприклад, існує протокол передачі даних MQTT. Для простоти можемо назвати його аналогом HTTP, але з деякими обмовками та юз кейсамиUse Case описує сценарій взаємодії учасників (як правило — користувача та системи), специфічними для IoT.

Якщо вам знадобиться писати перформанс-тести для MQTT, то вам не підійде будь-який перформанс-інструмент. Доведеться брати один із популярних, у якому є необхідний інструментарій. Наприклад, для Jmeter є така бібліотека, нехай і з обмеженим функціоналом. Або ж можете використовувати один з інструментів, який створювався спеціально для тестування MQTT:

• MQTT stresser
• MQTT stress

В іншому випадку ви просто не зможете виконати поставлене перед вами завдання.

Особливі завдання

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

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

Необхідність читати девелоперський код

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

Головне — зрозуміти основи програмування. А далі будь-яку мову не важко буде вивчити

Програмування — це набір концептів. Як тільки ви їх опануєте, вам буде не складно «натягнути» на цей концепт конкретну імплементацію у вигляді мови програмування, бібліотеки або фреймворку. Це подібно до того, як ми вчимося кататися на велосипеді. Ось 5 хвилин тому ти ще ніяково, підштовхуючи себе ногою, намагаєшся на завалитися на бік, а зараз вже відносно жваво їдеш, намагаючись навчитися повертати, гальмувати та об’їжджати перехожих.

Знаєте це відчуття, коли вчишся-вчишся, і раптом все стає ясно і все виходить? У голові ніби щось клацає.

Буквально те саме сталося і з моїм умінням програмувати ще в університетські роки. Спочатку мені багато що давалося нелегко. У перший рік навчання на програмуванні я не розумів і половини з того, що мені казав викладач. Але згодом я перестав думати про те, «як їхати на велосипеді», й отримав можливість опановувати більш складні конструкції та вміння. Колись спершу хитромудра для мене теорія впорядкувалася і стала зрозумілою.

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

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

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