Алена QA-Pop

Когда ты слишком хороший QA - это не всегда плюс

Если ты тот самый QA, который «тащит всё на себе» - этот текст для тебя.

Долгое время я была уверена, что хороший QA - это тот, кто проверяет всё. Дважды. Трижды. Лезет туда, куда не просили.
И на всякий случай - «эх, раз… ещё раз… и ещё много-много раз!».
И я не умела не проверять!
Не умела сказать: «это не моя зона ответственности» - даже когда это было очевидно.

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

Со стороны это выглядит как ответственность и профессионализм. Про меня говорили: «на неё можно положиться».
И я поначалу этим гордилась.

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

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

Проблема в том, что это «потом отдохну» всё время откладывается. Релизы. Дедлайны. Ещё одна срочная задача - и ты снова откладываешь себя.

Самый тревожный момент наступает не сразу. Со временем ты перестаёшь радоваться найденным багам. Сложный баг перестаёт быть маленькой победой и превращается в «ещё одну задачу».
Ты больше не испытываешь интерес - просто закрываешь дыры и работаешь на автомате.

Как сейчас помню январь 2024 года: после очередного созвона мои ладони резко стали влажными, поднялась температура, всё тело сжалось - и я упала в обморок.
Тогда я поняла: мне нужно учиться не брать на себя всю ответственность этого мира.
Мне нужно учиться останавливаться и давать проекту и команде право на ошибки.
Отдавать задачи, даже если кажется, что могла бы сделать качественнее, но дольше.
Позволять другим ошибаться - и не воспринимать это как личный провал.

Самым сложным оказалось разрешить себе быть не «спасателем проекта», а просто человеком, который делает свою работу.

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

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

Если ты дочитываешь до этого момента и узнаёшь себя в этом тексте - это уже первый шаг.
Тебе не нужно тащить всё в одиночку💓#qa

TCP против UDP: что выбрать?

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

TCP (Transmission Control Protocol) - обеспечивает надежность: перед отправкой устанавливается соединение (через handshake), каждому фрагменту данных (сегменту) присваивается порядковый номер (SEQ), его получение подтверждается получателем (ACK), и если сегмент потерян, его отправляют заново. Благодаря этому TCP гарантирует, что файл дойдёт полностью и в правильном порядке. Однако такая надёжность замедляет процесс - из-за проверки, подтверждений и повторных отправок скорость ниже.

Представьте себе такую ситуацию:
Заказное письмо с уведомлением о вручении, но перед отправкой письма отправитель звонит и спрашивает, готов ли получатель принять его (handshake).
Получатель подтверждает получение письма (ACK) - не пришло подтверждение, письмо отправляется заново.
В результате все письма доходят до адресата в нужном порядке и без потерь.

Подойдет для: Веб-страницы (HTTP/S), электронной почты (SMTP), передачи файлов (FTP). Там, где важна каждая буква и каждый бит.

UDP (User Datagram Protocol) - работает без установления соединения и не ждёт подтверждений. Пакеты просто отправляются один за другим. Такой подход делает передачу быстрой и с минимальной задержкой, но не гарантирует, что все данные целиком дойдут до получателя. Некоторая потеря возможна, а порядок пакетов может нарушиться. UDP подходит для ситуаций, где важна скорость и небольшая потеря данных не страшна.

Подойдет для: Онлайн-игр, видеостриминга (Zoom, Twitch), VoIP-телефонии. Там, где скорость важнее, чем потеря одного-двух кадров.

Нет лучшего протокола - есть более подходящий для задачи. Нужна надежность - ваш выбор TCP. Цените каждую миллисекунду - ваш выбор UDP. #qa

Коллеги, по состоянию здоровья я приостановила записи на консультации/созвоны/помощь в личке минимум до февраля!
Посты в канал планирую выкладывать, но с задержкой.
Не забивайте о закрепе - тут все посты в одном месте 💓

