Заметки о QA
Блок-схема локализации бага: фронт или бэкенд?
Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно?
Здесь многое зависит от специфики вашей работы и особенностей сервера. Однако для общих случаев подойдёт и предложенная мной блок-схема, поэтому верю пользе от нее💫.
(в хорошем качестве блок-схема представлена в следующем сообщении)
UPD общее правило: если ошибка была, а UI ее не вывел и бэк повел себя неправильно, баг и на UI, и на бэк
Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно?
Здесь многое зависит от специфики вашей работы и особенностей сервера. Однако для общих случаев подойдёт и предложенная мной блок-схема, поэтому верю пользе от нее💫.
(в хорошем качестве блок-схема представлена в следующем сообщении)
UPD общее правило: если ошибка была, а UI ее не вывел и бэк повел себя неправильно, баг и на UI, и на бэк
Практики хорошего кода
Чем дольше я программировала, тем больше понимала, насколько много ошибок было у меня в самом начале пути. Сегодня я хочу немного погрузиться в инструменты, подходы и принципы, которые позволят создавать качественный код с самого начала.
Что помогает нам создавать красивый и расширяемый код:
- Использование практик написания хорошего кода: они позволят навести порядок в коде, упростить расширение проекта и переиспользовать код, но сохранять при этом логику и читаемость и много чего еще.
- Применение популярных паттернов проектирования и автоматизации, которые были уже проверены ни раз до нас: помогут найти типичный вариант рабочей структуры, что позволит не строить велосипед.
- Проведение ревью в команде: обзор кода помогает выявить потенциальные проблемы и предложить улучшения, которые мог упустить человек, писавший код.
- Соблюдение руководства по стилю и подключение библиотек, которые эти стили проверяют: одинаковые правила к коду позволят улучшить читаемость, быстрее решать спорные вещи в ревью и создавать согласованный код, что позволит избежать стандартных ошибок. А также позволит не создавать трех одинаковых методов, отличающихся только названием
- Документирование и комментирование кода: комментирование методов и классов упростит переиспользование методов и ускорит чтение кода. Поподробнее советую почитать в этой статье.
Про паттерны автоматизации я уже писала в этом посте, а сейчас хочу поговорить про практики написания кода.
В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YAGNI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть.
#автоматизация
Чем дольше я программировала, тем больше понимала, насколько много ошибок было у меня в самом начале пути. Сегодня я хочу немного погрузиться в инструменты, подходы и принципы, которые позволят создавать качественный код с самого начала.
Что помогает нам создавать красивый и расширяемый код:
- Использование практик написания хорошего кода: они позволят навести порядок в коде, упростить расширение проекта и переиспользовать код, но сохранять при этом логику и читаемость и много чего еще.
- Применение популярных паттернов проектирования и автоматизации, которые были уже проверены ни раз до нас: помогут найти типичный вариант рабочей структуры, что позволит не строить велосипед.
- Проведение ревью в команде: обзор кода помогает выявить потенциальные проблемы и предложить улучшения, которые мог упустить человек, писавший код.
- Соблюдение руководства по стилю и подключение библиотек, которые эти стили проверяют: одинаковые правила к коду позволят улучшить читаемость, быстрее решать спорные вещи в ревью и создавать согласованный код, что позволит избежать стандартных ошибок. А также позволит не создавать трех одинаковых методов, отличающихся только названием
- Документирование и комментирование кода: комментирование методов и классов упростит переиспользование методов и ускорит чтение кода. Поподробнее советую почитать в этой статье.
Про паттерны автоматизации я уже писала в этом посте, а сейчас хочу поговорить про практики написания кода.
В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YAGNI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть.
#автоматизация
Мой личный путь и поиск карьерного развития
Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше.
Во время подготовки к мероприятию я задумывалась о своем пути в тестировании и о том, как я ищу новые горизонты для своего профессионального роста. И вот что произошло: я обнаружила, что у меня есть план, по которому я составляю свой карьерный трек и ставлю цели на ближайшее время.
Теперь я хочу поделиться этим планом с вами:
📝Составление плана развития
Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸
Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!
Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше.
Во время подготовки к мероприятию я задумывалась о своем пути в тестировании и о том, как я ищу новые горизонты для своего профессионального роста. И вот что произошло: я обнаружила, что у меня есть план, по которому я составляю свой карьерный трек и ставлю цели на ближайшее время.
Теперь я хочу поделиться этим планом с вами:
📝Составление плана развития
Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸
Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!
Блок-схема "Как выбрать язык программирования для автоматизации"
В чек-листе перехода в автоматизацию (тык) я писала не только о необходимых для автоматизации навыках, но и о списке действий, которые могут помочь вам перейти в автоматизацию или развивать ее на текущем проекте.
Один из главных пунктов начала знакомства с автоматизацией - это выбрать язык программирования.
Я уже отмечала, что на этом этапе важнее выбрать язык и развиваться в нем, а не зарыться в выбор языка, так как на реальных работах вы можете поработать на многих языках программирования. Важнее уметь программировать, а не на чем вы это делаете.
Часто бывает, что именно выбрать язык - это огромный шаг, который нас останавливает. Поэтому я постаралась немного облегчить решение и подготовила схему выбора первого языка программирования. Надеюсь, мне удалось учесть большинство особенностей, которые могут возникнуть на этом шаге, но если нет, рада буду почитать комментарии.
В чек-листе перехода в автоматизацию (тык) я писала не только о необходимых для автоматизации навыках, но и о списке действий, которые могут помочь вам перейти в автоматизацию или развивать ее на текущем проекте.
Один из главных пунктов начала знакомства с автоматизацией - это выбрать язык программирования.
Я уже отмечала, что на этом этапе важнее выбрать язык и развиваться в нем, а не зарыться в выбор языка, так как на реальных работах вы можете поработать на многих языках программирования. Важнее уметь программировать, а не на чем вы это делаете.
Часто бывает, что именно выбрать язык - это огромный шаг, который нас останавливает. Поэтому я постаралась немного облегчить решение и подготовила схему выбора первого языка программирования. Надеюсь, мне удалось учесть большинство особенностей, которые могут возникнуть на этом шаге, но если нет, рада буду почитать комментарии.
Как_выбирать_язык_программирования_для_автоматизации_drawio.png
523.2 KB
Блок-схема в хорошем качестве
Кратко повторю на что ориентироваться при выборе языка:
1. Область, в которой вы хотите автоматизировать (UI для web, desktop, backend, mobile), : при выборе языка также нужно учитывать что вы хотите автоматизировать: для мобильных чаще используется Swift и Kotlin.
2. Язык, используемый на работе мечты: изучить рынок, выбрать компании, которые сильнее всего вас привлекают и выбрать для изучения их язык программирования
3. Востребованность в области и в конкретной компании: например, какие языки чаще мелькают в вакансиях.
4. Простота и популярность (Python проще в освоении с нуля, Java даст отличное понимание ООП, но сложнее для освоения)
5. Язык, базу которого вы уже изучали
6. Знакомые/менторы/разработчики, которые могут помочь
Кратко повторю на что ориентироваться при выборе языка:
1. Область, в которой вы хотите автоматизировать (UI для web, desktop, backend, mobile), : при выборе языка также нужно учитывать что вы хотите автоматизировать: для мобильных чаще используется Swift и Kotlin.
2. Язык, используемый на работе мечты: изучить рынок, выбрать компании, которые сильнее всего вас привлекают и выбрать для изучения их язык программирования
3. Востребованность в области и в конкретной компании: например, какие языки чаще мелькают в вакансиях.
4. Простота и популярность (Python проще в освоении с нуля, Java даст отличное понимание ООП, но сложнее для освоения)
5. Язык, базу которого вы уже изучали
6. Знакомые/менторы/разработчики, которые могут помочь
Про правильное формулирование, мета-вопросы и решение проблем путем редких ответов
Чем дольше я работаю и общаюсь с людьми, тем чаще понимаю, как правильно сформулированный вопрос ускоряет процесс решения проблемы.
Например, сегодня ко мне пришли с запросом "Не могу найти документ в системе, помоги".
Я полезла в базу данных и логи двух микросервисов, чтобы проследить путь документа и обнаружила, что документ доставлен до системы.
После проведенного исследования и предоставления ссылки на документ, я получила ответ: "Да, ссылка на документ у меня есть. Но вот в другую систему он не направился, а еще в статусе ошибки подписи".
Тут возникает вопрос: значит коллега знал, что документ дошел до системы, но все равно спросил, где документ? Соответственно вопрос в поиске документа не стоял, а запрос оказался в другом: почему подпись не отработала. Из чего следует, что путь документа нам не нужно было отслеживать и я зря потратила на это свое время.
Если бы коллега сформулировал вопрос сразу с подробностями, это сэкономило бы мне минимум 10 минут и сохранило бы силы на решение более насущного вопроса, а именно почему в подписи возникли проблемы.
Проблемы с формулированием вопросов встречается постоянно, поэтому следует тщательнее подходить к этой задаче. Оттого, насколько качественно сформулирован вопрос, настолько же полноценно будет дан ответ на него.
Как лучше формулировать вопрос:
- описать, где и когда произошла проблема
- перечислить, какие данные по проблеме собраны
- описать, какие действия уже были проделаны для решения (шаг необходим, чтобы собеседник не предлагал вам уже сделанные действия)
- объяснить, что требуется от человека, чтобы он тебе помог
Перед отправкой перечитайте сообщение и проверьте, нет ли уже ответа на ваш вопрос в нем же.
Примеры
Плохой вопрос:
я не могу понять, как замержить в репозиторий autotest
Хороший вопрос:
Мне нужно замержить новые автотесты в ветку master.
При попытке мержа через консоль у меня возникает ошибка 403.
Я пытался сменить пароль на новый, но это не помогло. Google подсказал, что ошибка может возникать из-за прав доступа к мастеру, но я их не могу посмотреть.
Можешь ли ты объяснить, куда мне сходить для получения прав, или объяснить, что еще можно сделать?
В таком случае человек сразу поймет, что ошибка заключалась в мерже в мастер без дополнительной ветки, ведь в их репозитории это запрещено. И объяснит, какой список действий нужно проделать для мержа.
Что можно попробовать сделать, если вам задают плохо сформулированные вопросы
Чаще всего причина плохих вопросов в лени их формулирования. В этом может помочь игнорирование вопросы на 30 минут: через пол часа вопрос порой пропадает сам по себе или становится нормально сформулированным с описанием собранных материалов и проделанных шагов.
Мета-вопросы
В связки с формулированием вопросов, я бы порекомендовала вам почитать про мета-вопросы, которые съедают не только ваше время, но и время собеседника.
Пример мета-вопроса простой: когда ты вместо формулирования вопроса, просто пишешь "Тут?" и отвлекаешь собеседника. Подробнее почитайте по ссылке.
Важно помнить, правильно сформулированный вопрос - это уже половина ответа на него.
#softSkills
Чем дольше я работаю и общаюсь с людьми, тем чаще понимаю, как правильно сформулированный вопрос ускоряет процесс решения проблемы.
Например, сегодня ко мне пришли с запросом "Не могу найти документ в системе, помоги".
Я полезла в базу данных и логи двух микросервисов, чтобы проследить путь документа и обнаружила, что документ доставлен до системы.
После проведенного исследования и предоставления ссылки на документ, я получила ответ: "Да, ссылка на документ у меня есть. Но вот в другую систему он не направился, а еще в статусе ошибки подписи".
Тут возникает вопрос: значит коллега знал, что документ дошел до системы, но все равно спросил, где документ? Соответственно вопрос в поиске документа не стоял, а запрос оказался в другом: почему подпись не отработала. Из чего следует, что путь документа нам не нужно было отслеживать и я зря потратила на это свое время.
Если бы коллега сформулировал вопрос сразу с подробностями, это сэкономило бы мне минимум 10 минут и сохранило бы силы на решение более насущного вопроса, а именно почему в подписи возникли проблемы.
Проблемы с формулированием вопросов встречается постоянно, поэтому следует тщательнее подходить к этой задаче. Оттого, насколько качественно сформулирован вопрос, настолько же полноценно будет дан ответ на него.
Как лучше формулировать вопрос:
- описать, где и когда произошла проблема
- перечислить, какие данные по проблеме собраны
- описать, какие действия уже были проделаны для решения (шаг необходим, чтобы собеседник не предлагал вам уже сделанные действия)
- объяснить, что требуется от человека, чтобы он тебе помог
Перед отправкой перечитайте сообщение и проверьте, нет ли уже ответа на ваш вопрос в нем же.
Примеры
Плохой вопрос:
я не могу понять, как замержить в репозиторий autotest
Хороший вопрос:
Мне нужно замержить новые автотесты в ветку master.
При попытке мержа через консоль у меня возникает ошибка 403.
Я пытался сменить пароль на новый, но это не помогло. Google подсказал, что ошибка может возникать из-за прав доступа к мастеру, но я их не могу посмотреть.
Можешь ли ты объяснить, куда мне сходить для получения прав, или объяснить, что еще можно сделать?
В таком случае человек сразу поймет, что ошибка заключалась в мерже в мастер без дополнительной ветки, ведь в их репозитории это запрещено. И объяснит, какой список действий нужно проделать для мержа.
Что можно попробовать сделать, если вам задают плохо сформулированные вопросы
Чаще всего причина плохих вопросов в лени их формулирования. В этом может помочь игнорирование вопросы на 30 минут: через пол часа вопрос порой пропадает сам по себе или становится нормально сформулированным с описанием собранных материалов и проделанных шагов.
Мета-вопросы
В связки с формулированием вопросов, я бы порекомендовала вам почитать про мета-вопросы, которые съедают не только ваше время, но и время собеседника.
Пример мета-вопроса простой: когда ты вместо формулирования вопроса, просто пишешь "Тут?" и отвлекаешь собеседника. Подробнее почитайте по ссылке.
Важно помнить, правильно сформулированный вопрос - это уже половина ответа на него.
#softSkills
Чем могут быть полезны Extensions в JUnit5
Extensions - список интерфейсов, которые появились в JUnit5. Они расширяют работу с жизненным циклом в автотестах.
Чем поможет
Сделает работу с автотестами гибкими.
Например, раньше мы могли работать в рамках автотеста только с Before и After. Благодаря extensions вы можете значительно повлиять на работу автотестов, сравните хотя бы количество этапов в жизненном цикле (картинка по ЖЦ автотеста в junit5).
Теперь легко повесить общую аннотацию @Something на класс автотестов, внутри которой будет реализация полноценной настройки окружения. Это позволит не дописывать в каждом новом классе велосипед, настраивающий окружение.
Примеры использования интерфейсов
- ExcisionCondition: может создать условие для запуска теста. Например, вы хотите запускать тесты только на ОС = Windows. Мы создаем реализацию класса и особенности запуска, добавляем его к классу и вуаля, ваш тест имеет особенности запуска.
- ParameterResolver: позволяет предоставить параметры для автотестов. Например, у вас специфический тип в параметрах, и вам нужно гибко его передавать, а стандартной работы JUnit5 вам не хватает.
- TestWatcher позволяет сделать что-то при падении или запуске теста. Он следит за тестами и ходом их выполнения.
(полная документация всех интерфейсов в extension)
В рамках extension мне очень нравится такой класс как ExecutionContext, который позволяет получить доступ к данным о тесте, его местонахождении, параметрам запускам и всем-всем, связанным с тестом.
Что почитать/посмотреть
Я познакомилась с Extensions благодаря выступлениям Дмитрия Тучс, которые рекомендую и вам:
- Дополнительная открытая лекция с продвинутого курса по Java, где я впервые услышала про extensions
- JUnit, дай пять! Переносим код в JUnit 5 Extensions
- Доклад The art of JUnit extensions с Heisenbug и The art of JUnit extensions 2
Прочие полезные материалы:
Статья про практическое применение Extensions (kotlin)
Полное руководство по расширениям JUnit 5 (java)
Практическое применение Extensions с канала Oleh Pendrak
Руководство по расширениям JUnit 5
#junit #автоматизация
Extensions - список интерфейсов, которые появились в JUnit5. Они расширяют работу с жизненным циклом в автотестах.
Чем поможет
Сделает работу с автотестами гибкими.
Например, раньше мы могли работать в рамках автотеста только с Before и After. Благодаря extensions вы можете значительно повлиять на работу автотестов, сравните хотя бы количество этапов в жизненном цикле (картинка по ЖЦ автотеста в junit5).
Теперь легко повесить общую аннотацию @Something на класс автотестов, внутри которой будет реализация полноценной настройки окружения. Это позволит не дописывать в каждом новом классе велосипед, настраивающий окружение.
Примеры использования интерфейсов
- ExcisionCondition: может создать условие для запуска теста. Например, вы хотите запускать тесты только на ОС = Windows. Мы создаем реализацию класса и особенности запуска, добавляем его к классу и вуаля, ваш тест имеет особенности запуска.
- ParameterResolver: позволяет предоставить параметры для автотестов. Например, у вас специфический тип в параметрах, и вам нужно гибко его передавать, а стандартной работы JUnit5 вам не хватает.
- TestWatcher позволяет сделать что-то при падении или запуске теста. Он следит за тестами и ходом их выполнения.
(полная документация всех интерфейсов в extension)
В рамках extension мне очень нравится такой класс как ExecutionContext, который позволяет получить доступ к данным о тесте, его местонахождении, параметрам запускам и всем-всем, связанным с тестом.
Что почитать/посмотреть
Я познакомилась с Extensions благодаря выступлениям Дмитрия Тучс, которые рекомендую и вам:
- Дополнительная открытая лекция с продвинутого курса по Java, где я впервые услышала про extensions
- JUnit, дай пять! Переносим код в JUnit 5 Extensions
- Доклад The art of JUnit extensions с Heisenbug и The art of JUnit extensions 2
Прочие полезные материалы:
Статья про практическое применение Extensions (kotlin)
Полное руководство по расширениям JUnit 5 (java)
Практическое применение Extensions с канала Oleh Pendrak
Руководство по расширениям JUnit 5
#junit #автоматизация
Подборка каналов про тестирование
В начале этого года я делилась с вами подборкой tg-каналов про тестирование.
С тех пор прошло больше полугода, и мы тщательно пересмотрели этот список, чтобы убедиться, что каждый канал предлагает уникальный и ценный контент.
Сегодня я рада представить вам обновлённую версию этой подборки!
Готовы погрузиться в мир тестирования? Тогда жмите на ссылку ниже и начинайте исследовать! 🌐
https://www.tgoop.com/addlist/PNmSaWa9ktw2YjRi
В начале этого года я делилась с вами подборкой tg-каналов про тестирование.
С тех пор прошло больше полугода, и мы тщательно пересмотрели этот список, чтобы убедиться, что каждый канал предлагает уникальный и ценный контент.
Сегодня я рада представить вам обновлённую версию этой подборки!
Готовы погрузиться в мир тестирования? Тогда жмите на ссылку ниже и начинайте исследовать! 🌐
https://www.tgoop.com/addlist/PNmSaWa9ktw2YjRi
Telegram
QA Лучшее
Anton Duenin invites you to add the folder “QA Лучшее”, which includes 46 chats.
Полезное про Selenoid
Selenoid - инструмент, который позволит вам запускать ваши UI или Anrdoid автотесты параллельно и изолированно в Docker-контейнерах. Рекомендую для первоначального ознакомления обзорный гайд по Selenoid
Мне нравится этот инструмент легкостью использования и минимальным порогом вхождения. На вашем компьютере всего лишь должен быть docker, в котором будут разворачиваться уже настроенные docker-контейнеры.
Варианты запуска Selenoid
1️⃣Скачать подготовленный образ с помощью curl или через браузер из официального github
Инструкцию для запуска образа можно почитать в документации либо рекомендую статья для windows.
Для macOS мне подошла вот эта статья (это medium, поэтому запуск через VPN)
2️⃣Самостоятельно создать docker образ (либо docker-compose), файл конфигурации браузеров (browser.json) и запустить сборку контейнеров через консоль.
Самостоятельное создание позволит гибко подойти к образу, необходимым вам браузерам и их настройкам
Примеры для самостоятельного создания
- Минимальный пример написания docker compose и browser.json
- Пример docker compose + browser.json и описание работы
- Настройка Selenoid для запуска UI-тестов на Android
Функции, которые понравились мне
➖Selenoid UI: инструмент для визуального отображения работы с Selenoid. Позволяет просматривать результаты тестов и прочую информацию, а также подключаться к тестам в режиме реального времени*
для этого необходимо включить опцию VNC в capabilities
➖ Доступ к видеозаписям прогонов
В инструменте есть возможность записи видео прохождения автотестов.
Мне кажется, что это очень удобная функция для добавления видео в баг-репорт.
В процессе работы я столкнулась с проблемой того, что видео прогона не записывалось. Что помогло мне:
- настроить файл docker-compose.yml: указать пути к папкам, где будут сохраняться видеозаписи, и прописать соответствующие команды в command
- создать папки для дублирования видео из docker в файлы
- настроить capabilities* в автотестах, которые можно подсмотреть на соответствующей вкладке в Selenoid UI
* Capabilities определяют возможности браузера во время тестирования
Также для кастомизации запуска видео рекомендую статью про Extensions (Java)
Прочие рекомендации
Более подробный пример работы с Selenoid (Java)
Selenoid - инструмент, который позволит вам запускать ваши UI или Anrdoid автотесты параллельно и изолированно в Docker-контейнерах. Рекомендую для первоначального ознакомления обзорный гайд по Selenoid
Мне нравится этот инструмент легкостью использования и минимальным порогом вхождения. На вашем компьютере всего лишь должен быть docker, в котором будут разворачиваться уже настроенные docker-контейнеры.
Варианты запуска Selenoid
1️⃣Скачать подготовленный образ с помощью curl или через браузер из официального github
Инструкцию для запуска образа можно почитать в документации либо рекомендую статья для windows.
Для macOS мне подошла вот эта статья (это medium, поэтому запуск через VPN)
2️⃣Самостоятельно создать docker образ (либо docker-compose), файл конфигурации браузеров (browser.json) и запустить сборку контейнеров через консоль.
Самостоятельное создание позволит гибко подойти к образу, необходимым вам браузерам и их настройкам
Примеры для самостоятельного создания
- Минимальный пример написания docker compose и browser.json
- Пример docker compose + browser.json и описание работы
- Настройка Selenoid для запуска UI-тестов на Android
Функции, которые понравились мне
➖Selenoid UI: инструмент для визуального отображения работы с Selenoid. Позволяет просматривать результаты тестов и прочую информацию, а также подключаться к тестам в режиме реального времени*
для этого необходимо включить опцию VNC в capabilities
➖ Доступ к видеозаписям прогонов
В инструменте есть возможность записи видео прохождения автотестов.
Мне кажется, что это очень удобная функция для добавления видео в баг-репорт.
В процессе работы я столкнулась с проблемой того, что видео прогона не записывалось. Что помогло мне:
- настроить файл docker-compose.yml: указать пути к папкам, где будут сохраняться видеозаписи, и прописать соответствующие команды в command
- создать папки для дублирования видео из docker в файлы
- настроить capabilities* в автотестах, которые можно подсмотреть на соответствующей вкладке в Selenoid UI
* Capabilities определяют возможности браузера во время тестирования
Также для кастомизации запуска видео рекомендую статью про Extensions (Java)
Прочие рекомендации
Более подробный пример работы с Selenoid (Java)
Советы для автоматизации [2]
Первую часть советов можно почитать тут, также рекомендую полезные советы по инструментам для программирующих на Java.
- Автоматизация тестирования - это инструмент для достижения цели, а не сама цель.
Часто, когда работаешь full-stack QA, легко увлечься автоматизацией и улучшением кода, забывая о главном — обеспечении качества функционала.
Поэтому хочется напомнить, что автоматизировать нужно для того, чтобы это приносило пользу бизнесу и помогало улучшить качество продукта, а не просто для того, чтобы писать код.
- Чаще учите и используйте горячие клавиши в своей IDE.
Не ленитесь запоминать сочетания клавиш в ваших средах разработки. Это поможет ускорить процесс написания кода и облегчить вам ежедневные повторяющиеся действия.
Мои любимые сочетания клавиш (macOS, IntelliJ IDEA):
cmd + click (либо b) - отображение, где метод/класс/прочее используется в коде
double shift - быстрый переход к классу/функции
option + cmd + l - форматирование кода (сделать по всему классу правильные отступы)
cmd + w - закрытие вкладки
control + options + o - удаление неиспользуемых импортов (также рекомендую включить автоматическое удаление таких импортов)
shift + options + click - курсор на несколько строк
cmd + d - дублирование строки без ее выделения и копирования
(буду рада увидеть ваши любимые горячие клавиши в комментариях)
- Тэгируйте автотесты для гибкого управления.
Последнее время я стала больше ценить тэгирование и кастомизацию запуска прогонов. Чем больше становится тестов, тем проще запускать не все подряд, а только те, с которыми ты сейчас работаешь.
На помощь приходят аннотации для тэгов, которые можно найти практически для любого фреймворка тестирования.
- Разрабатывайте тестовые сценарии, учитывая реальных пользователей API.
Покрывать тесты и придумывать варианты использования - это хорошо. Но иногда эффективнее заглянуть к тем, кто использует бэкенд. Например, фронтенд.
Изучите, какие данные отправляются, какие запросы участвуют в работе и как происходит обработка ответа. Есть ли вариации, которые не описаны в ваших автотестах? Ведь именно реальные пользователи бэкенда находят баги, а не тесты в вакууме.
- Воспринимайте ревью кода как возможность для роста.
Изначально ревью кода вызывал у меня страх и напряжение. Но постепенно я научилась воспринимать ревью как полезный инструмент: именно в процессе ревью я улучшала качество своего кода и училась новым фишкам.
Ревью кода позволяет другим указать на недостатки, которые вы могли пропустить, и научить вас больше не повторять такие ошибки.
- Используйте плагины для поддержания стиля кода.
Одним из способов улучшить качество кода и упростить процесс ревью является использование линтеров, например, Checkstyle. Они позволяют автоматически проверять ваш код на наличие распространенных ошибок.
Например, подсветит вам неиспользуемые методы, усложнение кода и прочие несоответствия стилю.
Такие инструменты помогут поддерживать высокое качество кода и избегать мелких ошибок, которые так и норовят образоваться в коде.
See you soon
#автоматизация #java #советы
Первую часть советов можно почитать тут, также рекомендую полезные советы по инструментам для программирующих на Java.
- Автоматизация тестирования - это инструмент для достижения цели, а не сама цель.
Часто, когда работаешь full-stack QA, легко увлечься автоматизацией и улучшением кода, забывая о главном — обеспечении качества функционала.
Поэтому хочется напомнить, что автоматизировать нужно для того, чтобы это приносило пользу бизнесу и помогало улучшить качество продукта, а не просто для того, чтобы писать код.
- Чаще учите и используйте горячие клавиши в своей IDE.
Не ленитесь запоминать сочетания клавиш в ваших средах разработки. Это поможет ускорить процесс написания кода и облегчить вам ежедневные повторяющиеся действия.
Мои любимые сочетания клавиш (macOS, IntelliJ IDEA):
cmd + click (либо b) - отображение, где метод/класс/прочее используется в коде
double shift - быстрый переход к классу/функции
option + cmd + l - форматирование кода (сделать по всему классу правильные отступы)
cmd + w - закрытие вкладки
control + options + o - удаление неиспользуемых импортов (также рекомендую включить автоматическое удаление таких импортов)
shift + options + click - курсор на несколько строк
cmd + d - дублирование строки без ее выделения и копирования
(буду рада увидеть ваши любимые горячие клавиши в комментариях)
- Тэгируйте автотесты для гибкого управления.
Последнее время я стала больше ценить тэгирование и кастомизацию запуска прогонов. Чем больше становится тестов, тем проще запускать не все подряд, а только те, с которыми ты сейчас работаешь.
На помощь приходят аннотации для тэгов, которые можно найти практически для любого фреймворка тестирования.
- Разрабатывайте тестовые сценарии, учитывая реальных пользователей API.
Покрывать тесты и придумывать варианты использования - это хорошо. Но иногда эффективнее заглянуть к тем, кто использует бэкенд. Например, фронтенд.
Изучите, какие данные отправляются, какие запросы участвуют в работе и как происходит обработка ответа. Есть ли вариации, которые не описаны в ваших автотестах? Ведь именно реальные пользователи бэкенда находят баги, а не тесты в вакууме.
- Воспринимайте ревью кода как возможность для роста.
Изначально ревью кода вызывал у меня страх и напряжение. Но постепенно я научилась воспринимать ревью как полезный инструмент: именно в процессе ревью я улучшала качество своего кода и училась новым фишкам.
Ревью кода позволяет другим указать на недостатки, которые вы могли пропустить, и научить вас больше не повторять такие ошибки.
- Используйте плагины для поддержания стиля кода.
Одним из способов улучшить качество кода и упростить процесс ревью является использование линтеров, например, Checkstyle. Они позволяют автоматически проверять ваш код на наличие распространенных ошибок.
Например, подсветит вам неиспользуемые методы, усложнение кода и прочие несоответствия стилю.
Такие инструменты помогут поддерживать высокое качество кода и избегать мелких ошибок, которые так и норовят образоваться в коде.
See you soon
#автоматизация #java #советы
Как рассказать о себе на собеседовании?
Один из этапов собеседования - это рассказ о себе.
Зачем рассказывать о себе? Ведь кажется, что резюме уже отражает весь опыт кандидата. Но в живом рассказе выделяются детали, которые важны для самого человека, подробности о процессах в компании и роли в команде, огонь в глазах при рассказе о любимом рабочем процессе и много чего ещё, что позволяет лучше понять, подходит ли кандидат нанимающей компании.
Для ускорения вашей подготовки к этапу самопрезентации, хочу поделиться планом, на базе которого я строю свой рассказ.
1. Имя, должность и количество лет в профессии.
2. Рассказ о последнем месте работы.
- продукт
- состав команды
- занимаемая роль
- обязанности
- соотношение автоматизации/мануального тестирования, web/mobile/desktop
3. Стек инструментов.
4. Рабочие процессы.
- методология разработки на проекте
- события команды (рабочие созвоны по типу дейли, груммингов, планирования)
- степень влияния на продукт
- участие в ревью документации
- этап создания продукта, на котором начинаешь тестирование
- участие во вне командных активностях компании
5. Зоны ответственности в команде/компании.
- проведение релиза
- онбординг
- внедрение продуктов
- проведение собеседований
- особые достижения, на которые хочется обратить внимание
6. Подчеркнуть релевантный опыт для компании.
Дополнительно можно рассказать о том, что ты ищешь в новой работе и почему хочешь сменить текущее место.
Добавлю, что мне, как собеседующей, всегда приятно услышать цельный рассказ о человеке, а не вытаскивать плоскогубцами каждое слово.
Полезный материал
1. Youtube-видео Самопрезентация учит нас доносить идеи
#собеседование
Один из этапов собеседования - это рассказ о себе.
Зачем рассказывать о себе? Ведь кажется, что резюме уже отражает весь опыт кандидата. Но в живом рассказе выделяются детали, которые важны для самого человека, подробности о процессах в компании и роли в команде, огонь в глазах при рассказе о любимом рабочем процессе и много чего ещё, что позволяет лучше понять, подходит ли кандидат нанимающей компании.
Для ускорения вашей подготовки к этапу самопрезентации, хочу поделиться планом, на базе которого я строю свой рассказ.
1. Имя, должность и количество лет в профессии.
2. Рассказ о последнем месте работы.
- продукт
- состав команды
- занимаемая роль
- обязанности
- соотношение автоматизации/мануального тестирования, web/mobile/desktop
3. Стек инструментов.
4. Рабочие процессы.
- методология разработки на проекте
- события команды (рабочие созвоны по типу дейли, груммингов, планирования)
- степень влияния на продукт
- участие в ревью документации
- этап создания продукта, на котором начинаешь тестирование
- участие во вне командных активностях компании
5. Зоны ответственности в команде/компании.
- проведение релиза
- онбординг
- внедрение продуктов
- проведение собеседований
- особые достижения, на которые хочется обратить внимание
6. Подчеркнуть релевантный опыт для компании.
Дополнительно можно рассказать о том, что ты ищешь в новой работе и почему хочешь сменить текущее место.
Добавлю, что мне, как собеседующей, всегда приятно услышать цельный рассказ о человеке, а не вытаскивать плоскогубцами каждое слово.
Полезный материал
1. Youtube-видео Самопрезентация учит нас доносить идеи
#собеседование
🎄Новогодние советы 2.0🎄
Я очень люблю подводить черту: составлять достижения, писать списки, подготовить итоги. Листая свой телеграм-канал, я попала на новогодние советы. И захотелось повторить небольшие советы-размышления и в этом году!
Про баги
- За баг нет одного ответственного - это часть общих усилий и ошибок. Аналитик не прописал требование, разработчик не добавил это в код, тестировщик пропустил при проверках. Не обвиняй только себя, лучше постарайся сделать вывод и не повторять ошибок.
- Баги на проде - это часть работы тестировщика, а не наша смерть. Когда мне говорят, что не пропускали на прод серьезный баг, то у меня есть три объяснения: ты единорог, в твоем продукте нет пользователя или ты еще не нашел этот пропущенный баг. Баг пропускали все, это часть рабочего процесса.
Общение с другими участниками команды
- Обязательно записывай все артефакты, которые возникают в процессе обсуждения. Это позволит вспомнить, о чем вы говорили, не упустить todo и иметь аргументы во время спорных моментов.
- Формулируй свой вопрос, проведя предварительное исследование. Мне часто хочется побыстрее написать с вопросом другому участнику команды, не изучив вопросов поглубже. И иногда это заканчивается тем, что я использую другого человека как уточку и просто зря трачу его время. Не делай так, подходи к этому ответственно.
Про планирование и время
- Намечай свой карьерный путь. План помогает упростить движение к цели, а отсутствие плана заставляет прыгать с места на место и терять время на вещи, которые тебе не интересны. Не поленись и подумай, что ты хочешь от работы. Это позволит тебе быстрее вырасти.
- Научись оценивать свое рабочее время. В этом году я плотно подсела на toggl track (наконец!). Сейчас я четко могу сказать, чем я занимаюсь, сколько я этим занимаюсь и прогнозировать сколько еще я буду этим заниматься. Рекомендую!
- Не переживай, если не понял с первого/второго/десятого раза. Все знания, которые ты получаешь, смогут помочь тебе в будущем, даже если кажется, что это не так. И ты обязательно когда-нибудь поймешь! Дай мозгу сделать свою работу.
- Очень часто стоит потратить время на то, что ты откладываешь. Например, наконец научиться запускать автотесты через консоль, а не руками. Или написать свод правил для работы. Кажется, что это не сильно ускорит работу, но практика показывает, что ускорение/упрощение/изменение рутины приводит к повышению эффективности.
- Критерии приемки - это круто! Тут добавить нечего.
И пусть каждая ошибка приносит вам опыт, а не боль. С наступающим 💫
Я очень люблю подводить черту: составлять достижения, писать списки, подготовить итоги. Листая свой телеграм-канал, я попала на новогодние советы. И захотелось повторить небольшие советы-размышления и в этом году!
Про баги
- За баг нет одного ответственного - это часть общих усилий и ошибок. Аналитик не прописал требование, разработчик не добавил это в код, тестировщик пропустил при проверках. Не обвиняй только себя, лучше постарайся сделать вывод и не повторять ошибок.
- Баги на проде - это часть работы тестировщика, а не наша смерть. Когда мне говорят, что не пропускали на прод серьезный баг, то у меня есть три объяснения: ты единорог, в твоем продукте нет пользователя или ты еще не нашел этот пропущенный баг. Баг пропускали все, это часть рабочего процесса.
Общение с другими участниками команды
- Обязательно записывай все артефакты, которые возникают в процессе обсуждения. Это позволит вспомнить, о чем вы говорили, не упустить todo и иметь аргументы во время спорных моментов.
- Формулируй свой вопрос, проведя предварительное исследование. Мне часто хочется побыстрее написать с вопросом другому участнику команды, не изучив вопросов поглубже. И иногда это заканчивается тем, что я использую другого человека как уточку и просто зря трачу его время. Не делай так, подходи к этому ответственно.
Про планирование и время
- Намечай свой карьерный путь. План помогает упростить движение к цели, а отсутствие плана заставляет прыгать с места на место и терять время на вещи, которые тебе не интересны. Не поленись и подумай, что ты хочешь от работы. Это позволит тебе быстрее вырасти.
- Научись оценивать свое рабочее время. В этом году я плотно подсела на toggl track (наконец!). Сейчас я четко могу сказать, чем я занимаюсь, сколько я этим занимаюсь и прогнозировать сколько еще я буду этим заниматься. Рекомендую!
- Не переживай, если не понял с первого/второго/десятого раза. Все знания, которые ты получаешь, смогут помочь тебе в будущем, даже если кажется, что это не так. И ты обязательно когда-нибудь поймешь! Дай мозгу сделать свою работу.
- Очень часто стоит потратить время на то, что ты откладываешь. Например, наконец научиться запускать автотесты через консоль, а не руками. Или написать свод правил для работы. Кажется, что это не сильно ускорит работу, но практика показывает, что ускорение/упрощение/изменение рутины приводит к повышению эффективности.
- Критерии приемки - это круто! Тут добавить нечего.
И пусть каждая ошибка приносит вам опыт, а не боль. С наступающим 💫
Критерии выбор компании
Несмотря на то, что рынок сейчас не самый горячий, каждый из нас может в любой момент выйти "в активный поиск". И если ты уже начал/а искать новую работу, то стоит подойти к этому основательно.
Когда тебе присылают оффер, часто можно потерять голову и согласиться на первое, что предлагают (особенно когда у тебя нет карьерного пути). Знаю по своему прошлому опыту...
Стоит ли так делать? Определенно нет. Особенно в случае, если офферов у тебя несколько и есть возможность выбрать будущую компанию.
В такой ситуации я выписала себе критерии выбора компании:
- будущий стек технологий
- возможность роста
- заработная плата
- формат работы
- команда и мой комфорт общения с ней
- все особенности, связанные с типом компании (статусность, ограничения и прочее)
- дополнительные плюшки от компании
- (добавьте свое)
Для удобства я распределила все критерии в категории и создала некую схему, чтобы можно было быстро вспомнить, что важно при поиске компании
(⬇️в хорошем качестве)
#собеседование
Несмотря на то, что рынок сейчас не самый горячий, каждый из нас может в любой момент выйти "в активный поиск". И если ты уже начал/а искать новую работу, то стоит подойти к этому основательно.
Когда тебе присылают оффер, часто можно потерять голову и согласиться на первое, что предлагают (особенно когда у тебя нет карьерного пути). Знаю по своему прошлому опыту...
Стоит ли так делать? Определенно нет. Особенно в случае, если офферов у тебя несколько и есть возможность выбрать будущую компанию.
В такой ситуации я выписала себе критерии выбора компании:
- будущий стек технологий
- возможность роста
- заработная плата
- формат работы
- команда и мой комфорт общения с ней
- все особенности, связанные с типом компании (статусность, ограничения и прочее)
- дополнительные плюшки от компании
- (добавьте свое)
Для удобства я распределила все критерии в категории и создала некую схему, чтобы можно было быстро вспомнить, что важно при поиске компании
(⬇️в хорошем качестве)
#собеседование
Но это не все!
Для еще большего удобства я составила таблицу (тык сюда, чтобы перейти в google excel), которую можно использовать в качестве отбора вашей будущей компании.
В ней выделила уже перечисленные критерии и варианты ответа о его наличии в конкретной компании.
Таблицу можно скопировать к себе и менять под свой запрос (файл -> создать копию).
Также в комментарии добавлю информацию, как создавать новое правило, если вам понадобится увеличить таблицу.
Таким образом у вас будет возможность объективно оценить, подходит ли компания под ваш запрос или нет🌸
Надеюсь, что с помощью этой таблицы сделаю вам поиск новой работы чуть приятнее. И пусть удача всегда будет с вами (хих)
Для еще большего удобства я составила таблицу (тык сюда, чтобы перейти в google excel), которую можно использовать в качестве отбора вашей будущей компании.
В ней выделила уже перечисленные критерии и варианты ответа о его наличии в конкретной компании.
Таблицу можно скопировать к себе и менять под свой запрос (файл -> создать копию).
Также в комментарии добавлю информацию, как создавать новое правило, если вам понадобится увеличить таблицу.
Таким образом у вас будет возможность объективно оценить, подходит ли компания под ваш запрос или нет🌸
Надеюсь, что с помощью этой таблицы сделаю вам поиск новой работы чуть приятнее. И пусть удача всегда будет с вами (хих)
🌸Рекомендация авторских каналов про тестирование🌸
Год назад (даже больше!) я рекомендовала вам подборку авторских каналов про тестирование. И хочу снова напомнить о ней.
Все каналы прошли повторное экспертное ревью небольшого сообщества - каналы живые, интересные и уникальные. Контент абсолютно разнообразный, поэтому подойдет каждому.
👉 Добавить подборку
Год назад (даже больше!) я рекомендовала вам подборку авторских каналов про тестирование. И хочу снова напомнить о ней.
Все каналы прошли повторное экспертное ревью небольшого сообщества - каналы живые, интересные и уникальные. Контент абсолютно разнообразный, поэтому подойдет каждому.
👉 Добавить подборку
🐛 Плавающие баги и как их искать
Хочу попробовать новый формат: выжимки из докладов в виде конспекта и моих интерпретаций. Формат тестовый, обычно делаю конспекты для себя, а тут захотелось поделиться.
Конспект сделан на основе доклада SQA Days-28 (крайне рекомендую к просмотру!)
👩💻 Докладчица: Анна Васильева (ныне Куренова)
🎯 Тема: "Поиск плавающих багов"
Главное из доклада:
- Что такое плавающие баги
- Типичные причины возникновения плавающих багов
- Состояние гонки (Race condition) как одна из самых интересных причин появления плавающего бага
- Как искать плавающие баги
- Почему их стоит искать
В свой конспект добавила личную историю о моем пропущенном плавающем баге, а также кучу моих интерпретаций доклада.
📝 Конспект с моими веселыми заметками вы можете почитать тут
Хочу попробовать новый формат: выжимки из докладов в виде конспекта и моих интерпретаций. Формат тестовый, обычно делаю конспекты для себя, а тут захотелось поделиться.
Конспект сделан на основе доклада SQA Days-28 (крайне рекомендую к просмотру!)
👩💻 Докладчица: Анна Васильева (ныне Куренова)
🎯 Тема: "Поиск плавающих багов"
Главное из доклада:
- Что такое плавающие баги
- Типичные причины возникновения плавающих багов
- Состояние гонки (Race condition) как одна из самых интересных причин появления плавающего бага
- Как искать плавающие баги
- Почему их стоит искать
В свой конспект добавила личную историю о моем пропущенном плавающем баге, а также кучу моих интерпретаций доклада.
📝 Конспект с моими веселыми заметками вы можете почитать тут