autotest что это за программа
Словарь тестировщика: автотесты, юнит-тесты и другие важные слова
Основные подходы и понятия инженеров по тестированию
В прошлой статье про тестирование калькулятора мы занимались ручным тестированием. Это эквивалент любого другого ручного труда: может быть эффективно, но плохо масштабируется, и вообще это не инженерный подход.
А вот — инженерный. В этой статье разберём на базовом уровне основные подходы к инженерному тестированию.
Что такое автотесты
Автотесты — это тесты, которые выполняет компьютер, а не человек. Внутри автотест это тоже программа, цель которой — протестировать, как работает другая программа.
Автотест делается и работает так:
После этого тестировщики смотрят на тестовые и реальные результаты и делают вывод, правильно работает эта часть программы или нет.
Автотесты делятся по масштабам тестирования на юнит-тесты, сервисные тесты и интеграционные тесты.
Юнит-тесты
Юниты — это отдельные модули или части программы, каждый из которых отвечает за что-то своё.
Юнит-тесты проверяют работу отдельных юнитов: берут модуль и прогоняют его по всем своим тестам. Чем меньше и проще модуль, тем проще сделать юнит-тест и прогнать его по модулю. Модулем может быть что угодно — функция, метод класса, часть API и так далее.
Юнит-тесты — самые простые в обслуживании и написании. Работают быстро, проверяют модуль вдоль и поперёк, но есть нюанс: если в программе больше одного модуля, то просто протестировать их по одному недостаточно — они могут работать классно поодиночке, но вместе работать плохо. Чтобы проверить работу нескольких модулей вместе, делают сервисные тесты.
Сервисные тесты
Задача сервисного теста — протестировать работу нескольких модулей вместе: как они запускаются, передают друг другу данные и правильно ли решают свою общую задачу как одно целое.
Это уже сложнее, чем юнит-тесты, зато помогает понять, как модули работают вместе. Правда, не все используют сервисные тесты, а переходят сразу к интеграционным, но знать про них тоже полезно.
Интеграционные тесты
Эти тесты проверяют, как работают все модули сразу или даже как работает вся программа.
Интеграционные тесты — самые сложные, потому что если меняется что-то хотя бы в одном модуле, то, скорее всего, нужно будет переделать весь интеграционный тест. Это дорого и занимает много времени, поэтому в компаниях стараются делать так:
Минусы автотестов
Если бы всё можно сделать автотестами, которые не пропускают ни одной ошибки в программе, то в разработке ПО наступил бы идеальный мир. Но у автотестов тоже есть минусы.
Стоимость разработки. Так как автотест — это тоже программа, на её разработку тоже нужны время и деньги. Чем сложнее автотест, тем больше ресурсов на него нужно. Иногда проще разбить один большой тест на много тестов поменьше, чем разрабатывать огромную универсальную тест-машину.
Поддержка. Там, где разработка, там и поддержка ПО. Автотесты тоже нужно поддерживать в актуальном состоянии: следить за правильностью тестируемых параметров, текущими названиями классов и методов и версиями тестируемого софта.
Выбор тестов. Чтобы написать хороший автотест, нужно перед этим определиться, а что именно он будет тестировать. Иногда на это уходит столько же времени, сколько и на пару юнит-тестов, а иногда и больше. Если ошибиться на этом этапе, тест может сработать вхолостую и пользы для проекта не будет.
Вот пример: если бы мы автотестировали калькулятор, то мы бы могли сделать тесты с числами 1, 2, 3, 4, 5 … 9999. В нашей голове это максимальное значение, которое людям нужно в обычной жизни. Мы даже не подумаем, что кому-то в нашем калькуляторе понадобится число длиной 17 знаков. А ведь именно на таком числе наш калькулятор и сломался.
Умение программировать. Сейчас появляются инструменты, которые упрощают задачу тестировщика, но без знания алгоритмов пока ещё никуда. Чем лучше инженер по тестированию умеет программировать и строить в голове нужные алгоритмы для проверки, тем круче у него всё получается. Про это как раз в следующем разделе.
Где этому научиться
Можно прочитать нашу подборку книг для новичков — там книги идут по возрастанию сложности, и лучше читать их по порядку. А можно прийти в Практикум и полностью освоить профессию тестировщика за несколько месяцев. По времени будет столько же, а пользы в сто раз больше.
Автоматизация тестирования с нуля. Часть 1
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Когда делать автотесты?
Краткий ответ — как можно раньше.
А полный будет раскрыть ниже. В любом случае, когда проект работает 3 года, и все проверялось вручную, жить становится очень монотонно. И парк из 5000 сценариев автоматизировать за месяц-два проблематично. Как правило в таких проектах придется начинать прорабатывать сценарии заново. Потому что это окажется быстрее. И не факт, что старые получится автоматизировать без существенных изменений.
Почему?
Потому что автотетсы:
Накопленные сценарии
Чем больше парк автоматизированных сценариев, там больше вероятность найти регрессию, особенно если при каждом запуске данные изменяются.
Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.
Непредвзятость
Если меняли требования — автотест должен отправиться на переделку вместе с переделкой основного функционала. Именно поэтому тестировщики принимают участи в согласовании ТЗ.
Если прогон теста автоматически линкуется к задаче, то никто не сможет сказать, что это не тестировалось. Или наоборот, сможет. В общем проблем точно становится меньше.
Скорость
Если каждый тест удовлетворяет занудным условиям:
Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.
А потом легко распараллелить. Потому что они получаются независимыми.
Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.
Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.
Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).
С чего начать?
С пользовательских сценариев.
Ценность атомарных тестов все время падает, особенно на микросервисах. И вообще, в идеальном мире это зона ответственности программиста. Такие ошибки должны быть обнаружены на этапе юнит-тестирования.
QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.
Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.
Есть конечно сложности с подготовкой данных, например в случае интернет-магазина процесс оплаты картой требует наличия вещей в корзине, и или данных для нового пользователя, или данных авторизации существующего.
Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.
Какие сценарии автоматизировать
Наименее подверженные изменениям в ближайшей перспективе. Чтобы автоматизация хоть сколько-то прожила.
Или наиболее часто используемые. Есть смысл помогать ручному тестированию в генерации тестовых данных. Например в доске объявлений есть смысл автоматизировать создание объявлений, т.к. далее любой сценарий требует созданного объявления.
Что конкретно делать?
Обычно в проектах есть
Поэтому предлагаю заняться Бэкэндом и Фронтом.
Выбираем сценарий
Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.
С чего начать автоматизацию?
Есть клиенты, есть сотрудники.
У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.
Какой кейс автоматизируем первым? И как?
Самое важное для магазина — продажи.
Поэтому клиентская история наиболее важна для бизнеса. Поэтому найти товар, поместить в корзину и завершить оформление с любым способом оплаты это первое, что нужно сделать.
По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.
Далее сделать проверки на API редактирования карточки товара и ее фронт.
И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.
Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.
Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.
Какой тип оплаты будем проверять первым? Конечно картой.
То есть мы должны четко представлять, какой сценарий самый важный для бизнеса в данный момент. И его качество обеспечивать в первую очередь.
Постусловия
Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.
Если товар можно оставить в магазине, и ничего страшного не произойдет, то добавление прав администратора обычному пользователю нужно вернуть. А то следующий тест, связанный с правами может упасть. Или хуже — пройти позитивно, хотя должен был упасть.
Странности
Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.
То есть новый БИК не обновлялся. Но новый банк заводился нормально.
Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.
Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?
Что будет дальше?
В следующей статье я расскажу как быстро начать тестировать API, встроить эти тесты в релизы, распараллелить тесты, как подбирать данные для тестов и что нам это даст.
Напомню про эффект пестицида, и как его свети к минимуму.
Технологии: Java + maven + testng + allure + RestAssured + Pict.
Автоматизация тестирования: минусы
Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, цель которого – локализация ошибок в работе программного обеспечения.
Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.
Отбор тестов для автоматизации
Стоимость
Далеко не всегда оказывается, что разработка и сопровождение автоматизированных тестов будет дешевле ручного тестирования. Необходимо потратиться на среду разработки, системных администраторов, наем программистов, их информационную поддержку (имеется ввиду поддержка при возникновении вопросов относительно тестируемой системы и тест кейсов), обеспечить им рабочие места. Все это выльется в немалую сумму и окупится только при тестировании больших систем, когда есть возможность автоматизировать довольно большое количество тестов. После разработки скриптов их нужно кому-то запускать и анализировать результаты. Не получится проводить тестирование по схеме «запустил – подождал – получил конечный результат». Нужен человек, который сможет анализировать выполнение автотестов: определять, нужно ли отправлять тест на доработку, действительно ли существует ошибка, найденная автотестом, подготавливать данные для тестирования. На подготовку среды для разработки, саму разработку уйдет масса времени.
Отдельная статья расходов на автоматизацию – это поддержка автотестов.
Поддержка
Автотесты всегда требуют поддержки. Так как написание автотестов – это программирование, то чтобы изменить\исправить логику автотеста нужно лезть в исходный код. Для этого нужно нанимать дополнительных специалистов, которые будут сопровождать написанные скрипты. Это новые расходы, без которых не обойтись и которые значительно повышают стоимость автотестов. Есть 2 основных случая, при которых может понадобиться вмешательство в исходный код:
1. Изменение входных данных к тесту
Хорошо, если при выполнении нескольких итераций тестирования приложения можно всегда подавать автотестам на вход одни и те же данные. Например, проверка занесения записи в базу данных, или проверка открытия какого-либо меню, где входные данные вообще не требуются.
Но бывает и так, что перед каждым запуском автотестов данные нужно готовить заново. При большом количестве тестов подготовка входных данных может занять много времени. Например, при тестировании банковской системы могут потребоваться счета в рублях, долларах, евро; счета с разными суммами, принадлежащими как физическим лицам, так и организациям. После прогона серии автотестов на всех счетах может остаться нулевой баланс, некоторые из них будут закрыты, некоторые заблокированы. При последующем тестировании необходимо будет использовать другие счета. В некоторых случаях данные могут быть хардкодом прописаны в скриптах автотестов, и происходить это может не из-за того что разработчику было лень сделать свой скрипт более гибким, а просто потому что такого хардкода требовал тест кейс. Через некоторое время тест кейс изменится (например название банка изменится с «хабрабанк» на «хабракредитбанк»), и потребуется изменение скрипта.
2. Изменение функционала
В обоих случаях многое зависит от разработчиков: процесс написания автотестов требует не меньших знаний и усилий чем процесс создания любого другого ПО. Следовательно, тут проявляются все проблемы, связанные с разработкой: сложность контроля качества и надежности, перенос сроков, изменение бюджета и многие другие.
И всё-таки
Эти минусы не означают, что нужно избегать автотестов любой ценой. От них тоже есть польза.
Как видно из графика, использование автоматизации дает лучшие результаты при тех же затратах. Но, еще раз повторюсь, эти результаты будут лучшими только при автоматизации тестирования больших проектов.
ТОП-5 вопросов начинающего автоматизатора про автотесты
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
А пока мы не перешли к торжественной части, было бы круто, если бы вы помогли нам в нашем исследовании:
Каждый год мы изучаем технобренд крупных и не очень игроков российского IT-рынка. Выясняем, кого знают меньше или больше, куда пойдут работать охотнее и почему. Результатами обычно делимся прямо здесь, на Хабре.
Пожалуйста, пройдите этот опрос и помогите изучить рынок IT в 2021 году.
Вопрос 1. Мы пишем и прогоняем автотесты, а баги с прода все равно прилетают.
Начнем с того, что баги с прода продолжат прилетать в любом случае, и это совершенно нормально.
Пользователи могут совершать с вашим приложением невообразимые действия и проходить невероятные, непредсказуемые сценарии — открыли, перешли в другое приложение, заблокировали телефон, получили пуши, где-то полистали новости и решили вернуться в наше приложение. И вот тут-то баг его и поджидает. Частично такие кейсы можно автоматизировать — с помощью нагрузки, прерываний и выгрузки в фон и т.п. Но все возможные уникальные сценарии покрывать автотестами точно не стоит. Как минимум потому что ни один CI не выдержит такой загрузки, а время тестового прогона не будет того стоить.
Также могут быть девайс-зависимые баги, которые невозможно отловить автотестами, если вам не повезло тестировать именно на этом устройстве. Можно, конечно, попробовать настроить CI так, чтобы он создавал разные эмуляторы, или гонять автотесты на разных реальных девайсах, но это значительно увеличит сложность поддержки таких автотестов и скорее всего снизит их стабильность. И, опять же, это не будет стоить увеличенного времени на поддержку и прогоны, особенно с учетом, что находимые баги будут минорными.
Вопрос 2. Как сделать так, чтобы автотесты не заставляли всех страдать?
Чтобы автотесты не заставляли страдать всех вокруг, достаточно следовать некоторым правилам:
Правило 1. Писать понятный читаемый код, настроить отчеты.
Тесты должны быть понятны не только вам, но и другим тестировщикам и разработчикам. Если ваш тест упал, то человек не должен сидеть над ним полдня или сразу идти к автору автотеста с “помоги, посмотри почему он упал”, а должен сам понимать место и причину падения. Еще лучше, если у вас настроены человекочитаемые отчеты, в которых также видны шаги и место, где и почему упал тест.
Никому не хочется тратить время на то, чтобы понять, как автотест работает и что он там вообще проверяет — всё должно быть прозрачно.
Правило 2. Обязательное ревью.
Чтобы убедиться в том, что ваш тест действительно полезен и идеален, нужно, чтобы кто-то еще это подтвердил, и тогда можете спать спокойно.
У нас в hh для всех задач предусмотрено обязательное ревью. Для всех задач с автотестами предусмотрено обязательное ревью от QA. Это крайне важно, так как ревьювер может найти не только неправильный отступ, но и ошибки в логике, посоветовать добавить какие-либо дополнительные проверки, или указать на то, что вы запросто могли пропустить.
Правило 3. Сразу внедрять автотесты в ваш CI/CD
Очень важно, чтобы автотесты сразу приносили пользу, а не ждали лучших времен где-то в недрах кода. Чем быстрее все начнут привыкать, что их код теперь тестируется, тем проще всем станет жить. При этом важно не забывать, что выпускать автотесты нужно максимально стабильными. Перед тем, как вмержить свои тесты, лучше в прямом смысле 100 раз прогнать их на CI. И только убедившись на 100%, что тест не флакует, не падает неожиданно в разных местах, работает и работает как надо — сразу вперед!
Вопрос 3. Из-за чего тесты постоянно падают? Как можно им доверять?
Начнем с того, что какие-то автотесты в любом случае будут падать. Это совершенно нормально, так как если они в 100% случаев всегда зеленые, стоит задуматься — а проверяют ли они вообще что-то?
Но со своей стороны мы обязательно должны сделать максимум для того, чтобы падали они как можно реже. Для этого нужно научиться быстро понимать и устранять причины падений и улучшать слабые места.
За время работы с автотестами я выявила свой личный ТОП-4 проблем с автотестами:
1 — Кто-то что-то выкатил и все упало
Тут все просто — изменения в функционале должны идти рука об руку с правкой автотестов. На такие правки мы закладываем время при оценке и декомпозиции задачи. Когда разработчик изменяет что-то в функционале, который уже был покрыт автотестами, перед тем как вмержить свою ветку, он должен поправить автотесты, чтобы они продолжали проверять этот функционал. Очень важно наладить этот процесс, не игнорить тесты, а всегда поддерживать их актуальность.
2 — Тесты начали падать, но мы ничего не меняли
Тут интереснее. Разработчик ничего не менял, но в какой-то момент тесты начали падать. Возможно, что-то поменяли на бэке.
Почему наши UI-автотесты зависят от бэкенда?
Наши автотесты гоняются на тестовых стендах — это копия продового бэкенда (без продовой базы данных). Мы поддерживаем их актуальность — каждый день автотесты запускаются на актуальном бэкенде. Соответственно, если кто-то зарелизил что-то новое, наши автотесты об этом узнают и, как следствие, могут упасть. Мы в срочном порядке бежим смотреть: баг это или наша новая реальность, которую следует поддержать. И далее либо сообщаем команде о баге, либо правим тесты.
Тут важно заметить, что это случается не при каждом изменении на бэке. Всё-таки в основном, мы синхронизируемся командами по всем изменениям. Но реальность такова, что иногда какие-то моменты упускаются — кто-то не подумал, что может зааффектить мобильные приложения, например. Наши автотесты к такому чувствительны.
Каждый раз, когда такое случается, мы задумываемся о моках. Моки — это классно, если ими не злоупотреблять. Но всё-таки я думаю, что такая чувствительность автотестов к изменениям — это нормально, потому что там мы остаемся в курсе новых фич, которые влияют на наше приложение со стороны других команд. Плюс на моки тоже нужно выделять время на поддержку и актуализацию. Тут каждый сам выбирает, что ему больше хочется поддерживать.
3 — Баги
Моя любимая причина падения автотестов. Тут можно и без комментариев. Если ваш автотест нашел баг, то это очень хороший автотест, а вы — большой молодец.
4 — Флакование
А это самая нелюбимая причина. О ней поговорим далее.
Вопрос 4. Почему мои тесты флакуют?
Флакование как эмоциональные качели — ваши тесты то зеленые, то красные, всем то грустно, то радостно, и как с этим жить никто не знает. Чтобы отношения вашего приложения и автотестов были максимально здоровыми, советуем придерживаться нескольких правил о том, как избежать флакований и писать изначально более стабильные автотесты:
1. Уникальные тестовые данные
Для каждого автотеста должны создаваться новые уникальные тестовые данные, с которыми будет работать только этот тест. Нельзя надеяться на то, что на каком-то экране точно будет что-то, что мы сможем проверить и нам ок. Предсказуемость очень важна.
2. Не забывать дожидаться элементов на экране
Вы написали логичный тест, все четко по шагам, но тест не проходит и постоянно падает в разных местах. Скорее всего где-то он не успевает дождаться нужного элемента и тапает не туда, куда бы вам хотелось. Усугубляют ситуацию различные анимации, лоудеры загрузки и внезапные алерты.
Чтобы такого не случалось, перед каждым действием над элементом (тапы, свайпы и т.д.) или ассертом (проверкой, чеком) нужно дождаться, пока этот элемент точно появится на экране и будет доступен.
У Kaspresso для android есть встроенный механизм, который перед каждым действием под капотом дожидается элемент, делая ретраи на isVisible, и только потом совершает это действие. Благодаря этому, проблем с “тапами не туда” или “тапами раньше, чем нужно” в ваших автотестах больше не будет. Также этот вейтер можно настроить на нужное/необходимое вам количество времени, так как возможно дожидаться какой-то элемент по 10 секунд на экране — это уже баг.
В XCUITest на iOS также есть вейтеры из коробки, но проставлять их нужно вручную перед каждым действием. Либо стоит самим написать механизм, подобный каспрессовскому.
Главное не оставлять в коде вейты на конкретное количество секунд, так как это сильно увеличит время прохождения тестов. И взять за правило — прежде, чем что-то сделать с элементом, — убедитесь, что он есть на экране.
3. Настроить стабильную инфраструктуру
Если инфраструктура, на которой гоняются тесты, постоянно подводит, то стоит решать эту проблему как можно быстрее. Зависающие и тормозящие эмуляторы, падающие тестовые стенды — в такой атмосфере ваши прогоны тестов вряд ли будут зелеными, да и всем довольно быстро надоест разбирать причины их падений. Поэтому нужно обязательно выделить время и ресурсы команды на стабилизацию инфраструктуры. Если все оптимизировано по-максимуму, но все равно остаются проблемы, возможно вам стало не хватать существующего железа и пора лезть в бюджет за новым.
Вопрос 5. Что делать, когда тестов стало очень много?
В самом начале вы писали коротенькие простые автотесты — открой в приложении такой-то экран и проверь, что он отобразился. Затем вы начинаете автоматизировать более сложные сценарии, более сложные проверки. Количество тестов растет. Время прогона увеличивается. А когда что-то ломается, вместо одного теста у вас падает целых десять, и все с одинаковой ошибкой. При этом время упавшей сборки увеличилось в несколько раз, так как упавшие тесты еще и ретраились.
В такой ситуации важно не держаться за свои старые, пусть даже стабильные, тесты и уметь их отпускать. Удаляйте их, если такие же проверки появились в новом. Железо не резиновое, а тратить х2 времени на запуск приложения для каждого нового теста контрпродуктивно и не экономично.
Чтобы не закапываться в будущие объемные рефакторинги, может помочь правило — актуализируй старое прежде, чем писать новое. Если вы сразу начинаете этому правилу следовать, то такой проблемы у вас возникнуть не должно.
Вместо заключения:
Эта статья — заключительная из серии ответов на вопросы про автоматизацию. Но мы продолжим рассказывать про тестирование и автоматизацию в hh.ru, о том, как проходят наши релизы и еще много о чем полезном и интересном.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Ищем тестировщиков в четыре разных направления: