Я пришёл в нативное iOS-тестирование из Appium, и простой логин на XCUITest раз за разом обрастал waitForExistence, ретраями и самописными хелперами. Так появился KassiOS — слой в стиле Kaspresso поверх XCUITest: тап с общим бюджетом ожидания, который не повторяется после отправки, перечитывание поля после ввода, понятные сообщения о падениях, параметризованные тесты.

Чтобы проверить, ловят ли тесты баги, я прогнал их против ChaosBank — приложения с включаемыми дефектами — и написал утилиту, которая включает дефекты по одному и показывает, какой из них прошёл незамеченным. Рассказываю, что из этого вышло, какие баги нашлись в самом фреймворке и кому он подойдёт, а кому нет.

Перед переездом автотестов с Java на .NET мы решили разобраться, что действительно стоит переносить. Я ручной QA и для этой задачи подключил ИИ-агента: дал ему доступ к репозиториям и TestIT, задал критерии и проверял его рекомендации. За две недели мы провели аудит примерно 2600 тестов и собрали статистику по базе из 6500. Расскажу, как устроили процесс, находили дубли и выбирали приоритеты с помощью P85.

Как построить конвейер обезличенных синтетических данных и убедиться, что они не врут? Собрал полезную статью для руководителей разработки и QA, продакт-менеджеров и всех, кто работает с тестовым контуром.

Я уже более 10 лет работаю с тестовыми средами, и раньше делал ошибку: выгружал из прода 200 000 строк, менял фамилии на обезличенные шаблоны, и считал, что все окей. А затем как-то заметил, что в выгрузке остались номера договоров. Мне повезло, что именно я нашел их первым, особенно учитывая всё более суровую регуляторку. С тех пор я отношусь к тестовым данным также серьезно, как к проду.

Как версионируемый QA-репозиторий помогает маршрутизировать контекст, повторно использовать процессы и сохранять обоснование выбора тестов.