Трохи якось не послідовно автор пішов описуючи ROI в порівнянні з TA і NC TA, враховуючи що це перша стаття. Було б логічніше зпершу розказати про ваш вибір конкретного codelees інструмента. Висвітлити порівняння як зробити авто тест(и) на codelees і традиційною автоматизацією. Які переваги і недоліки обох підходів та час на виконання. А потім уже можна і про ROI поговорити) Але зараз для мене оці таблички з данними виглядають дуже розмито і не зрозуміло

значить у вас поганий менеджер)

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

Ну це все одно, що сказати мені подобається білий колір а вам сірий. Уже другий коммент тут звучить що робот це типу дно, але ніхто не може аргументувати чому?)

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

robot framework норм рішення

Ну є рішення — пошук степів (методів) за допомогою Ctrl + Shift + F. Те що степи схожі це вже проблема реалізації цих методів (степів)

Так а що не подобається?) Аргументи в студію

Альтернатива — Robot Framework. Степи зрозумілі на простому англ і можна сказати те ж BDD але без обгортки тому що цей фреймворк і так в стилі BDD. Як результат тести завжди зрозумілі і виглядають як степи в тест кейсі і головне що писати і підтримувати тести дуже швидко

Якщо інтегрувати ваші звіти по авто тестам в testrail то це доволі гарний інструмент для аналізу і метрик. Є багато інфо як це можна зробити для конкреного тест фреймворка та мови програмування

Test Rail is a good choise

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

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

Хорошая статья!

Мене здивувала ситуація з тестовою картою в останньому кейсі. Я так розумію це ваша тестова карта і про дані якої знають лише всередині команди або тільки відділ розробки і тестування. То як так вийшло що хтось з клієнтів нею зміг розрахуватися? Інакше це могли зробити тільки спеціалісти з компанії. Тоді це не вигідно для них — бо це можна легко перевірити) Чи я чогось не розумію? Буду радий за відповідь ;)

«Баги есть всегда, но вот появляются они в момент обнаружения.» -
Серьезно?) Вы уверенны в этом?

Дороги делаются, например участок Пирятин — Ромны вполне норм дорога, ее начали ремонтировать 3 года назад. Так что эта мапа не совсем актуальная. И действительно, отвечает за дороги в районе больше местная власть, так что в первую очередь вопрос к ним

Ну вы и сравнили Трампа с Зеленским. Почитаейте хтотя бы биографию Трампа ru.wikipedia.org/wiki/Трамп,_Дональд и увидите, что это умный и опытный политик уже давно до президенства. А вот ЗЕ сейчас это ноль в политике и это правда

Есть альтернатива получше?