Вопросы на основе опыта

Когда вы уже работаете в тестировании, то при ответах на собеседованиях часто можете использовать свой опыт. Это поможет, если вы не знаете, как отвечать на конкретные вопросы по теории, или сильно переживаете: рассказы о повседневной работе легче даются, ведь мы делаем это каждый день.

Несмотря на то, что собеседования становятся легче из-за возможности опереться на ваш опыт, появляется ещё один блок вопросов — вопросы, которые требуют объединения вашего опыта и знаний для решения какой-то реальной практической задачи. Часто этот блок направлен на то, чтобы определить, как вы мыслите, решаете сложные задачи и как можете применить полученный опыт на практике.

В помощь приведу список популярных вопросов из данной тематики:
- Вы пришли на проект на начальной стадии. Как вы будете определять с какой тестовой документации начинать?
- Как тестировать продукт с большим количеством фичей, задач и сложным функционалом
- У нас три часа до окончания рабочего дня, а завтра с утра релиз. Что будешь делать?
- Что делать, если вам не хватает ресурса для выполнения задач в срок?
- Как убедиться, что тесты покрывают все необходимые сценарии?
- Что будете делать, если столкнетесь со сложной технической проблемой? А если с неизвестным инструментом?
- Разработчик прислал вам обратно баг с комментарием “Не баг”. Но вы уверены, что это баг; Что вы будете делать?
- Кто принимает решение, что все проверено и можно выпускаться?
- Как вы влияете на скорость исправления багов?
- Были ли конфликтные ситуации на предыдущем месте работы? Как вы выходили из них?
- Почему пропущен опыт в резюме?
- Почему уходите с предыдущего места работы?

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

#собеседование

IDOR🔐

В мое поле зрения сейчас активно попадается IDOR. Ранее я писала про тестирование безопасности (тут было интересно!). Но углубимся именно в IDOR.

IDOR - уязвимость, которая позволяет получить доступ до страниц и файлов, доступа к которым у человека быть не должно. Например, если вы как пользователь смогли изменить что-то в адресе ссылки и получить корзину другого пользователя - это IDOR. Подробнее узнать о том, что это и как это выглядит, можно тут.

Мне очень нравится это направление в тестировании: пытаться обойти систему и получить доступ к тому, что вам нельзя видеть (как подглядывать к кому-то в окна!).

Если хотите попробовать попрактиковаться, то рекомендую:
- проходить лабораторные работы от создателей Burp Suite (позволят вам на практике познакомиться с основными типами уязвимостей), а в помощь можете использовать эту статью
- посмотреть доклад Анны Васильевой “Поиск уязвимостей IDOR”
- поискать выступления Рамазана Рамазанова (@r0hack) (тут скорее сможете обзорно познакомиться, какие уязвимости существует)
- поискать полезное вот в этом посте

Интересные каналы на тему IDOR
- канал @r0hack
- канал Анны Васильевой

Как тестировать backend⁉️

Теоретические знания
1️⃣ Необходимо знать теорию веба и ее инструментов: это позволит понимать, что и как нужно тестировать в продукте, какие подводные камни могут возникать, а также успешно отвечать на собеседовании.

Основные знания перечислены в статье "Что должен знать тестировщик бэкенда"
В статье "Web Testing Specific" можно глубже погрузиться в то, как теория влияет на практику тестирования веба
Изучать основную базу можно обычным поиском по интернету: хороших статей и курсов огромное количество. В помощники рекомендую bible QA и пост с полезными статьями.

2️⃣ Быть знакомым с архитектурами, которые тебе предстоит тестировать, что позволит понимать особенности и учитывать их в работе.
Особенно понимать основные архитектуры API (для просмотра статьи нужен VPN)
(самый популярный архитектурный стиль для API REST, поэтому отдельно для него выделю статью с теорией и практикой). Если не любите читать, то видео на тему архитектур (и немного дополнительной теории) можно посмотреть тут
Также важно понимать разницу монолита и микросервисов и разницу синхронного и асинхронного взаимодействия (отсюда уже выходит работа с брокерами сообщения, но пока что это опустим).

