KDT на Selenide: як мануальники автоматизації вчилися

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

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

Довга передісторія: читайте мій попередній блог.

Коротка передісторія: я «виріс» на поточному проєкті від Trainee до Senior, довший час будучи на ньому єдиним Test Automation Engineer. Глобальна зміна UI в тестованому застосунку змусила переписувати половину фреймворку, але це також відкрило можливість перейти з чистого Selenium на Selenide і переглянути архітектуру.

Дисклеймер: замість словосполучення «команда Manual QC» я іноді вживатиму слово «дівчата». Це не гендерний стереотип, а наші проєктні реалії :)

Перші кроки. Bus factor як двигун прогресу

Що означає бути одним-однесеньким автоматизатором на проєкті? Не похворієш, не сходиш у відпустку без ноута, а ранок завжди починаєш не з кави, а зі щоденного аналізу звітів автотестів. Страшенний bus factor, двома словами. З іншого боку, робота Manual QC команди добре налагоджена, у ній не одна і не дві людини (хоча завжди треба більше), а QC Lead на ім’я Діана має неабияку експертизу та проактивність.

Першим і цілком логічним рішенням, яке запровадив мій попередник ще в доковідні часи, — на час відпустки делегувати аналіз автомейшн-репортів Діані. Керівник QC-команди занотовувала впалі тести та ймовірні причини, якщо це було пов’язано з новими фічами або появою дефектів.

Більше того, минулий TA Lead допоміг їй встановити automation framework локально і навчив перезапускати окремі тести — щоби пересвідчитися, чи кейс стабільно падає, чи то просто стався випадковий збій.

Повертаючись із відпустки, автоматизатор розгрібав накопичені проблеми. Такий підхід успішно працював кілька років, але був радше «костилем», аніж реальним усуненням bus factor. Хотілося більшого, а вибити кошти на другого TA Engineer було вкрай проблематично.

Мало-помалу виникла думка навчити аналізу репортів усю Manual QC-команду, тим більше це давало їм можливість закривати пунктики на performance review, пов’язані з концепцією автоматизації тестування. За нашими процесами, почергово одна людина з QC була відповідальною за спринт — от на неї і навісили додатковий обов’язок щодня переглядати звіти, незалежно від присутності автоматизаторів.

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

Вже за кілька місяців, коли кожна тестувальниця хоча би пару разів побула в ролі sprint master, стали помітні позитивні результати. Появу реальних дефектів і явні зміни очікуваного результату дівчата помічали майже завжди, а щодо нетривіальних проблем, зокрема на стороні мого фреймворку, зверталися з конструктивними запитаннями.

Цьому сприяли як якісно згенеровані кроки відтворення зі скриншотом у момент падіння, так і загальний фокус Manual QC-команди на story testing (тут варто зробити зауваження: у нас на проєкті обов’язки TA і QC чітко розподілені, і я не тестую нові фічі).

Таким чином, іноді мануальники могли визначити зміну expected result навіть швидше за мене, даючи цінну підказку. А за підозри багів ми співпрацювали: уточнивши в колег очікуваний та неочікуваний вплив недавно змерджаних stories, я підглядав у девелоперський код або логи застосунку і ділився спостереженнями — issues заносилися швидше, були якісніше описані і, як наслідок, швидше фіксилися.

До речі, про дефекти. Ще одним протокроком до пізнання автоматизації стала практика, щоби QC самостійно ставили статус Candidate / Not candidate на кожен свій занесений дефект — а я це переглядав і виправляв, пояснюючи, які є можливості фреймворку та чому щось потенційно може або не може бути покрито автотестом.

На періоди регресійного тестування або під час підготовки до релізу нового UI (див. передісторію) аналіз репортів скасовувався, щоби не перенавантажувати команду, але я дбав про підтримку документації і сам регулярно ділився статистикою та новинами з автоматизації. Загалом, ніхто з дівчат не нарікав на поверхове залучення в Automation — навпаки, відчували зацікавленість у новому досвіді.

