Чотири із п'яти претендентів-QA хочуть навчитися працювати з автотестами. Не всі компанії можуть здійснити такі бажання ручних випробувачів у робочий час. Wrike провів школу автоматизації для співробітників та реалізував це бажання для багатьох. Я в цій школі брав участь саме як учень-QA.
Я навчився працювати з Selenium і зараз самостійно підтримую певну кількість автотестів практично без допомоги ззовні. І, за підсумками нашого спільного досвіду та моїх особистих висновків, я постараюся вивести ту саму формулу якомога ідеальнішої школи автоматизації.
Досвід Wrike в організації школи
Коли необхідність у школі автоматизації стала зрозумілою, її організація лягла на Стаса Давидова, технічного ліда автоматизації. Хто як не може пояснити, навіщо придумали цю ініціативу, чи досягли результатів і чи не шкодують про витрачений час? Дамо йому слово:
— У 2016 році ми написали новий фреймворк для автотестів і зробили його таким, що тести стало легко писати: з'явилися нормальні степи, структура стала в рази зрозумілішою. У нас з'явилася ідея: потрібно залучити до написання нових тестів усіх, хто забажає, а щоб було простіше вникнути, створили серію лекцій. Ми колективно придумали план тим, кожен із майбутніх лекторів узяв собі одну і підготував доповідь.
— Якими були труднощі учнів?
— Здебільшого, звісно, архітектура. Було багато питань щодо структури наших тестів. У Фідбек багато писали на цю тему і нам довелося проводити додаткові лекції, щоб пояснити докладніше.
— Чи окупилася школа?
- Так, однозначно. Завдяки їй до написання тестів залучили купу людей, і в середньому по лікарні всі стали краще розуміти, що таке автотести, як їх пишуть і як вони запускаються. Також знизилося навантаження на автоматизаторів: нам тепер надходить у рази менше запитів на допомогу з розбором тестів, оскільки тестувальники та розробники стали з цим справлятися самі практично у всіх ситуаціях. Ну і кілька внутрішніх плюсів для відділу: набули досвіду у презентаціях та лекціях, завдяки чому деякі автоматизатори вже встигли зробити доповіді на конференціях, а також отримали потужний набір відео та презентацій для онбордингу новачків.
Від себе ж додам, що комунікація між нашими відділами спростилася до смішно легкого рівня. Наприклад, мені тепер практично не потрібно думати над тим, які кейси і з яким рівнем атомарності віддати на автоматизацію. Як результат, турбота про тестове покриття, що невпинно зростає, йде повною мірою з усіх зацікавлених сторін. Ніхто не потребує інших неможливого.
Загалом вплив на роботу команд — однозначно позитивний. Можливо, колеги, які читають цю статтю, теж замислюються про проведення чогось подібного? Тоді порада буде простою: воно того варте, якщо автотести для вас у пріоритеті. Далі поговоримо про складніше питання: як це все організувати максимально правильно, щоб витрати всіх сторін були мінімальними, а вихлоп — максимальним.
Поради щодо організації
Школа була корисною, але, як визнав Стас, були певні складнощі, через які довелося влаштовувати додаткові лекції. І саме як нещодавній студент, що навчився, порівнював себе-в-невіданні і себе-зараз, я сформулював наступні кроки зі створення ідеального, на мою думку, способу навчити тестувальників розбиратися з автотестами.
Крок 0. Створюємо словник
Звичайно, цей крок потрібен не лише QA. Тим не менш, я хочу його проговорити в явному вигляді: кодова база автоматизації повинна зберігатися у вигляді, що читається. Мови програмування – не в останню чергу саме мови, І з цього можна буде починати занурення.
Перед вами скріншот тасквю із назвами елементів. Припустимо, що ви займаєтеся тестуванням тасквью як чорної скриньки і в житті не бачили Selenium. Що робить цей код?
(Спойлер - через рест віддаляється таск від імені адміна, а потім ми дивимося, що в стримі залишився про це запис.)
Вже один крок дозволяє зблизити мови QAA і QA. Автоматизаторам простіше пояснювати результат прогону, ручним тестувальникам доводиться витрачати менше сил на складання кейсів: їх можна робити менш детальними. Все ж таки один одного розуміють. Ми отримали виграш ще до того, як розпочалося безпосередньо навчання.
Крок 1. Повторюємо фрази
Продовжимо паралель із мовою. Коли ми вчимося говорити у дитячому віці, ми не йдемо від етимології та семантики. Ми повторюємо «мама», «купи іграшку», але не ліземо відразу в праїндоєвропейське коріння цих слів. Так і тут: немає сенсу пірнати в глибину технічних особливостей роботи автотестів, не спробувавши написати щось робоче.
Звучить дещо контрінтуїтивно, зате працює.
На першому занятті варто дати базис у тому, як писати безпосередньо автотести. Допомагаємо налаштувати середовище розробки (в моєму випадку Intellij IDEA), пояснюємо той мінімум правил мови, який необхідний для написання ще одного методу в існуючому класі з використанням наявних кроків. Пишемо з ними один-два тести і даємо домашнє завдання, яке я оформив би так: гілка, відведена від майстра, але в ній видалено кілька тестів. Залишилися лише їхні описи. Просимо тестувальників відновити ці тести (не через show diff, звичайно).
За підсумками той, хто все послухав і зробив, зможе:
- навчитися працювати з інтерфейсом середовища розробки: створення гілок, хоткеї, комміти та пуші;
- освоїти ази структури мови та класів: куди вставляти інжекти, а куди імпорти, навіщо потрібні анотації і що там зустрічаються за символи, крім кроків;
- зрозуміти різницю між дією, очікуванням та перевіркою, де що використовувати;
- помітити відмінність автотестів і ручних перевірок: в автотестах можна смикнути той чи інший хендлер замість виконання дій через інтерфейс. Наприклад, відправити коментар безпосередньо на бекенд замість відкриття таскв'ю, виділення інпуту, набору тексту та натискання кнопки Send;
- сформулювати питання, на які будуть надані відповіді на наступному кроці.
Останній пункт дуже важливий. Ці відповіді легко можна дати заздалегідь, але це важливий принцип викладання: відповіді без сформульованих питань не запам'ятовуються і не застосовуються, коли, нарешті, будуть потрібні.
Ідеально буде, якщо в цей час автоматизатор з команди QA повісить на нього завдання з написанням парочки тестів на бою і дозволить підкомітуватись у свою гілку.
Чого давати не варто:
- Найбільш поглиблені знання функціоналу середовища розробки та самої мови програмування, які будуть потрібні лише за самостійної роботи з гілками. Не запам'ятається, доведеться пояснювати двічі-тричі, а ми дорожимо часом автоматизаторів, га? Приклади: вирішення конфліктів, додавання файлів у гіт, створення класів з нуля, робота із залежностями;
- все, що пов'язане з xpath. Серйозно. Про нього треба розповідати окремо, раз і дуже концентровано.
Крок 2. Придивляємось до граматики
Згадаймо скріншот з тасквью з кроку №0. У нас є степ під назвою checkCommentWithTextExists. Наш тестувальник уже розуміє, що цей степ робить і можна зазирнути всередину кроку і трохи його декомпозувати.
А всередині у нас таке:
onCommentBlock(userName).comment(expectedText).should(displayed());Де onCommentBlock - це
onCommonStreamPanel().commentBlock(userName);Тепер вчимо говорити не "купи іграшку", а "купи іграшку з магазину Дитячий світ, що стоїть у синій шафі на третій полиці зверху". Потрібно пояснити, що ми вказуємо на елемент послідовно, від великих елементів (стрим -> блок з коментарями від певної людини -> та частина цього блоку, де сидить заданий текст).
Ні, все ще час розповідати про xpath. Лише згадати коротко, що всі ці вказівки ними описуються і успадкування йде через них. Натомість треба розповісти про всі ці метчери та вейтери, вони ставляться саме до цього кроку і необхідні для розуміння того, що відбувається. Але не перевантажуйте: складніші асерти ваш студент зможе вивчити сам і пізніше. Швидше за все, повинно вистачити should, waitUntil, displayed();, exist();, not();.
Домашнє завдання очевидне: гілка, у якій видалено вміст кількох степів, які необхідні деякої кількості тестів. Нехай тестувальники їх відновлять і змусять прогін знову бути зеленим.
Додатково, якщо у команди тестувальника в роботі є не тільки нові фічі, але й деякі багфікси, можна попросити його написати відразу тести на ці баги і зарелізувати. Швидше за все, всі елементи вже описані, може бракувати лише пари-трійки степів. Це буде ідеальним тренуванням.
Крок 3. Повне занурення
Настільки повне, як це можливо для тестувальника, який збирається продовжувати виконувати свої прямі обов'язки. Нарешті потрібно розповісти про xpath.
Спочатку даємо зрозуміти, що всі ці на CommentBlock і comment описуються саме ними.
Разом:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Порядок оповідання дуже важливий. Спочатку беремо будь-який існуючий xpath і показуємо, як у вкладці elements знаходиться один і лише один елемент. Далі розповідаємо про структуру: коли потрібно використовувати WebElement, а коли потрібно створити окремий файл нового елемента. Це дозволить краще зрозуміти наслідування.
Потрібно явно проговорити, що окремий елемент це все тасквью, він містить дочірній елемент весь стрим, який містить дочірній елемент окремий коментар, і т.д. Дочірні елементи – всередині батьківських як на сторінці, так і в структурі фреймворку автотестів.
На цьому моменті аудиторія повинна була вже твердо зрозуміти, як вони успадковуються і що можна ввести після точки на CommentBlock. У цей момент пояснюємо всі оператори: /, //, ., [] та інше. У навантаження докидаємо знання про використання @class та інших необхідних речей.
Слухачі повинні зрозуміти, як перекладати xpath подібним чином. Щоб закріпити – правильно, хатко. Видаляємо опис елементів, нехай відновлять роботу тестів.
Чому саме такий шлях?
Ми не повинні перевантажити людину складними знаннями, але маємо пояснити все й одразу, а це непроста дилема. Даний шлях дозволить нам спочатку змусити слухачів ставити запитання і не розуміти щось і відповідати на них вже наступного моменту. Якщо розповісти про всю архітектуру, то на момент розбору теми степів чи xpath найважливіші частини її вже забудуться через свою незрозумілість.
Проте хтось із вас напевно зможе поділитися досвідом, як можна оптимізувати процес ще сильніше. Із задоволенням прочитаю у коментарях подібні пропозиції!
Джерело: habr.com