QA AK

QA AK pinned «Друзья, рад поделиться отличной новостью — я запускаю интенсив по тестированию API! 🚀 Довольно часто я вижу потребность начинающих тестировщиков в практике базового и необходимого для QA навыка — тестирования API. И естественный вопрос в данном случае: где…»

Друзья, рад поделиться отличной новостью — я запускаю интенсив по тестированию API! 🚀

Довольно часто я вижу потребность начинающих тестировщиков в практике базового и необходимого для QA навыка — тестирования API. И естественный вопрос в данном случае: где эту практику взять?

Мы с моим коллегой, автором канала "Кофе и код", подготовили рабочий продукт — трекер привычек в виде REST API, который можно будет использовать для получения практических навыков по тестированию API. На базе этого продукта я разработал интенсивный курс, чтобы помочь всем желающим уверенно освоить тестирование API.

🎯 Кому подойдёт интенсив?

Интенсив подойдёт вам, если:

🔸 Вы выпускник курсов по тестированию и с API знакомы бегло и теоретически.
🔸 Вы уже работаете в качестве Junior QA, но API не тестировали или работали с ним очень мало.
🔸Вы хотите приобрести практический опыт и уверенность в своих знаниях.

Если вы чувствуете себя неуверенно в этой области — приходите, будем разбираться вместе! 😊

🔍 Из чего он будет состоять?

Мы проведём полный цикл тестирования API, используя созданный для курса трекер привычек. Во время работы на курсе вы:

🔸 Освежите необходимую теорию и будете лучше понимать прикладное назначение API и его возможные реализации.
🔸 Научитесь планировать и проводить smoke и регрессионное тестирование API.
🔸 Выявите требования, изучив документацию (включая Swagger).
🔸 Примените на практике техники тест-дизайна и заведёте тестовую документацию для проектирования тестов.
🔸 Научитесь создавать коллекции в Postman, содержащие скрипты и автоматические тесты.
🔸 Проведёте полный цикл тестирования API, выявите баги и заведёте баг-репорты.

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

🏆 Что вы получите на выходе?

По завершению интенсива у вас будет:

☑️ Опыт и знания о том, как тестировать API.
☑️ Навыки работы в Postman и Swagger, которые вы сможете смело указывать в резюме.
☑️ Уверенность в применении этих навыков в "боевых условиях". 💪

📅 Организационная информация:

- Старт интенсива: 3 февраля.
- Длительность: месяц.
- Формат работы: регулярные вебинары (с записью), на которых будет даваться необходимая информация и ответы на вопросы.
- Расписание занятий: доступно на странице курса.
- Стоимость: смотрите тарифные планы на странице курса (гибкие возможности оплаты).

🎉 В честь запуска первого потока — 15% скидка на все тарифы!
Для этого воспользуйтесь промокодом: STREAM1ST

👉 Более подробную информацию смотрите на trackhabits.ru.
💬 По всем вопросам пишите в комментарии или в личные сообщения.

📢 Приходите, буду рад видеть вас на курсе! 🌟

Публикую свой вариант ответа на задачу выше. Покажу верхнеуровневую логику рассуждений.

Решение можно разбить на части:

🔎 1. Анализируем исходные данные и ищем неполноту требований, после чего уточняем их у интервьюеров. В данном случае это:
- уточнение требований к полям. Например, какие символы принимает значение поля name, какой оно может быть длины, должно ли значение являться уникальным;
- какое тело ответа должно возвращаться при выполнении успешного запроса;
- какие статус-коды должны возвращаться при:
-- выполнении обновления без предварительной авторизации;
-- ошибках валидации при отправке некорректных данных;
- какие конкретные сообщения об ошибках должны быть в теле ответа в том или ином негативном кейсе.

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

🧺 2. Начинаем отбирать проверки. Начинаем с позитивных тестов ➕, проверяющих обновление данных пользователя — то, для чего этот endpoint был создан.

Почему в таком порядке? Потому что даже если остальные требования будут соблюдаться, невозможность выполнить целевое действие, ради которого создавался этот функционал, будет лишать смысла остальные проверки. Представим себя на месте пользователя в ситуации, когда у нас изменился телефон или email, и нам нужно изменить это в системе. Если мы получим ошибку при выполнении такого действия — это скажется на нашем отношении к системе и желании её использовать. Зачем нам пользоваться ПО, которое не решает наши задачи?

Поэтому начнем с кейсов:
- проверка обновления данных с указанием всех валидных значений в полях -> проверяем, что все данные в профиле изменились;
- проверка обновления данных с указанием только обязательных полей -> данные в обязательных полях обновились, в необязательных остались прежними.

Обязательно делаем уточнение, что выполняем запросы под авторизованным пользователем.

Далее следует проверить отдельные требования к полям. Например, если у поля name есть длина (скажем, от 5 до 30 символов), нужно выполнить два кейса с проверкой граничных значений в 5 и 30 символов для этого поля. Если интервьюеры не дадут конкретных требований для значений в каждом поле, то стоит озвучить, сделав допущение, что вы выполнили бы кейсы на граничные значения, используя соответствующую технику тест-дизайна "анализ граничных значений", так как у поля name зачастую бывает фиксированная длина.