Практические знания
1️⃣ Уметь тестировать backend (и понимать основные концепции тестирования)
- знать и применять общие подходы при тестировании API
▪️Лучшие практики тестирования API
▪️Мой любимый чек-лист API тестов (с которым можно сверяться, чтобы убедиться в непропущенности основных сценариев)
▪️Этапы тестирования API, тестовые сценарии
▪️Хороший пример шаблона тест-кейсов по API и от той же авторки примеры чек-листов по API (и свежие обновления для коллекций)
- знать как тестировать конкретный вид API (не обязательно все, но точно тот, который тестируете вы)
▪️тестирование rest
▪️тестирование grpc
▪️тестирование graphQL
▪️тестирование soap [тут хороших статей не нашла🙁]
- уметь тестировать все части backend: например, рекомендую почитать про тестирование баз данных
2️⃣ Уметь использовать основные инструменты
▪️devTools
▪️инструменты тестирования API: Postman vs Insomnia vs Soap UI
▪️работать с curl
▪️уметь подключаться и работать с базами данных (например, через dbeaver)

Вот такой минимальный набор навыков и знаний нужен для спокойной работы на первых порах. Затем багаж будет увеличиваться и расширяться, но пока что остановимся на этом.

#web #backend

С Новым годом!🎄

Надеюсь, этот год принесет вам много радости и карьерных достижений. А я постараюсь помочь вам развиваться с помощью полезных постов ❤️

А сегодня я хочу поделиться ссылкой, нежно собранной командой админов тг-каналов, на супер-полезную подборку известных и не очень каналов о тестировании https://t.me/addlist/PNmSaWa9ktw2YjRi.

Все каналы прошли экспертное ревью и получили зеленый свет🟢 - каналы живые, интересные и уникальные.

Каждый найдет в них для себя что-то полезное - и джуны, и сеньоры.

Не упускайте свой новогодний подарок и добавляйте каналы в библиотеку!

Чек-лист перехода в автоматизацию

В новом году хочется ставить перед собой новые цели и менять свою жизнь. И я подготовила некоторым из вас подарок.

Часто ко мне приходят с запросом: как перейти в автоматизацию (и за этим тянутся вопросы: что нужно уметь, какой язык выбрать, что делать). Я собрала все вопросы в кучу, просмотрела много источников информации и собрала чек-лист навыков и действий, которые нужно совершить, чтобы перейти в автоматизацию из ручного тестирования.

Забирай чек-лист по ссылке "Чек-лист перехода в автоматизацию"
(его можно скопировать к себе в Notion с помощью кнопки Duplicate и отмечать выполненные пункты)

Надеюсь, именно он поможет тебе найти путь в автоматизацию!

#автоматизация

Поговорим немного о локализации бага 🔎
А в следующем посте разберем задачу с собеседования👩‍🎓

Локализация бага - это процесс поиска места и причины возникновения ошибки в коде: при какой последовательности действий, в какой части приложения, а иногда даже в какой строчке кода.

Что может помочь в локализации

- Проверка запросов с фронта на бэкенд. Для этого можно использовать различные инструменты, такие как dev-tools, fiddler, charles и другие. Они позволяют убедиться, что запросы отправляются и принимаются правильно, а также отслеживать их параметры и содержание.
- Отправка запросов без фронтенда. Для этого можно использовать инструменты, такие как postman/insomnia, swagger, curl и другие. Они позволяют отправлять запросы напрямую на бэкенд, без участия фронтенда, и проверять их результаты. Это помогает локализовать баг на уровне фронтенда или бэкенда.
- Чтение логов бэкенда. Для этого можно использовать инструменты, такие как kibana/kubernetes, подключение к удаленной машине или просто txt файл в windows. Они позволяют прочитать логи бэкенда и понять, как обрабатываются данные на сервере, и выявить возможные ошибки или несоответствия.
- Проверка сохранения сущностей. Для этого можно использовать инструменты, такие как базы данных или другие хранилища данных (например, minio для файлов). Они позволяют проверить, как сохраняются и извлекаются данные из хранилищ, и обнаружить возможные проблемы с ними.
- Сравнение с дизайном/аналитикой. Для этого можно использовать документацию, такую как макеты, спецификации, требования и другие. Они позволяют сравнить фактическое поведение приложения с ожидаемым и убедиться, что баг не является нашим заблуждением или неправильным пониманием. Также они помогают опираться на конкретную информацию, а не на нашу память.


