High Tech — Low Test. Проблеми сучасного тестування і як їх позбутися

Усім привіт, мене звати Олександр. Я працюю у сферах тестування, автоматизації та розробки вже трохи понад 10 років. За цей час я бачив різне: аутсорс та аутстаф проєкти, великі продуктові компанії та банки. Я був тест-інженером та автоматизатором, був SDET’ом, керівником команди інженерів та розробником.

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

Усвідомлення цих проблем — перший крок до їх вирішення. Я певний, що разом ми зможемо підняти рівень тестування, автоматизації та якості на ще вищий рівень! Україна переможе!

Дисклеймери:

1. Стаття висловлює тільки мої персональні погляди, а не погляди мого роботодавця.
2. Стаття опирається тільки на мій досвід та досвід, отриманий від спілкування з іншими спеціалістами в індустрії.
3. Існує ненульова ймовірність, що описані у статті проблеми зовсім вас не стосуються: у вас є ідеальний проєкт, чудові стосунки з колегами та й взагалі, світ магії та чаклунства. В такому випадку — гайда у коментарі ділитися своїм досвідом!

Photo by Jeremy Bezanger on Unsplash

Що змінилося в індустрії за 10 років

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

Від Waterfall моделі практично усі перейшли до Agile та Scrum.

Від великих та дуже дорогих комбайнів для написання автотестів ми перейшли до невеликих, гнучких, а найголовніше — безплатних бібліотек та інструментів.

Починаючи з автотестів — закінчуючи репортинг системами та паралельним запуском тестів у докері чи навіть десь далеко «у хмарах».

Але разом з тим, багато речей і тверджень залишилися без змін.

Ось деякі з «вічних» тем, що постійно вирують у середовищі тестувальників:

• «Ручне тестування померло!»
• «Давайте все завтоматизуємо! Через UI — то найкраще!»
• «SDET — то є вершина еволюції тест інженера! Хочу бути як у Гуглі!»
• «Та я один рік трошки попрацюю у тестуванні, а потім піду у розробку. Бо відразу у розробку мене не взяли.»
• «Заробітна плата у тестувальників — на самому дні!»
• «Test engineering — то робота для низькокваліфікованих спеціалістів!»

Як бачите, основною темою так чи інакше є низькі зарплати та відсутність перспектив.

Але чому склалася така ситуація в індустрії? Чи може бути, що проблеми дещо в іншому? Які все ж таки проблеми бачу я?

Проблеми сучасного тестування

Проблеми умовно я поділю на дві великі групи.

Перша група: Гонитва за технологіями

• Концентрація тільки на короткотривалих цілях. Багато інженерів віддають перевагу швидким рішенням, скажімо так, «палок». Особливо полюбляють таке ставлення до автотестів. Швидко написали «абияк» та й побігли на новий проєкт.
• Resume-driven development. Проєкти (та нова робота) розглядаються не с позиції поглибити технічні знання, здобути навички та реальний досвід, та навіть не с позиції «розв’язати проблему бізнесу» — а тільки, щоб здобути рядок з модною технологією у резюме.
• Культ «зелених пайплайнів». У цьому випадку тест-інженери, що успішно включили тести у пайплайн, починають робити усе, щоб тести були зеленими. Найчастіше це виливається в ігнорування чи навіть видалення особливо нестабільних тестів. А по факту, за кожним нестабільним тестом може бути потенційна проблема.
• Фреймворк-орієнтована автоматизація. У деяких проєктах інженери настільки прагнуть написати ідеальний фреймворк — що забувають про самі тести. В результаті, маємо 3-6 місяців розробки зовсім без тестів, попри те, що для замовника це прямий показник відсутності користі від автоматизації.
• Пошук «срібних куль». Деякі інженери створюють успішний фреймворк на одному проєкті (в одному контексті), а потім починають його тягти в усі інші. Причому не свідомо використовувати частини напрацювань, а бездумно «натягувати» інструменти там, де вони зовсім не потрібні.

Друга група: Недостатній рівень навичок та знань

• Базові технічні знання

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

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

• Програмування та архітектура

Частина тест інженерів досі вважає, що вчитись програмуванню — то складне та непотрібне завдання. Хай програмісти програмують!

Інша частина — ті, хто все ж таки навчились чогось, але концентрують свої сили тільки у межах UI автотестів. Світ поза цими тестами наче й не існує.

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

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

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