Что такое первичный ключ и внешний ключ в базе данных. Зачем они нужны?
Первичный ключ (Primary Key) и внешний ключ (Foreign Key) - это два фундаментальных элемента реляционной базы данных, обеспечивающих целостность данных и связь между таблицами.

Что такое Primary Key (PK)?
Назначение: уникальная идентификация записи в таблице.
Главные свойства:
Значение обязательно уникальное и не может быть NULL.
В таблице может быть только один PK.
Может состоять из одного или нескольких атрибутов (составной ключ).

Пример:
В таблице "Пользователи" поле user_id - это PK, и оно уникально для каждого пользователя.

CREATE TABLE users (
user_id INT PRIMARY KEY,
username VARCHAR(50),
email VARCHAR(100)
);

Что такое Foreign Key (FK)?
Назначение: устанавливает связь между таблицами, ссылаясь на первичный ключ другой таблицы.
Главные свойства:
Может содержать повторяющиеся значения, но все они должны ссылаться на существующие записи в другой таблице.
Значения NULL могут быть разрешены для этого поля.
Обеспечивает целостность данных и предотвращает "браки" (ссылки на несуществующие данные).

Пример:
В таблице "Заказы" поле user_id - это FK, ссылается на user_id из таблицы "Пользователи".

CREATE TABLE orders (
order_id INT PRIMARY KEY,
order_date DATE,
user_id INT,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Зачем нужны эти ключи?
- Обеспечивают уникальность данных(PK).
- Позволяют связывать таблицы, создавая реляционную базу данных (PK + FK).
- Гарантируют целостность: нельзя добавить заказ для несуществующего пользователя или удалить пользователя, если у него есть заказы.
- Упрощают работу с большими объемами данных: связи позволяют быстро получать связанные данные через JOIN.

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

📱 Вопросы с собесов + ответы читайте на бусти

📱 СОБЕСЕДОВАНИЕ QA: Основные виды SQL-команд: DML, DDL, DCL и DQL?

SQL (Structured Query Language) - универсальный язык работы с базами данных. Все SQL-команды делятся на группы в зависимости от того, какую задачу они решают:

DML (Data Manipulation Language) = манипуляция данными
Позволяет работать с содержимым таблиц: добавлять, изменять, удалять и извлекать содержимое таблиц, напрямую воздействуя на данные.

INSERT INTO - добавляет новые записи

INSERT INTO users (id, username) VALUES (1, 'Ivan');

UPDATE - обновляет существующие данные

UPDATE users SET username = 'IvanPetrov' WHERE id = 1;

DELETE - удаляет записи

DELETE FROM users WHERE id = 1;

DDL (Data Definition Language) = определение структуры данных
Отвечает за создание и изменение структуры базы данных: таблиц, индексов или схем.

CREATE TABLE - создание таблицы

CREATE TABLE users (id INT, username VARCHAR(100));

ALTER TABLE - изменение структуры (например, добавление столбца)

ALTER TABLE users ADD email VARCHAR(255);

DROP TABLE - удаление таблицы

DROP TABLE users;

TRUNCATE TABLE - очистка всех данных в таблице

TRUNCATE TABLE users;

DCL (Data Control Language) = управление доступом
Позволяет управлять правами пользователей и доступом к данным.

GRANT - предоставление прав

GRANT SELECT ON users TO 'readonly_user';

REVOKE - отзыв прав

REVOKE SELECT ON users FROM 'readonly_user';

DQL (Data Query Language) = язык запросов
Основная команда - SELECT, которая позволяет запрашивать и извлекать данные из базы, без изменения содержимого таблиц.
Позволяет читать данные, фильтровать, группировать, сортировать, агрегировать информацию.

SELECT * FROM users WHERE age > 18;

DQL включает:
- фильтрацию (WHERE)
- сортировку (ORDER BY)
- группировку (GROUP BY)
- агрегирование (COUNT, SUM, AVG, MIN, MAX)
- соединения таблиц (JOIN)

Понимание классификации SQL-команд поможет тестировщику осознанно строить запросы к БД, эффективно работать с данными, тем самым проактивно отслеживая проблемы и обеспечивая более полное тестирование.

📱 Реальные примеры, когда QA использует SQL-запросы на бусти

Что выбрать для API-тестирования: Postman или полноценный фреймворк

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

Когда стоит выбирать Postman

Преимущества:
Быстрый старт. Даже без навыков программирования можно делать запросы, проверять ответы, работать с коллекциями.
Наглядная визуальная среда: UI позволяет сразу видеть запрос/ответ, легко настраивать переменные/среды.
Подходит для мануального тестирования, exploratory-тестов и тех случаев, когда нужно быстро “пощупать” API и прояснить, как он работает.
Легко делиться коллекциями с командой.

Ограничения:
Масштабируемость: при большом числе сценариев и данных наглядный UI из преимущества превращается в помеху, и Postman может “сдать позиции”: сложно эффективно поддерживать десятки/сотни коллекций.
Сложные проверки и взаимодействие с другими слоями (например, база данных, брокер, внешние интеграции) уже требуют автоматизации скриптами, порог вхождения в которую уже чуть выше, чем использование UI.
Ограниченная гибкость по сравнению с кодовым решением: модульность, поддержка сложных сценариев, параллельные выполнения.

Когда стоит использовать полноценный фреймворк

Под “фреймворком” я имею в виду такие решения как RestAssured (Java), Cypress, Playwright и др.

Преимущества:
Полный контроль и гибкость: писать сложную логику, интеграцию с внешними системами, работу с базами, etc. aka "test as code"
Высокая масштабируемость и удобство поддержки больших тестовых наборов и проектов.
Хорошая интеграция с CI/CD пайплайнами, что обеспечивает непрерывное тестирование и автоматический запуск при изменениях кода.
Возможность кастомизации отчётов, логирования, параллельных запусков, моков, заглушек и др.
Позволяет покрывать не только функциональные, но и нагрузочные, безопасность и контрактные тесты, что делает тестирование API комплексным и глубоким.

Ограничения:
Порог вхождения выше: нужны навыки программирования, знание инструментов и фреймворков.
Настройка и поддержка могут отнимать время: окружения, зависимости, инфраструктура.
Может быть “перегибом” для маленьких проектов или когда API несложный - усилия по написанию и поддержке могут не окупаться!

Выводы
Если вам нужно быстро начать и эффективно проводить ручные проверки, Postman - идеально подходящий для старта, но со своими ограничениями по масштабируемости и сложности сценариев.
Если задача - масштабируемые автотесты, регрессия, сложная логика, интеграция с CI/CD - лучше фреймворк.

Обычно используют оба: Postman для исследований и быстрых проверок; фреймворк - для стабильной автоматизации и прогона регресса. #qa

📱 СОБЕСЕДОВАНИЕ QA: Внезапный ночной баг после релиза. Что делать?

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

Что делать? Звонить? Писать в чат? Ждать понедельника?

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

Если процесс прописан - следуем ему.
Но допустим, что таких договоренностей не было…

Алена QA-Pop pinned «🅰️🅰️ 🅰️🅰️🅰️🅰️🅰️🅰️🅰️ 🐸 🅰️🅰️ ➖🅰️🅰️🅰️ QA-БАЗА ❤️ Цикл тестирования ПО: зачем он нужен и как работает Как писать тест-кейсы для любой фичи Когда писать чек-листы, а когда тест-кейсы Как smoke-тесты спасают проекты Как писать баг-репорты Баг-менеджмент (статусы…»

🅰️🅰️ 🅰️🅰️🅰️🅰️🅰️🅰️🅰️ 🐸 🅰️🅰️ ➖🅰️🅰️🅰️

QA-БАЗА ❤️
Цикл тестирования ПО: зачем он нужен и как работает
Как писать тест-кейсы для любой фичи
Когда писать чек-листы, а когда тест-кейсы
Как smoke-тесты спасают проекты
Как писать баг-репорты
Баг-менеджмент (статусы бага)
Серьезность и Приоритет багов
Когда завершать тестирование
Нефункциональное тестирование

API & TECH 🤔
Гайд по API
Что такое API-тестирование
Типы тестирования API
Идемпотентность в RESTful API
Что такое JSON
Разница между реляционной базой данных и нереляционной
Основные виды SQL-команд: DML, DDL, DCL и DQL?
Что такое первичный ключ и внешний ключ в базе данных. Зачем они нужны?
TCP vs UDP
Лучшие ресурсы по изучению JS/TS, ООП и Playwright
Изучаем SQL, Postman, JavaScript
Что выбрать для API-тестирования: Postman или полноценный фреймворк

СОБЕСЫ & КАРЬЕРА 😭✨
Что спросить у компании на собеседовании?
Расскажите о своих слабых сторонаx?
В резюме написано увеличил покрытие тестами до 92% - а как вы это сделали?
Расскажите про самый большой вызов/челлендж в вашей QA-практике?
Что делать, если перед релизом найден блокер?
Что будете делать, если на проекте нет требований?
Серьезность vs. Приоритет: каверзные вопросы о багах на собеседованиях
Внезапный ночной баг после релиза. Что делать?
Как не завалить испыталку: софт-скиллы, которые решают
Зачем нам тестировщики, если есть разработчики?
ОНБОРДИНГ НА ПРОЕКТЕ: как пройти и как организовать
Начни спасать свою карьеру, пока не поздно!

GROW & IMPACT 🤗
Я ЗАВЕЛА 1000 БАГОВ: веха профессионального роста
Вредные советы для тестировщика
История багов в моем блокноте
Учимся тестированию на карандашах: база или кринж?
Гайд: как правильно акуевать от происходящего
2500 нейросетей в одном месте

📱 По вопросам QA консультации
📱 Больше контента на бусти
💅 Мой ляйф канал

У меня день рождения и все о чем прошу… 🥳

Обзор шапки от бренда авось не порвется - с драмой, сумеречной эстетикой и честным тестом на прочность!

📱 СОБЕСЕДОВАНИЕ QA: Что делать, если перед релизом найден блокер, а командa всё равно идёт в прод?

Перед самым релизом нашли блокер, а команда всё равно идёт в прод? Классика жанра))
В посте на бусти - как действовать системно, не сгореть и не стать крайним.

