Легко в ИТ | Даниил Николаев

Словарь терминов Git и GitHub

2025-05-10T10:20:37.240Z

🧠 Основы

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

📁 Репозитории

Репозиторий (Repository) — проект, отслеживаемый с помощью Git. Содержит весь код, историю изменений, конфигурации, ветки и коммиты.
Локальный репозиторий — версия проекта на вашем компьютере.
Удалённый репозиторий (Remote) — версия проекта на сервере, например, на GitHub. Обычно называется origin.
Fork (Форк) — копия чужого репозитория в вашем GitHub-аккаунте. Используется для самостоятельной работы и последующего внесения изменений обратно через Pull Request.

📌 Ветки и изменения

Branch (Ветка) — отдельная «линия» разработки. Позволяет параллельно работать над фичами, багфиксом и экспериментами.
Master / Main — основная ветка проекта. Сейчас чаще используется название main.
Commit (Коммит) — сохранённое изменение. Содержит снимок состояния проекта с комментарием и автором.
Push — отправка локальных коммитов в удалённый репозиторий.
Pull — получение новых изменений из удалённого репозитория.
Clone — скачивание репозитория с GitHub на локальную машину.
Checkout — переключение между ветками или коммитами.
Merge (Мёрдж) — объединение изменений из одной ветки в другую.
Rebase (Ребейз) — «перепроигрывание» коммитов поверх другой ветки. Помогает сделать историю проекта линейной.
Merge conflict (Конфликт слияния) — ситуация, когда Git не может автоматически объединить ветки, и разработчику нужно вручную выбрать, какие изменения оставить.
Stash (Ста́ш) — временное сохранение изменений без коммита. Удобно, когда нужно срочно переключиться на другую задачу.

📦 Работа с форками

Обновиться из апстрима (upstream) — синхронизировать свою копию проекта (форк) с оригинальным репозиторием.
Обновиться из ориджина (origin) — получить обновления с удалённой версии своего же репозитория.

🧪 Проверка и публикация

Pull Request (PR) — предложение внести изменения из одной ветки в другую. Обычно используется для отправки изменений в основной репозиторий.
Code Review (Кодревью) — проверка кода другим разработчиком перед слиянием в основную ветку. Оценивается стиль, читаемость, безопасность и логика.
CI/CD (Continuous Integration / Continuous Delivery) — автоматизация запуска тестов, сборок и деплоя после коммита или PR.

🛠 Полезные команды

git clone <url>            # клонирование репозитория
git checkout -b <branch>   # создание и переход в новую ветку
git add .                  # добавление всех изменений в индекс
git commit -m "comment"    # фиксация изменений
git push                   # отправка в удалённый репозиторий
git pull                   # получение новых изменений
git merge <branch>         # слияние ветки
git rebase <branch>        # ребейз на другую ветку
git stash                  # сохранение изменений во временное хранилище
git stash pop              # восстановление изменений из stash

📌 Итог

Git и GitHub — это основа современной командной разработки. Понимание всех этих терминов и их практическое применение помогает не только грамотно управлять кодом, но и выстраивать эффективную командную работу.

SOAP (Simple Object Access Protocol) VS REST (Representational State Transfer)

2025-03-13T08:45:54.318Z

🔒 1. Встроенная безопасность через WS-Security

SOAP изначально разработан для работы в корпоративной среде, где безопасность критически важна. Он поддерживает WS-Security, стандарт, который добавляет к сообщениям:

Шифрование 🔐 – данные можно зашифровать так, что их сможет прочитать только получатель.
Подписи ✍️ – сообщения можно подписывать цифровыми подписями, чтобы убедиться, что они не были изменены в процессе передачи.
Аутентификацию 🔑 – можно требовать, чтобы отправитель доказывал свою личность с помощью токенов, сертификатов и других методов.

💡 Пример: В банковских системах SOAP используется для передачи платежных данных, потому что он может обеспечить их защиту от взлома и подмены.

🏢 2. Поддержка сложных схем авторизации

SOAP поддерживает такие мощные механизмы аутентификации, как:

SAML (Security Assertion Markup Language) – используется в корпоративных системах для единого входа (SSO).
OAuth + WS-Security – можно комбинировать оба метода для усиленной защиты.
X.509 сертификаты – можно использовать цифровые сертификаты для безопасного обмена данными.

💡 Пример: SOAP идеально подходит для работы с государственными порталами и крупными корпорациями, где требуется высокая степень безопасности.

