Заметки о QA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас я работаю full-stack QA в продуктовой команде и автоматизирую на Java. Но в будущем я мечтаю стать ✨лидом✨ .
На данный момент мне не полностью понятно, из чего состоит работа, как давать фидбек, оценивать качество своей работы и еще миллион вопросов, на которые я не знала, где найти ответы.

А теперь знаю. Потому что Наталья Петровская (великолепная специалистка, с которой мне повезло работать в качестве менти) создала свой курс про лидство. Подробнее про него и бесплатный вебинар в посте ниже ❤️.

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

🎄Новогодние советы для тестировщиков🎄

До Нового года осталось ровно неделя. За этот год каждый из нас вырос. И каждый из нас подводит итоги за прошедшее время. Для вас я собрала свои мысли-выводы года в этом посте.

Про созвоны
- Чтобы не отвлекаться, обсуждайте задачи, а не молчите.
- Если вы не можете обсуждать, постарайтесь занять руки делом, а голову созвоном.
- Иногда лучше 1 раз позвонить, чем 10 раз написать. А иногда лучше написать полноценное сообщение вместе неподготовленного звонка. Всегда нужночувствовать грань.

Про командную работу
- Мозговой штурм помогает решить многие проблемы, поэтому иногда групповые созвоны стоят потраченного времени (но обязательно нужно всем подготовиться и понимать тему звонка).
- Планирование правда может спасти много часов работы. Но, чтобы оно было эффективном, стоит в нем участвовать.
- Не надо забывать рассматривать задачи со стороны бизнес-фич, а не только со стороны тест-дизайна. И в этом вам может помочь вся команда (потому что помнить досконально продукт очень трудно).

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

Про работу мозга
- Если сейчас не получается, то шанс, что получится завтра, намного больше. Иногда нужно время, чтобы знания уложились.
- Большая часть интеллектуальной работы происходит во время отдыха.

Про развитие и заботу о себе
- Деньги и их количество - не всегда определяющая вещь для работы. Иногда важнее рост, который работа тебе даёт
- Надо заботиться о себе и помнить, что работа не спасет в моменты проблем со здоровьем или критических событий.
- Развитию нет предела. Ощущение «теперь-то я все поняла» обманчиво.

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

И пусть следующий новый год принесет вам больше профессиональных успехов и радости🎄

Как тестировать 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

IDOR🔐

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

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

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

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

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

Зачем нужен CI/CD (ручному тестировщику и не только)

CI/CD - методология разработки, которая позволяет автоматизировать процесс сборки, тестирования и развертывания приложений. Простыми словами - это автоматическая сборка вашего ПО с уже настроенными этапами запуска, тестирования (автотесты) и разворачиванием на сервере (например, где уже вы будете тестировать руками).

Иногда вы можете задаваться вопросом: но я тестирую руками/пишу автотесты, как мне это может помочь?

Вот несколько пунктов, чем вам поможет CI/CD:

➡️ автоматически без дополнительных действий со стороны разработчика получать новый функционал и разворачивать себе стенд одной кнопкой: без настроенной сборки приложения надо настраивать окружение, прописывать скрипты и прочее. А если CI/CD настроено, то можно просто нажать кнопку и вы уже готовы тестировать.
➡️ не получать неработающую сборку: не знаю, как у вас, а у меня бывали в работе задачи, которые просто приводили к падению при их запуске. И каждый раз нужно дойти в логи, узнать, это у меня не работает или разработчик отдал сырую задачу, идти к разработчику, ну и так далее. А тут с настроенным CI/CD (и хорошими тестами) задача просто бы не развернулась, и я не тратила бы время на выяснение причин.
➡️ автоматический прогонять автотесты, регресс и составлять отчеты: прогон автотестов на дальней дистанции позволит вам узнать, какой функционал чаще всего приходит в негодность и чему нужно уделить особое внимание. А еще вам просто не нужно будет ругами прогонять тесты и занимать мощности своего компьютера.

