Заметки о QA

(обязательный мем к посту)

Про правильное формулирование, мета-вопросы и решение проблем путем редких ответов Чем дольше я работаю и общаюсь с людьми, тем чаще понимаю, как правильно сформулированный вопрос ускоряет процесс решения проблемы. Например, сегодня ко мне пришли с запросом "Не могу найти документ в системе, помоги". Я полезла в базу данных и логи двух микросервисов, чтобы проследить путь документа и обнаружила, что документ доставлен до системы. После проведенного исследования и предоставления ссылки на документ, я получила ответ: "Да, ссылка на документ у меня есть. Но вот в другую систему он не направился, а еще в статусе ошибки подписи". Тут возникает вопрос: значит коллега знал, что документ дошел до системы, но все равно спросил, где документ? Соответственно вопрос в поиске документа не стоял, а запрос оказался в другом: почему подпись не отработала. Из чего следует, что путь документа нам не нужно было отслеживать и я зря потратила на это свое время. Если бы коллега сформулировал вопрос сразу с подробностями, это сэкономило бы мне минимум 10 минут и сохранило бы силы на решение более насущного вопроса, а именно почему в подписи возникли проблемы. Проблемы с формулированием вопросов встречается постоянно, поэтому следует тщательнее подходить к этой задаче. Оттого, насколько качественно сформулирован вопрос, настолько же полноценно будет дан ответ на него. Как лучше формулировать вопрос: - описать, где и когда произошла проблема - перечислить, какие данные по проблеме собраны - описать, какие действия уже были проделаны для решения (шаг необходим, чтобы собеседник не предлагал вам уже сделанные действия) - объяснить, что требуется от человека, чтобы он тебе помог Перед отправкой перечитайте сообщение и проверьте, нет ли уже ответа на ваш вопрос в нем же. Примеры Плохой вопрос: я не могу понять, как замержить в репозиторий autotest Хороший вопрос: Мне нужно замержить новые автотесты в ветку master. При попытке мержа через консоль у меня возникает ошибка 403. Я пытался сменить пароль на новый, но это не помогло. Google подсказал, что ошибка может возникать из-за прав доступа к мастеру, но я их не могу посмотреть. Можешь ли ты объяснить, куда мне сходить для получения прав, или объяснить, что еще можно сделать? В таком случае человек сразу поймет, что ошибка заключалась в мерже в мастер без дополнительной ветки, ведь в их репозитории это запрещено. И объяснит, какой список действий нужно проделать для мержа. Что можно попробовать сделать, если вам задают плохо сформулированные вопросы Чаще всего причина плохих вопросов в лени их формулирования. В этом может помочь игнорирование вопросы на 30 минут: через пол часа вопрос порой пропадает сам по себе или становится нормально сформулированным с описанием собранных материалов и проделанных шагов. Мета-вопросы В связки с формулированием вопросов, я бы порекомендовала вам почитать про мета-вопросы, которые съедают не только ваше время, но и время собеседника. Пример мета-вопроса простой: когда ты вместо формулирования вопроса, просто пишешь "Тут?" и отвлекаешь собеседника. Подробнее почитайте по ссылке. Важно помнить, правильно сформулированный вопрос - это уже половина ответа на него. #softSkills

Блок-схема "Как выбрать язык программирования для автоматизации" В чек-листе перехода в автоматизацию (тык) я писала не только о необходимых для автоматизации навыках, но и о списке действий, которые могут помочь вам перейти в автоматизацию или развивать ее на текущем проекте. Один из главных пунктов начала знакомства с автоматизацией - это выбрать язык программирования. Я уже отмечала, что на этом этапе важнее выбрать язык и развиваться в нем, а не зарыться в выбор языка, так как на реальных работах вы можете поработать на многих языках программирования. Важнее уметь программировать, а не на чем вы это делаете. Часто бывает, что именно выбрать язык - это огромный шаг, который нас останавливает. Поэтому я постаралась немного облегчить решение и подготовила схему выбора первого языка программирования. Надеюсь, мне удалось учесть большинство особенностей, которые могут возникнуть на этом шаге, но если нет, рада буду почитать комментарии.