Аналогично с другими полями. Если кроме озвученных в задаче требований больше ничего нет, то следует попытаться руководствоваться логикой и здравым смыслом в связке с техниками тест-дизайна типа "разбиения на классы эквивалентности". Например, для поля birthDate проверяем 29 февраля в високосный год.

Далее следует выполнить негативные кейсы ➖, чтобы проверить валидацию значений для каждого поля и обработку ошибок системой. Нам нужно убедиться, что система вернёт нам понятное, человекочитаемое описание ошибки, которое позволит понять, где она была допущена. Примеры кейсов:
- запрос с валидными параметрами, но не под авторизованным пользователем;
- отсутствие обязательного поля;
- пустое значение в поле;
- несоответствие требованиям к значению для поля.

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


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

#api #задача

Что спрашивают на собеседованиях в блоке про backend, касательно API?

Вопросы на технических собеседованиях делятся на логические блоки, на основе тем: теория тестирования, web, backend, базы данных, и т.д. Внутри каждого блока идет деление на подблоки на основе области, технологий, инструментов. В этом посте я покажу структуру и логику в блоке про API (HTTP REST).


Обычно начинают с общего базового вопроса, описывающего HTTP в целом. Интервьюеры хотят услышать:

🔸 понимание принципов его работы, описание клиент-серверного взаимодействия;
🔸 структуру запроса: URI, методы запроса, заголовки, тело запроса и форматы, в которых оно передается;
🔸 структуру ответа сервера: статус-код, заголовки, тело ответа.

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

🔸 чем отличаются HTTP от HTTPS;
🔸 можно ли отправить GET-запрос с телом;
🔸 чем отличаются методы POST и PUT;
🔸 что такое Bearer Token и как его передать;
🔸 как сервер аутентифицирует пользователя;
🔸 в чем отличия JSON и XML;
🔸 примеры статус-кодов разных групп.

Также кандидата могут попросить рассказать про его опыт тестирования API на предыдущих проектах с описанием стека и предметной области, после чего могут задать уточняющие вопросы по тем технологиям и инструментам, которые будут упомянуты. Например, при упоминании Postman могут спросить, как передать значение хедера/ключа из одного запроса в другой.

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

Как подготовиться к этому блоку?

🟡 Если вы Middle QA, у которого есть опыт тестирования API, то освежите теорию и заранее потренируйтесь в ответах на вопросы, подобные указанным выше.

🟢 Если же вы Junior QA, и опыта в тестировании API у вас мало, то в дополнении к рекомендациям выше, попрактикуйтесь в тестировании открытых тестовых API, типа PetStore. Или какого-либо API отсюда. Выберите сервис или группу endpointов и выполните их функциональное тестирование, используя инструменты типа Postman.


А теперь, друзья, я предлагаю вам попробовать самостоятельно решить 1 типовую задачу по тестированию, которая
поможет подготовиться к собеседованиям.

Задача: Тестирование API для обновления профиля пользователя.

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

Метод:

PUT /user/profile

Тело запроса:

{
  "name": "string",
  "email": "string",
  "phone": "string",
  "birthDate": "string"
}

Требования:

- Поля name и email обязательны.
- Поля phone и birthDate опциональны.
- Поле email должно быть валидным адресом.
- Поле phone должно соответствовать формату телефона (например, +1234567890).
- Поле birthDate должно быть валидной датой в формате YYYY-MM-DD.
- Сервер должен возвращать 200 OK при успешном обновлении данных.
- Пользователь должен быть авторизован для выполнения запроса.


Напишите ваши варианты решения с ходом рассуждений (это важно демонстрировать на собеседовании во время решения задач) в комментарии. А через день я напишу свой вариант ответа. 😊

#http #api #собеседование #практика
—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Написал заметку про редко встречаемые на практике статус-коды 100 и 300 групп с примерами, которые можно воспроизвести.

> > > Коды состояния HTTP 100 и 300 групп < < <

#http #api #web
—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Тестировщики, да сколько можно работать за копейки? 🤔

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

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

А если это не так?

В своём канале Роман Цакунов каждый раз доказывает на практике, что освоить навыки автоматизации может каждый.

– шпаргалками для QA любого уровня, которые помогут в работе
– объясняет сложные вещи и термины на пальцах
– рассеивает мифы о том, что автоматизация - это сложно

Переходите по ссылке и узнайте, как внедрить автоматизацию в свою работу: @rvtsakunov

Реклама. Цакунов Р.В. ИНН 500120617790
erid: 2Vtzqwgi1zb

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

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

Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем посте, тут есть и про выбор, и про синхронные-асинхронные способы, и про разные интеграционные стили. Что на картинке:

4 интеграционных стиля:
- файловый обмен
- общая БД
- вызов удаленной процедуры
- асинхронный обмен сообщениями

Или по другой классификации:
- Ресурсный стиль (REST)
- RPC-стиль
- Query-стиль
- Стиль Publisher/Subscriber

Технологии:
- REST
- SOAP
- GraphQL
- gRPC
- Webhooks
- WebSockets
- Long Polling
- AMQP (RabbitMQ и др.)
- MQTT
- Kafka
- Redis

...и связанные с ними вещи: форматы сообщений/сериализации, языки спецификации интерфейсов и схем данных, средства документирования и тестирования.

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

