«Мы хотим помочь разработчикам сделать код неубиваемым». Рассказ тестировщика о карьере в Сбере

Вы не смогли бы пользоваться приложениями и сайтами, если бы не тестировщики. Это мы постоянно пытаемся все сломать и вывести из строя, чтобы найти все возможные баги и убедиться в том, что код работает идеально. Меня зовут Роман Новиков, и два года назад я устроился в Сбербанк «ручником» без опыта работы тестировщиком.

«Мы хотим помочь разработчикам сделать код неубиваемым». Рассказ тестировщика о карьере в Сбере

Теперь я работаю ведущим инженером-разработчиком в команде Сбербанка SmartBio (да, это про биометрию) и сейчас расскажу, почему люблю QA. И дам советы тем, кто хочет попробовать себя в профессии.

Первое собеседование

В 2018 году я решил заняться QA, а до этого был военным (занимался научно-исследовательскими разработками). Я прочел несколько книг, поискал информацию в интернете и записался на собеседования. На всех меня спрашивали примерно одно и то же — например, знаю ли я, что такое тест-дизайн, а я отвечал заученными фразами из книг. На первом собеседовании меня спросили, сколько методик тест-дизайна я знаю, — я сказал, что три, потому что в книгах Савина и Куликова их было именно столько. «Спасибо, мы позвоним» — тут я понял, что что-то не так.

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

С чего начать, если хочешь стать тестировщиком

📚 Что почитать:

Гленфорд Майерс, Том Баджетт, Кори Сандлер — «Искусство тестирования программ»

Тобиас Клейн — «Дневник охотника за ошибками. Путешествие через джунгли проблем безопасности программного обеспечения»

Святослав Куликов — «Тестирование программного обеспечения. Базовый курс»

Ron Patton — «Software Testing»

Mark Fewster, Dorothy Graham — «Software Test Automation»

Роман Савин — «Тестирование dot com, или Пособие по жестокому обращению с багами в интернет-стартапах»

👀 Что посмотреть:

Просто вбить в поисковую строку YouTube «введение в тестирование программного обеспечения» и смотреть самые релевантные ролики — это правда помогает на старте.


В Сбере есть несколько направлений тестирования, и они разделены по трайбам (это такие крупные подразделения внутри банка — например, трайб, в котором работаю я, занимается девайсами, и тестируем мы ПО для этих девайсов). В трайбе, где я работал поначалу, я занимался UI-тестированием — пользовательского интерфейса на андроиде. Джуны обычно начинают с регресса. Это когда ты изучаешь функционал на кейсах, а потом, сталкиваясь со сложными ситуациями, уже просматриваешь документацию, чтобы понимать, как все должно работать.

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

От ручника к тестировщику API

К API ты приходишь поневоле, тебя ведет туда твой же интерес и твои же вопросы, на которые ты не можешь увидеть полного, развернутого, исчерпывающего ответа. Я тестировал приложение, видел, что что-то не так, и мне хотелось понять, что именно сломалось. И я начинал читать логи, смотреть в архитектуру REST-запросов, общаться с аналитиками, с разработчиками. И уже не просто заводил безликие баги в Jira, а лез к парням в их HP ALM, согласовывал себе доступы в их пространства с их доками. Занимаясь всем этим, я понял, что «UI-йка» — это верхушка айсберга, а все основные процессы находятся под капотом, внутри. Тут уже включились азарт и желание узнать побольше, и я начал изучать все это в факультативное время.

Что изучать, когда стало интересно залезать под капот

👀 Что посмотреть:

Видео по запросу «тестирование api для чайников»

💡 Что изучать:

Курсы. Я смотрел разные — в «Виртуальной школе» Сбербанка (это такой онлайн-университет для сотрудников) у меня, оказывается, 436 изученных материалов.

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

Помните, я рассказывал про собеседование и семь методик тест-дизайна. Попав на работу тестировщиком, я узнал на внутренних курсах по продвинутой аналитике, что их на самом деле девять. На следующее утро я собрал коллег из своей команды и задал им вопрос про методики — мы посидели, пока пили кофе, подумали и насчитали 13. Спустя пару месяцев, на корпоративе, я собрал тестировщиков из разных команд и проектов и снова завел об этом разговор. Кто-то из старичков сказал, что знает 20 методик. И тут к нам развернулся один из топ-менеджеров, который сидел за соседним столом, и сказал: «Ребята, вообще их около 90». В общем, мы всем столом развернулись и начали слушать.

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

В SmartBio, команде, которая занимается биометрическими системами, у нас идет бэковая часть, то есть работа с серверными сервисам. Никаких графических интерфейсов нет. То есть мы работаем на уровне REST\SOAP-архитектуры запросов. То есть мы должны копаться в шестеренках. И это дико интересно — понимать процесс по описаниям документации, по объяснениям аналитиков, разработчиков, видеть то, что существует только на уровне кода.

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

Так почему же я люблю тестирование

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

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

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

Еще у меня появилась забавная профдеформация — я во всем вижу внутриуровневые процессы. Моя любимая игра — World of Warcraft, время от времени я туда захожу, и недавно стал обращать внимание — а вот тут идет просадка по фпс и трафику, ага, это какой-то аддон интерфейса, написанный на LUA, шалит, а еще какие-то снифферы из других аддонов пытаются что-то в памяти читать, не связанное с игрой, ну-ка, что это такое. В общем, процесс игры выглядит так: я смотрю на IDE с кодом и скриптами, а на заднем фоне — игра, которая на мешах траекторий движений и ротационных рутинах сама в себя играет и общается с другими игроками.

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

2121
25 комментариев

Каково это: тестировать Сбербанк-онлайн и плакать?

7
Ответить

плакать начинаешь, когда в комьюнити-чатах тестеров читаешь, что кто-то где-то на ноунейм проектах кейсы в экселе держит, и багтрекинг в виде тасок на канбан доске

4
Ответить

Пытливый ум - всему виновник. Молодец! Не засел в зоне комфорта.

4
Ответить

зона комфорта это один из инструментов по настройке самого себя, внести пару изменений в "определение" этой зоны комфорта (разобравшись в себе), и остальные "процессы" подтянутся, повышая планку твоих как желаний так и возможностей =)

Ответить

Если взять во внимание, что для кодера, программиста и уж тем более состоявшего инженера, тестирование полный отстой, то получается, что в сбере от нуля до ИНЖЕНЕРА можно за два года дорасти. В остальном мире для этого в несколько раз больше время нужно, а вот в сбере и пару лет хватает. Чем вас там кормят? После двух с половинрой лет, наверное, вселенского магистра дают и посох впридачу. После трех - вознесение.

3
Ответить

«Трайб» 🤦‍♂️

2
Ответить

Судя по статье, сбер набор джунов разморозил)))) Простите, но Глен Майерс, сомнительный выбор для средне статистического начинающего тестировщика, хотя книга хороша. Думаю, что для джунов стоит добавить - Луиза Тамре введение в тестирование, вполне неплохая литература.

1
Ответить