• Знання бізнесу та продукту

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

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

Але саме користувачі можуть надати багато корисної інформації щодо найбільш ризикованих частин застосунку або дати зворотний зв’язок щодо usability-системи.

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

• І наостанок — персональний розвиток інженерів.

Щодо персонального розвитку, інженери зазвичай діляться на дві категорії:

1. «Нащо мені вчитися програмувати? Це ж зробить мене менш скілованим тестувальником!»
2. «Я нібито і хочу вчитися, але чекаю свого річного фідбеку. Менеджер чи лід прийдуть та напишуть мені, що треба вчити.»

Але тут криється найголовніший момент. За персональний розвиток навичок, знань та вашої кар’єри відповідальні ТІЛЬКИ ВИ САМІ!

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

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

Замкнуте коло невпевненості

То ж які питання можуть виникати у середньостатистичного тестувальника чи автоматизатора на більшості проєктів?

• «Я не можу писати код — я ж не розробник...»
• «Хто я взагалі такий, щоб говорити з Архітектором про архітектуру чи testability компонентів системи?»
• «Девопси відключили нестабільні тести у пайплайні — ну, вони ж більше знають, як воно повинно бути...»
• «Менеджер продовжує запитувати мене: що конкретно ти тестуєш? Нащо це? А це?»
• «Бізнес тільки й прагне „зрізати кости“ та позвільняти увесь відділ непотрібних тестувальників....»
• «Звідки я взагалі знаю, які проблеми у юзерів нашого софту?»

В результаті більшість тест-інженерів потрапляють в таке собі коло невпевненості.

• Тестувальники не можуть нормально довести команді, іншим інженерам, менеджменту та бізнесу свою справжню користь. Брак технічних та бізнес-знань заважає побудувати довіру в команді;
• Демотивація тест-інженерів росте. Разом із демотивацією поширюються думки перейти в розробку або у той самий менеджмент. Або взагалі піти з цього айті! (Я не говорю, що перехід — то щось страшне. Але в деяких випадках, перехід можна й не робити);
• Багато досвідчених та сеньйорних інженерів залишають індустрію тестування або взагалі переходять тільки на тренінги. Кейсів успішних тестувальників, автоматизаторів стає все менше. Кейси, коли тест-інженери дійсно впливають на продукт, процеси, вносять технічні удосконалення, — можна перерахувати на пальцях. Досягнення та розповіді на конференціях зводяться до «ну, ми заюзали оцей фреймворк чи оцю тулзу для тест-менеджменту — тепер всьо у шоколаді». Нема кому писати круті тулзи та бібліотеки. Нема кому тестувати дійсно складний та науковий софт. Нема кому робити наукові дослідження у сфері тестування;
• Індустрія продовжує думати, що тестувальник — це той, хто «тільки натискає кнопки й нічого практично не шарить». Молоді тест інженери бачать ту ж картину, та ще швидше демотивуються;

Як змінити ситуацію на краще

• Самостійно готуй план свого професійного розвитку: які навички здобути, що вивчити, як це знадобиться у роботі. Якщо ти можеш здобути знання та навички у компанії — круто. Якщо категорично не можеш — шукай інший проєкт чи компанію. Вибір завжди є. Він у твоїх руках.
• Навчися програмувати. Я не говорю тут про скіли на рівні сіньйор девелопера. Але вміння написати скрипт може прибрати багато одноманітної роботи з деплойменту чи конфігурації. Вміння читати та розуміти чужий код дає більше розуміння того, як взагалі працює система та які кейси ще не покриті.
• Поглиблюй свої знання по архітектурі застосунків та систем. Почни з системи, яку тестуєш зараз. Декомпозуй її. Розбери архітектурні діаграми. Подумай, як і де окремий компонент може «впасти» та як система в цілому буде на це реагувати. Поговори на цю тему з вашим архітектором.
• Якщо ти створюєш скрипти чи автотести, завжди запитуй себе: хто та як буде використовувати мій код (тести)? Чи достатньо зрозуміло написано? Чи є деталізований репорт? Як легко буде розібратися у коді новому інженеру?
• Вивчай, як користувачі працюють з вашою системою. Яка у вашого продукту бізнес-модель? Які найбільш ризикові частини є? Вся ця інформація допоможе тобі тестувати саме те, що важливо користувачеві, та заощаджувати гроші бізнесу.

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