Системный аналитик: что это за роль и зачем ее смотреть
Если коротко — тот, кто превращает «бизнес хочет вот это» в «разработка знает, что сделать». Собирает требования, рисует схемы, описывает поведение системы и ставит задачи разработке. Это соседняя роль к QA — часть работы пересекается, часть новая. Из текста вакансий или описания курсов понять, стоит ли туда смотреть, тяжело: нужен один проект изнутри.
Один такой проект разберут 5 ноября в 18:00 мск на бесплатном вебинаре karpovꓸcourses «Системный аналитик в 2026: как войти в профессию, когда код пишет ИИ».
Ведет Екатерина Комиссарова, архитектор решений в Лемана ПРО, 5+ лет в системной аналитике. На эфире разберет один проект по шагам, границу между БА, СА, проджектом и архитектором и место ИИ в этой работе: что он уже забирает и почему системам с ИИ-ассистентами по-прежнему нужен человек.
Примерьте профессию на себя: https://clc.to/erid_2W5zFGyuuHL
Всем участникам придет запись после эфира.
Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFGyuuHL
Если коротко — тот, кто превращает «бизнес хочет вот это» в «разработка знает, что сделать». Собирает требования, рисует схемы, описывает поведение системы и ставит задачи разработке. Это соседняя роль к QA — часть работы пересекается, часть новая. Из текста вакансий или описания курсов понять, стоит ли туда смотреть, тяжело: нужен один проект изнутри.
Один такой проект разберут 5 ноября в 18:00 мск на бесплатном вебинаре karpovꓸcourses «Системный аналитик в 2026: как войти в профессию, когда код пишет ИИ».
Ведет Екатерина Комиссарова, архитектор решений в Лемана ПРО, 5+ лет в системной аналитике. На эфире разберет один проект по шагам, границу между БА, СА, проджектом и архитектором и место ИИ в этой работе: что он уже забирает и почему системам с ИИ-ассистентами по-прежнему нужен человек.
Примерьте профессию на себя: https://clc.to/erid_2W5zFGyuuHL
Всем участникам придет запись после эфира.
Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFGyuuHL
❤5🤔2👍1
📌 ТОП инструментов для тестирования file upload / download
Загрузка и скачивание файлов — частая функциональность в веб-приложениях.
И именно здесь часто возникают баги: неверный формат, битые файлы, проблемы с правами доступа или безопасностью.
Собрали инструменты и подходы, которые помогут QA качественно проверять upload/download-флоу:
▫️ Postman
— Тестирование upload через form-data
— Проверка Content-Type и размера файла
— Валидация ответа сервера
🔗 https://www.postman.com
▫️ HTTPBin
— Проверка отправки multipart/form-data
— Анализ headers и payload
— Удобно для экспериментов с API
🔗 https://httpbin.org
▫️ Chrome DevTools (Network)
— Проверка статуса ответа
— Анализ Content-Disposition и Content-Type
— Проверка размера файла и времени загрузки
🔗 https://developer.chrome.com/docs/devtools/network
▫️ cURL (CLI)
— Загрузка файлов через терминал
— Проверка API без UI
— Полезно для негативных сценариев
🔗 https://curl.se
▫️ OWASP File Upload Cheat Sheet
— Рекомендации по безопасной загрузке файлов
— Проверка MIME-type, расширений, размера
— Полезно для security-тестирования
🔗 https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
▫️ Checklist для QA (что проверять)
— Ограничение размера файла
— Разрешённые / запрещённые форматы
— Переименование файла на сервере
— Обработка одинаковых имён
— Проверка вирусов (если предусмотрено)
— Доступ к скачиванию по ролям
— Поведение при обрыве соединения
Файловый функционал кажется простым, но часто содержит критичные баги.
Загрузка и скачивание файлов — частая функциональность в веб-приложениях.
И именно здесь часто возникают баги: неверный формат, битые файлы, проблемы с правами доступа или безопасностью.
Собрали инструменты и подходы, которые помогут QA качественно проверять upload/download-флоу:
▫️ Postman
— Тестирование upload через form-data
— Проверка Content-Type и размера файла
— Валидация ответа сервера
🔗 https://www.postman.com
▫️ HTTPBin
— Проверка отправки multipart/form-data
— Анализ headers и payload
— Удобно для экспериментов с API
🔗 https://httpbin.org
▫️ Chrome DevTools (Network)
— Проверка статуса ответа
— Анализ Content-Disposition и Content-Type
— Проверка размера файла и времени загрузки
🔗 https://developer.chrome.com/docs/devtools/network
▫️ cURL (CLI)
— Загрузка файлов через терминал
— Проверка API без UI
— Полезно для негативных сценариев
🔗 https://curl.se
▫️ OWASP File Upload Cheat Sheet
— Рекомендации по безопасной загрузке файлов
— Проверка MIME-type, расширений, размера
— Полезно для security-тестирования
🔗 https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
▫️ Checklist для QA (что проверять)
— Ограничение размера файла
— Разрешённые / запрещённые форматы
— Переименование файла на сервере
— Обработка одинаковых имён
— Проверка вирусов (если предусмотрено)
— Доступ к скачиванию по ролям
— Поведение при обрыве соединения
Файловый функционал кажется простым, но часто содержит критичные баги.
👍4❤2
Железо до релиза: экскурсии по лабораториям YADRO в Санкт-Петербурге и Москве
Маршруты пройдут через рабочие зоны команд, где проверяют серверы, системы хранения данных и телеком-оборудование. По пути инженеры расскажут, как проходят испытания, и покажут железо, которое они тестируют.
Вопросы можно задавать прямо по ходу экскурсии: о продуктах, задачах и о том, как устроена работа команд.
📍 Санкт-Петербург — 12 ноября и 1 декабря
📍 Москва — 17 ноября и 8 декабря
Сбор гостей в 18:30, старт в 19:00.
Возраст участников — от 18 лет. Экскурсии проходят по вечерам, а участие бесплатное — нужно зарегистрироваться и дождаться подтверждения от организаторов.
👉 Зарегистрироваться
Реклама. ООО "КНС ГРУПП". ИНН 7701411241. erid: 2W5zFGRLrZ8
Маршруты пройдут через рабочие зоны команд, где проверяют серверы, системы хранения данных и телеком-оборудование. По пути инженеры расскажут, как проходят испытания, и покажут железо, которое они тестируют.
Вопросы можно задавать прямо по ходу экскурсии: о продуктах, задачах и о том, как устроена работа команд.
📍 Санкт-Петербург — 12 ноября и 1 декабря
📍 Москва — 17 ноября и 8 декабря
Сбор гостей в 18:30, старт в 19:00.
Возраст участников — от 18 лет. Экскурсии проходят по вечерам, а участие бесплатное — нужно зарегистрироваться и дождаться подтверждения от организаторов.
👉 Зарегистрироваться
Реклама. ООО "КНС ГРУПП". ИНН 7701411241. erid: 2W5zFGRLrZ8
👎1
Выбор языка для автотестов.
Автор: Ксения Райковская, QA Automation Lead в Plata
Сегодня хочу затронуть тему, которая почти всегда вызывает споры. Вопросы по ней часто задают на собеседованиях, мнения на этот счёт - диаметрально противоположные, и правильного ответа нет.
Всё, что написано ниже - моё личное мнение, во многом совпадающее с мнением Alex Pshe и ряда других источников, которые я читала и смотрела.
Способы выбора языка автотестов:
1. По языку backend.
Часто используемая стратегия. Позволяет переиспользовать модели, классы работы с базой, API-контракты. Обычно тесты фронта в таком случае тоже пишут на этом языке, особенно если он достаточно универсален.
2. По языку фронта.
Когда в фокусе UI-часть, в игру вступают JS/TS. Плюсы: можно задействовать фронтов, больше специалистов с таким стеком, сами языки проще. В таком случае и бэк часто тестируется на этом же языке.
3. Разные языки для тестов фронта и бэка.
Иногда UI и API тестируются разными людьми или даже командами. Тогда каждый пишет на «своём» языке. Это рабочий вариант, но если QA-команда одна - жизнь усложняется, падает переиспользуемость, возрастают усилия на поддержку.
4. Язык, не используемый в разработке.
Моё любимое. Исторически сложилось - взяли QA, который писал, скажем, на Python - продолжаем писать на Python, хотя бэк на Go. Бывает, что тесты начинали писать разработчики, выбрали «удобный» фреймворк, который не имеет никакого отношения к тому на чём написан проект, а теперь нанимают QA для поддержки. Ещё причина - рынок - Python и Java QA найти проще и дешевле, чем C# или Go. Иногда уже есть свой фреймворк и обучение в компании - на всех проектах используется один язык - проще перевести людей между проектами и масштабировать best practice и подходы.
5. Низкоуровневые или визуальные инструменты (Katalon, TestComplete и т.п.)
Часто - от руководства. Иногда - это способ перевести ручников в автотестирование. Слышала на собесе историю, где купили дорогущий Katalon «инструмент простой, тестировщики справятся».
Что выбрать?
Универсального ответа нет. Мне ближе первый подход. Но всё зависит от ситуации. Иногда четвёртый - лучшее, что можно придумать, когда нет доступа к коду, когда нужно снизить косты, и повысить ROI.
А что говорить на собеседовании?
Первое - задать встречные вопросы:
• Что уже используется?
• На чём написаны бэк и фронт, есть ли вообще доступ у тестировщиков к коду?
• Планируется ли автоматизация мобилки?
• Что первично - UI или backend?
• Насколько часто меняется код?
• Сколько человек в QA-команде или планируется?
Если всё только начинается - уточни, какой функционал будет покрываться в первую очередь. Если бэк стабилен - его тестировать дешевле и быстрее.
Если стек проекта редкий и проект не очень большой, лучше не настаивать на языке бэка. Можно честно сказать: «у меня есть экспертиза в таких-то стеках. Учитывая, что ваш язык редкий, я бы выбрала <X> - это ускорит запуск и упростит найм».
Автор: Ксения Райковская, QA Automation Lead в Plata
Сегодня хочу затронуть тему, которая почти всегда вызывает споры. Вопросы по ней часто задают на собеседованиях, мнения на этот счёт - диаметрально противоположные, и правильного ответа нет.
Всё, что написано ниже - моё личное мнение, во многом совпадающее с мнением Alex Pshe и ряда других источников, которые я читала и смотрела.
Способы выбора языка автотестов:
1. По языку backend.
Часто используемая стратегия. Позволяет переиспользовать модели, классы работы с базой, API-контракты. Обычно тесты фронта в таком случае тоже пишут на этом языке, особенно если он достаточно универсален.
2. По языку фронта.
Когда в фокусе UI-часть, в игру вступают JS/TS. Плюсы: можно задействовать фронтов, больше специалистов с таким стеком, сами языки проще. В таком случае и бэк часто тестируется на этом же языке.
3. Разные языки для тестов фронта и бэка.
Иногда UI и API тестируются разными людьми или даже командами. Тогда каждый пишет на «своём» языке. Это рабочий вариант, но если QA-команда одна - жизнь усложняется, падает переиспользуемость, возрастают усилия на поддержку.
4. Язык, не используемый в разработке.
Моё любимое. Исторически сложилось - взяли QA, который писал, скажем, на Python - продолжаем писать на Python, хотя бэк на Go. Бывает, что тесты начинали писать разработчики, выбрали «удобный» фреймворк, который не имеет никакого отношения к тому на чём написан проект, а теперь нанимают QA для поддержки. Ещё причина - рынок - Python и Java QA найти проще и дешевле, чем C# или Go. Иногда уже есть свой фреймворк и обучение в компании - на всех проектах используется один язык - проще перевести людей между проектами и масштабировать best practice и подходы.
5. Низкоуровневые или визуальные инструменты (Katalon, TestComplete и т.п.)
Часто - от руководства. Иногда - это способ перевести ручников в автотестирование. Слышала на собесе историю, где купили дорогущий Katalon «инструмент простой, тестировщики справятся».
Что выбрать?
Универсального ответа нет. Мне ближе первый подход. Но всё зависит от ситуации. Иногда четвёртый - лучшее, что можно придумать, когда нет доступа к коду, когда нужно снизить косты, и повысить ROI.
А что говорить на собеседовании?
Первое - задать встречные вопросы:
• Что уже используется?
• На чём написаны бэк и фронт, есть ли вообще доступ у тестировщиков к коду?
• Планируется ли автоматизация мобилки?
• Что первично - UI или backend?
• Насколько часто меняется код?
• Сколько человек в QA-команде или планируется?
Если всё только начинается - уточни, какой функционал будет покрываться в первую очередь. Если бэк стабилен - его тестировать дешевле и быстрее.
Если стек проекта редкий и проект не очень большой, лучше не настаивать на языке бэка. Можно честно сказать: «у меня есть экспертиза в таких-то стеках. Учитывая, что ваш язык редкий, я бы выбрала <X> - это ускорит запуск и упростит найм».
❤10👍3👎1
AI в QA: свежие кейсы на Podlodka QA Crew
Искусственный интеллект не только ускоряет работу, но и влияет на сам подход к тестированию. Часть рутины автоматизируется, но растут требования к способности инженера оценивать качество проверок, находить ошибки и сохранять контроль над результатом.
С 16 по 20 ноября на конференции Podlodka QA Crew эксперты разберут, как меняется работа QA-инженеров и какие практики помогают адаптироваться к новым условиям.
🧠 В программе сезона:
• Как теперь распределяется ответственность между AI и человеком
• Зачем автотестам иногда нужно падать
• Как пройти путь от требований до проверяемого решения со Spec-Driven Development
• Как не превратиться в оператора нейросетей и сохранить собственную квалификацию.
Формат конференции — комфортный онлайн: 5 дней, утренние и вечерние сессии в Zoom и много общения с коллегами в закрытом телеграм-чате.
Программа дополняется — следить за обновлениями можно на сайте конференции.
Podlodka QA Crew — возможность разобраться, как использовать AI в тестировании без потери контроля над качеством и забрать лучшие практики в свой проект уже в следующем спринте.
Присоединиться: https://podlodka.io/qacrew
Искусственный интеллект не только ускоряет работу, но и влияет на сам подход к тестированию. Часть рутины автоматизируется, но растут требования к способности инженера оценивать качество проверок, находить ошибки и сохранять контроль над результатом.
С 16 по 20 ноября на конференции Podlodka QA Crew эксперты разберут, как меняется работа QA-инженеров и какие практики помогают адаптироваться к новым условиям.
• Как теперь распределяется ответственность между AI и человеком
• Зачем автотестам иногда нужно падать
• Как пройти путь от требований до проверяемого решения со Spec-Driven Development
• Как не превратиться в оператора нейросетей и сохранить собственную квалификацию.
Формат конференции — комфортный онлайн: 5 дней, утренние и вечерние сессии в Zoom и много общения с коллегами в закрытом телеграм-чате.
Программа дополняется — следить за обновлениями можно на сайте конференции.
Podlodka QA Crew — возможность разобраться, как использовать AI в тестировании без потери контроля над качеством и забрать лучшие практики в свой проект уже в следующем спринте.
Присоединиться: https://podlodka.io/qacrew
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👎4❤3🎉2👍1🌚1
Знать синтаксис каналов в Go и уверенно применять их в задачах — не одно и то же. В конкурентном коде важно понимать, зачем нужен канал, как он участвует во взаимодействии горутин и где выбранное решение может привести к ошибке.
10 ноября в 20:00 на открытом уроке курса «Go-разработчик. Продвинутый уровень» разберёте использование каналов на практике.
Начнёте с короткого повторения теории — как устроены каналы и для чего они нужны. Затем перейдёте к классическим и прикладным примерам, чтобы связать поведение этого инструмента с конкретными задачами.
Отдельное внимание уделите частым ошибкам и подводным камням. Разбор поможет внимательнее читать конкурентный код и замечать места, где работу с каналами стоит проверить, прежде чем переносить решение в свой проект.
Урок подойдёт тем, кто знакомится с конкурентностью в Go или уже использует каналы, но хочет лучше понимать их применение. Можно будет сопоставить разобранные примеры со своим опытом и задать вопросы преподавателю.
После занятия у вас будет более ясное представление о том, как переходить от теории каналов к их использованию в реальных задачах и на какие ошибки обращать внимание.
Урок проведёт Юрий Рубаха.
Зарегистрироваться: https://vk.cc/d3E5WV
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
10 ноября в 20:00 на открытом уроке курса «Go-разработчик. Продвинутый уровень» разберёте использование каналов на практике.
Начнёте с короткого повторения теории — как устроены каналы и для чего они нужны. Затем перейдёте к классическим и прикладным примерам, чтобы связать поведение этого инструмента с конкретными задачами.
Отдельное внимание уделите частым ошибкам и подводным камням. Разбор поможет внимательнее читать конкурентный код и замечать места, где работу с каналами стоит проверить, прежде чем переносить решение в свой проект.
Урок подойдёт тем, кто знакомится с конкурентностью в Go или уже использует каналы, но хочет лучше понимать их применение. Можно будет сопоставить разобранные примеры со своим опытом и задать вопросы преподавателю.
После занятия у вас будет более ясное представление о том, как переходить от теории каналов к их использованию в реальных задачах и на какие ошибки обращать внимание.
Урок проведёт Юрий Рубаха.
Зарегистрироваться: https://vk.cc/d3E5WV
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
❤2👍1👎1😎1