Для выбора QA-команды в Конаеве важно понять не только перечень инструментов, но и содержание проверки. Сравните, какие действия пользователей она рассмотрит и как передаст сведения об обнаруженных проблемах.
Представьте, что автоматизированные проверки уже есть, но сотрудники перестали доверять их результатам. Сначала обсудите разбор существующего набора и причины расхождений; новый большой комплект не следует считать единственным возможным предложением.
Подготовка среды влияет на содержание заказа. На какой версии будут выполнять проверки, какие устройства или браузеры нужны и откуда возьмутся данные для примеров? Обсудите с разработчиками условия доступа и правила работы со служебными сведениями. Если продукт меняется во время проверки, договоритесь, как отмечать версию и повторять важные сценарии. Иначе замечания разных участников будет трудно связать с одним состоянием программы.
Определите, какую часть продукта предстоит проверять. У сайта это может быть путь от выбора товара до получения подтверждения, у внутренней программы — операция сотрудника и передача сведений следующему отделу. Попросите команду объяснить, какие обычные и необычные ситуации она рассмотрит. Перечень экранов сам по себе не раскрывает проверки действий пользователя. Отдельно назовите то, что пока останется за пределами согласованной работы.
Ручное и автоматизированное тестирование сравнивайте через конкретные проверки. Спросите, что специалист будет исследовать сам, какие повторяющиеся действия предлагает выполнять программно и кто станет поддерживать созданные проверки. Автоматизация не превращает любой заказ в разовую покупку готового результата. Для нагрузочной проверки отдельно определяют сценарий и оцениваемые показатели; её не следует считать заменой всей работе с качеством продукта.
Организуйте связь между проверяющими, разработчиками и владельцем продукта. Кто отвечает на вопросы о задуманном поведении, кто уточняет важность проблемы для пользователей и кто сообщает об исправлении? Эти роли лучше не оставлять за общим словом «команда». Обсудите повторную проверку изменённых частей и порядок передачи новых версий. Отчёт о найденном и решение о готовности выпуска связаны, но не являются одним действием.
Попросите показать обезличенный пример сообщения об ошибке. Разработчику должно быть понятно, что сделал проверяющий, какой результат получил и чего ожидал, на какой версии возникла проблема. Снимок или запись могут дополнять описание, но не всегда объясняют последовательность действий. Сравните, как команда обсуждает неповторившуюся ошибку и уточняет обстоятельства. Итоговый список замечаний полезен тогда, когда с ним можно продолжить работу.
В предложении сопоставьте объём проверок, участие специалистов и передаваемые материалы. Разработка автоматизированных проверок, их запуск и дальнейшая поддержка могут оцениваться отдельно. Выясните, что получите помимо списка ошибок: описание выполненных сценариев, ограничения проверки или другие согласованные сведения. В примерах прежних работ важны похожий продукт и собственная роль QA-команды, а не только число упомянутых технологий.
Сравните QA-компании в Конаеве по проверяемым действиям пользователей и понятности сообщений об ошибках. Выбирайте содержание работы, которое команда продукта сможет использовать после получения отчёта.