Блок-схема в хорошем качестве Кратко повторю на что ориентироваться при выборе языка: 1. Область, в которой вы хотите автоматизировать (UI для web, desktop, backend, mobile), : при выборе языка также нужно учитывать что вы хотите автоматизировать: для мобильных чаще используется Swift и Kotlin. 2. Язык, используемый на работе мечты: изучить рынок, выбрать компании, которые сильнее всего вас привлекают и выбрать для изучения их язык программирования 3. Востребованность в области и в конкретной компании: например, какие языки чаще мелькают в вакансиях. 4. Простота и популярность (Python проще в освоении с нуля, Java даст отличное понимание ООП, но сложнее для освоения) 5. Язык, базу которого вы уже изучали 6. Знакомые/менторы/разработчики, которые могут помочь

Мой личный путь и поиск карьерного развития Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше. Во время подготовки к мероприятию я задумывалась о своем пути в тестировании и о том, как я ищу новые горизонты для своего профессионального роста. И вот что произошло: я обнаружила, что у меня есть план, по которому я составляю свой карьерный трек и ставлю цели на ближайшее время. Теперь я хочу поделиться этим планом с вами: 📝Составление плана развития Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸 Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!

Практики хорошего кода Чем дольше я программировала, тем больше понимала, насколько много ошибок было у меня в самом начале пути. Сегодня я хочу немного погрузиться в инструменты, подходы и принципы, которые позволят создавать качественный код с самого начала. Что помогает нам создавать красивый и расширяемый код: - Использование практик написания хорошего кода: они позволят навести порядок в коде, упростить расширение проекта и переиспользовать код, но сохранять при этом логику и читаемость и много чего еще. - Применение популярных паттернов проектирования и автоматизации, которые были уже проверены ни раз до нас: помогут найти типичный вариант рабочей структуры, что позволит не строить велосипед. - Проведение ревью в команде: обзор кода помогает выявить потенциальные проблемы и предложить улучшения, которые мог упустить человек, писавший код. - Соблюдение руководства по стилю и подключение библиотек, которые эти стили проверяют: одинаковые правила к коду позволят улучшить читаемость, быстрее решать спорные вещи в ревью и создавать согласованный код, что позволит избежать стандартных ошибок. А также позволит не создавать трех одинаковых методов, отличающихся только названием - Документирование и комментирование кода: комментирование методов и классов упростит переиспользование методов и ускорит чтение кода. Поподробнее советую почитать в этой статье. Про паттерны автоматизации я уже писала в этом посте, а сейчас хочу поговорить про практики написания кода. В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YANGI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть. #автоматизация

Блок-схема локализации бага: фронт или бэкенд? Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно? Здесь многое зависит от специфики вашей работы и особенностей сервера. Однако для общих случаев подойдёт и предложенная мной блок-схема, поэтому верю пользе от нее💫. (в хорошем качестве блок-схема представлена в следующем сообщении)