Кілька колег навіть зверталися до мене з бажанням якщо не перекваліфікуватися в автоматизаторів, то хоча би глибше познайомитися зі спеціалізацією. Це було трохи несподівано, але приємно. «Дай може мені щось почитати, або попробувати» — ну що ж, я дав книжку «Head First Java», пояснивши, що TA Engineer — це програміст, і без знання мови проєкту далеко не зайдеш.

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

«А я нічого не зламаю?». Дотик до коду

У якийсь момент в нашій system under test появилася нова фіча — попередження про прийдешній реліз. Вона працювала так, що фронтенд слав запит на бекенд, звідки отримував дату наступного downtime і за потреби показував повідомлення (або блокував застосунок, якщо реліз іде прямо зараз).

Звучить ніби добре, але з точки зору тестування з’явилася залежність: доводилося кожен раз просити девелоперів наконфігурувати потрібну дату релізу — і потім нікуди не відволікатися, аби не проґавити граничні моменти, коли повідомлення міняє свій стан.

Для автотестів це взагалі жах, оскільки часто popup залишався на ніч і заважав клікати на деякі кнопки, ламав скриншоти, а то й усе блокував, якщо його забули вчасно прибрати. У QC чаті почастішали повідомлення на кшталт «Увага, нині з 14 по 15 годину стейджинг буде недоступний — тестую maintenance notification».

У зв’язку з цим у мене виникло нестримне бажання придумати, як же викликати цей maintenance popup локально, не чіпаючи загальні конфігурації тестового середовища і не заважаючи один одному. Тоді я вже активно користувався Selenium 4 DevTools, тож спало на думку підробити відповідь бекенду, встановлюючи потрібну дату релізу. Сказано — зроблено, і невдовзі набір автотестів поповнився кейсами на цю фічу.

З іншого боку залишилася частина сценаріїв, які вимагали саме ручного тестування — тож я став думати, як доставити своє рішення, гордо назване «MaintenanceMocker», решті команди тестувальників. Виконуваний файл? Консольна Java-аплікація? Просто для користування, але як оновлювати? Напрошується Git, тим паче мануальники трошки вміють з ним працювати... Стоп, а нащо розробляти і підтримувати окремий продукт, якщо можна просто поділитися всім automation framework?

Так поміркувавши, я створив окремий клас, призначений суто для запуску браузера з нашим застосунком у режимі симуляції техобслуговування. Усі можливі конфігурації виніс у поля-константи. Тепер треба колегам надати доступи до репозиторію, поставити Java, IDE, навчити змінювати параметри і власне запускати MaintenanceMocker. Першим же запитанням, яке пролунало, було:

— Ой, а я тут тобі нічого не поламаю?

— Мені не поламаєш, я даю лише read доступ.

— А якщо я дуже сильно затуплю і щось не те наклікаю?

— Ну, максимум — завісиш собі комп’ютер. Але це треба дуже постаратися, тож слухайте, як робити правильно...

Щоби вгамувати страх «начудити», я першим ділом навчив колег команді git reset --hard та пояснив за важливість постійно синхронізуватися з master. На код вони дивилися, як на древні манускрипти, а коли автоматизований Chrome відкривав нашу апку з потрібним popup — вбачали у цьому сущу магію. «Вітаю, тепер ви на один крок ближче до того, щоби стати автоматизаторами!».

Перехід на Keyword-Driven Testing

Поки на етапах feature testing дівчата допомагали з аналізом звітів автотестування, а під час регресій бавилися з IDE — на проєкті назрівала глобальна зміна користувацького інтерфейсу. Потреба щось робити із сотнями й тисячами UI-автотестів нависла дамокловим мечем, і я вирішив, що це унікальна нагода переглянути архітектуру фреймворку та перейти з чистого Selenium на Selenide.