In a nutshell: оценить риски, донести последствия, зафиксировать решение, минимизировать ущерб и извлечь урок.

Стрем или норм: «Техсобес? А где тех?»
Рубрика #собесы - делюсь своей историей! 💅

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

"Ну давай, расскажи нам эту «интересную» историю, как ты перешла в тестирование?"

Ну, рассказываю: работала инженером на заводе, писала научные статьи…затем кратко рассказали про свой продукт, на который ищут тестировщика.
Но потом начались 40 минут допроса с пристрастием:
"А как так получилось-то, и наукой занималась, и на заводе работала - а зачем в айти-то приперлась пришла?"

Но "зачем" дело не кончилось. Эти ребята меня “приятно” удивили количеством любопытных вопросов про что угодно, кроме тестирования! Тех вопросов не было. Про мой текущий опыт работы - тоже ни слова.

А знаете, какой был итог? Через два дня прислали отказ. Причина: "не хватает технических знаний"!(💔 Тех самых, про которые даже не спросили…)

Вопрос к вам: Было ли у вас такое, что вместо диалога о компетенциях/опыте работы - устраивают психологическую пробежку по прошлой жизни, а потом в отказе стандартное "вы не подходите из-за недостатка техзнаний"?

P.S. Я думаю, такие истории - не редкость. Но каждая из них учит: не все «нет» - про вашу компетентность как специалиста. Иногда - просто про чужой хаос в процессаx. #qa

