Быть тупым тестировщиком24.07.2023 19:01

У него недостаточно накопленных знаний о проекте

…для работы в текущих процессах. Я искренне убеждена, что при идеально отлаженных процессах свои задачи смогут выполнять даже обезьяны. Но отлаженные до такой степени процессы — утопия, недостижимая мечта. Реальность же оборачивается отсутствием документации, аналитика, у которого можно спросить всё, и нормального описания задач. Спасением здесь может быть хорошая погружённость в предметную область или опыт работы на проекте («мы такое уже делали полгода назад в задаче Х»). Но не всегда они есть.

Он действительно недостаточно/слишком умён

…для работы на текущем проекте/над текущей задачей.

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

Причина проста, как чистый лист: у каждого человека есть свои ограничения при выстраивании логических связей о работе продукта. И для кого-то уложить в голове все зависимости в рамках области функциональности в энтерпрайзе даже за полгода — невыполнимая задача. Зато он с легкостью и задором проверит все UI элементы там, где критически важен UI, ещё и дизайнеру укажет на несоответствие гайдлайнов, а «энтерпрайзер» впадёт в уныние уже на четвёртой кнопке и будет требовать вернуть его в родные SQL' и и консоль. Возможно, начнёт писать скрипт по сверке цветов кнопок и потратит на задачу в три раза больше времени.

Способность удержания фокуса внимания

Фича на 40 часов, а у тестировщика через пять часов работы обнуляется мозг. И всё по новой. Затупы, паника, выгорание и вопросы.

И наоборот — фича на пять часов, а тестировщик полноценно переключится с предыдущей задачи только через три часа курения документации и тыканья кнопок по новой таске. Затупы, паника…

Выученная беспомощность и неумение «гуглить» по документации и задачам.

— Я не вижу кнопку «Редактировать», а фича про изменение цвета кнопки на странице редактирования.
— Она отображается только для «Админа»

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

Разная трактовка задачи

Сколько песен об этом спето, сколько абзацев во всевозможных обучающих трактатах написано! Разработчик понял задачу так. Тестировщик — эдак. И пытается тестировать так, как понял. И всё время всё не складывается.

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

Созвонитесь, поговорите, выясните, кто, что и как понял. По спорным моментам привлеките третье лицо, которое сможет точно сказать, что тут всё-таки нужно.
Время всё равно будет потрачено. Но при разговоре — с двойной продуктивностью: и вопросы будут обозначены, и более-менее контакт налажен. После наладки контакта до 100% читать задачи будете одинаково. Возможно даже, что одинаково неправильно (тогда это беда, а не тестировщик, конечно).

Чтобы минимизировать такие ситуации существует, тестирование требований, которое позволяет избавиться от неоднозначного прочтения. Разумеется, для этого нужно нормальное описание требований. И небольшая магия со временем, чтобы на тестирование документации оно выделялось.

Отсутствие описания реализации функциональности

«Я нажал кнопку и всё сломалось». «Я отправил POST запрос, ответ 200, а сущность на сайте не появилась, не понимаю, что произошло, в логах криминала не вижу».

На самом деле такого зверя — описание реализации — в жизни в глаза не видела (и возможно он как‑то по‑умному называется). Зато неоднократно писала. Данные из поля А передаются в запросе U как значение L, записываются в таблицу S столбец K потом вычитаются, уже обработанные, из другой таблицы.

Это первое, что должен спросить тестировщик после разработки задачи. Что именно было сделано. Какие таблицы и поля затронуты, где что смотреть и как отслеживать. Какие контракты апи изменены/добавлены, и как это всё связано.

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

Почему-то эта тема, в отличие от тестирования требований, поднимается редко. Но переоценить её сложно: это и снижение количества вопросов, и уточнение оценки тестирования, и оптимизация тест-кейсов по факту, и прокачка в технических дебрях. Да, и если у вас есть техподдержка с доступом к БД — они скажут спасибо за такое описание.

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

Неинформативные ошибки в логах

Та же история — «я нажал кнопку и всё сломалось, что‑то не так». Опытный и (как следствие) достаточно наглый тестировщик просто заведёт баг на неадекватные тексты ошибок. И будет прав. Неопытный будет ходить за расшифровкой логов по каждой ошибке к разработчику. Или аналитику. Или другому тестировщику. На что хватит фантазии.

То же будет с ошибками на бою.

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

На самом деле никто не знает, что должно быть реализовано в фиче

Боль маленьких команд, отсутствия аналитика и подхода «быстро‑быстро и в продакшн» (иногда немного виновато легаси).

В качестве примера можно привести мои любимые сортировщики на сайтах с товарами — ну, тех самых, где сортировка по цене идёт с вариантами «А‑я» и «я — А». Вроде всё очевидно — убывание и возрастание, какие тут могут быть вопросы. Но приблизим задачу к более реальной для бэка, а не фронта. Предположим, что у нас в БД три столбца: название товара, цена и валюта. И валюты бывают разные! А сортировка «А‑я». Это сначала по валюте сортируем? Или всегда по значению цены? Или доллары переводим в рубли и сортируем по цене? Или если пользователь из России — исключаем товары с валютой USD и выводим только рублёвые в порядке убывания?

Каждый такой шаг при тестировании оборачивается ответом «сейчас уточню», вопросом к заказчику, в особо тяжёлых случаях ещё и ответом «да всё равно как, главное, чтобы сортировка была». И задача растягивается, растягивается… прокачки по предметной области не происходит, количество «тупых» вопросов только увеличивается («пользователям из Белоруссии доллары показываем? — нет, не очевидно, что не показываем —, а из Казахстана?»). Тестировщик выгорает, разработчик выгорает, менеджер рвёт волосы на головах разработчика и тестировщика и просит как‑то уже эту задачу закончить и выпустить.

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