В попередніх статтях ми вже ділилися корисними рекомендаціями на кшталт Що читати та дивитися автотестувальнику-початківцю, сьогодні ж поговоримо про терміни, знання яких суттєво полегшить ваш прогрес в обраній компетенції. Отже, 10 термінів автоматичного тестування, які повинен знати кожен початківець, ілюструє наочними прикладами Олена Крамар, Lead Software Test Automation Engineer.

1. Quality gate або Ворота якості

Як зрозуміло з самого терміну, ворота якості – це контрольні точки, встановлені на певних ділянках у процесах, в команді, щоб «затримати» просування коду, який не відповідає критеріям якості. Якщо код успішно проходить перевірку, він рухається далі до наступних воріт. А що трапляється, коли якісь з воріт блокують його? Уявіть собі рамку металошукача в аеропортах: якщо ви маєте при собі заборонені предмети, пристрій подає звуковий сигнал. Те ж саме роблять і ворота якості — вони сигналізують про виявлену проблему тестувальникам (або\і всім іншим залученим у процес фахівцям: мануальним тестувальникам, керівникам проєкту тощо) через визначений канал комунікації – електронну пошту або месенджери, якими користується команда.

2. Release Candidate (RC) або Реліз-кандидат

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

3. Log або Журнал

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

4. Stack trace або Трасування стеку

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

5. Regression або Регресивне тестування

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

6. Breaking change або Критична зміна

Доволі широке поняття, яке може включати в себе як суттєве перебудування архітектури продукту, так і зміну положення кнопки «Увійти» на початковій сторінці. «Критичною» вважається будь-яка зміна, яка здатна ускладнити рутину тестувальника. Інколи навіть найдрібніша, з точки зору замовника чи кінцевого користувача, маніпуляція (приміром, інший колір кнопки «Замовити») може повністю зруйнувати усю систему автотестів. Чому це відбувається? Автотести – це такий самий програмний продукт, як і будь-який додаток, і якщо вони не враховуватимуть останні бізнес вимоги, про валідацію поведінки продукту належним чином можна забути. Саме тому інженерам з автоматизації тестування необхідно бути проінформованими про усі критичні зміни.

7. Non-functional requirements (NFR) або Нефункціональні вимоги

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

8. Branch Strategy або Стратегія відгалуження

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

9. Code Refactoring або Рефакторинг коду

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

10. Code Stabilization або Стабілізація коду

Інший різновид удосконалення коду носить назву «стабілізація». Це процес налагодження коду таким чином, щоб його виконання призводило до того й самого (стабільного) результату. Зазвичай він полягає лише у виявленні та усуненні певної несправності й не означає суттєву переробку коду.

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

Цікаво? Це лише верхівка айсбергу того, чому можна навчитися в ЕРАМ University на програмах за спеціалізацією Test Automation. Реєструйтесь та долучайтеся до нашої команди!