Логи и их применение в работе Работаете ли вы с логами в своей работе? Если нет, то давайте разберёмся, что это такое и как их можно использовать. Если да, то, возможно, я смогу рассказать вам о новых способах работы с ними. Логи — это текстовые записи, которые описывают работу программы. В них содержится информация о том, что произошло, в какой последовательности, какие значения передавались или изменялись. Что может логироваться — Изменение статусов сообщений. — Создание/изменение/удаление сущностей. — Взаимодействие с другими сервисами. — Перезагрузка и ошибки приложения. — Вызов методов. — Запуск задач. — Данные пользователей — Системная информация Созданием логов занимаются разработчики: это непосредственно содержится в коде программы (или добывается какими-то дополнительными инструментами). Поэтому важно понимать, что логи могут быть как скудными, так и очень детальными. Мы, тестировщики, также можем влиять на это и попросить увеличить их подробность и детальность. Как можно использовать логи в работе тестировщика — Провести локализацию бага: поиск в логах информации о сбоях или ошибках, застревании в каком-то статусе, неправильной обработке сообщения и получение любой информации, которая позволит нам понять, почему возник баг. — Отслеживание пути предмета тестирования: через какие статусы он проходил, как обновлял значения, куда отправлялся. Особенно это полезно при отсутствии визуальной составляющей, что упростит понимание правильной работы. — Создание подробного логирования ошибок приложения или его падения. Это полезно для быстрого реагирования поддержки на баг и поиска причины проблемы у пользователя. — Проверка интеграции с другими сервисами, их доступность и корректное взаимодействие — Анализ производительности. Логи могут содержать информацию о производительности приложения, такую как использование памяти, загрузка процессора или сетевая активность, что помогает выявить узкие места и оптимизировать работу приложения. Пример работы с логами У меня возникла ошибка, например, при создании сущности возвращается 500 и сущность не создаётся. Я понимаю, что возникла ошибка, но должна найти причину и локализовать ее. Я сразу иду в логи и изучаю историю, которая произошла в момент создания: возникла ошибка при сохранении сущности в базу данных: разработчик забыл заполнить обязательное поле, и запись просто не произошла. При отсутствии логирования процесс локализации занял бы совсем не 5 минут. Совет для работы с логами Иногда логирование неполное или к логам нет доступа, что не позволяет использовать этот инструмент в полной мере. Я всегда за то, чтобы тестировщик мог максимально использовать все инструменты в работе, ведь это улучшит процесс тестирования и проверки функционала. Поэтому при любой возможности добивайтесь доступа к логам и к их расширению, если это упростит вашу работу и улучшит процесс тестирования! Полезные материалы О чём могут рассказать логи: важный инструмент в работе тестировщика Как тестировщику работать с логами Уровни логирования как использовать логи Как снимать логи с устройств на Android и iOS Инструменты для тренировки: Kibana (программа для удобной работы с логами) и ее функции, а также тренажер для практики в Kibana #инструменты

Как проводить собеседования🗣 [часть 2] Подбор вопросов Важный этап подготовки к собеседования - это выбор вопросов. От чего я отталкиваюсь, когда составляю вопросы: - резюме кандидата и его опыт: что он делал и в чем силен - навыки и знания, необходимые именно для вакансии (в том числе учитывать материал, построенный на прошлом этапе подготовки), рекомендую статью на эту тему - упор в оценку применения теории на практике - мое обязательное знание ответа на вопрос, который я задаю! Где взять базовые вопросы, которые позволят составить ваш идеальный список: - Популярный список всех вопросов. - Вопросы про автоматизацию тестирования. - Вопросы для оценки опыта кандидата. - Чек-лист тем для собеседования. - Огромный список вопросов для QA. - "Анализ 10 000 вопросов с технических интервью: частотность и вероятность встречи". Подготовка себя как собеседующего Нам всегда кажется, что самое страшное - это быть на месте собеседуемого. Но знали бы вы, как волнительно быть с другой стороны. Один из полезных советов, как меньше волноваться, это посмотреть, как кто-то другой проводит собеседование, а особенно в первый раз поучаствовать в качестве помощника на реальном собеседовании. Если такой возможности нет, то советую приглядеться к следующим мок-собеседованиям: - Публичное собеседование QA лида. Алексей Петров, Ольга Артемьева. - Публичное собеседование: QA Lead. - Реальное техническое собеседование на работу тестировщиком Senior AQA. - Automation QA мок-собеседование. - Собеседование на микросервисный проект. - Собеседование на должность Middle QA Automation. - Публичное собеседование / мок-интервью для QA-инженера. Также рекомендую почитать об опыте нанимающего часть 1 и часть 2 Обязательно помните, что вы лицо компании. И именно благодаря вам создается впечатления о ней. Надеюсь, этот список поможет вам покорить вершину первого собеседования или улучшить текущий подбор кандидата 🥳