Хотілося, щоби тести виглядали елегантно і читалися, як такі собі steps to reproduce. Крім власного перфекціоністського задоволення, це би суттєво знизило потенційний поріг входу у фреймворк (нагадаю: я досі працював один, але не полишав надії на найм напарника-автоматизатора); також було не зайвим підняти maintainability і таке інше, щоби підтримка наявного рішення часом не відбирала цілий день.

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

Напевно, якщо би умовний індус з умовної аутсорс-контори почув би ідею залучати «нетехнічних» людей до Test Automation, він би одразу почав впарювати клієнтам умовний Cucumber. На щастя, така доля обійшла наш проєкт стороною: навіть коли б я вважав Gherkin-запис такою собі «чарівною паличкою», будувати додатковий шар абстракції для обробки всіх цих natural language команд не було жодного натхнення.

Натомість я зробив ставку на те, що спершу прозвав «псевдо-BDD», а потім виявилося, що таке зазвичай йменується KDD або KDT (Keyword-Driven Development/Testing). Суть у тому, щоби записувати тест ланцюжком команд, які мають зрозумілі стандартизовані назви, наприклад:

new HomeBL().checkDefaultState()
    .getHeader()
    .clickSignInButton()
    .login(myUser)
    .checkSuccessfulLogin();

Методи бізнес-логіки, у свою чергу, складаються із простих методів PageObject’ів і більш складної обробки, де потрібно. Крім того, вони повертають this або ту сторінку, на яку користувач переходить — так званий Fluent Interface.

public HomeBL checkDefaultState() {
   homePage.checkLogoIsVisible()
      .checkSearchBoxIsEnabled();
   checkLocalizedWelcomeBanner(currentTarget);
   return this;
}

public SignInBL clickSignInButton() {
    checkAnonymousUserView();
    headerPage.getSignInButton().click()
    return new SignInBL().checkDefaultState();
}

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

Можна запитати: до чого тут Selenide? І справді, використовувати саме його зовсім не обов’язково — просто його будова теж заохочує інженера вживати читабельні ланцюжки команд. І вбудовані очікування дозволяють уникнути маси «костилів» порівняно з чистим Selenium. Тобто Selenide добре вкладається в задану концепцію, хоча не бачу перешкод розробляти подібну архітектуру з тим самим Playwright чи будь-яким іншим інструментом.

Звісно, суворий поділ фреймворку за шарами сам собою не гарантує підйому readability-maintainability-stability та інших ...ability — але доповнений наявністю чітких code conventions, розумним поділом сторінок на компоненти і, найголовніше, відсутністю «біганини» та фантастичних очікувань з боку замовника, утворив красиве й ефективне рішення з автоматизації тестування.

Запрягайте, дівчата, коні...

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

«Здається, якраз час готуватися до Secret Santa...» — чув менеджер не з одних вуст. Для мене чудовим дарунком «від Миколая» була новина, що з нового року є шанси нарешті найняти помічника-автоматизатора. Але найбільший новорічний сюрприз приготувала Діана, запропонувавши провести повноцінний Test Automation курс для тестувальників на проєкті — з тим, щоби вони не просто «закрили пункти» на performance review, а реально в міру можливостей мені допомагали (а точніше, вивели цю поміч на кардинально новий рівень).

Досі я згадував колег як абстрактну Manual QC команду, але зараз познайомлю читача з ними поіменно. Крім ліда Діани, штат тестерів складався з Іри, Іринки й Оленки — їм і належало спробувати свої сили у ще не розробленому, але багатообіцяючому курсі.

Іра, зокрема, була серед тих, хто цікавився автоматизацією ще давніше; а Іринці з Оленкою дуже подобалися вже наявні елементи TA у регулярних процесах — тож умовляти не довелося. Також хочу згадати і передати привіт QC-колегам, що покинули наш проєкт до початку цього масштабного курсу: Юля, Марта, Марія, Олена — ми вас не забуваємо і були раді співпрацювати;)

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