Полезные статьи

- Локализация дефектов на интеграционном уровне (очень рекомендую статью, расписаны конкретные кейсы)
- Что общего между локализацией багов и расследованием преступления?
- Как локализовать плавающие баги
- Что означает локализовать баг

Пример задачи на локализацию с собеседования👩‍🎓


На собеседованиях могу дать задачу на локализацию. Приведу пример и решения для одной из таких задач:

Есть форма входа, которая состоит из логина и пароля. Ты вводишь корректные значения, нажимаешь на кнопку войти и ничего не происходит. Какие действия ты предпримешь?

Остановись и подумай: что ты бы ответил собеседующему, какие бы действия совершил и что вообще следует сделать? Идеально, если ты выпишешь свои действия на листочке.

Мой список действий можно почитать в посте

как понять, что я норм?

с этим вопросом ко мне регулярно приходят лиды на консультации, или же он всплывает в рамках совершенно других запросов. причины вопроса более, чем понятны: к лиду очень редко приходят с нормальным фидбеком, задачи придумывать себе приходится самостоятельно, никаких тебе понятных карьерных треков и матриц для самовалидации. прекрасная почва для переработок и выгорания, как будто у лида её не хватает.

а что делать-то (особенно пока я не беру на менторинг хехе)?

учиться авторизовывать результаты работы (и вообще замечать свою работу), формулировать свою ценность и собирать непрямой фидбек.

для начала всегда даю упражнение записывать то, что ты делаешь в течение недели-двух, при чём записывать каждый чатик, каждый митинг. стараться анализировать, какой получился результат из этого действия.

например, вместо "отвечала на вопросы по онбордингу" — "разблокировала прохождение онбординга, помогла разобраться с вопросами Х, У". или не "сидела на очередном планинге", а "задала вопросы по фичам в след спринт, нашла гэпы в требованиях, получила информацию для планирования работы команды".

ну и не игнорируйте свою работу головой. работа лида во многом — это обдумывание вопросов и принятие решений. отрывайте оценку своей эффективности от работы руками и производимых артефактов.

об остальном поговорим завтра в 18 по мск на вебинаре.

а в целом подход "с тобой всё норм" будет активно использоваться на курсе :)

Как проводить собеседования🗣
[часть 1]

Обычно подбор кандидата проводится в несколько этапов:
- встреча с HR
- техническое собеседование (может быть разделено на несколько этапов)
- встреча с командой

Я хочу поговорить именно о техническом собеседовании и как к нему подходить со стороны нанимающего.

Стандартный план технического собеседования QA
(присутствие и отсутствие этапов зависит от вакансии):

1. Знакомство
- вы рассказываете о формате встречи
- кандидат описывает свой прошлый опыт и свои навыки.
2. Вопросы на базу теории тестирования.
3. Технический блок
- специфика тестирования: web/mobile/backend/desktop
- автоматизация тестирования
4. Практический блок
- задачи на теорию тестирования (тест-дизайн, локализация и прочее)
- ситуационные вопросы
- лайв-кодинг
5. Вопросы от кандидата

Для собседования обязательно нужно подготовиться (даже когда ты собеседующий!):
- выстроить процесс (например, построить матрицу компетенций, что вы хотите от кандидата)
- определиться с вопросами
- подготовиться к роли собеседующего

Поговорим о каждом поподробнее

Выстраивание процесса

Для построения хорошего процесса я бы изучила следующий материал

- Лучший дизайн процесса собеседований: объясняет, почему сейчас мы часто строим собеседования неправильно, как лучше выстраивать вопросы, как в этом поможет матрица компетенций и еще куча всего. По мне одно из лучших чтений на эту тему.
- Теория по собеседованиям: какие виды существуют, как подготавливаться, какие вопросы лучше задавать и все в этом направлении.
- Видео “Как проводить собеседования, чтобы было интересно кандидату и не обидно HR”: очень нравится подход, описание и общие шаги.
- Изучить чужой опыт, например, как проходит интервью в Тинькофф

О вопросах и подготовки себя поговорим в следующей части 🔜

