Дуже вчасно)
Вчора побачив вакансію із вимогою мати досвід з контрактного тестування.
І хотів розібратись що ж це таке.
Дякую що «розклали все по полицям».

Вітаю!
Я спеціалізуюсь на тестуванні веб-продуктів (UI та API) з використанням TS/JS та Python, а тому не можу давати рекомендації щодо використання C# чи тестування мобільних додатків.
А стосовно використання Playwright, то однозначно варто спробувати.
Як на мене то для ознайомлення найкраще купити курс на Udemy, наприклад цей www.udemy.com/...​rials-automation-testing, або інший.
Зараз вартість вказаного курсу — $74.99, але періодично з’являється знижка і можна буде купити за $8.
Окрім цього є Oleksandr Khotemskyi, який проводить оффлайн (а може і онлайн) майстер класи по Playwright — це гарний варіант якщо є потреба в «живому» фідбекові.
Якщо витрачати кошти на курси не хочеться або немає можливості, то можна знайти аналогічні курси на ютубі, але зазвичай вони менш деталізовані і можуть бути застарілими.
Враховуючи курси та вичерпну офіційну документацію (playwright.dev/docs/intro) можна швидко зробити тестовий проєкт і зрозуміти ви підходить цей інтрмент для поставлених завдань.

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

Маєте поради що можна почитати в цьому напрямі?

Дякую за статтю і за посилання!
Може щось собі цікавого знайду.

Влучне зауваження, дякую.
То я неточно сформував свою думку.

Іду в ПП)

Такі можливості є, оскільки Playwright має великий вибір вейтрів, але універсального рішення немає, тому кожем випадок потрібно розглядати окремо і на це можна витрати більше часу а ніж хотілося б.
Приклад з власного досвіду.Є модалка, дані для якої підвантажились на етапі завантаження сторінки, тому перевіряти запити-відповіді не має сенсу, але при її відкритті виконується анімація для відображення кнопок. Використання «.waitFor();», як рекомендують розробники Playwright, не допомогає, оскільки метод поверне true (що елемент видимий) ще в процесі анімації, не дочекавшись її завершення, а тому буде розпочато a11y-сканування і буде зафіксовано порушення правила контрасту (співідношення кольорів фону кнопки і тексту та розміру тексту).
Тому я і зробив акцент на тому що не варто довіряти «.waitFor();» бо це ненадійний варіант.

1) проведення такого виду тестування було вимогою клієнта, а тому і розробники і тестувальники мають розуміння і досвід повʼязаний із аксесібіліті;
2) звісно що такий варіант не покриває усі необхідні аспекти, але суттєво зменшує кількість мануальних перевірок;
3) на момент впровадження цього тестування ми уже використовували playwright.

«Із коробки» такої можливості немає.
Я планував реалізувати такий варіант, але через брак часу зупинився на проміжному варіанті, а саме — дворівневий список (порушене правило -> селектори порушених елементів) + скрін всієї сторінки з виділенням порушень як в браузерному розширені Axe + атач json репорту. Такий варіант виявився досить вдалим за рахунок поєднання лаконічності та інформативності, тому поки реалізацію html-репорту відклав.
В статті цього не має, бо доробив уже після написання статті, але можу швидко оформити і зробити як продовження цієї статті.
По html-репорту — бачив одну репу, але мені не сподобалось тому не зберіг посилання. Якщо цікаво, то можу пошукати по історії.

Чи є запис вебінару?