Что вызывает недовольство у тестировщиков

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

Угадай, что сломалось

О, это классика. Прилетает задача в баг-трекинге с заголовком «Все сломалось, почините!» и пустым описанием. Ни тебе шагов воспроизведения, ни данных, ни окружения, ни ожидаемого результата. Особенно щедры на такие сюрпризы «боевые» тестировщики, которые, видимо, считают, что остальные умеют читать мысли. Про логи, скриншоты и прочие «мелочи» я вообще молчу — видимо, это опция из премиум-пакета.

И так сойдет

Отдельный вид искусства — когда разработчик отдает код, даже не проверив его ни разу. Приносишь ему задачу: кнопка «Закрыть» не закрывает окно, а вываливает кучу ошибок и вешает систему. Вроде и задача формально передана в QA, но по факту ты просто проверяешь, включил ли коллега компьютер сегодня. 

Баг или фича?

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

ЪУЪ

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

Меня тут не было

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

А теперь готово? А сейчас?

Самый любимый вопрос от менеджера: «Ну что там? Когда уже на прод?». А я только-только сборку получил, и она уже с первого экрана посыпалась багами. И откуда мне знать, сколько времени у разработчика уйдет на исправления? Я не экстрасенс, я просто проверяю, работает ли ваше «готово» на самом деле.

Все горит, и ты горишь

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

Кто здесь?

Когда в команде нет единства, а есть просто набор людей, которые делают вид, что работают вместе. Коллега видит проблему, но молчит, потому что «это не моя зона ответственности». И никто не подскажет, не подстрахует, не поможет. А потом все удивляются, почему релиз провалился. Потому что команда — это не просто список ников в чатике.

Понятно, что ничего не понятно

Любите головоломки? Добро пожаловать в проект без версионности. Ты тестируешь сборку и даже не знаешь, какую именно. В баг-репорте пишешь просто «билд от 12:00», но на самом деле это все равно что гадать на кофейной гуще. А потом выясняется, что баг уже давно пофиксили, просто ты тестировал старую версию. И время ушло, и нервы, и кофе остыл.

Шпионский шифр

О, это мое любимое. Разработчик с гордостью приносит логи, которые выглядят как послание инопланетян: ERR_TCP_CONN_REFUSED:0x7F3A2B и еще 50 строк машиноподобного бреда. И попробуй разберись, что там случилось на самом деле. А если сроки горят, то это превращается в настоящий детектив с элементами триллера. Спасибо, конечно, за информацию, но я по-русски тоже немного понимаю, можно было и попроще.

Противоречивый заказчик

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

Нет времени допиливать

Знаете такое: сроки горят, релиз нужно выкатывать вчера, и команда решает: «Давайте быстро запилим, а потом допилим». Спойлер: «потом» не наступает никогда. Тестирование сокращают до минимума, баги закрывают как «не критичные», а пользователи потом удивляются, почему приложение падает на ровном месте. Но главное — сроки соблюдены, галочка стоит.

Быть всегда крайним

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

На завод!

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

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

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