Как проводить собеседования🗣
[часть 2]

Подбор вопросов

Важный этап подготовки к собеседования - это выбор вопросов.

От чего я отталкиваюсь, когда составляю вопросы:
- резюме кандидата и его опыт: что он делал и в чем силен
- навыки и знания, необходимые именно для вакансии (в том числе учитывать материал, построенный на прошлом этапе подготовки), рекомендую статью на эту тему
- упор в оценку применения теории на практике
- мое обязательное знание ответа на вопрос, который я задаю!

Где взять базовые вопросы, которые позволят составить ваш идеальный список:
- Популярный список всех вопросов.
- Вопросы про автоматизацию тестирования.
- Вопросы для оценки опыта кандидата.
- Чек-лист тем для собеседования.
- Огромный список вопросов для QA.
- "Анализ 10 000 вопросов с технических интервью: частотность и вероятность встречи".

Подготовка себя как собеседующего

Нам всегда кажется, что самое страшное - это быть на месте собеседуемого. Но знали бы вы, как волнительно быть с другой стороны.
Один из полезных советов, как меньше волноваться, это посмотреть, как кто-то другой проводит собеседование, а особенно в первый раз поучаствовать в качестве помощника на реальном собеседовании.

Если такой возможности нет, то советую приглядеться к следующим мок-собеседованиям:
- Публичное собеседование QA лида. Алексей Петров, Ольга Артемьева.
- Публичное собеседование: QA Lead.
- Automation QA мок-собеседование.
- Собеседование на микросервисный проект.
- Мок-собеседование Java QA Automation с разбором ответов и материалами
- Собеседование на должность Middle QA Automation.
- Публичное собеседование / мок-интервью для QA-инженера.

Также рекомендую почитать об опыте нанимающего часть 1 и часть 2
Обязательно помните, что вы лицо компании. И именно благодаря вам создается впечатления о ней.

Надеюсь, этот список поможет вам покорить вершину первого собеседования или улучшить текущий подбор кандидата 🥳

Логи и их применение в работе

Работаете ли вы с логами в своей работе? Если нет, то давайте разберёмся, что это такое и как их можно использовать. Если да, то, возможно, я смогу рассказать вам о новых способах работы с ними.

Логи — это текстовые записи, которые описывают работу программы. В них содержится информация о том, что произошло, в какой последовательности, какие значения передавались или изменялись.

Что может логироваться
— Изменение статусов сообщений.
— Создание/изменение/удаление сущностей.
— Взаимодействие с другими сервисами.
— Перезагрузка и ошибки приложения.
— Вызов методов.
— Запуск задач.
— Данные пользователей
— Системная информация
Созданием логов занимаются разработчики: это непосредственно содержится в коде программы (или добывается какими-то дополнительными инструментами). Поэтому важно понимать, что логи могут быть как скудными, так и очень детальными. Мы, тестировщики, также можем влиять на это и попросить увеличить их подробность и детальность.

Как можно использовать логи в работе тестировщика
— Провести локализацию бага: поиск в логах информации о сбоях или ошибках, застревании в каком-то статусе, неправильной обработке сообщения и получение любой информации, которая позволит нам понять, почему возник баг.
— Отслеживание пути предмета тестирования: через какие статусы он проходил, как обновлял значения, куда отправлялся. Особенно это полезно при отсутствии визуальной составляющей, что упростит понимание правильной работы.
— Создание подробного логирования ошибок приложения или его падения. Это полезно для быстрого реагирования поддержки на баг и поиска причины проблемы у пользователя.
— Проверка интеграции с другими сервисами, их доступность и корректное взаимодействие
— Анализ производительности. Логи могут содержать информацию о производительности приложения, такую как использование памяти, загрузка процессора или сетевая активность, что помогает выявить узкие места и оптимизировать работу приложения.

Пример работы с логами
У меня возникла ошибка, например, при создании сущности возвращается 500 и сущность не создаётся. Я понимаю, что возникла ошибка, но должна найти причину и локализовать ее.
Я сразу иду в логи и изучаю историю, которая произошла в момент создания: возникла ошибка при сохранении сущности в базу данных: разработчик забыл заполнить обязательное поле, и запись просто не произошла.
При отсутствии логирования процесс локализации занял бы совсем не 5 минут.