Хотите историю другого техсобеса, где я спросила тим лида как сейчас выглядит пирамида тестирования на проекте? А в ответ получила: А что это? Погоди, ща погуглю" 😎

📱 Разница между реляционной базой данных и нереляционной на примере PostgreSQL vs MongoDB?

Реляционные базы данных (например, PostgreSQL) и нереляционные базы данных (например, MongoDB) различаются структурой, целостностью, масштабированием и областями применения. Ниже рассмотрим их отличия на примере интернет-магазина - одной из типичных сфер, где применяются обе СУБД.

Реляционные БД (PostgreSQL):
Хранит данные в таблицах со строками и столбцами.
Имеет жёсткую схему - структура таблиц задаётся заранее.
Между таблицами строятся связи с использованием foreign keys (JOIN).
Обеспечивает строгую целостность данных (ACID).
📱 Про целостность данных (ACID) в контексте тестирования читай на бусти!
Использует язык SQL для запросов и анализа.

Пример запроса:

SELECT * FROM users WHERE age > 25;

SQL описывает, что нужно выбрать из таблицы users, где age > 25.

Нереляционные БД (MongoDB):
Хранит данные в JSON-подобных документах вместо таблиц.
Нет фиксированной схемы - структура записей может меняться на ходу.
Заточена под скорость, масштабирование и гибкость.
Использует набор функций (методов) для взаимодействия с данными.

