Ти пишеш тести, а хто їх перевірить?На звʼязку Артур Шевченко і сьогодні я хочу поговорити про перевірку Test Automation Solution (TAS) — окремий, доволі важливий етап впровадження автоматизації. Згідно з розділом Verifying the Test Automation Solution в ISTQB Test Automation Engineer Syllabus, автоматизована система тестування сама по собі є програмним продуктом і повинна проходити валідацію так само, як і SUT (System Under Test).Перевірка Test Automation Solution — це системний процес, що охоплює функціональність, надійність, звітність, архітектуру та інтеграцію. Лише валідований TAS здатний забезпечити достовірні результати та реальну цінність для якості продукту. Розглянемо детально кожен етап цієї перевірки:1️⃣Перший рівень перевірки — коректність виконання тестів. Необхідно переконатися, що автоматизовані тести правильно реалізують тест дизайн і відображають очікувану бізнес-логіку. Цілком логічно. Очевидно, що вам тут треба цілком визначені сценарії з відомим результатом. Наприклад, якщо API повертає фіксовану відповідь на тестові дані, фреймворк повинен стабільно фіксувати PASS або FAIL відповідно до очікування. Це найпростіше.2️⃣Другий рівень — точність оркестрації та управління тестами. Звучить складно. TAS має коректно ініціювати тестові дані, виконувати setup/teardown та ізолювати тести. Перевірка включає аналіз обробки винятків, таймаутів, ретраїв. Наприклад, якщо тест переривається через нетворк помилку, то система повинна або коректно залогувати причину, або застосувати політику повтору.3️⃣Третій рівень — валідація репортів та логувів. Так-так, інколи і це треба перевіряти. Згідно з ISTQB, TAS повинен забезпечувати достовірні, відтворювані та інтерпретовані результати. Це означає перевірку: чи коректно формуються звіти, чи містять вони інформацію про середовище, версію білду, тестові дані, stack trace при помилках. Неповні або неконсистентні звіти знижують діагностичну цінність автоматизації.4️⃣Четвертий рівень — перевірка стабільності та надійності. Тести повинні бути надійними, а не як твій колишній/колишня. TAS повинен бути стійким до змін оточення, конфігів і даних. Вам треба заранити тести у різних енвах (dev, stage) та запустити паралельний ран, як приклад. Якщо фреймворк демонструє флекі-поведінку то у SUT проблема.5️⃣П’ятий рівень — підтримуваність і розширюваність. Verifying TAS включає рев’ю архітектури: чи дотримано принципів модульності, чи ізольовано бізнес-логіку від технічної реалізації (наприклад, Page Object або Service Layer). Оцінюється рівень зв’язаності, наявність конфігурацій через параметри, а не хардкод.6️⃣Нарешті, ISTQB підкреслює необхідність регресійної перевірки самого TAS. Після оновлення фреймворку слід виконувати контрольний набір тестів для впевненості, що зміни не зламали інфраструктуру автоматизації. Тобто “внезапно” треба писати тести на тести, хах.Хух, сподіваюся, не налякав вас складністю🤓 Бо тема важлива і у 2-3 речення не вкладається. А якщо хочете прокачати власну експертизу в автоматизації та отримати сертифікат ISTQB Advanced Test Automation Engineer — чекаю вас на курсі, що стартує 9 квітня!