Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>24 апр 2020</li>

3 <li>0</li>

4 </ul>Профессиональная "кухня" - это самое интересное. Как сами тестировщики воспринимают свою работу и работу коллег?

5 vlada_maestro / shutterstock

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

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

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

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

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

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

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

13 - Вот тут не работает.

14 - Это не моё!

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

16 - А, ну ладно…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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