📜 3. Чёткая спецификация и строгая структура

SOAP использует XML, и у него есть строгая схема, которая предотвращает ошибки в данных.
REST же может работать с разными форматами (JSON, XML, YAML), и поэтому у него нет встроенных механизмов проверки, как у SOAP.

💡 Пример: Если REST API отправит некорректный JSON (например, забудет кавычки), сервер может неправильно его обработать. В SOAP такого не будет – все данные проверяются на соответствие схеме.

🔄 4. Сообщения передаются через POST, что сложнее для атак

SOAP всегда использует метод POST, а это означает, что данные передаются в теле запроса, а не в URL.
В REST часто используют GET, и параметры передаются в адресной строке, что делает их уязвимыми для атак (например, их можно подглядеть в логах).

💡 Пример: В SOAP банковский перевод будет отправляться через POST, и никто не сможет увидеть параметры в URL. В REST, если бы использовался GET, данные могли бы попасть в логи сервера и стать уязвимыми.

🛡️ 5. SOAP поддерживает MTOM – безопасную передачу бинарных данных

Если нужно передавать файлы, SOAP делает это через MTOM (Message Transmission Optimization Mechanism), который автоматически шифрует и защищает файлы. В REST приходится либо использовать Base64 (что увеличивает размер файлов), либо настраивать дополнительные уровни безопасности.

💡 Пример: Если нужно передавать скан паспорта, SOAP зашифрует его встроенными средствами, а в REST это нужно делать вручную.

🏆 Итог: Когда использовать SOAP вместо REST?

✅ Когда нужна высокая безопасность – банки, государственные системы, корпоративные API.
✅ Когда важна строгая структура данных – SOAP использует XML-схемы, которые предотвращают ошибки.
✅ Когда передаются конфиденциальные файлы – SOAP умеет их безопасно передавать.

📌 Но! REST проще и быстрее для большинства задач, особенно в веб-разработке. Если безопасность не критична, REST будет удобнее.

🔒 Реальные примеры использования SOAP vs REST в безопасности

1️⃣ Банковские переводы и платежные системы 🏦💰

Почему SOAP?

Банки используют SOAP для перевода денег, потому что он поддерживает WS-Security и шифрование данных.
SOAP гарантирует, что данные не изменятся при передаче.
Работает с SAML, который позволяет безопасно аутентифицировать пользователей.

📌 Пример:
Допустим, ты отправляешь деньги через интернет-банк.
Система отправляет SOAP-запрос с твоими данными:

<soapenv:Envelope>
  <soapenv:Header>
    <wsse:Security>
      <wsse:UsernameToken>
        <wsse:Username>user123</wsse:Username>
        <wsse:Password>securepassword</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <TransferFunds>
      <FromAccount>12345678</FromAccount>
      <ToAccount>87654321</ToAccount>
      <Amount>1000</Amount>
    </TransferFunds>
  </soapenv:Body>
</soapenv:Envelope>

🔹 Тут пароль зашифрован и передаётся в заголовке, что делает атаку сложнее.
🔹 В REST тот же запрос мог бы передаваться через GET (что небезопасно) или POST, но без встроенной защиты данных.

2️⃣ Государственные сервисы и налоги 🏛️📄

Почему SOAP?

В налоговых системах SOAP используется из-за строгого контроля передачи данных.
Налоговые декларации шифруются, аутентифицируются с помощью цифровых сертификатов (X.509).

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

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

3️⃣ Безопасность в медицине 🏥🔬

Почему SOAP?

В медицинских сервисах, таких как HL7 (стандарт передачи медицинских данных), SOAP используется для передачи конфиденциальной информации.
Данные зашифрованы и подписаны, чтобы не было подмены.

📌 Пример:
Больница отправляет SOAP-запрос с медицинскими данными пациента в страховую компанию:

<soapenv:Envelope>
  <soapenv:Header>
    <wsse:Security>
      <wsse:BinarySecurityToken ValueType="X.509">
        MIIBIjANBgkqh...
      </wsse:BinarySecurityToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <PatientRecord>
      <ID>98765</ID>
      <Name>John Doe</Name>
      <Diagnosis>COVID-19</Diagnosis>
    </PatientRecord>
  </soapenv:Body>
</soapenv:Envelope>

🔹 Здесь данные подписаны цифровым сертификатом, и их нельзя подделать.
🔹 REST API не может гарантировать защиту из коробки, поэтому его почти не используют в медицине.

