«Вы просто нажимаете на кнопки, любой так может». 18 глупых вопросов тестировщику

Мы задаём глупые вопросы профессионалам, с которыми верстальщики часто сталкиваются в работе.

Наш первый гость — Михаил, специалист по тестированию из Яндекс.Денег. Мы расспросили его о работе тестировщика и о том, что тестировщиков бесит в программистах.

— Давно ли ты в отрасли, и чем занимаешься сейчас?

В IT чуть больше 6 лет, из них 4.5 года — тестировщиком. Сейчас работаю в Яндекс.Деньгах, а до этого почти 4 года работал в 2ГИСе. В Яндекс.Деньгах работаю в одной из команд Яндекс.Кассы, команда занимается преимущественно бэкендом.

— Кто такой тестировщик в семи словах?

Человек, который тестирует, пишет автотесты, отвечает за качество.

— Зачем сайтам тестирование?

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

— Почему всё это не должны делать сами разработчики?

В книге «Как тестируют в Google» описано, что что «в Google вся ответственность за качество лежит на плечах тех, кто пишет код». Никто не проверит код лучше, чем разработчик, который его написал. В других компаниях роль ручного тестировщика выделяется по двум причинам:

1. Экономия времени разработки.
2. Для контроля — разработчик может полениться и не проверить все кейсы досконально.

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

— Что тестировщиков бесит в верстальщиках?

Я никогда не работал с верстальщиками в чистом виде. Когда пришел работать в 2ГИС, тестировать онлайн-версию, в команде были разработчики и фронтендеры. Фронтендеры тоже писали код, отвечающий за логику отображения всего в приложении, а не только делали вёрстку. Разработчики делали бизнес-логику.

Через какое-то время это разделение вообще пропало — все стали делать всё.

— А в программистах?

Когда на очевидные косяки начинают отмазываться, что это не баг, и вообще, так и должно быть.

— Какой самый главный миф о работе тестировщика? Развеешь его?

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

— Самая частая ошибка, которую ты находишь на страницах?

Самая частая — 500 (Internal Server Error).

— Где грань, после которой говоришь верстальщику или программисту «Тут надо переделать всё»? Было ли у тебя такое?

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

— Самое долгое исправление бага в твоей жизни?

Бесконечность. Найденные баги приоритизируются, и большинство из багов, которые незначительно влияют на пользователей, откладывается в бэклог с тем, чтобы никогда оттуда не выбраться.

— Что ты больше всего не любишь в своей работе?

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

— А что больше всего любишь?

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

— Есть миф, что после тестирования не становятся программистами.

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

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

— Программист — друг или враг тестировщика?

Друг, конечно. Цели — общие, задачи тоже общие. С программистами вообще нужно общаться как можно больше по работе, потому что зачастую они могут знать, что могло сломаться в коде, но умолчать эту информацию.

— Совет верстальщикам, которые хотят никогда не получать макет на переделку обратно?

О, у меня есть много советов:

• Уточните список браузеров, в которых страница должна работать, и проверьте, будут ли во всех из них работать то, что вы используете, например на caniuse. Чаще всего проблемы бывают с Internet Explorer.
  
• Если нет макетов каких-то сценариев, не стесняйтесь попросить об этом дизайнера. Сделаете самостоятельно — придёт продакт и скажет, что надо переделывать.
  
• Не поленитесь проверить то, что сделали, самостоятельно. Желательно не в одном браузере.
  

— Бывает ли такое, что на сайт вообще никто из людей во время тестирования не смотрит, и почему?

Такое может быть, если не добавляется новой вёрстки. Тогда можно проверить правки на бэкенде, а то, что ничего не сломалось, проверят автотесты.

— Худшие последствия, к которым в твоей практике приводило некачественное тестирование?

Часовой простой сервиса с аудиторией в 20 миллионов человек в месяц. К счастью, тестировал задачу не я.

— Как измерить успех тестировщика?

Например, по соотношению скорость тестирования / количество инцидентов на проде. Совсем без багов не получится, но чем реже они будут, тем лучше. Ну и чем быстрее ты будешь тестировать, тем быстрее новую функциональность увидят пользователи.