Імовірно, добірка була спрямована на QC, що опинилися на бенчі і мали вдосталь вільного часу — а мені було потрібно «не спугнути» і дати можливість пошвидше конвертувати набуті знання на користь проєкту. Отже, з усього букету онлайн-курсів я вибрав один найкоротший — «Java for Testers» на 6 годин, та й із нього викинув пару фрагментів, неактуальних для нашого фреймворку.

За мету задуманого курсу, згодом названого «Test Automation для Manual QC на [нашому проєкті]», я в жодному разі не ставив повноцінну перекваліфікацію на автоматизаторів. Натомість, ідея полягала в залученні дівчат лише на найвищий рівень automation framework’у — рівень тестів, де вони би змогли реалізувати тестові сценарії вже готовими методами бізнес-логіки та нижчих рівнів.

Оскільки міграція зі старого UI на новий активно тривала, це мало би надзвичайну користь: поки TA Engineers розробляють «фундамент» фреймворку, помічники з QC можуть переносити старі тести або покривати свіжі дефекти.

Отже, єдиною перешкодою лишалася потреба вивчити основи Java, і це брав на себе обраний third-party курс, який я розділив на кілька частин. Ми призначили щоп’ятничні зустрічі, на яких проговорювали незрозумілі моменти і дивилися, де ті чи інші конструкції Java використовуються в нашому рішенні автоматизації.

Оскільки записаний лектор давав домашні завдання і наступним же уроком їх розбирав, я часом вигадував додаткові домашки, з фокусом на те, що вважав актуальним. Весело дивитися ці записи на швидкості x2, а потім слухати скарги про те, «як він швидко все робить, я ставила на х0.75 і ледве встигала!». І дівчата, і в якомусь плані я уявляли себе знову студентами — а найнезвичніше було спостерігати, як досвідчена керівниця Діана з багаторічним досвідом теж виступає в ролі учениці.

Не обійшлося й без вікторин на базі Kahoot, у які я обов’язково додавав кілька жартівливих запитань або варіантів відповідей.

Скажу відверто: основи Java йшли не надто легко, новоспечені програмісти довго вчилися розуміти фрази на кшталт «оголоси змінну», «створи об’єкт», «викликай метод», «передай параметр», «зайди в тіло методу». Швидше за все засвоїли «створи новий клас». Одного разу я навіть застукав учениць за списуванням: біля Іринчиного стола стояла Backend Dev Аліна і допомагала подругам із домашкою:)

До слова, ми звикли регулярно бувати в офісі — тож більшість навчальних зустрічей відбувалися офлайн у великій meeting room, яка певно ще з часів ковіду простоювала без діла. Не обходилося і без спокус скасувати чергове заняття, «бо ми зовсім не готові» — але я приймав лише аргументи щодо підготовки до релізів, а в решті випадків знаходив, що розібрати під час уроку; якщо ж хтось пропускав — записи в поміч.

За півтора місяця дівчата опанували готовий Java-курс — і тепер я брав лекторство на себе. Можна би було знайти ще якісь матеріали про власне ази автоматизації і таке інше, але я вирішив дати лише головне, без зайвої «водички».

Протягом двох чи трьох уроків ми писали мікро-фреймворк для тестування Duck Duck Go Calculator, в якому я показав спрощену концепцію багатошарової архітектури, поверхнево пояснив селектори, дав відчути різницю Selenium і Selenide та майже випадково продемонстрував нюанси кросбраузерних тестів (головна сторінка пошукової системи відображалася по-різному у Chrome та Firefox).

Тут «студенти» відчули себе значно впевненіше, і накопичена боязнь складності чистої Java поступово розвіялася. Ще б пак: коли ти вперше щось написав своїми руками, а воно працює, і ти бачиш, як воно працює (піднімає браузер і тицяє кнопки) — sense of accomplishment сягає висоти Говерли.

Велкам ту продакшн!

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

Я перелопатив беклог дефектів зі статусом Candidate for Automation і обрав кілька простих, що можна було покрити без розширення бізнес-логіки, тобто не спускаючись з рівня тестів. Детально показавши в режимі live coding процес автоматизації одного з них, я зробив pull request і сам собі його порев’ювив, роз’яснюючи весь процес від коміту до merge.

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

