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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы дружить с тестировщиками, делайте сразу хорошо

А мы научим — приходите в HTML Academy на курс по вёрстке.

Хочу!