Загальне
Автоматизація тестування (test automation): Використання програмного забезпечення для здійснення або допомоги у проведенні певних тестових процесів, наприклад, управління тестуванням, проектування тестів, виконання тестів та перевірка результатів. (ISTQB)
Автоматизація виконання тестів (test execution automation): Використання програмного забезпечення (наприклад, засобів захоплення/відтворення) для контролю виконання тестів, порівняння отриманих результатів з еталонними, встановлення передумов тестів та інших функцій контролю тестування та організації звітів. (ISTQB)
Автоматизоване тестування (scripted testing): Виконання тестів, що реалізується за допомогою заздалегідь записаної послідовності тестів. (ISTQB)
Автоматизоване тестове забезпечення: тестове забезпечення, що використовується в автоматизованому тестуванні, наприклад, інструментальні сценарії. (ISTQB)
Автоматизований сценарій тестування (test script): Зазвичай використовується як синонім специфікації процедури тестування, зазвичай автоматизованої. (ISTQB)
Автоматизоване тестування (automated testing, test automation) – набір технік, підходів та інструментальних засобів, що дозволяє виключити людину з виконання деяких завдань у процесі тестування.
Багато завдань та дій, описаних в ІСО/МЕК/ІІЕР 29119-2 як процеси Менеджменту Тестування та Динамічного Тестування, а також багато аспектів методів тестування, представлені в ІСО/МЕК/ІІЕР 29119-4, можуть бути автоматизовані. Автоматизація тестування вимагає використання програмного забезпечення, яке зазвичай називають інструментами тестування.
Області застосування автоматизації :
Регресійне тестування : необхідність виконувати вручну тести, кількість яких неухильно зростає з кожним білдом, але вся суть яких зводиться до перевірки того факту, що функціональність, що раніше працювала, продовжує працювати коректно.
Інсталяційне тестування і налаштування тестового оточення : безліч рутинних операцій, що часто повторюються, з перевірки роботи інсталятора, розміщення файлів у файловій системі, вмісту конфігураційних файлів, реєстру і т.д. Підготовка програми у заданому середовищі та із заданими налаштуваннями для проведення основного тестування.
Конфігураційне тестування та тестування сумісності : виконання одних і тих же тест-кейсів на безлічі вхідних даних, під різними платформами та в різних умовах. Класичний приклад: є файл налаштувань, у ньому сто параметрів, кожен може набувати сто значень: існує 100 100 варіантів конфігураційного файлу – всі їх потрібно перевірити.
Використання комбінаторних технік тестування (в т.ч. доменного тестування): генерація комбінацій значень та багаторазове виконання тест-кейсів з використанням цих згенерованих комбінацій як вхідні дані.
Модульне тестування : перевірка коректності роботи атомарних ділянок коду та елементарних взаємодій таких ділянок коду – практично нездійсненне для людини завдання за умови, що потрібно виконати тисячі таких перевірок і ніде не помилитися.
Інтеграційне тестування : глибока перевірка взаємодії компонентів у ситуації, коли людині майже нема чого спостерігати, т.к. всі що представляють інтерес і піддаються тестуванню процеси проходять рівнях глибших, ніж інтерфейс.
Тестування безпеки : необхідність перевірки прав доступу, паролів за промовчанням, відкритих портів, уразливостей поточних версій і т.д., тобто. швидке виконання дуже великої кількості перевірок, у процесі якого не можна щось пропустити, забути чи не так зрозуміти.
Тестування продуктивності : створення навантаження з інтенсивністю та точністю, недоступною людині. Збір із високою швидкістю великого набору параметрів роботи програми. Аналіз великого обсягу даних із журналів роботи системи автоматизації.
Димовий тест для великих систем : виконання при отриманні кожного білду великої кількості досить простих для автоматизації тест-кейсів.
Програми (або їх частини) без графічного інтерфейсу : перевірка консольних програм на великих наборах значень параметрів командного рядка (та їх комбінацій). Перевірка додатків та його компонентів, взагалі призначених взаємодії з людиною (веб-сервіси, сервери, бібліотеки тощо.).
Довгі, рутинні, стомлюючі для людини та/або потребують підвищеної уваги операції : перевірки, що вимагають порівняння великих об'ємів даних, високої точності обчислень, обробки великої кількості розміщених по всьому дереву каталогів файлів, відчутно великого часу виконання і т.д. Особливо коли такі перевірки повторюються дуже часто.
Перевірка «внутрішньої функціональності» веб-додатків (посилань, доступності сторінок тощо): автоматизація гранично рутинних дій (наприклад, перевірити всі 30'000+ посилань на предмет того, що всі вони ведуть на реально існуючі сторінки). Автоматизація тут спрощується через стандартність завдання - існує багато готових рішень.
Стандартна, однотипна багатьох проектів функціональність : навіть висока складність при первинної автоматизації у разі окупиться рахунок простоти багаторазового використання отриманих рішень у різних проектах.
"Технічні завдання" : перевірки коректності протоколювання, роботи з базами даних, коректності пошуку, файлових операцій, коректності форматів та вмісту генерованих документів і т.д.
Переваги автоматизації:
Швидкість виконання тест-кейс може в рази і на порядки перевищувати можливості людини. Якщо уявити, що людині доведеться вручну звіряти кілька файлів розміром кілька десятків мегабайт кожен, оцінка часу ручного виконання стає лякає: місяці і навіть роки. При цьому 36 перевірок, що реалізуються в рамках димового тестування командними скриптами, виконуються менш як за п'ять секунд і вимагають від тестувальника лише однієї дії - запустити скрипт;
Відсутній вплив людського фактора у процесі виконання тест кейсів (втоми, неуважності тощо). Продовжимо приклад із попереднього пункту: яка ймовірність, що людина помилиться, порівнюючи (посимвольно!) навіть два звичайні тексти розміром у 100 сторінок кожен? А якщо таких текстів 10? 20? І перевірки потрібно повторювати щоразу? Можна сміливо стверджувати, що людина помилиться гарантовано. Автоматика не помилиться;
Засоби автоматизації здатні виконати тест-кейси, в принципі непосильні для людини через свою складність, швидкість або інші фактори. І знову наш приклад з порівнянням великих текстів є актуальним: ми не можемо дозволити собі витратити роки, раз-по-раз виконуючи вкрай складну рутинну операцію, в якій ми до того ж будемо гарантовано припускатися помилок. Іншим чудовим прикладом непосильних для людини тест-кейсів є дослідження продуктивності, в рамках якого необхідно з високою швидкістю виконувати певні дії та фіксувати значення широкого набору параметрів. Чи зможе людина, наприклад, сто разів на секунду вимірювати та записувати обсяг оперативної пам'яті, яку займає додаток? Ні. Автоматика зможе;
Засоби автоматизації здатні збирати, зберігати, аналізувати, агрегувати та представляти у зручній для сприйняття людиною формі колосальні обсяги даних. У нашому прикладі з димовим тестуванням "Конвертера файлів" обсяг даних, отриманий в результаті тестування, невеликий - його можна обробити вручну. Але якщо звернутись до реальних проектних ситуацій, журнали роботи систем автоматизованого тестування можуть займати десятки гігабайт за кожною ітерацією. Логічно, що людина не в змозі вручну проаналізувати такі обсяги даних, але правильно настроєне середовище автоматизації зробить це сама, надавши на вихід акуратні звіти в 2-3 сторінки, зручні графіки та таблиці, а також можливість занурюватися в деталі, переходячи від агрегованих даних до подробиці, якщо в цьому виникне необхідність;
Засоби автоматизації здатні виконувати низькорівневі дії із додатком, операційною системою, каналами передачі і т.д. В одному з попередніх пунктів ми згадували таке завдання, як «сто разів на секунду виміряти та записати обсяг оперативної пам'яті, яку займає додаток». Подібне завдання збору інформації про ресурси, що використовуються додатком, є класичним прикладом. Однак засоби автоматизації можуть не тільки збирати подібну інформацію, але і впливати на середовище виконання програми або саму програму, емулюючи типові події (наприклад, брак оперативної пам'яті або процесорного часу) і фіксуючи реакцію програми. Навіть якщо у тестувальника буде достатньо кваліфікації, щоб самостійно виконати такі операції,
Недоліки автоматизації:
Необхідність наявності висококваліфікованого персоналу через те що, що автоматизація - це «проект усередині проекту» (зі своїми вимогами, планами, кодом тощо.). Навіть якщо забути на мить про «проект усередині проекту», технічна кваліфікація працівників, які займаються автоматизацією, як правило, має бути відчутно вищою, ніж у їхніх колег, які займаються ручним тестуванням.
Розробка та супровід як самих автоматизованих тест-кейсів, так і всієї необхідної інфраструктури займає дуже багато часу. Ситуація посилюється тим, що в деяких випадках (при серйозних змінах у проекті або у разі помилок у стратегії) всю відповідну роботу доводиться виконувати наново з нуля: у разі відчутної зміни вимог, зміни технологічного домену, переробки інтерфейсів (як користувацьких, так і програмних) багато тест-кейси стають безнадійно застарілими і вимагають створення наново.
Автоматизація потребує більш ретельного планування та управління ризиками, т.к. в іншому випадку проекту може бути завдано серйозної шкоди (див. попередній пункт про переробку з нуля всіх напрацювань).
Комерційні засоби автоматизації коштують відчутно дорого, а наявні безкоштовні аналоги який завжди дозволяють ефективно вирішувати поставлені завдання. І тут ми знову змушені повернутися до питання помилок у плануванні: якщо спочатку набір технологій та засобів автоматизації було обрано неправильно, доведеться не лише переробляти всю роботу, а й купувати нові засоби автоматизації.
Засобів автоматизації дуже багато, що ускладнює проблему вибору того чи іншого засобу, ускладнює планування та визначення стратегії тестування, може спричинити додаткові тимчасові та фінансові витрати, а також необхідність навчання персоналу або найму відповідних фахівців.
Виходячи з перерахованого вище, існують** випадки, в яких автоматизація, швидше за все, призведе тільки до погіршення ситуації**. Коротко - це всі області, де потрібне людське мислення, і навіть певний перелік технологічних областей:
Планування, розробка тест-кейсів, написання звітів про дефекти, аналіз результатів тестування та звітність: комп'ютер поки що не навчився думати;
Функціональність, яку потрібно (досить) перевірити лише кілька разів, тест-кейси, які потрібно виконати лише кілька разів (якщо людина може їх виконати): витрати на автоматизацію не окупляться;
Низький рівень абстракції в інструментах автоматизації: доведеться писати дуже багато коду, що не тільки складно і довго, але і призводить до появи безлічі помилок у самих тест-кейсах.
Слабкі можливості засобу автоматизації щодо протоколювання процесу тестування та збору технічних даних про додаток та оточення: є ризик отримати дані у вигляді «щось десь зламалося», що не допомагає у діагностиці проблеми.
Низька стабільність вимог: доведеться багато переробляти, що у разі автоматизації обходиться дорожче, ніж у разі ручного тестування.
Складні комбінації великої кількості технологій: висока складність автоматизації, низька надійність тест-кейсів, висока складність оцінки трудовитрат та прогнозування ризиків.
Проблеми з плануванням і ручним тестуванням: автоматизація хаосу призводить до появи автоматизованого хаосу, але ще й вимагає трудовитрат. Спочатку варто вирішити наявні проблеми, а потім включатись в автоматизацію.
Нестача часу та загроза зриву термінів: автоматизація не дає миттєвих результатів. Спочатку вона лише споживає ресурси команди (зокрема час). Також є універсальний афоризм: «краще руками протестувати хоч щось, аніж автоматизовано протестувати нічого».
Області тестування, потребують оцінки ситуації людиною (тестування зручності використання, тестування доступності тощо.): у принципі, можна розробити деякі алгоритми, оцінюють ситуацію оскільки її міг би оцінити людина. Але на практиці жива людина може зробити це швидше, простіше, надійніше та дешевше.
Далі копіпаста різних запитань-відповідей із циклу статей на хабрі.
Навіщо потрібна автоматизація, якщо наші ручні випробувачі і так справляються?
Дійсно, перш ніж вводити автоматизацію на проекті, тому що це "стильно, модно, молодіжно", і у всіх воно є, варто врахувати такі фактори:
Як довго житиме проект, який його масштаб, наскільки сильно і часто він змінюється;
Оцінити, наскільки важко писати автотести в кожному конкретному випадку. Можливо, що автоматизувати ваш функціонал буде набагато складніше, довше та дорожче, ніж тестувати його руками;
Також, якщо на проекті очікується "випилюємо все старе і пишемо нове з нуля", час автотестів ще не настав.
Але якщо ваш проект:
стабільно розвивається та росте;
збільшується кількість розробників;
програма починає обростати новим функціоналом.
То прямо пропорційно почне збільшуватися час тестування. Рано чи пізно воно дійде до критичного моменту, коли регрес займатиме більше часу, ніж велася технологія. Це означає, що настав час задуматися про автоматизацію тестування.
Автотести стануть гарантією, що нічого зі старого не відвалилося, допоки розробники робили нові круті штуки. Особливо якщо ці нові штуки робилися в зовсім інших частинах коду. Ручні регреси, в даному випадку, це, звичайно, добре, але тут і людський фактор, і замилене око, і непередбачуваність місць, в яких можуть спливти баги. руками. Немає сенсу автоматизувати те, що, можливо, не злетить і вже через тиждень буде випиляно або відправлено на доопрацювання.
Але замість того, щоб займати ручного тестувальника написанням тест-кейсів на новий функціонал, підтримку документації та постійними регресами, можна виділити йому хоча б один день на тиждень на автоматизацію, допомогти на старті з налаштуваннями інфраструктури, і вже за кілька місяців у вас почнуть ганяти перші автотести, ваші завдання стануть в рази швидше доходити до релізів а заразом стане більше впевненості в стабільності коду, що випускається.
Ще автоматизований регрес дозволяє тестувальникам більше часу приділяти корисним завданням, наприклад, дослідницького тестування. Крім того, з'явиться найкраще розуміння, як працює додаток під капотом, що знадобиться навіть у ручному тестуванні.
Чи можна розпочати писати автотести за один день?
Писати автотести можна почати прямо в цей момент, але краще з цим не поспішати і підійти до питання осмислено.
Якщо на проекті ще не було автоматизації, то потрібно обов'язково розпочати з ресерчу існуючих інструментів, фреймворків, підходів. Почитати про те, з якими проблемами стикаються користувачі та як швидко вони вирішуються. Оцінити всі плюси і мінуси, вибрати найкраще, з чим буде легко і приємно працювати. Ціна помилки на старті набагато менша, ніж коли ви вже активно автоматизуєте і раптом розумієте, що вибраний вами фреймворк нікому не зручний і абсолютно вам не підходить.
Якщо ви ніколи раніше не займалися автотестами, спочатку може бути складно.. Непросто почати писати автотести відразу, якщо ще немає жодних прикладів і не на що спертися. Благо, зараз в інтернеті дуже багато різних статей з безліччю хороших прикладів коду, які можна брати, підлаштовувати під себе та розбиратися, як вони працюють.
Зрештою, щоби навчитися автоматизувати, треба просто почати автоматизувати. Це справді працює.
Ідеально, якщо з боку розробників будуть ті, хто готовий спочатку вам допомагати розбиратися в коді, відповідати на всі ваші питання. У hh саме так і було - спочатку, коли ми тільки починали писати свої перші автотести, ми просто завалювали наших хлопців усілякими питаннями. Завдяки їм ми й дійшли того, що маємо сьогодні
Але цілком можливо, що ваша команда не матиме часу допомагати вам з автотестами. На жаль, таке можливо, і не варто їх звинувачувати. Якщо ви потрапили в таку ситуацію, не засмучуйтесь! В інтернеті дуже потужне ком'юніті тестувальників. У тому самому телеграмі є чати, де 24/7 вам дадуть відповідь на всі питання і допоможуть розібратися.
Чи можна змусити розробників писати автотести?
Теоретично, звичайно можна. Але швидше за все вони будуть не дуже раді, та й навряд чи хтось буде радий у принципі.
По-перше, це сповільнить саму розробку. Замість того, щоб писати код, розробляти продуктовий функціонал, розробники займатимуться написанням автотестів.
По-друге, це дорого.
Ну і по-третє, у кожного має бути своя зона відповідальності. Розробники створюють функціонал, тестувальники – його перевіряють. З автотестами все так само, як і в звичайному тестуванні. Ось юніт-тести - так, зона відповідальності розробників, але UI - це вже тестування.
За фактом, це питання дорівнює "Навіщо нам тестувальники, якщо можна попросити розробників самим перевіряти те, що вони написали?"
Чи не уповільнюють автотести розробку?
Почнемо з того, що в першу чергу автотести потужно скорочують час на тестування та регреси, а значить допомагають випускати фічі в релізи швидше.
Але, дійсно, іноді вони підвищують час розробки. Наприклад, коли розробник змінює покритий автотестами функціонал, у зв'язку з чим доводиться перед мержем свого коду правити автотести, що падають.
Щоб це не ставало проблемою, при оцінці та декомпозиції завдання потрібно закладати час на можливі фікси автотестів. В ідеалі на таких зустрічах має бути тестувальник, який зможе сказати, які автотести можуть бути порушені новим функціоналом. Тоді час завдання буде передбачуваним і збільшиться.
Але щоби це нормально працювало, потрібно, щоб на проекті була стабільна інфраструктура, і автотести падали зі зрозумілих причин. Тоді розробникам не доведеться витрачати свій дорогоцінний час, щоб у кожному завданні розбиратися, через що саме впав автотест - через його код чи проблеми на тестовому стенді.
Чи можна писати 1 автотест одразу на обидві платформи?
Звичайно можна. Існують кросплатформові фреймворки, і багато їх використовують. Але ми одразу вибрали для себе нативні, як стабільніші, надійніші та легко підтримувані.
У чому основні проблеми кросплатформових фреймворків?
Це окремий код від вашої програми. Якщо вам знадобиться в ньому щось доопрацювати або налаштувати під себе, то доведеться йти до інших розробників, робити запити і чекати, доки вони зроблять і випустять це на своєму боці, що не завжди зручно та продуктивно. Часті проблеми при виході нових ОС та баги. Потрібно чекати на підтримку з боку розробників фреймворку, і це очікування дуже непередбачуване. Ви не знаєте, коли все виправлять та оптимізують, і коли воно у вас нарешті запрацює. Тобто, ви залежні від інших людей. Можливо, вибраний вами кросплатформовий фреймворк написаний мовою програмування, яка не знайома вашим розробникам. Тоді допомогу від них буде складніше, якщо вона вам раптом знадобиться. Також розробники у цьому випадку не зможуть писати та правити автотести самостійно.
Може здатися, що написати один кросплатформний автотест швидше і простіше, ніж два нативні. Але насправді це негаразд.
По-перше, весь “заощаджений” час надалі може піти на підтримку такого автотесту для двох платформ. Це може стати проблемою через оновлювану специфіку різних ОС. Крім того, часто поведінка однієї і тієї ж фічі або кнопки може відрізнятися для iOS та Android.
По-друге, якщо при виборі між кросплатформовим фреймворком та нативними, головним аргументом є “вивчити одну мову програмування простіше, ніж дві”, не поспішайте приймати рішення. Синтаксис мов Kotlin і Swift дуже схожі (принаймні у питаннях написання автотестів). Написавши автотест однією з мов, ви без праці напишете такий самий для другої платформи.
Коли автотести почнуть приносити більше користі, аніж проблем?
Рівно тоді, коли:
на вашому проекті буде налаштована стабільна інфраструктура,
автотести будуть вбудовані у ваш CI/CD, а не запускатися локально у когось, коли про їхнє існування згадали,
автотести будуть падати прийнятну для вас кількість разів, тобто не будуть флакувати.
Навіть якщо тестів зовсім небагато, але вони вже ганяються хоча б перед мержем гілки розробника, то це вже користь: мінус якась кількість ручних перевірок та гарантія того, що ваша програма як мінімум запускається.
За скільки місяців можна дійти до 100% покриття?
Питання 100% покриття - дуже слизьке. Не хочеться вдаватися в марні суперечки про те, чи існує воно взагалі і чи потрібно до нього прагнути. Але оскільки його ставлять дуже часто, давайте розбиратися.
По-перше, варто розглядати покриття кожної фічі окремо.
По-друге, глобально відповідь на питання "на скільки в тебе покрита ця фіча" буде ґрунтуватися на досвіді та знанні продукту тестувальника.
Оцінюючи покриття фічі, я розмірковую так:
всі позитивні перевірки – це 60-70% від усього покриття,
далі додаємо негативні перевірки (різні переривання, згортання-розгортання екранів, зероскрини тощо) - отримуємо 90%.
10% - це складновідтворювані сценарії, залежності від інших фічів і т.д., які покривати або взагалі не варто (подумайте, чи витримає таке навантаження ваш CI і чи варто того часу на підтримку таких автотестів), або залишати це на останню. черга. Також додам, що не всі фічі, в принципі, потрібно автоматизувати. Іноді трудовитрати на автоматизацію якоїсь неймовірно складної перевірки перебільшують можливість один раз перед релізом швидко перевірити її руками. Щоб не залишати питання менеджера без відповіді - виявляємо серед усієї функціональності програми найбільш критичний і в ньому дивимося, яку кількість позитивних та негативних перевірок нам потрібно автоматизувати насамперед, щоб бути впевненими, що функціонал працює.
Скільки потрібно тестувальників, щоби автоматизувати весь проект?
Розповім історію про автоматизацію мобільних додатків у hh.ru.
У різні періоди часу ми мали від 2 до 4 тестувальників на весь мобільний напрямок. Приблизно за рік ми дійшли практично повного покриття регресів на обидві платформи. І це з урахуванням того, що ми продовжували тестувати функціонал руками та проводити ручні регреси, а на андроїд двічі переїжджали на новий фреймворк. У результаті, до речі, ми зупинилися на Kaspresso, з яким тести стали сильно стабільнішими і простішими в написанні. Кожен переїзд був великим об'ємним рефакторингом, оскільки до того ми вже встигли написати якусь значну кількість автотестів. Проте за один рік регреси були автоматизовані.
Іншими словами, будь-якою кількістю тестувальників можна автоматизувати проект, якщо виділити на це достатньо часу. Але постає питання: як тестувальнику встигати і руками тестувати, і автотести писати? Іноді це справді складно. Особливо, якщо йде великий потік нового функціоналу, який терміново потрібно тестувати. Усім хочеться встигнути у реліз, і завданням ставлять більший пріоритет. Знайома ситуація. Що робити? Сідаємо. Розуміємо, що автотести в недалекому майбутньому принесуть нам максимум користі та виділяємо кожному тестувальнику, наприклад, один день на тиждень під автоматизацію. Ми таке практикуємо, коли у тестувальників завал із ручним тестуванням, і це працює. Для автоматизації можна вибрати день після релізу, коли нічого не горить, і тестувальник із чистою совістю може писати автотести, не відволікаючись інші завдання.
Як вам живеться з автоматизованими регресами?
За два роки, що ми живемо з автоматизованим регресом, у нас надійно устаканився тижневий реліз-трейн. Релізи регулярно вирушають у прод без проведення ручних регресів завдяки кількості, якості та, головне, довірі до автотестів.
Крім того, що автотести запускаються на релізних гілках, весь набір автотестів завжди проганяється на фіче-гілки розробників перед мерджем. У девелоп/майстер не допускається код, який упустив тести. Завдяки цьому ми підтримуємо стабільність девелопа, ми впевнені у ньому і можемо відрізати релізну гілку будь-якої миті.
Для тестувальника автоматизований регрес може означати більше вільного часу для важливіших і корисніших завдань - це, наприклад, написання нових автотестів, збільшення стабільності існуючих, розвиток свого напряму тощо круті завдання.
Чи багато часу витрачається на підтримку автотестів?
Підтримка автотестів убудована в наші процеси розробки. Як це працює – щотижня призначається черговий тестувальник, одним із завдань якого є стежити за стабільністю тестів. Якщо тест впав, черговий повинен розібратися внаслідок падіння та призначити відповідального на фікс. Якщо тест впав через власну нестабільність – завдання на тестувальника, якщо тест знайшов баг – на розробника, код якого вплинув на цей автотест. За досвідом, найчастіше це не займає багато часу – один тестувальник витрачає кілька годин на тиждень.
Більш складні завдання – розвиток, покращення та оптимізація, фікси інфраструктури. Такі завдання йдуть нарівні з розробкою продуктового функціоналу та мають відповідний флоу (проробка, декомпозиція, оцінка, розробка тощо). Це трапляється не надто часто, в середньому раз на квартал на кожну платформу. Тут важливо відзначити, що найчастіше це не найвищі пріоритетні завдання, і робляться вони, коли у команди з'являється на це ресурс.
Якщо все чітко налаштувати, навчитися працювати з тестами, що флакують, і по-максимуму їх не допускати, то підтримка автотестів займає мало часу і приносить багато користі.
Наскільки важко знайти мобільного автоматизатора?
Іноді складно знайти просто хорошого мобільного тестувальника з релевантним досвідом, а з досвідом автоматизації в конкретному стеку технологій справи ще складніші.
У мобільних командах hh.ru ми зазвичай шукаємо просто крутих ручних тестувальників, які хочуть розвиватися у бік автоматизації. Під час співбесід базові знання у програмуванні, звісно, є плюсом, але не вирішальним фактором. Автоматизації ми готові навчати себе. А ось що дійсно важливо - щоб людина прагнула розвиватися, вміла і хотіла навчатися і була проактивною в цих моментах. Звісно, складно точно визначити таке під час співбесід, але не зовсім неможливо.
Джерела:
Дод. матеріал:
Last updated