Чем CI/CD поможет именно команде:

➡️ настроить сбор метрик на проекте и, благодаря этому, мониторить их: например, собирать данные о производительности приложения: среднее время ответа, количество запросов к приложению и т.д.
➡️ создать нормальное количество unit-тестов со стороны разработчика: при настройке CI/CD можно настроить несколько этапов, одним из которых может быть количество покрытых тестами функциональности. Таким образом непокрытый (и хотя бы частично непротестированный!) функционал просто не дойдет до тестировщиков (и вы не будете страдать)
➡️ уменьшить количество исправлений на код-ревью: также один из этапов quality gate - это запуск задач, которые направлены на проверку качества кода. Это поможет нам меньше возвращать функционал на этапе код ревью кода.
➡️ упростить и автоматизировать "уход" до клиента: первоначальная цель CD заключалась именно в этом: правильно настроенные quality gate позволят нам в автоматизированном режиме отдавать новый функционал нашим клиентам и таким образом сокращать время между разработкой и поставкой функциональности.

К слову, CI/CD это не панацея: у нас все еще присутствует человеческий фактор. Например, на одной работе devOps решил выключить прогон unit-тестов, благодаря чему баг, который они бы словили, успешно проник на прод. Не будьте как этот devOps.

Полезные материалы

Почитать:
📄Что такое CI/CD
📄Зачем CI/CD тестировщикам?
📄Хорошая статья про CI/CD в целом и конкретный кейс
📄Вопросы по CI/CD на собеседованиях
📄Инфраструктура и пайплайн (CI/CD) (qa bible): много полезных ссылок

Послушать/посмотреть:
🎦Лайв-кодинг: GitLab CI as Quality Gates: CI глазами тестировщика" / Александра Пшеборовская
🎶Подкаст “Вроде в проде”: 11 выпуск CI/CD для тестировщика

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

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

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

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

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

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

Чек-лист тем для собеседования

Итак, как найти работу мечты? Этот секрет я вам не раскрою (потому что ответ у каждого свой), а вот подготовиться к собеседованию помочь могу.

Поэтому держите мою новую “разработку”: чек-лист “Темы для собеседований”

Как им пользовать:
- открыть ссылку
- скопировать чек-лист себе в notion
- подготавливаться к собеседованию, изучая/вспоминая информацию, и ставить done тем темам, которые уже повторил

И последнее не менее важное: верить в себя и успешно пройти собеседование.

А еще круто дорабатывать чек-лист под себя и добавлять темы, которые у вас спрашивали на собеседовании!

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

Пошучу: не является публичной офертой

Но очень надеюсь, что это будет вам полезно!

🌅Как писать код красивым и понятным?🌇

Когда мы пишем код для автотестов, не стоит забывать, что это все так же остается кодом. И к коду есть свои требования: понятность, читаемость, удобство его доработки. Поэтому приходится напрягаться и думать “а как писать код лучше?”

Что нужно для создания идеального (или хотя бы близкого к этому) кода:
- соблюдать основные принципы разработки SOLID, KISS, DRY, YAGNI и другие, особенно советую погрузиться в SOLID(и, например, разобрать в нем с помощью картинок). Также разобраться в этой концепции вам может помочь конкретные примеры на java и на python
- помнить о концепции ООП
- применять шаблоны проектирования и паттерны автоматизации

Также рекомендую отличную статья с советами, как написать идеальный автотест (аж 25 принципов!) : собраны основные требования к коду именно автотеста (прямо рекомендую читать статью и анализировать ваш код)

Рефакторинг кода
Если все-таки вышло, что вы попали в ловушку плохо написанного кода (с кем такого не было?), то пора заняться рефакторингом.
Отличный цикл статей про рефакторинг, как лечиться от проблем в вашем коде и какие есть best practice для этого (заходить нужно под VPN).


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