Пришло время подводить итоги уходящего года. Вот каким этот год был для меня:

• 🎉 Впервые за 7 лет я сменил компанию и теперь работаю в Ozon Tech в одном из крутейших проектов, где продолжаю развивать навыки написания автотестов на Python 🐍 и открываю для себя новое. Например, в этом году, я участвовал в проведении нагрузочного тестирования. В общем, в очередной раз убеждаюсь, что для роста и развития важно периодически делать в жизни перемены. 🌱

• 📅 В начале февраля провел практический интенсив с небольшой группой ребят, на котором мы провели полный цикл тестирования продукта. Про похожий опыт я писал в том году, только теперь это уже был полностью мой проект. В результате несколько учеников сообщили о получении оффера 🎓, как в процессе интенсива, так и в относительно короткий промежуток после. Так что проект оказался полезным. 👍

• 📹 Записал несколько видео на YouTube канале, хотя, конечно, хотелось записать больше. Думаю, что буду и дальше заниматься этим, так как вижу отклик, несмотря на все возникающие ограничения. 💪

• 👩‍🏫 Продолжил преподавать в OTUS, расширив список тем для занятий, а также получил опыт проведения открытых уроков. ✨

И самое интересное. Уже несколько месяцев я занимаюсь созданием практического курса - интенсива по тестированию API 🌐, для которого была разработана полноценная API, на которой будет выполняться практика. В рамках курса будет даваться необходимая теория 📚 и проводиться полный цикл тестирования API, с использованием возможностей Postman и Swagger. 🚀 Сейчас процесс на финальной стадии, и уже в начале 2025 года будет дан старт! Все, кто хотел бы научиться тестировать API и получить первый практический опыт, следите за новостями и ждите анонса. 🔔


С наступающим новым годом, друзья! 🎊 Желаю вам успехов, новых достижений и профессионального роста, а также, конечно, чтобы все были здоровы. ❤️ Ваш автор канала - Алексей.

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

- на тест-дизайн 📝💡
- тестирование API 🌐🔍

на Boosty с возможностью просмотра через плеер Boosty 🎥

> > > ссылка_для_просмотра < < <

👉 Заходите, доступ к видео свободный! ✨


—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Хотите быстро вкатиться (спойлер: нет) в роль QA Lead и навести порядок в хаосе? Или уже руководите, но чувствуете, что процессы несовершенны?

Попробуйте наш уникальный симулятор-курс для QA Lead и пройдите путь в роли руководителя команды тестировщиков. Контролируйте процессы, принимайте сложные решения о найме и увольнении, делегируйте задачи и взаимодействуйте с руководством — всё это в реалистичном симуляторе с поддержкой преподавателя.

👩‍💻 Автор курса — Дима Ерёмин, который знает автоматизацию тестирования изнутри. Его путь — от единственного тестировщика в организации до QA Lead. Уверены, ему есть чем поделиться.

На курсе вы научитесь:

1. Переходу к руководящей роли: строить самостоятельные команды, определять их уровень зрелости и развивать их. Включая постановку и делегирование задач, принятие решений о найме и увольнении, а также разрешение конфликтов.
2. Оптимизации процессов тестирования: внедрять автоматизацию тестирования, управлять багами и проводить нагрузочное тестирование, чтобы повысить эффективность работы команды и отладить процессы.
3. Оценке эффективности: правильно рассчитывать ROI (возврат инвестиций) в тестирование, обосновывать затраты и демонстрировать ценность работы команды руководству.
4. Навыкам взаимодействия с руководством: продавать и презентовать результаты работы команды, доносить их важность и принимать обоснованные решения.

Погрузитесь в реальные задачи QA Lead и ощутите все тонкости этой роли в нашем симуляторе с поддержкой преподавателя. Чтобы оценить подход и формат обучения, начните с демо-доступа курса.

↪️ Получить демо-доступ

Написал новую статью по Python, с примерами использования и объяснениями.

> > > Декораторы и менеджеры контекста в Python. < < <

#aqa #python
—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

📊  Оверимплоймент: что это? Примите участие в новом исследовании от NEWHR и получите инсайты рынка

Вы сотрудник и совмещаете несколько мест работы? Или пока только задумываетесь о поиске подработки и взвешиваете «за» и «против»? А может, никогда не смотрели в эту сторону? Или вы — работодатель, который сталкивается с феноменом оверимплоймента среди своих сотрудников? А может, не сталкивались или не знаете наверняка, совмещают ли ваши сотрудники? Расскажите нам о своем опыте и/или отношении к вопросу!

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

В рамках исследования узнаем:

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

👉🏻 Пройти опрос 👈🏻

Результаты исследования опубликуем в начале 2025 года.

🎁 Для всех, кто поучаствует в опросе:

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

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

👉 Расскажите о вашем отношении к совмещению работ и/или поделитесь этим постом с теми, кому может быть интересна эта тема. Опрос займет не больше 6 минут.

#партнерский_материал

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

1. Ложные ожидания, что будет легко. 💭

