Публичное собеседование: QA Automation Lead

• Алекс Пше объясняет, что публичное собеседование проводится для демонстрации кейшн-лида.  

• Цель - показать, как выглядит процесс собеседования и какие вопросы могут быть заданы.  

• Сегодняшнее собеседование будет с Анной Шишориной.  

• Анна работает в банке "Открытие" более пяти лет.  

• Её опыт включает работу специалистом по автоматизации и руководство проектами по веб-тестированию и тестированию мобильных продуктов.  

• Анна подчеркивает, что не будет упоминать конфиденциальную информацию.  

• Анна сначала была кейшн-инженером, а затем стала кейшн-лидом.  

• Она руководит командой автоматизаторов, состоящей из 17 человек.  

• В общей команде проектов около 200 человек, включая руководителей, аналитиков, тестировщиков и дизайнеров.  

• Анна обсуждает важность стратегии автотестирования и построения процессов.  

• Она отмечает, что имеет ограниченные контакты с релиз-менеджментом и является наблюдателем.  

• В банке "Открытие" процесс тестирования строго регламентирован из-за высоких стандартов безопасности и ответственности перед клиентами.  

• В проекте стараются не совмещать несколько языков программирования.  

• Важно придерживаться одного технологического стека для преемственности специалистов.  

• Важно выстраивать процессы автотестирования с нуля, если проект новый.  

• Необходимо работать с командой тестирования и заказчиками для понимания возможностей и ограничений автоматизации.  

• Важно формировать тестовый план на автоматизацию и согласовывать его с заказчиком.  

• Автоматизаторам выдают критичный функционал для покрытия.  

• Важно договариваться о сроках написания тестового фреймворка и предоставлении доступов.  

• Необходимо согласовывать сроки достижения MVP и дальнейшие цели с бизнесом.  

• Важно вовлекать команду в процесс автоматизации и объяснять её полезность.  

• Автоматизация помогает выявлять проблемы, которые могут не заметить тестировщики.  

• Регулярные кудривью помогают улучшать код продукта.  

• Самая большая ошибка – не вовлечение команды в процесс автоматизации.  

• Важно объяснять команде, что автоматизация помогает, а не мешает.  

• Автоматизация выполняет монотонную работу, разгружая тестировщиков.  

• Необходимо анализировать причины, по которым тесты флыкуют.  

• Важно учитывать изменения в функционале и нестабильность поведения систем.  

• Необходимо корректировать ожидания и локаторы для стабильного выполнения тестов.  

• Анализ кода и типичных ошибок помогает выявить причины падений.  

• Важно обрабатывать перекрывающиеся элементы и принудительно переносить фокус.  

• В случае нехватки ресурсов, нужно продолжать работу и выпускать релизы.  

• Важно спрашивать у автоматизаторов о частых проблемах и критичном функционале.  

• Улучшение автотестов и навыков специалистов по борьбе с флкованиями.  

• Стандартизация процессов для минимизации ручного фактора.  

• Основной критерий качества – количество отловленных багов.  

• Автоматизация помогает экономить время и избегать ошибок.  

• Экономия времени конвертируется в деньги и улучшает бизнес-показатели.  

• Отслеживание метрик объема тестовых сценариев и критичного плана регрессионного тестирования.  

• Использование инструментов для анализа покрытия и выявления ошибок.  

• Важность совместной работы всей команды для улучшения качества продукта.  

• Ответственность всей команды, включая автоматизаторов и разработчиков.  

• Тесное сотрудничество для улучшения качества продукта.  

• Проблемы с пирамидой тестирования и дублированием тестов на разных уровнях.  

• Важность наличия идентификаторов у элементов для тестирования.  

• Вопросы о тестировании кнопок и элементов без идентификаторов.  

• Разделение ответственности между уровнями тестирования и важность совместной работы.  

• Автотесты часто являются "черным ящиком" для разработчиков.  

• Важно контролировать, что автотесты пишутся для нужных вещей и в нужном количестве.  

• На проектах есть пул тестовых сценариев, которые покрываются в соответствии с видением бизнеса.  

• Тестовые сценарии покрываются на основе стратегического видения бизнеса.  

• Автоматизация используется для стабильного функционала, который не будет меняться.  

• Прозрачность работы достигается через отчеты и диаграммы, показывающие покрытие тестов и прирост автоматизации.  