4️⃣ Передача файлов и защищённые документы 📁🔐

Почему SOAP?

SOAP поддерживает MTOM (Message Transmission Optimization Mechanism), который позволяет передавать зашифрованные файлы.
REST приходится кодировать файлы в Base64, что увеличивает их размер и снижает безопасность.

📌 Пример:
Компания отправляет скан паспорта в банк для верификации личности.
SOAP передаёт его зашифрованным файлом:

<soapenv:Envelope>
  <soapenv:Body>
    <UploadDocument>
      <File>binary_data</File>
    </UploadDocument>
  </soapenv:Body>
</soapenv:Envelope>

🔹 REST пришлось бы делать это через обычный POST, что не так безопасно.

5️⃣ Корпоративные системы (Microsoft, IBM, Oracle) 🏢💼

Почему SOAP?

Крупные компании используют SOAP для внутренних API, где важна строгая безопасность и контроль.
Например, в Microsoft Active Directory аутентификация пользователей происходит через SOAP-запросы.

📌 Пример:
Когда сотрудник входит в корпоративную систему, его логин передаётся с цифровой подписью, а не обычным паролем, как в REST.

🔹 REST чаще используют для открытых API, например, в мобильных приложениях или веб-сервисах.

Вывод: Где использовать SOAP, а где REST?

🚀 Когда REST лучше?

REST лучше, если:
✔ Нужно простое и быстрое API (например, для мобильного приложения 📱).
✔ Безопасность не критична (например, блог, новости 📰).
✔ Нужно работать с браузерами (REST API легко интегрируются в фронтенд).

🔒 Когда использовать SOAP?

SOAP лучше, если:
✔ Требуется высокий уровень безопасности 🔐.
✔ Нужно передавать конфиденциальные данные (банки, медицина, госуслуги).
✔ Важна строгая структура данных и их неизменность.

🔥 Итог: SOAP – это как броневик для данных, а REST – как легковая машина 🚗. Если нужно максимальная защита, выбирай SOAP. Если важна скорость и удобство, лучше REST.

Урок 10.1. Архитектура для тестировщика

2025-03-01T10:12:18.983Z

Описание сервисов

🔹 API Gateway 🚪

Что это?
API Gateway — это точка входа для всех запросов от пользователей и внешних систем. Он управляет маршрутизацией, авторизацией и безопасностью.

Почему используется?
✅ Централизованный контроль доступа.
✅ Балансировка нагрузки.
✅ Безопасность и управление API.

Пример работы:
👤 Пользователь отправляет запрос → API Gateway проверяет авторизацию → перенаправляет запрос в нужный микросервис.

🔹 Auth Service (Сервис авторизации) 🔑

Что это?
Проверяет права пользователя и определяет, можно ли ему выполнять определённые действия.

Почему используется?
✅ Обеспечивает безопасность.
✅ Поддерживает аутентификацию по JWT или OAuth.

Пример работы:
👤 API Gateway отправляет запрос в Auth Service → Auth Service проверяет токен → возвращает результат (успешно / ошибка 401).

🔹 Transaction Service (Сервис транзакций) 💰

Что это?
Отвечает за выполнение и обработку банковских операций (переводы, платежи, пополнение счета).

Почему используется?
✅ Гарантирует выполнение транзакций (ACID).
✅ Логирует операции для аудита.

Пример работы:
📨 API Gateway отправляет платежный запрос → Transaction Service проверяет баланс → записывает в базу → отправляет события в Kafka и RabbitMQ.

🔹 RabbitMQ (Очередь сообщений) 📩

Что это?
Обрабатывает асинхронные события и уведомления пользователей.

Почему используется?
✅ Гарантия доставки сообщений.

Пример работы:
🔁 Transaction Service отправляет уведомление → RabbitMQ передает его Notification Service → пользователь получает SMS/email.

🔹 Notification Service (Сервис уведомлений) 📢

Что это?
Отправляет пользователям сообщения о выполненных операциях.

Почему используется?
✅ Разгружает Transaction Service.
✅ Позволяет легко менять механизмы уведомлений (SMS, email, push).

Пример работы:
🔁 Notification Service получает сообщение от RabbitMQ → отправляет SMS/email пользователю.

🔹 Kafka (Платформа потоковой обработки) 🔄

Что это?
Используется для передачи данных в систему аналитики и логирования.