В рекламе курсов часто можно услышать, что "тестирование — это лёгкий/быстрый путь в IT". У человека, далёкого от IT и желающего туда перейти, может возникнуть иллюзия, что это действительно так. В реальности же обучение тестированию потребует: погружения в новую предметную область,
понимания теории и умения применять её в нужный момент в определённых ситуациях, выработки новых навыков, овладения множеством инструментов для выполнения отдельных задач в рамках процесса тестирования, плюс погружения в IT в целом. Как показывает время, требования к начинающему тестировщику с каждым годом только растут. Следовательно, растут и объём изучаемого материала, и сложность обучения.

Поэтому у учащегося может возникать представление, что раз профессия "лёгкая", а у него почему-то не получается, то, видимо, дело в нём. Однако ситуация ровно противоположная — с ним всё нормально. Просто профессия далеко не так проста, как могло показаться.

2. Тяжело в учении — легко в бою. ⚔️

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

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

3. Конкретизировать запрос: в чём именно возникают трудности. 🔍

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

Поэтому, испытывая подобные эмоции, следует начать разбираться, задавая себе уточняющие вопросы. Это поможет понять области неопределённости, с которыми стоит поработать.


Если вы разделяете переживания автора запроса, надеюсь, этот пост сможет вас приободрить. 😊 А разобраться с возникшими вопросами по тестированию можно, обратившись за менторской консультацией. Например, ко мне или к коллегам на канале для поиска менторов по тестированию.

#поддержка
—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Решение задач по SQL полезно, чтобы закрепить знания после обучения или если требуется их освежить перед собеседованием. Это позволяет вспомнить правила составления и структуру запросов, а также используемый синтаксис. Но где брать задачи и как организовать процесс? 🤔

Можно, конечно, поднять необходимое СУБД локально, создать в нём базу с таблицами, настроив связи, типы данных и ограничения. Но это потребует времени и сил. Часто оптимальнее обратиться к сайтам-тренажерам, на которых можно прорешать задачи на создание выборки данных. Вот небольшая подборка таких сайтов, с которыми я работал ранее:

1. sql-ex.ru - старый ресурс с большим набором задач на выборку данных (+ на другие типы операций в рамках DML) и учебником. 📚 Задачи содержат ссылки на актуальные главы учебника, что позволяет использовать подход, при котором теоретический материал изучается ровно в том объёме, который необходим для решения конкретной задачи. При этом каждую задачу требуется решить ровно тем способом, который описывается в прикрепленной к задаче главе учебника. Т.е. если вы напишите запрос с использованием других функций или операторов, который даст аналогичный искомому результат, задача не будет засчитана, так как проверка происходит на нескольких базах, идентичных по структуре, но разных по наполнению.

2. sql-practice.com - тренажёр доступный без регистрации (нажимай старт и решай задачи), содержит набор задач на SELECT разной сложности, а также набор фильтров, позволяющий отобрать задачи на основе ключевых слов (например, на JOIN). 🔍 Помимо готовых задач ничто не мешает придумать свои и практиковаться в их решении. На прошлом проекте мы так и сделали и использовали тренажёр во время проведения собеседований.

3. sqltest.online - тренажёр, также доступный без регистрации, позволяющий решать задачи на разных СУБД. Задачи также ранжируются по степени сложности или по темам. Для каждой базы есть диаграмма структуры и связей и подробное описание входящих в неё таблиц с описанием каждой колонки и примером вывода одной записи. 📊 А ещё у проекта есть комьюнити, в котором можно в живом режиме задать вопросы и поделиться обратной связью.


Все эти ресурсы бесплатны и позволяют быстро приступить к практике. Если знаете еще годные площадки, поделитесь ими в комментариях! 💬

#sql #подборка
--
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Всем привет!

Сегодня у меня день рождения 🎉и пользуясь случаем хочу сказать спасибо всем подписчикам и гостям этого канала. Надеюсь что мое творчество приносит пользу и вносит вклад в QA комьюнити. 📚

Радует, что сейчас есть все возможности делиться знаниями и опытом в любом удобном формате. Поэтому буду делать это и дальше. Впереди много планов и надеюсь результаты части из них вы в скором времени сможете увидеть. ⏱👨‍💻


Если захотите меня поздравить и поддержать канал, то можете оформить подписку или отправить донат на бусти. 🤝

Хотите управлять командой тестировщиков?
Или уже руководите, но чувствуете, что процессы несовершенны, а задачи ускользают?

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

Автор курса Дима Ерёмин, и он знает автоматизацию тестирования изнутри. Его путь - от единственного тестировщика в организации до QA Lead, и его опыт дал глубокое понимание различных IT-проектов и ролей в командах. Уверены, ему есть чем поделиться.

На курсе вы научитесь:
✅ Строить самостоятельные команды, определять их уровень зрелости и растить
✅ Налаживать процессы, не превращая их в формальность
✅ Эффективно внедрять новых людей в коллектив
✅ Ставить качественные задачи
✅ Оцифровывать решения и не отстраняться от продукта
✅ Принимать решения и продавать их руководству
✅ Визуализировать планы, доносить их важность и контролировать сроки

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

[ Получить демо - доступ ]

Сегодня столкнулся с ситуацией, когда один API автотест (на Python), успешно выполнявшийся локально, стал падать при добавлении его в джобу с автотестами.❌ Тест проверял создание сущности, которая сначала создавалась в статусе черновика, а затем требовала утверждения. При этом в системе существует правило: у 1 пользователя может быть только 1 сущность в статусе черновик. Создание новой автоматически удаляет черновик предыдущей, делая ее недоступной.

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

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