Одній версії нового тесту пощасливилося потрапити в master, а решту пул ріквестів я попросив відкликати із коментарем «nice job!». Невдовзі за графіком проранилися деякі набори тестів, і у звітах ми знайшли й щойно доданий кейс. Радості дівчат не було меж, а переможний Іринчин вигук «хей!» оголосив ледь не весь поверх.

Відтепер я до кожного заняття добирав дефекти на покриття (кожному свій, як домашку), а під час зустрічей ми проговорювали виниклі труднощі та проводили ревью. Чимало вкладався у якісну постановку задачі: у тікеті прописував нюанси реалізації, давав підказки по типу де знайти подібне, а часом товсто натякав на використання якогось конкретного методу з бізнес-логіки.

Почастішали звернення до мене поза плановими зустрічами, адже всім хотілося приходити на синки вже готовими, показувати результат роботи, а не оце школярське «я не зрозуміла, тому не зробила». Отримавши за рік до того досвід викладання старшокласникам, я думав: як же класно тепер працювати зі вмотивованими дорослими людьми, які проактивно ставлять запитання і не діють «на відчепись».

Постановка процесу «на рейки» дозволила перейти від щотижневих зустрічей до синхронізацій раз на два тижні — за цей період не проблема дівчатам знайти годинку-дві-три на написання тесту, а мені — на перегляд pull requests.

Гіпотеза про KDT як ключ до успіху справджувалася, значною мірою завдяки IDE: створивши об’єкт бізнес-логіки тої сторінки, із якої починається тест, інженер просто ставить крапочку — і бачить усі можливі методи взаємодії. Треба щось перевірити? Крапочка-check — й ось тобі асерти. Натиснути на кнопку? Крапочка-click — вибирай. Перейти на header, footer чи іншу компоненту? Крапочка-get, ...getFooterBL().clickNextButton() — і ось ти вже на наступній сторінці, можеш продовжувати ланцюжок.

Щось більш специфічне? Став крапочку і шукай, а краще спробуй почати писати логічну назву потрібної дії — і ось IDE все підказує.

Якщо на початку курсу я міг жартома процитувати свого професора: «Не чую захоплених вигуків!» (коронна фраза після начитки дуже складного матеріалу), то тепер бурхливе вираження радості від працюючих автотестів стало настільки частим, що девелопери часом запитували колег-QC: «Чого ти така весела?». Особливо приємним для дівчат було покривати ті дефекти, які вони самі й заносили — або ж свіжі, що запам’яталися з найближчого релізу.

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

Оленка поводилася більш обережно, чітко слідуючи інструкціям і перепитуючи на всякий випадок — та чимраз ставала все впевненішою. Найскладніше, здавалося, було Ірі: вона через певні обставини пропустила кілька зустрічей з поданням матеріалу — і силилася це наздогнати. Але не встиг я подумати про проведення додаткових уроків для неї, як Іра мене здивувала, зробивши одним махом три завдання. «Навесні трохи часу не було: малий, школа, все таке... а зараз я сіла, зі всім розібралася — слухай, так класно, все вдається. Давно хотіла навчитися!».

Випускний

Задуманий курс добіг кінця, тож було доречно подумати про якесь урочисте підбиття підсумків. Ще взимку я розробив і замовив авторські брелки із символікою TAQC, один одразу почепив собі на рюкзак — і з нетерпінням чекав моменту, коли вручатиму такі самі колегам. Цілком природньо захотілося завершити курс не абияк, а саме у форматі випускного вечора: з екзаменом, дипломами, випивкою і всім належним. Тільки Діана в більшості знала про мій намір, а для решти «призи на пам’ять» мали стати сюрпризом.

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