Пример запроса:

db.users.find({ age: { $gt: 25 } });

где: db.users - коллекция пользователей
.find() - функция, которую предоставляет MongoDB
{ age: { $gt: 25 } } - фильтр в формате JSON, где $gt - оператор “больше чем” (greater than).

Когда используют PostgreSQL
PostgreSQL оптимален для системы, где критична согласованность и строгость структуры данных:
- Заказы, платежи и корзины покупателя. Эти данные требуют транзакций, строгих связей и соблюдения целостности ACID*.
- Ценообразование и скидки. Сложные связи между товарами, категориями и складскими остатками обрабатываются быстрее с помощью SQL и индексов.
- Отчеты, аналитика и фильтры. PostgreSQL поддерживает сложные запросы и аналитические функции, что упрощает работу с данными.
- Применение внешних ключей, триггеров и ограничений позволяет предотвратить логические ошибки (например, двойное списание товара).

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

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

Почему я выбрала эти примеры?#qa

Потому что я работала и с MongoDB и с PostgreSQL! Больше всего мне понравилось работать с реляционной БД. Для меня PostgreSQL ближе по духу: структура, контроль, валидация, ACID - всё как в хорошем тестировании!))

Друзья! Я создала канал алё, налим? 💅, в котором буду делиться всем, что мне близко и интересно:

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

Никакого тестирования и прочей технички! 💘💅💞

Ну а тут завтра пост на тему базы данных! 🐶

📱 СОБЕСЕДОВАНИЕ QA: «Расскажите про самый большой вызов/челлендж в вашей QA-практике?»

Когда на собеседовании задают такой вопрос, важно:
Не просто описать проблему, а показать системное мышление, умение находить решения и доказывать ценность QA для бизнеса.
* Лучше всего заготовить несколько историй из разных проектов и ситуаций: срочные релизы, отсутствие документации или процессов, нестабильные сервисы, слабая автоматизация и тд.

Несколько примеров из реальных проектов, которые вы можете подстроить под себя и подобрать под контекст интервью:

💯 На проекте нет требований
Ситуация: На проекте требования задавались устно и постоянно менялись, часть фич приходила в разработку без документации.
Челлендж: Тестирование без чётких acceptance criteria / definition of done.
Решение: Зафиксировала бизнес-логику после общения с БА и разработчиками и сформировала спеку с юзер-сторями в Confluence.
Результат: Практически исчезли баги, к которым приводило непонимание требований, процесс стал прозрачным для всей команды!

🎶Ограниченные ресурсы и жёсткий дедлайн
Ситуация: Срочный релиз продукта, на тестирование оставалось всего 48 часов.
Челлендж: Протестировать критичные фичи без потери качества в очень сжатые сроки!
Решение: Ввела risk-based testing, разделила команду на зоны ответственности, ручное тестирование шло по чек-листам, а автоматизация выполнялась параллельно.
Результат: Релиз вышел вовремя и без критичных дефектов!

