Складнощі E2E-тестування з точки зору тест-менеджера

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

Привіт друзі. Я — Олексій Остапов, автор блогу QA Mania і один з ведучих подкасту «Питання Якості»!

Нещодавно виступав на qamagic meetup, і деякий час роздумував над темою, про яку мені цікаво буде розказати, а вам — послухати. На щастя, ми з Михайлом Чубом викладаємо в КПІ і нас попросили написати тези для статті. Ми ж наукою займаємось. Я трохи подумав і вирішив взяти тему Складнощі Е2Е тестування у телекомах (великих проєктах).

Я почав збирати інфу для дослідження теми. Погуглив, а ще й запитав ШІ Bing, чи не може він знайти мені статті на цю тему. Він пошукав, видав 5 статей і додав: «Перша в списку — дуже класна, прям те, що треба». Відкриваю, а це — моя стаття на DOU 4-річної давнини. Дякую, блін 🙂

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

Я вирішив написати цю статтю наступним чином:

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

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

1. Люди

Вони щось (не)роблять, організуються і взагалі ДИХАЮТЬ! І БІСЯТЬ! Коли нас замінить ШІ, стане, краще (але це не точно).

Бюрократія

Не можна просто взяти і зробити роботу. Треба запланувати мітинг, поговорити кілька годин, запланувати фолоу-ап мітинг, потім написати купу листів і доків, дочекатись апруву і потім зробити. Чи от, наприклад, у вас є менеджер, і ще менеджер, і ще менеджер... І всі дають різні задачі, які треба виконати ASAP.

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

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

В мене колись був менеджер, який хотів проводити 1-to-1 мітинг кожен день, просто тому що міг, не допомагаючи у вирішенні моїх проблем. Спочатку я пручався, але коли не допомогло, почав щось типу італійської забастовки, сам призначаючи 1-to-1 мітинги, пінгуючи менеджера по 10 разів на день з follow-up`ами, «навалював» йому детальної інфи стільки, що в якийсь момент він просто від мене відчепився «через велику зайнятість».

Міскомунікація і розмитість відповідальності

Одна з першопричин всіх багів. Вам дали доку з вимогами, але це не та дока. Сказали робити одне, а треба було робити інше. Звернулись з проблемою до однієї команди, а за неї відповідає інша.

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

Як вирішити? Мітинги тут не допоможуть, тому що більшість мітингів — не потрібна. Спілкуйтесь письмово. Мені ще 15 років тому людина, що вчила мене тестуванню, казала — без письмового доказу не роби нічого. Всі дії і їх результати мають бути задокументовані. Робіть гайди, пишіть відео, додавайте коменти в коміти і в Jira-тікети. Meeting notes, в яких проставлений дедлайн і по одній відповідальній людині на кожну задачу не вирішать проблему повністю, але точно зроблять її не такою болючою.

Неоптимізована швидкість роботи

Тут все просто. Ви запланували вашу роботу на тиждень, а робите 2 місяці, бо чекаєте на 3rd-party, дані, енви, «рака на горі».

Як вирішити? Якщо «простоюєте» — простоюйте з користю. Зменшуйте технічний борг, оптимізуйте документацію, навчайтесь! Нещодавно написав пост з рекомендаціями до CV і співбесід, і отримав коментарі до деяких пунктів в стилі «як це так, вчитись в неробочий час? Я маю відпочивати. За навчання не платять і т.д.» Ось ваш шанс, чекаєте 3rd-party — вчіться. Нова мова програмування, новий фреймворк — ніколи не завадить. А ще можете статтю написати ;)

Пізнє тестування

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

Як вирішити? Shift-left тестування. Не просто починайте з документації вашої підсистеми. Думайте, як ви будете проводити інтеграційне тестування. Треба більше логів — попросіть більше логів. Треба тестові ендпоінти з дебаг інфою чи моки — просіть вже, а не перед релізом. (До речі, після мене на мітапі робив доповідь Олександр Хотемський, і теж розповідав про додаткові енпоінти чисто для тестування, що мене дуже порадувало. Це нормальний інженерний підхід: думати про такий параметри якості ПЗ, як Testability ще на етапі проєктування.)

2. Інфраструктура

Я бачив 2 крайнощі. Від «ось тобі всі права, роби що хочеш» до «Це що в тебе, термінал? Повільно закрий його і прибери руки з клавіатури».

Проблема з усіма правами — інженери мають самостійно знати, що налаштувати і як, але мають більше контролю за системою. Я колись випадково видалив всі дані з БД, куди колега їх вносила для тестування, бо після DELETE не написав WHERE.

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

• Ваш софт юзає 3rd party в іншій мережі? Для production середовища ми зробимо виключення, а на деві — страждайте, мокайте, нас не хвилює.
• Треба окремий енв для тестів? І не мрійте, дорого. Тестуйте на проді. А краще просто не робіть помилок.
• Що, кажете, лямбда функції в FAAS по $100500 за виклкик? Так це ж так легко налаштовувати, і думати не треба. Зробити нормально? В нас на такі дурниці часу нема.
• Налаштувати простий пайплайн build-test-deploy? Вам не зручно буде. Зробимо вам 20 степів. І що, що падає постійно? І тестів нема? Зате подивіться, який гарний вийшов пайплайн!

Як вирішити? Проблеми інфраструктури часто зводяться до проблем з комунікацією. Точніше формулюйте ваші запити: на що вам треба ресурс, на коли, на який час. Робіть follow up — це ж вам потрібно. Знайте, на кого ескалювати питання. Це не гарантовано допоможе, але може бути краще, ніж нічого.

Також завжди можна придумати альтернативні флоу і workaround`и. Колись я просив в DevOps’ів пайплайн і середовище для автотестів. Вони пів року робили, і не зробили. Тоді я замовив просто PC в нашому IT-відділі, поставив там Jenkins, написав пайплайн і ганяв тести. Не все було ідеально, але воно працювало!