Почему используется?
✅ Поддерживает обработку большого количества событий.
✅ Устойчив к сбоям, благодаря репликации.

Пример работы:
🔁 Transaction Service отправляет данные о транзакции в Kafka → Kibana использует эти данные для визуализации логов.

🔹 Kibana (Мониторинг) 📊

Что это?
Система визуализации логов и аналитики.

Почему используется?
✅ Показывает графики и дашборды в реальном времени.
✅ Позволяет анализировать ошибки.

Пример работы:
📊 Kibana получает данные из Kafka → отображает их на дашборде.

🔹 PostgreSQL (Реляционная база данных) 🗄

Что это?
Основное хранилище данных о пользователях, счетах и транзакциях.

Почему используется?
✅ Поддерживает сложные SQL-запросы.
✅ Гарантирует целостность данных (ACID).

Пример работы:
💾 Transaction Service сохраняет транзакцию в PostgreSQL → данные доступны для отчетов.

🔹 Redis (Кэш) ⚡

Что это?
Используется для кеширования данных и быстрого доступа.

Почему используется?
✅ Обеспечивает мгновенный доступ к часто запрашиваемым данным.
✅ Снижает нагрузку на PostgreSQL.

Пример работы:
🔄 Запрос баланса сначала ищет данные в Redis → если их нет, идёт в PostgreSQL.

💡 Различия между Kafka и RabbitMQ 🤔

💡 Когда использовать?
🔹 Kafka → если нужно обрабатывать много данных и событий.
🔹 RabbitMQ → если важна гарантированная доставка сообщений.

💡 Различия между Redis и PostgreSQL 🧐

💡 Когда использовать?
🔹 Redis → когда важна быстрая обработка данных.
🔹 PostgreSQL → когда важна целостность и надёжность данных.

Как это всё работает

1️⃣ Ты (пользователь) делаешь запрос (например, «Отправить деньги»).

2️⃣ Этот запрос попадает в API Gateway, который разбирается, куда его перенаправить.

3️⃣ API Gateway передаёт запрос в Auth Service, чтобы тот проверил:
🔹 «У тебя есть право делать переводы?»
✅ Если проверка пройдена, идём дальше.

4️⃣ Запрос на перевод летит в Transaction Service.

5️⃣ Transaction Service:
🔹 Сохраняет транзакцию в PostgreSQL (чтобы ничего не потерялось).
🔹 Отправляет уведомление в RabbitMQ (чтобы ты получил сообщение).
🔹 Шлёт данные в Kafka (для аналитики).
🔹 Обновляет Redis (кеширует данные, чтобы быстрее загружать баланс).

6️⃣ Notification Service читает уведомление из RabbitMQ и отправляет тебе на телефон или email сообщение, что «Деньги ушли туда-то».

7️⃣ Kafka передаёт данные в Kibana и внешние аналитические системы, чтобы можно было смотреть отчёты, графики и логи.

8️⃣ Kibana – это как приборная панель, показывает всё, что происходит в твоём «цифровом банке», где и что логируется, были ли ошибки и т.д. 🚀

Примеры позитивных сценариев

1. Проверка платежной транзакции

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

🔹 Шаги тестирования:

Отправить запрос на перевод через Postman
Проверить, что транзакция записалась в PostgreSQL

Данные должны быть внесены в таблицу

Проверить, что уведомление отправлено в RabbitMQ:

Открыть RabbitMQ Management UI
Убедиться, что сообщение попало в очередь уведомлений.

Проверить, что Kafka получила событие:

Подключиться к Kafka UI
Найти сообщение о переводе.

Проверить логи в Kibana:

Открыть Kibana
Перейти в Discover и найти запись по transaction_id.
Убедиться, что ошибок нет, лог содержит нужные поля (user_id, amount, status).

Проверить, что пользователь получил SMS/email

✅ Ожидаемый результат:

Транзакция успешно проведена.
Уведомление отправлено.
В Kibana лог с правильными параметрами.

2. Проверка получения баланса

Цель: Убедиться, что данные кешируются в Redis, а при сбое Redis данные берутся из PostgreSQL.

🔹 Шаги тестирования:

Запросить баланс пользователя через API Gateway
Проверить, что данные загружены из Redis

Баланс должен быть в Redis.

Удалить кеш (как удалить, сможешь узнать по инструкциям на проекте) и проверить повторный запрос

Данные теперь должны быть загружены из PostgreSQL.

Проверить логи в Kibana:

Найти запись в Kibana → Discover по request_id.
Убедиться, что первый запрос получил данные из Redis, второй – из PostgreSQL.

✅ Ожидаемый результат:

Данные сначала приходят из Redis.
После удаления кеша – загружаются из PostgreSQL.
В Kibana логируется источник данных.

Примеры негативных сценариев

1. Ошибка авторизации (Auth Service)

Сценарий:

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

Что должно произойти?

API Gateway перенаправляет запрос в Auth Service.
Auth Service не подтверждает права доступа.
Пользователь получает ошибку (например, 401 Unauthorized или 403 Forbidden).

Как искать и диагностировать ошибку?

Postman:

Отправить запрос без токена или с поддельным токеном.
Проверить HTTP-ответ (должен быть 401 или 403).

Kibana:

В разделе Discover отфильтровать логи по дате/ID запроса.
Посмотреть, что сервис Auth Service вернул ошибку авторизации.

Убедиться, что Gateway получил запрос и действительно отдал его на Auth Service, а не «потерял» где-то.

2. Недостаточно средств на счёте (Transaction Service)

Сценарий:

Пользователь пытается перевести сумму, которая превышает баланс счёта.

Что должно произойти?

Transaction Service при обработке обнаружит, что баланс меньше требуемой суммы.
Операция должна быть отклонена.
Пользователь получает ошибку (например, 400 Bad Request с сообщением "Insufficient Funds").

Как искать и диагностировать ошибку?

Postman:

Отправить запрос с суммой больше, чем доступный баланс.
Убедиться, что сервис вернул корректный код ошибки (400 или 422) и понятное сообщение.

PostgreSQL (DBeaver):

Проверить, что транзакция не появилась в таблице transactions или имеет статус FAILED.

Kibana:

Найти лог по transaction_id и убедиться, что там есть запись об ошибке «Insufficient funds».

3. Некорректные данные запроса (API Gateway / Transaction Service)

Сценарий:

Отправить запрос с неправильным форматом JSON, отсутствием обязательных полей (например, не указать amount или to_account), или с некорректным типом (вместо числа передать строку).

Что должно произойти?

API Gateway может отклонить запрос из-за невалидного тела (400 Bad Request).
Если прошёл до Transaction Service – тот должен вернуть ошибку при парсинге / валидации данных.

Как искать и диагностировать ошибку?

Postman:

Отправить специально искажённый JSON.
Проверить код ошибки (400 Bad Request или 422 Unprocessable Entity).

Kibana:

Поиск по request_id или transaction_id.
Увидеть лог о «JSON parse error» или «Validation error».

Может оказаться, что API Gateway не пропустил запрос — смотрим его логи.

🛠 Что важно проверять

✅ RabbitMQ → Сообщения не теряются в очереди.
✅ Kafka → События корректно попадают в аналитику и Kibana.
✅ PostgreSQL → Данные правильно сохраняются и не теряются.
✅ Redis → Кеш работает и обновляется при изменениях.
✅ Kibana → Логи логируются корректно, их можно просматривать и анализировать.

📌 Правильность запросов и ответов: отправил запрос на перевод → получил корректный результат.
📌 Безопасность: никто не может украсть данные или перевести деньги без разрешения (Auth Service).
📌 Целостность данных: все транзакции верно записываются в PostgreSQL.
📌 Уведомления: проверяешь, как работает RabbitMQ и Notification Service → приходит ли пользователю сообщение?
📌 Аналитика и логи: Kafka всё ли записывает? Kibana всё ли отображает?
📌 Кеш: Redis действительно ускоряет ответ? А если кеш упадёт, система продолжит работать через PostgreSQL?

🔥 Главная задача тестировщика — убедиться, что система работает стабильно, данные не теряются, а ошибки легко отслеживаются! 🚀

9.2 Как работают Elasticsearch, Kibana, Filebeat и Restful-Booker вместе.

2024-12-17T11:40:02.208Z

Конечно! Вот простое объяснение, как работают Elasticsearch, Kibana, Filebeat и Restful-Booker вместе.

1. Restful-Booker – приложение

Что это?

Это ваше приложение, которое отвечает на HTTP-запросы. Например:

• Если кто-то отправляет запрос GET /booking, приложение отвечает 200 OK и возвращает “Booking details”.

Что происходит?

• Приложение пишет свои логи в консоль (stdout) – это сообщения о запросах, их статусах и ответах.

Пример лога:

GET /booking 200 4.017 ms - 162

2. Filebeat – сборщик логов

Что это?

Filebeat – это инструмент, который читает логи из приложения (Restful-Booker) и отправляет их в Elasticsearch.

Что происходит?

• Filebeat “смотрит” в файлы Docker-логов (например, /var/lib/docker/containers/*/*.log).

• Он находит логи приложения Restful-Booker и отправляет их в Elasticsearch.

Пример того, что отправляет Filebeat:

{
"message": "GET /booking 200 4.017 ms - 162",
"container.name": "restful-booker",
"log.level": "info",
"timestamp": "2024-12-17T13:56:57.361Z"
}

3. Elasticsearch – хранилище данных

Что это?

Elasticsearch – это база данных, которая умеет быстро искать и обрабатывать текстовые данные (логи).

Что происходит?

• Filebeat отправляет логи в Elasticsearch.

• Elasticsearch сохраняет логи в виде индексов (например, filebeat-2024.12.17).

• Теперь можно искать по этим логам: по запросам, статусам, времени и т.д.

4. Kibana – визуализация данных

Что это?

Kibana – это инструмент для визуализации данных из Elasticsearch.

Что происходит?

• Kibana подключается к Elasticsearch и “видит” все сохранённые логи.

• Вы создаёте Data View (например, для индексов filebeat-*).

• В разделе Discover вы можете искать и фильтровать логи.

Пример поиска в Kibana:

• Найти все запросы с /booking.

• Найти ошибки (status: 500).

Как всё работает вместе?

1. Restful-Booker:

Приложение принимает HTTP-запросы и пишет логи.

2. Filebeat:

Читает логи из контейнера Restful-Booker и отправляет их в Elasticsearch.

3. Elasticsearch:

Сохраняет логи и позволяет быстро искать их.

4. Kibana:

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

Пример потока данных

1. Кто-то отправляет запрос:

GET /booking

2. Restful-Booker пишет лог:

GET /booking 200 4.017 ms - 162

3. Filebeat собирает этот лог и отправляет в Elasticsearch.

4. Elasticsearch сохраняет лог в индекс filebeat-2024.12.17.

5. В Kibana → Discover вы видите:

message: "GET /booking 200 4.017 ms - 162"

Доведу до трудоустройства в QA за 2 месяца

2024-11-01T15:39:55.851Z

Привет!

Меня зовут Даниил, мне 34 года, работаю на позиции Senior Automation QA Engineer.

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

Полный цикл обучения выглядит так*:

Знакомство. Обсуждаем на бесплатной консультации твои скиллы и цели. Около 30 минут.
Подготовка и приглашение в личное рабочее пространство. Подготолвю для тебя рабочее пространство, которое используется на рекльных проектах в компаниях. Расскажу как им пользоваться.
Процесс обучения и проверка знаний. Будем созваниваться каждую неделю, примерно по 1 часу, для корректировки процесса обучения при необходимости и для проверки знаний.
Резюме и собеседования. Создадим с тобой легенду и резюме. Опишем подробно твои достижения, скилы и легенду о твоей прошлой работе. Так же проведем торги по повышению оклада, после получения оффера.
Сопровождение. Далее в течении 2-3 месяцев буду помогать внедряться в компанию и правильно работать.

*на всех этапах буду помогать по всем возникающим вопросам.

Прайс-лист:

- Первая консультация – бесплатно.
- Помощь новичкам в получении оффера:

на позицию QA Manual – 20.000 рублей за полное сопровождение + 50% от первой и от второй зарплаты + 0 рублей за послеофферное сопровождение.

на позицию QA Automation – 50.000 рублей за полное сопровождение + 50% от первой и от второй зарплаты + 0 рублей за послеофферное сопровождение.

- Помощь в поиске удаленной работы – 7000 рублей за занятие. Помогу составить резюме, продумать легенду.
- Помощь на испытательном сроке - 7000 рублей за занятие, если у вас уже есть работа QA или AutoQA и вам нужна помощь.
- Другие услуги – 7000 рублей за консультацию.

Контакты:

Запись на бесплатную консультацию - aqa-pro.tec h
Telegram - https://t.me/danilfg
Telegram канал - https://t.me/aqa_pro_tech
Teletype - https://blog.aqa-pro.tech/

RuTube - https://rutube.ru/channel/274005/
YouTube - https://www.youtube.com/@aqa_pro/
Дзен - https://dzen.ru/aqa_pro