📱 Полный текст с решениями для других ситуаций читайте на бусти! (например, "QA-специалистам было сложно понять, что именно нужно тестировать" или "нестабильные автотесты").

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

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

А какие челленджи были у вас? Делитесь в комментариях! #qa

ну наконец-то - прекрасное будущее

Нефункциональное тестирование - герой, которого недооценивают

Нефункциональное тестирование (НФТ) - это проверки не «что делает система», а как она это делает: быстро ли отвечает, выдерживает ли нагрузку, безопасна ли, удобна ли, как восстанавливается после сбоев и насколько её легко поддерживать. Например, оформление заказа остаётся быстрым, стабильным и безопасным при реальной нагрузке.

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

Несколько видов НФТ:
1. Производительность - измеряет скорость отклика системы.
2. Нагрузочное тестирование - проверяет стабильность работы под ожидаемой «боевой» нагрузкой.
3. Безопасность - защита от уязвимостей, атак и утечек данных.
4. Обслуживаемость (maintainability) - насколько легко поддерживать, модифицировать, обновлять и исправлять систему в процессе ее жизненного цикла.
5. Масштабируемость - готовность системы к росту нагрузки без ухудшения параметров.
6. UI, UX - обеспечивает понятный и удобный пользовательский опыт.
7. Совместимость - корректная работа на разных ОС, устройствах и браузерах.
8. Стресс-тестирование - поведение системы при экстремальной нагрузке.
9. Объёмное тестирование - работа системы с большими объёмами данных.

Примеры НФТ, которые чаще всего выпадают из практики:
Стресс-тестирование
Почему: часто не хватает времени или инфраструктуры, и команда обычно ориентируется на «базовую» нагрузку и не моделирует крайности.
Совместимость / конфигурационные сценарии
Почему: на расширенном покрытии экономят бюджет, из-за чего в команде не хватает разных сред (устройств, браузеров).
Объёмное тестирование
Почему: на этапе разработки и тестов используют упрощённые выборки, не моделируя реальные объёмы данных.
Безопасность
Почему: функциональные тесты кажутся важнее. Часто считают, что этим займутся DevOps или security-аудиторы. В итоге QA либо совсем не смотрит в эту сторону, либо проверяет только happy-path, принимая условности окружения.

📱 Реальные примеры из практики можно почитать на бусти

Корневая причина игнорирования нефункциональных тестов - фокус на фичи и сроки.
Команды и бизнес чаще всего мыслят так:

«Время - деньги. Нужно успеть к релизу/демо/ивенту, остальное потом».
«Фича приносит прибыль прямо сейчас, а перфоманс/безопасность/масштабируемость - это когда-нибудь доведем до ума».

В итоге ценность НФТ часто не очевидна: если его провести - никто не заметит, если не провести - «может повезёт».
Но когда случается сбой или утечка - ущерб кратно выше, чем выигрыш от «ускоренного релиза».

А какой вид нефункционального тестирования у вас чаще всего «выпадает», а потом больно аукается в проде? #qa

Я ЗАВЕЛА 1000 БАГОВ: веха профессионального роста

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

- накопленные данные показывают закономерности и дают рычаги для улучшения процессов;

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

Мне кажется, шаблон баг-репорта теперь у меня в мышечной памяти 😪

Стоит отметить, что фокус не на самом количестве (хоть это и звучит громко), а на способности видеть истинные риски и приоритизировать задачи.

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

Пост про истории багов в моем блокноте

А какие вы ведете личные метрики? #qa

Баг-менеджмент: что происходит после нахождения бага

Найденный баг - это только начало истории. Каждый баг проходит целый жизненный цикл, прежде чем его окончательно закроют.

Разберем типовые этапы жизненного цикла бага из моей практики:

Тестируемый функционал: пользователь может генерировать и скачать отчет о продажах за выбранный период в формате PDF.