Чи інший приклад — треба було протестувати обладнання в умовах повільної мережі. Замовив в ІТ обладнання, але без жодних сроків. Тож приніс з дому роутери і зробив власний тестовий стенд (згідно політик, власне обладнання не можна підключати до мережі компанії, але якщо зробити власну з блекджеком, то наче норм). Провів тести, надав результати, всі задоволені!

3. Програмне забезпечення і дані

Тут все за класикою.

1. Якщо ми говоримо про будь-який ентерпрайз продукт, зазвичай ми маємо низку пов’язаних мікро чи макросервісів, які складно тестувати автономно, бо вони залежать одне від одного. Вже давно минули ті часи, коли можна було розгорнути систему, що ми тестуємо локально і робити ті тести, що ми захочемо — тільки cloud, тільки хардкор.
2. Дані для кожної системи/ сервіса треба тримати актуальними та цілісними. Всі системи мають знати про ID сутностей в інших системах.
3. Команда розробки має дбати про транзакційність, відновлюваність, синхронізацію даних. А нам все це тестувати.
4. Різні системи від різних команд розробки — різні канали комунікації. В одному проєкті можна легко мати і Message Broker’и, і REST з SOAP, і сокети + якісь додаткові пропрієтарні протоколи.

Як ви можете зрозуміти, я ностальгую за старими добрими монолітами. І я не просто луддит і ретроград. На мій подив, знайшов влучний опис своїх претензій до мікросервісів в біографії Лінуса Торвальдса. На межі 80х-90х він мав суперечку з Ендрю Таненбаумом, що працював на мікроядерною архітектурою ядра ОС, на противагу монолітному ядру Linux.

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

Як вирішувати проблеми , якщо я — простий QA, чи, в кращому випадку, тест-менеджер? Тут теж рекомендація на шифт лефт, з фокусом на високу тестованість вашого ПЗ. Готуйте сервісні ендпоінти, домовляйтесь про читабельні і відстежувані логи.

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

...

Дякую, що дочитали! Впевнений, у вас в кар’єрі теж були десятки проблем з тестуванням, тож поділіться вашим досвідом — як сами ви і ваша команда їх вирішували?