• Выбор инструментов зависит от потребностей проекта и используемых баз данных.  

• Тестовые фреймворки часто расширяются для сложных продуктов.  

• Важно создавать архитектуру и хелперы для работы с файлами и данными.  

• Используются стандартные инструменты для логирования времени выполнения тестов.  

• Создается слушатель для отслеживания времени старта и завершения тестов.  

• Важно отражать все возможные варианты завершения тестов.  

• Архитектура классов включает уровни хелперов и тестовых сценариев.  

• Хелперы могут использовать различные паттерны, такие как пейдж-объекты.  

• Тестовые классы имеют стандартную структуру с выделением текстур и инициализацией.  

• Тестовые сценарии хранятся в отдельном инструменте, обслуживаемом ручными тестировщиками.  

• Автоматизаторы могут оставлять комментарии для улучшения тестовых сценариев.  

• Используется аннотация для ссылки на тестовые сценарии в TFS.  

• Java является объектно-ориентированным языком строгой типизации.  

• Основные принципы: инкапсуляция, полиморфизм, наследование и абстракция.  

• Существуют дополнительные принципы, такие как SOLID, которые помогают писать качественный код.  

• Использование паттернов для улучшения читаемости и удобства кода.  

• Модификатор static позволяет обращаться к методам и свойствам по имени класса, а не по имени объекта.  

• Константы в Java пишутся с использованием модификатора static для стабильности.  

• Интерфейсы в Java позволяют обойти ограничение наследования от одного родителя.  

• Абстрактные классы требуют реализации методов в дочерних классах.  

• Абстрактные классы не могут быть созданы напрямую, но их методы обязательны для реализации.  

• Выделение классов для авторизации и метчеров для общих паттернов.  

• Использование классов для парсинга и модификации JSON-данных.  

• Применение библиотек, таких как Lombok, для упрощения работы с данными.  

• Проблемы с транзитивными зависимостями в Kotlin могут привести к нестабильной работе.  

• Обновление библиотек может вызвать проблемы с совместимостью.  

• Важно учитывать обратную совместимость при работе с библиотеками.  

• Процесс валидации email на стороне сервера и браузера.  

• Автоматизация тестирования email-подписки с учетом различных сценариев ввода.  

• Проверка корректности обработки различных символов и доменов.  

• Важность атомарности в тестировании.  

• Использование запросов для проверки системы на разных этапах.  

• Избегание длительных подготовительных действий для тестирования.  

• Объединение тестовых сценариев для экономии времени.  

• Использование рефреша для обновления страницы.  

• Минимизация действий в UI-тестировании.  

• В мобильных устройствах UI-тесты преобладают над API-тестами.  

• В приложениях UI-тесты должны быть минимизированы.  

• Тестирование серверной функциональности и работы с базой данных.  

• Выяснение потребностей сотрудников в хардкорных задачах.  

• Регулярные встречи для обсуждения технологических фишек.  

• Прокачка коммуникативных и менеджерских навыков.  

• Предупреждение сотрудников о толерантности в команде.  

• Пресечение дискриминации и оскорблений.  

• Конструктивные разговоры и возможные меры при повторных нарушениях.  

• Впечатления от интервью и роль адвоката автоматизации.  

• Важность опыта работы в банковской сфере.  

• Подход к выстраиванию процессов в ограниченных условиях.  

• Важность распространения культуры автоматизации на всю команду и компанию.  

• Прозрачность в объяснении процессов и результатов автоматизации.  

• Важность метрик и культуры в компании.  

• Высокий уровень опыта и готовность отвечать на вопросы.  

• Подход к пипл-менеджменту как к наставничеству и обучению.  

• Отсутствие стремления к захвату авторитета.  

• Важность создания культуры и комьюнити в команде.  

• Учет типов личностей в команде и их взаимодействие.  

• Команда важнее техники, токсичные люди должны быть исключены.  

• Важность ручного тестирования новых фич.  

• Ограниченные условия и невозможность активного вовлечения в другие уровни разработки.  

• Возможность развития в других областях.  

• Восторг от интервью и благодарность за советы.  

• Советы для коллег: уважать и любить свое дело, читать литературу, делегировать, показывать пример развития, фиксировать договоренности, не критиковать публично.  

• Важность создания культуры, при которой люди задают вопросы и работают в едином направлении.