Обнаружение (New)
Тестировщик находит проблему и создает баг-репорт:
«При попытке экспорта отчета за последний квартал (1 апреля - 30 июня) система выдает ошибку "Internal Server Error 500". Отчет за более короткие периоды (например, за один день) генерируется нормально. Шаги воспроизведения: ...»

Назначение (Assigned)
Багу назначают исполнителя - конкретного разработчика, который становится ответственным за его исправление.
Проблема явно связана с обработкой больших объемов данных или работой сервиса генерации PDF. Баг назначается backend-разработчику, ответственному за модуль отчетов: «Саша, разберись с экспортом PDF для длительных периодов».

В работе (In Progress)
Разработчик исследует логи и код:
«Вижу проблему. Сервис генерации PDF (сторонняя библиотека) имеет лимит на размер входных данных. Когда мы передаем данные, мы этот лимит превышаем, и библиотека вызывает необработанное исключение, которое приводит к 500-й ошибке. Нужно или разбивать данные на части, или менять подход к формированию PDF».

Исправлено (Fixed)
Разработчик принимает решение реализовать пагинацию данных внутри PDF-документа. Он вносит изменения, чтобы отчет для больших периодов разбивался на страницы и данные в библиотеку передавались порциями.
«Готово. Реализовал потоковую передачу данных в PDF-генератор. Лимит больше не превышается. Код отправлен на тестовый сервер».

Повторная проверка (Retest)
Тестировщик проверяет исправление:
Основной сценарий: Пробует экспортировать отчет за квартал. Ошибка 500 больше не возникает, файл скачивается.
Проверка содержимого: Открывает PDF и обнаруживает новую проблему. «Отчет создался, но данные в нем неполные. На второй странице обрываются строки таблицы, а итоговая сумма не совпадает с данными в интерфейсе. Похоже, алгоритм разбивки на страницы работает некорректно».

Переоткрытие (Reopened)
Тестировщик возвращает баг разработчику: «Основная ошибка исправлена (500-я пропала), но фикс привел к дефекту контента. Отчет содержит не все данные и итоги подсчитаны неверно. Требуется доработка логики пагинации».
Статус меняется на Reopened.

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

Цикл повторяется:
In Progress (снова): Разработчик исправляет алгоритм пагинации, чтобы он корректно переносил строки и пересчитывал итоги для каждой страницы и общего отчета.
Fixed (снова): Правки отправлены.
Retest (снова): Тестировщик проверяет экспорт за квартал, а также за другие периоды (неделя, месяц, год), чтобы убедиться, что фикс не затронул другие сценарии. Теперь все данные отображаются верно, итоги сходятся.

Закрыт (Closed)
После полной и успешной проверки баг торжественно закрывают. На ретро можно снова вернуться к этой проблеме для разбора полётов.

📱Разбор полётов по шагам на бусти

Этот пример довольно простой, он пропускает шаг ревью (In Review), но он уже наглядно показывает, что самый проблемный этап - часто не само исправление, а исчерпывающая проверка этого исправления (Retest), которая должна покрывать не только шаги из баг-репорта, но и смежные сценарии и, что особенно важно, проверку на целостность данных.

А какой этап жизненного цикла бага чаще всего становится самым проблемным в ваших проектах? И почему? #qa

📱 СОБЕСЕДОВАНИЕ QA: «В резюме написано увеличил покрытие тестами до 92% - а как вы это сделали?»

В резюме часто встречаются громкие достижения:
- «Сократил время регресса в 2 раза»
- «Внедрил чеклист онбординга для QA»
- «Увеличил покрытие тестами с 40% до 92%»

И вот на собеседовании звучит интересный вопрос:

Как именно ты это сделал и как посчитал?

На бусти я собрала готовые примеры вклада QA с метриками!
Чтобы ты мог(ла) уверенно пояснять за цифры в своём резюме:
- не просто «92% покрытия», а как это было сделано и посчитано;
- не просто «внедрил чеклисты», а за счёт каких шагов;
- не просто «снизил количество багов от клиентов», а какие процессы ты изменил. #qa