Тому-то я вирішив не замовляти дипломи, а надрукувати їх самостійно. «Спіймавши» день, коли всі QC працювали онлайн, я поліз у шафу, перерив там усе — і знайшов якийсь тиснений блакитний картон, що ідеально підходив для саморобних дипломів. Коли ж запрацював давно забутий принтер, колеги-розробники аж здригнулися: «Ай, блін, це ти друкуєш? Я вже думав, кацапський дрон летить!».

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

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

Завдання містили локальний запуск автотестів, пошук конкретного кейсу за звітами, просте виправлення тесту (який я напередодні цілеспрямовано зламав) і розповідь про свої досягнення в покритті дефектів. «Коли перездача по талонах?» — самокритично запитала Оленка. «Йду писати шпаргалки!» — пожартувала Іринка.

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

Ще одним сюрпризом стали запрошені гості, наші колишні тиммейти. Завітали до мітінг-руми і розробники: Аліна, в якої дівчата одного разу «списували», і Володя — завсідник офісу, що був постійним спостерігачем наших занять і інколи ледь не за вуха тягнув нас, охоплених азартом і втративших відчуття часу, на обід. Розпочався залік.

Попри гучну назву, сам «залік» мав бути максимально ненапруженим, тож я офіційно дозволив користуватися всім, а коли стало трохи нудно, включив легеньку музику. Метою було не перевірити знання (які я і так бачив), а показати колегам-глядачам, чим ми весь цей час займалися, і що це було не дарма. Оленчине побоювання талонів виявилося марним — «здали» всі.

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

Результати, підсумки та наслідки

Якщо читач раптом подумав, що випускним вечором усе і завершилося — то це далеко не так. Навпаки, все тільки почалося! Я продовжую тісну співпрацю з командою мануальників, яких тепер можна, мабуть, гордо називати General QA.

Щодватижні кожна з дівчат автоматизує по тесту (коли ж найде натхнення — то й по два-три), а я тримаю наповненим беклог і радо допомагаю. Як і протягом курсу, надалі маємо регулярні зідзвони з обговоренням написаних автотестів, а в разі потреби й індивідуальний knowledge sharing. Все, чому ми вчилися, гарно інтегрувалося у проєктні процеси. Дівчата задоволені, я також.

Що цей курс дав мені особисто і автоматизації тестування на проєкті загалом? Щонайменше, це суттєве зниження bus factor: навчені QC можуть самостійно (чи спільним розумом) дати раду зі звітами автотестування та навіть виправити нескладні помилки — тож у відпустки можу йти зі спокійною совістю.

Проєкт тепер має стабільний приріст автотестів, причому саме в напрямку покриття критичних дефектів — працюючи сам, я частенько не мав це пріоритетом, фокусуючись на підтримці наявного і переносі його на новий UI.

Може виникнути слушне запитання: а чи не витратив я на курс стільки часу, що міг би натомість сам покрити ці дефекти? Що ж, це гра в довгу — і я вже отримую віддачу вкладених зусиль. Крім того, для спокушеного автоматизатора написання чергового тесту по steps to reproduce — це справа доволі нудна, чого не скажеш про колишніх мануальників.

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

Вмотивований працівник — працівник ефективний. Чого-чого, а sense of accomplishment нам з дівчатами вистачає: коли я дивлюся на їхні успіхи, а вони — на свої, ми відчуваємо кайф від усього проробленого. Якщо ж говорити про речі більш матеріальні та заземлені, то набуті вміння, заточені під потреби проєкту, дають непогані аргументи для збереження робочого місця у нинішні бурхливі часи. Навіть якби, не дай Боже, комусь довелося шукати нову роботу — неординарний досвід дозволить яскраво виділитися на фоні інших кандидатів.

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

Будемо раді, якщо наш досвід підштовхне когось до дії — і в наступному зарплатному опитуванні DOU побільшає QC, що володіють мовами програмування ;) Але навіть якщо цей блог стане лише байкою для обговорення за кавою, звертаюся до вас: мануальники, вірте у свої сили та не бійтеся коду!