Тестове завдання — загальний фільтр чи стоп-критерій?

Привіт, спільното!

Нещодавно мав свій перший досвід виконувати тестове завдання на позицію Senior Test Automation Engineer у одну із компаній. Мене ріджектнули по суті по тій причині, що, можливо, ми не порозумілись. Про це згодом.
Виникло також логічне запитання, які є best practices до виконання завдання. Чи тестове завдання — це скоріше фільтр і здебільшого запрошують на співбесіди, де ти маєш пояснити свої рішення, чи це строгий стоп-критерій?

Додам трошки деталей.
Був забагований АПІ-контролер, документація до нього та вимогою було написати Test Automation Framework.

Stack:

Java 11, testNG

Assignment:

Write a framework for app testing
Write one positive and one negative autotest for each controller
Find possible bugs. Critical ones are covered with autotests.

Additional:

• Add Allure
• Make a test run in 3 threads
• Add logging
• Add framework configuration (app url, thread count, etc.)

Отож, я завів баг репорти, накидав автотести, описав також свої наступні кроки по вдосконаленню фреймворка, та які наступні автотести я буду дописувати. Від себе також додав Github actions, де все працює, щоночі ран автотестів, генерується Allure report, все ок.

Я вдячний компанії, що за кілька днів надали фідбек, проте не дуже зрозумів чи це справді моя помилка, що я не уточнив деталі чи це було не дуже добре зі сторони компанії одразу відмовляти кандидату. До речі, я запропонував виправити коментарі новим пул ріквестом, проте отримав відмову, що типу вже не треба.

Коментарі були наступними:

«It is recommended to use filters for logging, as this provides more flexible and centralized handling of logging logic»

В умові просто було зазначено прикрутити логер, я прикрутив log4j2.xml без фільтрів. В умові не було вказано і впринципі це не проблема додати, якщо потрібно. Але для тестового я «не заморочувався».

«Path parameters should be passed as a Map, populated using factory methods — this improves code readability and scalability»

Ідентично до попереднього коментаря. Я більше діяв по принципу «You aren’t gonna need it». Там всього кілька ендпоінтів, тому подумав, що це доречно робити, коли кількість ендпоінтів та тестів буде рости.

«The absence of functional tests poses a potential risk: contract tests will not reveal issues related to the expansion of business logic»

Вимога написати по 1 позитивному та 1 негативному тесті. Ендпоінти написані спеціально з багами, причому критичними, де пароль повертається у такому вигляді як зберігаєш, де метод GET на create, метод POST на get. Я завів баги і покрив автотестами. Додав інформацію, що функціонал потестував вручну, автоматизуємо наступним кроком, коли пофіксять ендпоінти. Проте отримав даний коментар, що навіть з моїм поясненням, що я не забув за функціональні автотести, все одно не підійшло.

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

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

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

Можливо хтось також мав досвід виконання тестових завдань в останні роки в Україні та і в інших країнах, поділіться будь ласка досвідом))