Что бесит тестировщика: самые раздражающие моменты в QA
2026-02-21 13:43 Diff
https://skillbox.ru/media/code/chto_besit_testirovshchika/

#статьи

  • 24 апр 2020
  • 0

Профессиональная «кухня» — это самое интересное. Как сами тестировщики воспринимают свою работу и работу коллег?

 vlada_maestro / shutterstock

Head of QA компании ITFB. Более 10 лет работаю над качеством процессов и продуктов. Наивно полагаю, что мой вклад меняет цифровой мир к лучшему. Вице-председатель Russian Software Testing Qualifications Board, соорганизатор московского клуба тестировщиков MSTC, редактор журнала "Tester’s Life".

Сейчас в тренде искренность и открытое проявление эмоций профессионалами и экспертами: на YouTube и в соцсетях множится контент из серии «Что бесит бортпроводника» или «10 фраз, которые раздражают дизайнера». У айтишников тоже есть чувства — поэтому команда QA (Quality Assurance) компании ITFB составила свой список раздражающих моментов в работе тестировщика.

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

Бесит, когда разработчик отдаёт на тестирование код, не проверив его хотя бы минимально. Например, кнопка «Закрыть» не закрывает, а выдаёт кучу сообщений об ошибках, которые приводят к зависанию системы. Вроде бы разработчик отчитался, что передал задачу в QA, но основной функционал не работает. А ты тратишь время, чтобы понять, что твои усилия были напрасны.

Бывает, что предыдущие команды не оставляют документации. Приходится иметь дело с неизвестно как работающим функционалом. И непонятно: где баг, а где фича? Да и вообще бесит, когда недостаточно документации и не у кого спросить или сложно найти нужную информацию.

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

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

— Вот тут не работает.

— Это не моё!

— Здесь Dev Result тобой написан!

— А, ну ладно…

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

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

Когда нет сплочённости внутри коллектива: коллега понимает, что есть проблема, но это напрямую его не касается. И он не делает ничего, чтобы как-то помочь.

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

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

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

Заказчик. Всё хорошо, но почему в комбобоксах приведены такие значения: первый, второй, третий?

Команда. Вы сами их согласовали.

Заказчик. Да? Давайте заменим на один, два, три…

А уже на следующий день:

Заказчик. В комбобоксах же были другие значения, разве нет?

Команда. Да, но вы согласовали текущие.

Заказчик. Ах да, точно… Ну ладно, давайте заменим на первый, второй, третий…

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

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

Бесит, что многие, особенно далёкие от IT, не воспринимают работу тестировщика всерьёз. Мол, сидит такой бездельник, кнопочки нажимает целый день — ничего сложного.

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

А если вы тестировщик, как я, то наверняка припомните что-то ещё: зависшие задачи, нарушающие workflow, частые рестарты без предупреждения, написанные на эльфийском диалекте комментарии аналитика «апплоим мапу на тайл, а потом берём квоту и делаем итем», жуткие опечатки в интерфейсе, корявое выравнивание, прыгающие кнопки… Или, может быть, то, что на прошлом проекте было три аналитика, две системы, десять разработчиков, а вы — единственный тестировщик.


Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу