Тестирование IT-систем *

Полгода назад я испытал культурный шок. Всю карьеру — я QA Automation Engineer — пилил фичи в аутсорсе: стабильно, предсказуемо, местами даже комфортно. Но на январских каникулах впервые за долгое время задумался: мне скоро 30, я уверенный сеньор — а будто бы стою на месте.

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

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

В мире тестирования безопасности важно не только «залезть внутрь», но и сделать это так, чтобы никто не заметил. Ниже собраны практики, которые используют пентестеры и исследователи, чтобы их действия было сложнее заметить. Все примеры — только для обучения и безопасных экспериментов. Рекомендую всем изучить и добавить свои методы в комментариях ...

Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)

В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.

Отладка E2E-тестов может быть трудоёмкой задачей. При падении тестов Playwright нередко приходится вручную анализировать сообщения об ошибках и стек-трейсы, искать причины неудач (например, неправильно подобранный селектор, увеличенные задержки или неожиданные изменения в DOM) и пробовать разные варианты исправлений. Традиционно QA-инженерам приходится копировать текст ошибок и обращаться к документации или чат-ботам вроде ChatGPT с вопросами вроде «почему селектор не нашёлся» или «как увеличить таймаут». Это занимает время и отнимает ресурсы команды.

Тест-кейс тест-кейсу рознь!

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

Доработка кейсов своими силами (силами автотестеров) в процессе автоматизации – это сизифов труд.

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

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

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

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

Итак, начнем урок.

Привет!

Меня зовут Валентин, я — руководитель направления тестирования моделей машинного обучения в Альфа-Банке. Моя команда занимается тестированием ML-моделей и модельных сервисов для наших клиентов уже более четырех лет, и более трех из них я погружен в наши процессы QA.

Я попал в Альфу через проект компании KTS, над которым работал раньше, и первое время занимался ручным тестированием. За несколько лет прошел путь от линейного тестировщика до руководителя команды из 8 человек, и в этой статье рассказываю о своем опыте и делюсь советами, которые дал бы самому себе несколько лет назад.

Эта статья будет полезна:

• тем, кто только начинает выстраивать процессы тестирования моделей;
• начинающим тимлидам QA-команд до 10 человек;
• тем, кто просто хочет познакомиться с примером организации QA-процесса с нуля.

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

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

Но отчёты сами по себе малоэффективны, если команда не узнает о результатах вовремя. Чтобы тестирование было действительно полезным, важно оперативно уведомлять участников проекта о его статусе. Один из самых простых и эффективных способов – автоматическая отправка отчетов Allure по электронной почте.

Привет! Я SDET-специалист SimbirSoft Руслан, и в этой статье мы разберем как настроить SMTP-сервер для отправки почты в Jenkins, как настроить GitLab Runner и как автоматизировать отправку отчетов после выполнения тестов.

Хотите прокачать навыки в Golang, понять, как работает FastAPI, освоить практики MLOps или разобраться с Terraform? В сентябре вас ждут 60 бесплатных уроков по разным ИТ-направлениям: программирование, архитектура, инфраструктура, безопасность, тестирование, ML, аналитика и управление.

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

Привет, Хабр! Меня зовут Егор, я руководитель Центра компетенций обеспечения качества SM Lab. И именно про наш центр компетенция я и хочу рассказать. Статья пригодится не только тестировщикам, но и разработчикам и аналитикам. Ведь тестирование — это не только поиск багов, но и создание культуры качества. 

Обсудим состав и механику работы нашего ЦК, продуктовые команды, а также немного подискутируем на тему тестирования в целом — каким оно будет в будущем, как на него повлияет ИИ и автоматизация.

Каждую ночь тысячи автотестов отрабатывают на бою, и сотни падений превращаются в рутину для QA-команд. Но что если привычный разбор ошибок можно отдать искусственному интеллекту — и самому сосредоточиться только на новых, действительно значимых сбоях? В этой статье — реальный опыт внедрения ReportPortal, который показывает, как ИИ помогает классифицировать падения, экономить время тестировщиков и снижать количество человеческих ошибок, не превращаясь при этом в «волшебную чёрную коробку».

Всем привет! Я Полина Спиридонова, product owner двух продуктов для подготовки специалистов по защите информации — Standoff Cyberbones и Standoff Defend.

В статье я расскажу, как мы прошли путь от формулирования идеи из вопроса «Как создать полигон для синих команд?» до запуска Standoff Defend — инструмента, который помогает командам SOC становиться сильнее. Давайте погрузимся в детали и узнаем, как все начиналось и к чему мы пришли.

Хочу рассказать об опыте пилотирования собственного решения компании — Kaspersky NGFW — с точки зрения специалиста по информационной безопасности.

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

В предыдущих частях работы (Часть 1, Часть 2) мы разобрали, что такое линейный конгруэнтный метод (ЛКМ), и как на его основе работает функция Rnd(), вшитая в скриптовый язык VBA, созданный Microsoft. Именно эта функция и "ответственна" за генерацию псевдослучайных чисел. Мы поняли, как ведет себя функция, если в качестве ее аргумента ввести число меньшее либо равное 0. Также мы выяснили, что эта функция работает с мнимым и реальными значениями своих аргументов, также мы поняли, как соотносятся некоторые мнимые значения аргумента функции с их реальными значениями.

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

В статье — эволюция поисковиков и практические хаки для работы: скрытые операторы, малоизвестные команды Яндекса и Google, промпты для Perplexity и Gemini, техники точной фильтрации и ИИ-подходы.

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

Мне нравится Scaled Agile Framework (SAFe), и я вброшу вам несколько идей по тестированию с точки зрения этого фреймворка.

Часто вижу, что во многих компаниях одной из ключевых метрик является количество найденных тестировщиком дефектов. Хочу донести мысль: от этой метрики можно смело отказаться и жить в прекрасном мире Agile-разработки! 🚀

🤯 Когда вы начинаете считать баги, найденные тестировщиком, происходит вот что:

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

В этой статье мы разберемся:

• чем отличаются методологии «черного», «серого» и «белого ящика»;

• какую из них выбрать под конкретные риски;

• как подготовиться к тестированию, чтобы не тратить деньги впустую;

• и почему даже «зеленый» отчет сам по себе — не повод выдыхать.

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

Это история о попытке создать новую логику.

О попытке, рожденной в эпоху, когда фракталы Мандельброта казались ключом ко всей природе. Я, логик по образованию, увидел аналогию: если математические "монстры" оказались фракталами, то, может быть, логические парадоксы — это тоже фракталы?

Я построил концепцию, где смысл — не точка, а процесс, бесконечный и самоподобный. Но концепция осталась без семантики.

И тогда я решил устроить суд Божий: я дал свою книгу двум арбитрам — искусственным интеллектам. Я ожидал диалога, но получил войну.

Qwen, стремясь к формализации, строил сложные системы. DeepSeek, как строгий судья, разрушал их одну за другой, обвиняя в "иллюзии формальности" и "магии".

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

Это — отчет с поля боя за семантику.

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

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

В этой статье я покажу, как построить гибкий и масштабируемый подход к тестированию фильтрации с помощью Playwright + TypeScript, используя: Page Object Model, Data-driven testing, конфигурацию фильтров и кастомные фикстуры.

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