pytest --dist loadgroup -n 10 ...

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

В качестве решения в оба теста был добавлен маркер

@pytest.mark.xdist_group(name='CreateEntity'),

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


Мораль: при написании автотестов следует учитывать, с какими параметрами и настройками они будут запускаться в рамках CI/CD процессов. ⚙️

#python #aqa
--
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Почем нынче менторство? 🤔

Если вы думаете обратиться за услугами ментора по тестированию, но не знаете, какие сейчас цены на рынке, то можете ознакомиться с результатами опроса на крупном канале по поиску менторов 📊:

https://t.me/qa_mentors/36709

В итоге распределение цен на услуги менторов по тестированию на конец 2024 года 💰:

• Бесплатно: ~22.22%
• 10-19$: ~22.22%
• 20-29$: ~16.67%
• 30-39$: ~16.67%
• 40-49$: ~5.56%
• 50-59$: ~5.56%
• 60-99$: ~5.56%
• От 100$ и выше: ~5.56%

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

#менторство #деньги
—
📺 Канал на YouTube | ☕️ Поддержать автора на Boosty

Запись условных конструкций и цикла for в Python одной строкой. 👨‍💻👩‍💻👨‍💻


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

👨‍💻 1. Цикл for одной строкой (List Comprehension).

Подобная форма записи называется в python list comprehension. List comprehension (генератор списков) — это способ создания списков, словарей и множеств на основе существующих коллекций, применяя к ним цикл и, возможно, условие.

Синтаксис:
[<выражение> for <переменная> in <последовательность>]

Пример:
Создадим список квадратов чисел от 1 до 5:

squares = [x**2 for x in range(1, 6)]

Результат: [1, 4, 9, 16, 25]

Сравните с формой записи, где мы сначала объявляем список, затем указываем цикл и действие в рамках каждой итерации:

squares = []
for x in range(1, 6):
  squares.append(x**2)

👨‍💻 2. Цикл for с условием (Conditional List Comprehension)

Для применения условия к циклу, следует добавить условный оператор if.

Синтаксис:
[<выражение> for <переменная> in <последовательность> if <условие>]

Пример:
Создадим список четных чисел от 1 до 10:

evens = [x for x in range(1, 11) if x % 2 == 0]

Результат: [2, 4, 6, 8, 10]


👨‍💻 3. Условные выражения одной строкой (тернарный оператор)

Способ записи простого условия с 2 исходами называется тернарный оператор. Эта условная конструкция требует три операнда.

Синтаксис:
<выражение1> if <условие> else <выражение2>

Пример:
Вернем x в квадрате, если x больше 0, иначе — само x:

result = x**2 if x > 0 else x

👨‍💻 4. Цикл for с условием внутри тернарного оператора

Эта конструкция объединяет и цикл, и условие, и позволяет создавать более сложные списки или генераторы.

Синтаксис:
[<выражение1> if <условие> else <выражение2> for <переменная> in <последовательность>]

Пример:
Вернем квадрат числа, если оно четное, и его отрицательное значение, если оно нечетное:

results = [x**2 if x % 2 == 0 else -x for x in range(1, 6)]

Результат: [-1, 4, -3, 16, -5]

Однако, как видите, такую конструкцию читать уже сложнее. И это подводит нас к области применения данных способов записи. Если у нас простое условие или цикл for, то запись в 1 строку будет компактнее и легко читаема. Но если у нас вложенные друг в друга условия, то их запись в одну строку будет снижать читаемость кода.

#python
—
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Ускоряем процессы тестирования, улучшаем качество продукта и сокращаем количество ошибок с помощью автоматизации на Java

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

Что будем изучать на практике?
Вы решите более 100 задач и освоите:
- Основы тестирования;
- Программирование на Java и основы ООП;
- PageObject и Unit тесты;
- Аннотации BeforeEach, AfterEach, Disabled и ParameterizedTest;
- Запросы для бэкенд-тестирования, HTTP-запросы (GET, POST, PUT, PATCH, DELETE);
- Запросы в Postman;
- Использование RestAssured для автоматизации тестирования REST API вместе с JUnit5;
- Тестирование iOS и Android приложений на доступность (Accessibility);
- Автоматизированные тесты на Java с использованием Selenide и Selenium;
- Основы работы с Linux и Docker.

Начните практиковаться прямо сейчас в демо-доступе курса.

➡️Регистрация на демо-доступ

🎵 Сегодня добавил новое видео с часом lo-fi музыки, сгенерированной в нейросети Suno, которая идеально подходит для того, чтобы звучать фоном во время работы или учебы.

🎵 Так как видео на канале уже несколько, завел для них отдельный плейлист:

>>> Ссылка на плейлист <<<

А что вы слушаете фоном, когда тестируете? 🎧

Работа с JSONB в PostgreSQL. 📚

Представьте что у вас есть таблица, в 1 из столбцов которой хранятся данные в формате JSONB.

JSONB - это бинарный формат хранения данных типа JSON.

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

Для иллюстрации мы будем использовать следующий JSONB-объект, который будет храниться в столбце data таблицы users:

{
  "id": 1,
  "name": "John Doe",
  "age": 30,
  "address": {
    "city": "New York",
    "zip": "10001"
  },
  "hobbies": [
    {"type": "sports", "name": "basketball"},
    {"type": "music", "name": "guitar"}
  ]
}

Теперь рассмотрим примеры запросов.

🔑 1. Найти запись в таблице по значению ключа

Допустим, нам нужно извлечь записи с именем John Doe. Для того, чтобы это сделать мы можем использовать оператор ->>:

SELECT *
FROM users
WHERE data->>'name' = 'John Doe';

->> используется для извлечения значения по ключу из JSON-объекта и возвращает его в текстовом формате. В данном примере мы вернем только те записи, которые после извлечения значения ключа name и преобразования в текст будут = 'John Doe'.

🔑 2. Найти записи в таблице, у которых значение ключа > определенного числа

Теперь представим, что нам нужно найти записи, значение возраста в которых будет больше 25. Так как оператор ->> вернет нам строку, то сравнить ее с числом не получится. Для этого значение нужно преобразовать в число:

SELECT *
FROM users
WHERE (data->>'age')::int > 25;

::int преобразует извлеченное значение ключа age в число. Таким образом в WHERE можно отфильтровать записи, значение age в которых превышает 25.

🔑 3. Найти запись по значению ключа объекта, вложенного в другой объект

Если нам нужно найти записи с городом New York, который находится внутри объекта address, мы можем использовать оператор ->:

SELECT *
FROM users
WHERE data->'address'->>'city' = 'New York';

С помощью -> мы извлекаем значение ключа address в формате JSONB и уже в нем, с помощью ->> извлекаем значение city в текстовом формате. Таким образом мы получим все записи, где значением city указан 'New York'.

🔑 4. Найти запись по значению ключа объекта, вложенного в список внутри другого объекта

Если мы хотим найти записи, где в массиве hobbies содержится хобби с названием guаitar, то можем воспользоваться оператором @> в запросе:

SELECT *
FROM users
WHERE data @> '{"hobbies": [{"name": "guitar"}]}';

С помощью оператора вложенности @> мы проверяем, содержит ли JSONB-объект hobbies в своем массиве другой JSONB-объект, с ключом name, значением которого является 'guitar'.


Таким образом мы можем выполнять поиск нужных нам записей, на основе значений ключа в JSONB-объекте. Следует помнить, что по мимо JSONB, данные также могут храниться в JSON формате и в этом случае мы не сможем выполнить оператор @> в запросе. Также здесь описана только часть возможностей работы с JSONB, более подробная информация описана в документации.

#sql #postgresql

Какими знаниями и навыками должен обладать QA, чтобы за ним выстраивалась очередь?

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

Команда SkillsTeam разработала такой удобный инструмент — готовые матрицы компетенций для различных специалистов. В частности, для T-shaped QA — тех, кто готов наращивать скилы и в смежных областях, например, разработке. Как показывает практика, именно они лучше всего закрывают задачи в заказной разработке.

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

Не баг, а фича уральской погоды 🙂

Терпение и труд всё перетрут 💪⏳

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

Я давно читаю блог Натальи, в котором автор решила стать QA и подробно описывает весь свой путь. Формат напоминает дневник, в котором регулярно подводятся итоги недели: по каким вакансиям было отправлено резюме, какой был отклик, где было выслано тестовое, какой был итоговый результат.

Недавно Наталья поделилась радостной новостью — она стала младшим тестировщиком! 🎉 Знаете, какая это была по счёту неделя поиска? 76-я! Полтора года поиска. За это время можно было множество раз отказаться от планов стать тестировщиком, бросить поиски и затем сетовать на невозможность получить работу QA. Но автор не сдалась и добилась своего. 🚀

И вы обязательно добьётесь своего, если продолжите работу (а это именно работа) по поиску, решению тестовых и прохождению собеседований, анализу ошибок и их исправлению. Пусть пример Натальи лишний раз напоминает вам об этом. 🔥👩‍💻

А вот и запись видео с посиделок. 🤝

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

Отдельное спасибо Надежде с канала ProTestingInfo за помощь в чате.

Завтра планирую принять участие в данном мероприятии ✨

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

Оценка и разбор резюме в прямом эфире

Анонс программы посиделок во вторник 24 сентября в 20 по мск :
- оценка резюме со стороны hr
- оценка резюме со стороны технического специалиста
- рекомендации по составлению резюме
- рекомендации по откликам на вакансии
- разбор резюме в прямом эфире
- можно будет задавать вопросы

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

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

Готовьте ваши резюме (без личных данных)

🎥 Новый разбор тестового задания уже на Boosty!

Друзья, мне настолько понравилось тестовое задание, что я записал его подробный разбор и загрузил на Boosty! Подписчики уровня Junior и выше уже могут посмотреть видео. 🏃‍♂️На YouTube видео тоже появится, но в понедельник.

И пользуясь поводом, хочу пригласить вас подписаться на мой Boosty! 🔥

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