Совет для работы с логами
Иногда логирование неполное или к логам нет доступа, что не позволяет использовать этот инструмент в полной мере. Я всегда за то, чтобы тестировщик мог максимально использовать все инструменты в работе, ведь это улучшит процесс тестирования и проверки функционала.
Поэтому при любой возможности добивайтесь доступа к логам и к их расширению, если это упростит вашу работу и улучшит процесс тестирования!

Полезные материалы
О чём могут рассказать логи: важный инструмент в работе тестировщика
Как тестировщику работать с логами
Уровни логирования как использовать логи
Как снимать логи с устройств на Android и iOS
Инструменты для тренировки: Kibana (программа для удобной работы с логами) и ее функции + статья на habr, а также тренажер для практики в Kibana
UPD: тренажёр временно (надеюсь) отключен, но у вас есть возможность использовать бесплатный пробный период в Kibana, подробнее читайте об в комментариях, либо использовать советы из поста автора тренажера.

#инструменты

Блок-схема локализации бага: фронт или бэкенд?

Я создала небольшую блок-схему, которая может помочь вам определить источник обнаруженного бага. Вы можете добавить множество дополнительных ветвей. Допустим, если ошибка от бэкенда 5хх, то точно ли она корректно обрабатывается и не нужно ли изменить ее на 4хх, что будет более информативно?

Здесь многое зависит от специфики вашей работы и особенностей сервера. Однако для общих случаев подойдёт и предложенная мной блок-схема, поэтому верю пользе от нее💫.

(в хорошем качестве блок-схема представлена в следующем сообщении)

UPD общее правило: если ошибка была, а UI ее не вывел и бэк повел себя неправильно, баг и на UI, и на бэк

Практики хорошего кода

Чем дольше я программировала, тем больше понимала, насколько много ошибок было у меня в самом начале пути. Сегодня я хочу немного погрузиться в инструменты, подходы и принципы, которые позволят создавать качественный код с самого начала.

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

Про паттерны автоматизации я уже писала в этом посте, а сейчас хочу поговорить про практики написания кода.

В статье Улучшаем код автотестов: популярные практики и их примеры я расскажу про такие подходы, как SOLID, KISS, DRY и YAGNI и на примере автотестов постараюсь показать применение этих принципов. В конце вас ждут полезные материалы, в которые обязательно стоит заглянуть.

#автоматизация

Мой личный путь и поиск карьерного развития

Недавно мне посчастливилось поучаствовать в QA Sis Conf #2, где вместе с другими удивительными девушками я поделилась своим опытом работы в сфере тестирования и поиском путей для развития, которые использовали после года в профессии. Рекомендую к просмотру: QA Sis Conf #2 Год в тестировании - что дальше.

Во время подготовки к мероприятию я задумывалась о своем пути в тестировании и о том, как я ищу новые горизонты для своего профессионального роста. И вот что произошло: я обнаружила, что у меня есть план, по которому я составляю свой карьерный трек и ставлю цели на ближайшее время.

Теперь я хочу поделиться этим планом с вами:
📝Составление плана развития

Статья включает в себя три ключевые части: поиск своих сильных сторон, определение зон для развития и выбор конкретных целей для достижения этого развития. Подробнее читайте в источнике🥸
Надеюсь, что план вдохновит вас на поиск будущих целей в вашей карьере!

Блок-схема "Как выбрать язык программирования для автоматизации"

В чек-листе перехода в автоматизацию (тык) я писала не только о необходимых для автоматизации навыках, но и о списке действий, которые могут помочь вам перейти в автоматизацию или развивать ее на текущем проекте.

Один из главных пунктов начала знакомства с автоматизацией - это выбрать язык программирования.

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

Часто бывает, что именно выбрать язык - это огромный шаг, который нас останавливает. Поэтому я постаралась немного облегчить решение и подготовила схему выбора первого языка программирования. Надеюсь, мне удалось учесть большинство особенностей, которые могут возникнуть на этом шаге, но если нет, рада буду почитать комментарии.

Блок-схема в хорошем качестве

Кратко повторю на что ориентироваться при выборе языка:

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