#автоматизация #программирование

🖇Микросервис vs монолит📎

Что такое монолит и микросервис, в чем их разница и как тестировать микросервисную архитектуру?

Монолит и микросервис

Монолитная архитектура
Подход при создании приложения, когда система строится как единый модуль: все части системы (модули, UI, данные) выступают как единый сервис
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.

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

- Подробно о микросервисе
- Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
- О микросервисной архитектуре

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

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

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

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

Подробнее можно почитать тут:
- Лучшие практики тестирования микросервисов
- Тестирование микросервисов, руководство для новичков
- Как тестировать интеграции, что это такое и в чем сложности
- Тестируем микросервисную архитектуру
- Стратегии тестирования микросервисов
- Контрактное тестирование
- Введение в тестирование контрактов 1, 2 и 3 (также есть часть 4, 5 и 6, но там больше про автоматизацию)

Что можно почитать про архитектуру приложений в целом
Нетривиальная статья про архитектуру приложений: что такое монолит и микросервисы, оркестрация и хореография, немного про SOAP, REST и GRPS

#web

🌐Про браузеры, браузерные инструменты и devTools🌐

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

Обзор всех инструментов разработчика Chrome DevTools
Полезные функции DevTools для тестировщиков
14 наиболее полезных особенностей Chrome DevTools
Практические навыки Chrome DevTools
Статьи с полезной информации: 1, 2

А вот на этом канале часто постится полезное и интересное про devTools.

Браузерные инструменты
Огненный доклад про браузерные инструменты: как сделать так, чтобы браузер стал ваш лучшим другом при тестировании. Также девушки-докладчицы поделились чек-лист "Браузерные расширения: инструкция по поиску и разумному использованию"
Полезные расширения для Chrome

Ручное тестирование браузеров
На собеседовании вам могут задать вопрос: почему не стоит дублировать тестирование на Chrome и Opera? И вы должны вспомнить о такой вещи, как движок, на котором написан браузер. В зависимости от него отрисовывается графика (хотя это и не всегда так работает, так что воспринимайте данную информацию под звездочкой). Для визуального восприятия информации предлагаю к прочтению статью на тему отрисовки элементов на разных движках.

Работа с devTools для автоматизаторов
Советую почитать, как использовать devTools при тестировании UI с помощью Selenide.

#инструменты #автоматизация #практика #web

💪Тренажеры для прокачивания различных навыков💪

Поиск багов
- https://qahacking.guru/: есть список багов для самопроверки, в целом очень интересные баги! Отличный тренажер, чтобы отточить навык поиска багов.
- https://sychev.tech/practice: позволит вам найти баги (и заодно потестировать API с помощью swagger)
- http://shop.bugred.ru/
- https://www.saucedemo.com/: базовый онлайн-магазин с обязательным логином. Преимущество: есть разные роли, под которыми можно залогиниться и увидеть разные баги.

Чтение логов
Особенная проблема начинающих тестировщиков (или специалистов, у которых нет доступа к логам) - это научиться читать логи и работать с популярным инструментом для просмотра логов. Но есть отличная статья про Kibana и ее функции, а также тренажер для практики.
А про то, что такое логи и какие они бывают, можно почитать тут.

Навыки тест-дизайна/создания кейсов
- http://testingchallenges.thetestingmap.org/
- тестирование треугольника
- калькулятор

Практика API
- отличный челлендж тестирования API
- огромный список публичных API

Мои любимые открытые REST API:
- Fake REST API
- Vikunja
- Petstore

Автоматизация
- демо-сайты для практики автоматизации

Прочее
- список тестовых заданий для прокачки с гитхаба (искать по ключевому слову "qa"/"тестиров")
- тренажер для работы со снифферами
- тренажеры и тесты по java, git и прочему
- тест по JUnit (🇬🇧)
- сборник тренажеров от Артема Русова

#практика