Для подписчиков будет много приятных бонусов:
🏅 Упоминание в титрах новых видео
⏳ Ранний доступ к новым видео и эксклюзивы, которых не будет ни в Telegram, ни на YouTube
🗣 Закрытый чат для с комфортной атмосферой общения и вопросов по всем важным темам
🎓 Скидки на консультации
... и думаю я еще пополню список. Чем выше уровень подписки, тем больше бонусов. 😉

Приходите и подписывайтесь, друзья!

Явные и неявные ожидания на примере Python Selenium.

Частый и популярный вопрос как на собеседованиях, так и в работе над автоматизацией UI-тестов. Попробуем разобраться. В качестве примера возьмём страницу -

https://www.selenium.dev/selenium/web/dynamic.html.

Представьте, что мы автоматизируем тест, проверяющий появление красного квадрата после нажатия кнопки "add a box!". Пример простого кода:

from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from webdriver_manager.chrome import ChromeDriverManager
from selenium import webdriver

def test_red_box_adding():
    service = Service(ChromeDriverManager().install())
    wd = webdriver.Chrome(service=service)
    wd.maximize_window()

    wd.get('https://www.selenium.dev/selenium/web/dynamic.html')
    btn = wd.find_element(By.ID, 'adder')
    btn.click()

    box = wd.find_element(By.ID, 'box0')
    el = box.get_attribute('class')
    assert el == 'redbox'

    wd.quit()

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

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

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

driver.implicitly_wait(10)

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

🐈 Явные ожидания многократно (в пределах указанного времени) опрашивают страницу на предмет соблюдения условия и, когда оно выполняется, переходят к выполнению следующих команд. Реализуются с помощью WebDriverWait, который задаёт таймаут, и ExpectedCondition, задающего необходимое условие.

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
<...>

WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.ID, "box0")))

В данном примере драйвер в течение 10 секунд проверяет, что элемент с id="box0" присутствует в DOM. Если это так, то будет выполнена следующая инструкция.

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

https://www.selenium.dev/selenium/docs/api/py/webdriver_support/selenium.webdriver.support.expected_conditions.html.

❓ Какой тип ожидания выбрать? Выбор типа ожидания зависит от конкретной ситуации. Например, при поиске разных элементов с различными условиями может потребоваться задавать разные таймауты, и в таком случае явные ожидания будут предпочтительнее. Однако иногда удобнее задать один раз неявное ожидание на несколько секунд, что позволит ускорить написание простых однотипных тестов. При этом важно помнить, что даже с использованием ожиданий остаётся риск того, что элемент не появится в DOM к моменту истечения времени ожидания.

#python #selenium #aqa

Делюсь тестовым заданием для уровня intern/junior от 2GIS для тех, кто хочет попрактиковаться в тестировании API:

ссылка_на_тестовое_задание

В нем можно:
🟢 проверить навыки тест-дизайна и написания баг-репортов
🟢 попрактиковаться в работе с инструментом для отправки запросов, таким как Postman
🟢 бонусом попробовать написать API автотесты


Рекомендую выполнить задание, а затем сравнить свое решение с решением из видео.

#практика #api

Коллеги, поздравляю с профессиональным праздником! 🎉

Желаю не терять критического мышления, творчески подходить к решению самых разнообразных задач, расти и развиваться как в профессии, так и в смежных направлениях, расширяя кругозор и насмотренность. 📚 А также делать жизнь вокруг лучше, обеспечивая качество выпускаемых продуктов. 💪

Всем же, кто только вступает на этот путь, желаю упорства и удачи, офферов мечты, а также интересных и вдохновляющих проектов! ✨

💡 Часто на работе узнаю какие-то мелочи, дополняющие уже имеющиеся знания по теории, инструментам или командам для работы с ними. Буду делиться такой информацией, так как она может оказаться полезной не только для меня.

👨‍💻 Вчера, работая с базой данных, узнал от коллеги, как с помощью RETURNING в SQL-запросе получить данные из модифицируемых строк в процессе их обработки. Представьте, что нам требуется добавить запись в таблицу, где ей автоматически будет присвоен id, который нам нужно узнать для последующего использования. Выглядеть такой запрос будет следующим образом:

INSERT INTO table_name (column1, column2, column3, ...)
VALUES (value1, value2, value3, ...)
RETURNING columnId; -- где columnId — наименование колонки с id

📝 Пример:

INSERT INTO Customer (FirstName, LastName, Address, City, PostalCode, Country, Email)
VALUES ('Cardinal', 'Tom B. Erichsen', 'Skagen 21', 'Stavanger', '4006', 'Norway', '[email protected]')
RETURNING CustomerId;

📌 В ответе вернётся id добавленной записи с информацией о клиенте.

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

⚙️ RETURNING может использоваться в командах INSERT, UPDATE и DELETE.

🎥 В своем первом видео на YouTube я рассказывал о том, как валидировать тело ответа в формате JSON в Postman на соответствие JSON-схеме с использованием Tiny Validator. Валидация на соответствие JSON-схеме — это процесс проверки того, что структура и данные в JSON-документе соответствуют определенным правилам, описанным в JSON-схеме. Такая проверка является комплексной и намного удобнее, чем проверять каждый параметр по отдельности.

🚨 С недавнего времени Postman перестал позволять использовать Tiny Validator, так как он устарел. Однако есть альтернатива, доступная по умолчанию, — библиотека AJV, которая также позволяет выполнять валидацию на соответствие JSON-схеме и при этом является более гибкой и производительной.

📚 Далее я покажу, как легко применить AJV для валидации данных из response body в формате JSON. Рассмотрим пример с тестовым API: https://apichallenges.herokuapp.com/
Для примера будем тестировать ответ одного из эндпоинтов — /challenges, который возвращает список челленджей.

📦 Тело ответа выглядит так:

{
    "challenges": [
        {
            "id": 1,
            "name": "POST /challenger (201)",
            "description": "Issue a POST request on the /challenger end point, with no body, to create a new challenger session. Use the generated X-CHALLENGER header in future requests to track challenge completion.",
            "status": false
        },
        {
            "id": 2,
            "name": "GET /challenges (200)",
            "description": "Issue a GET request on the /challenges end point",
            "status": false
        },
        ...
    ]
}

👨‍💻 Реализуем следующий алгоритм:

1. Определим для него JSON-схему.
2. Импортируем библиотеку и создадим экземпляр класса AJV.
3. Конвертируем тело ответа от сервера в JSON.
4. С помощью метода ajv.validate() выполним проверку соответствия JSON-ответа определенной схеме, поместив результат в переменную.
5. Создадим тест, в котором проверим, что результат валидации в переменной является true.
6. В случае неудачного выполнения теста выведем в консоль информацию об ошибках из атрибута экземпляра класса errors.

💻 Код будет выглядеть так:

// Определяем JSON-схему для всего ответа
const schema = {
  "type": "object",
  "properties": {
    "challenges": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": { "type": "integer" },
          "name": { "type": "string" },
          "description": { "type": "string" },
          "status": { "type": "boolean" }
        },
        "required": ["id", "name", "description", "status"]
      }
    }
  },
  "required": ["challenges"]
};

/*
Небольшие пояснения к схеме:
type: "object" — основной объект JSON должен быть объектом.
properties: { "challenges": ... } — определяет, что объект должен содержать свойство challenges, которое является массивом.
items: { ... } — схема для каждого элемента массива challenges.
required: [...] — массив, содержащий обязательные параметры, которые должны присутствовать в каждом элементе challenges.
*/

// Импортируем библиотеку AJV
const Ajv = require('ajv');

// Создаем экземпляр класса AJV
const ajv = new Ajv();

// Конвертируем тело ответа, полученное от сервера, в JSON
const responseData = pm.response.json();

// Выполняем валидацию JSON-ответа на соответствие схеме
const valid = ajv.validate(schema, responseData);

// Создаем тест, в котором проверяем, прошла ли валидация
pm.test("JSON body validation", function() {
    pm.expect(valid).to.be.true;
});

// Если валидация не прошла, выводим ошибки в console
if (!valid) {
    console.log(ajv.errors);
}

Как видите, реализация не сильно отличается от того, как это делалось с помощью Tiny Validator. Поэтому перестроиться можно быстро и легко.

🔝 Хедер и 🔻 футер

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

🧑‍💻 Header (шапка) — раздел сайта, располагающийся наверху веб-страницы. При открытии страницы это будет первое, что увидит пользователь. Хедер как правило содержит логотип, главное меню, контактную информацию, переключатель языка и ссылки на важные разделы.

📜 Footer (подвал) — нижняя часть сайта, которой заканчивается веб-страница. Содержит контактные данные, ссылки на политику конфиденциальности, условия использования, копирайт, а также иногда дополнительные меню, ссылки на социальные сети или карту сайта.

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

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

📌 Про разницу между Agile, SCRUM и итеративной моделью разработки.

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

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

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

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

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

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

Таким образом подытожим:

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

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

Scrum — это фреймворк, который предлагает конкретные процессы, роли и артефакты для работы в итеративной модели, в рамках Agile-принципов.

#теория

🎉 Друзья, отличные новости! 🎉

Ozon Tech запускает курс для Middle QA, которые хотят прокачать свои навыки в автоматизации тестирования на Go!

🧑‍💻 Вас ожидают: 2 месяца онлайн-обучения с экспертами из бигтеха, вебинары дважды в неделю, практические воркшопы и разбор домашних заданий. Также вас ждем погружение в специфику e-commerce и карьерные перспективы.

🚀 Что нужно для участия? 2 года опыта в автоматизации на любом языке и успех на отборочном контесте 11 августа. Оставьте заявку уже сейчас!

🔗 Переходите по ссылке, чтобы узнать все детали и зарегистрироваться:

https://s.ozon.ru/lBpyjNw

Не упустите возможность получить новые навыки и карьерные перспективы вместе с Ozon Tech! 🥳


Реклама. ООО «Озон Технологии». erid: LjN8K4gtM

Еще немного про монолит и микросервисы 🙂
(автор неизвестен)

#it_memes

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

Как создавать скриншоты при падении автотестов на Selenium с помощью Pytest?

#python #pytest #allure #selenium

🎙 Пробую новый формат видео на YouTube. Записал интервью с коллегой - опытным backend-разработчиком и лидом в Ozon из департамента доставки Дмитрием Кармишкиным, раскрывающее тему бэкенда для начинающих QA.

🔥 Интервью получилось большим, насыщенным и интересным. Приходите посмотреть/послушать:

> > > ссылка_на_видео < < <