Тестирование. Зачем тыкать на 1 000 кнопок в секунду и скармливать код мутантам

Всем привет, меня зовут Самат Галимов и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которым можно поговорить простым человеческим языком. Сегодня я хочу поговорить о тестировании. Все знают, что для того, чтобы появилась программа, нужны программисты, они её напишут. Но мало кто подозревает, что для того, чтобы появилась большая сложная программа, которую делают десятки программистов, и которую пользуют тысячи людей, которая развивается, меняется, в ней что-то удаляют, вот чтобы написать такую программу, чтобы она хорошо работала, нужно тестирование. На тестирование при этом в IT-тусовке взгляд такой немножечко свысока пренебрежительный от отношения к тестировщикам, потому что люди думают, что тестированием можно заниматься, если ты не умеешь заниматься программированием. Вообще многие начинают свою работу в IT именно с того, что становятся тестировщиками. Наш сегодняшний гость опровергнет многие стереотипы. Максим Садым сначала в Амазоне, а теперь работает над этим в Гугле. Вместе с ним мы разберемся, что такое тестирование, какие виды тестирования бывают, зачем оно нужно и как можно очень сильно зафакапиться, если не делать хорошего тестирования. Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. У Практикума есть курсы по разработке, по анализу данных и по английскому языку. Если вы хотите освоить цифровую профессию, переходите на сайт Яндекс Практикум и учитесь.

Этот список курсов вы наверняка слышали уже

тысячу раз. На самом деле у Яндекса курсов гораздо больше, и они постоянно запускают новые. Вот, например, 4 новых курса, которые они запустили недавно. UX-исследования, UX-копирайтинг, таргетированная реклама и контекстная реклама. Если вы хотите разобраться в этих цифровых профессиях, переходите на сайт Яндекс.Практикум и учитесь.

Меня зовут Максим Садым, я работаю в компании Google. До этого я работал в Амазоне, а еще до этого я работал в СКБ Контур.

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

там все, короче, вставлено в эту статью.

И вот я смотрю на разных телефонах, как оно выглядит, все ли нормально отображается. Это называется UI-тестирование. Тестирование интерфейсов пользовательских, то есть то, что видит обычный человек, когда открывает сайт или мобильное приложение. То, что я описал— это стандартное UI-тестирование или обычно в компаниях делают по-другому?

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

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

Должна открыться быстро.

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

Абсолютно, да. По сути, один сценарий описывает один workflow, одну последовательность действий какого-то пользователя.

Как часто это проверяется? Каждый раз, когда в программу вносятся изменения или каждый раз, когда выходят новые версии программы, как часто прогоняются тесты?

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

Так, тест упал, упал значит не прошел, значит нашлась ошибка.

Да.

А сколько таких тестов обычно бывает, UI-тестов? Можно быть как раз на примере своей работы в Амазоне?

Ну вот смотри, в Амазоне я работал над проектом Gift Receiver. Это достаточно небольшой проект, то есть там, по-моему, около 8 страниц было. За этим еще некоторые workflow, некоторые процессы стояли, тем не менее.

Gift Receiver. Что он делал?

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

Ну, чтоб тебе мусора было меньше, да? Чтоб люди не выкидывали вещи, которые мне нужны.

Да, абсолютно. При этом, чтобы люди не боялись дарить подарки и чтобы было меньше мусора.

Вау, прикольно. Ты сказал 8 страниц, это 8 веб-страниц, то есть 8 страничек на сайте или это 8 страничек кода?

А, нет, это 8 страничек на сайте. Кода там было, ой, я сейчас тебе не скажу по срочкам, но там хорошая лыжка была, достаточно большая. А UI-тестов у нас там было примерно около 200.

Нифига себе, то есть 8 страниц на

сайте и 200 UI-тестов Примерно так, может

быть я наврал, но по-моему там было порядка 200 тестов, потому что по большому счету ты можешь как сделать? Ты можешь сделать один тест, который проверяет все-все-все-все сценарии, но при этом человек зашел, он прошел по всем-всем страницам, сделал все, что ты можешь представить, что он сделал и вышел Такой тест один, наверное, нужен, но если он сломается, иди и узнай, что именно сломалось Более того, если что-то изменилось, то его поддерживать будет достаточно сложно. Это тест.

А, тест тоже надо менять, обновлять так же, как ты обновляешь программу.

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

Можешь привести примеры сценариев?

Потому что уже стало интересно, к чему эта страница может происходить.

Например, я получил подарок, зашел на страницу своих заказов, я вижу страницу, на которой у меня есть несколько кнопок. Например, у меня есть кнопка вернуть подарок, у меня есть кнопка написать email, спасибо за такой великолепный подарок.

Ага.

Я перехожу на эту страницу, спасибо за этот великолепный подарок, и пытаюсь отправить какую-нибудь ссылку на какой-нибудь вредоносный сайт. Так. Это сценарий, и мне нужно его протестировать.

А что должно произойти в такой ситуации?

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

Это отдельный сценарий? Проверить, что браузер защитил, и второе, что сервер защитил?

Это два разных сценария, да.

А, вот теперь становится понятно, почему их 200, ну и там очень много. Где эти тесты хранятся? Это как бы исходный код, который хранится рядом с программой, или это какая-то отдельная система, в которой можно хранить? То есть эти тесты они текстом пишутся или где-то накликиваются? Мне вот это интересно.

Не существует одного стандартного способа тестирования, нестандартизированная штука. Существует много подходов. Существует подход, например, называется BDD, Behavior Driven Development, разработка по поведению пользователя. Сначала мы описываем, что мы вообще ожидаем от системы. Да, но пользователь, залогиненный на сайте, когда он нажимает на кнопку «Добавить товар в корзину», тогда товар в корзину добавляется. Существуют системы, которые позволяют прямо на английском языке описывать сценарий. И существуют системы, которые это превращают в программы, которые уже тестируют в тестах. Но при этом, конечно, разработчикам нужно немножко поработать для того, чтобы описать, о чем вообще эта система и что значат эти слова, глаголы. Какие-то глаголы, какие-то существительные и так далее.

То есть программа позволяет разговаривать с собой на таком более-менее человеческом языке?

Да.

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

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

А потом программистам нужно сделать так, чтобы их программы понимали, что эти сценарии хотят получить.

Абсолютно.

Блин, это дохера работа для программиста.

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

Да, это жесть какая-то. Какие еще есть варианты? Потому что это какой-то ад.

А есть на русском языке такие системы, ты знаешь?

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

Один эсом.

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

Скажи, пожалуйста, это все еще UI или это уже что-то другое?

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

Очень длинный цикл получается, когда программист что-то доделал, и чтобы понять, типа, все ли в порядке, ему надо ждать, пока живой человек накликает это все на экране. Это, конечно, долго.

Абсолютно. Более того, у нас еще есть одна проблема. Когда тестировщик нашел какую-то проблему и сказал разработчику, разработчик пофиксил эту проблему, как-то изменил код, и нам нужно заново проверять все, потому что когда программист менял в одном месте, могло сломаться в другом.

Офигеть! Вот это, конечно, самый ад. Представляешь, типа ты 90% всех тестов прогнал, типа все проверил, все было в порядке, на последнем тесте что-то не так, и теперь тебе нужно все заново перепроверять.

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

Ну да.

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

Да.

Это надо осознать перед тем, как думать о программировании.

Ну, мне кажется, на самом деле, в достаточно большом количестве областей оно работает примерно так, то есть сайд-эффекты (side effects) в совершенно неожиданных местах.

Ну, я себе представляю, почему-то со строительством,

мне кажется, там как-то более... Здесь кирпич положил неправильно, значит, в этом месте оно и неправильно. А в целом здание вряд ли развалится.

Если мы пойдем в такой офф-топ, то был ужасный пример, по-моему, в Лас-Вегасе. Был проект, там висит трос, и на нем два болта. И вот вместо того, чтобы сделать эти два болта, они сделали два троса, потому что у них не было одного длинного троса. И в итоге вся нагрузка пришлась на один болт, и много людей погибло.

К счастью, у нас есть возможность написать

тесты, чтобы такого не происходило.

Абсолютно.

Слушай, раз мы уже говорили о нагрузке, давай уйдем с UI. Мне кажется, что мы его так более-менее покрыли тестами. Давай поговорим про нагрузочное тестирование. У меня был такой проект— интернет-магазин iGoods. Мы там работали как раз во время начала коронавируса, тогда мы еще не знали, что сейчас коронавирус начнется. Но в какой-то момент было выступление Путина по телевизору, что две недели сидим по домам, работать не будем, денег вам платить тоже не будем. Но суть была в том, что в

магазины ходить нельзя будет.

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

Ну, от коронавируса, к сожалению, нас бы это не спасло. И вот этот сценарий, который ты описал, обычно называется «Чёрный лебедь». То есть это произошло событие, которого мы вообще не ожидали и к которому были совершенно не подготовлены. К счастью, чёрный лебедь прилетает очень редко, и после того, как прилетел чёрный лебедь, он перестал быть чёрным лебедем. И мы уже знаем, что бывают такие сценарии. Приведу пример с Амазоном. Рождество наступает каждый год. У нас была по этому поводу шутка. Существует единственный дедлайн— это Рождество.

То есть к Рождеству надо точно успеть.

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

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

Мы количество машин увеличивали, по-моему, раз в 10.

В 10 раз больше серверов, чем обычно.

Что они все делают, Господи?

подарки. Так вот, представь себе, что у тебя есть система, какой-то сервис, и к тебе вдруг пришло в 10 раз больше пользователей. Уверен ли ты, что твоя система выдержит? Уверен ли ты, что ты можешь добавить какое-то количество дополнительных вычислительных мощностей, дополнительных компьютеров? Уверен ли ты, что они между собой будут корректно взаимодействовать? Уверен ли ты, что у тебя не будет проблем где-нибудь с сетью, например, с локальной сетью? Вот чтобы ответить на все эти вопросы, существует нагрузочное тестирование. По большому счету, как это работает? Мы симулируем огромный трафик людей, которые занимаются примерно тем же самым, чем они занимаются в обычной жизни.

То есть мы не сажаем дополнительно 10 тысяч или дополнительно миллион человек как ручное

тестирование, это уже точно программная штука.

Да, это достаточно дорого— посадить миллион человек на нагрузочное тестирование. Мы, опять же, пишем программу, которая симулирует большое количество реальных пользователей. Как правило, одна машина не справляется с тем, чтобы симулировать такое количество пользователей. У нас несколько машин симулируют пользователей, они приходят на систему, они симулируют реальные действия, они проверяют правильный результат и они, что очень важно, замеряют, как быстро мы ответили. То есть если интернет-магазин, страничка отвечает тебе через минуту, то, скорее всего, тебя уже там нет.

Человек не дождется просто.

Да.

Можешь привести пример?

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

Воу, очень понятный пример, да, спасибо большое. То есть обычно у тебя там 10 разных людей ищут что-нибудь на сайте, а тут у тебя 1000 разных людей ищут что-то на сайте. И сервер, который делает поиск, очевидно, как

бы надо больше попотеть, чем 10.

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

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

не пустим, потому что у нас база данных не выдерживает.

Условно так, то есть на самом деле существует load balancer, так называемый, это промежуточный слой между базой данных и сервисом. И вот load balancer в какой-то момент понимает, что слишком большая нагрузка, слишком большой latency, и он говорит, извините, мы больше заказов не принимаем.

Latency задержки.

Да, задержки запроса, то есть время, которое уходит на обработку запроса.

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

Да.

Больше людей не пустим.

Да.

Вау.

При этом нам нужно убедиться, что сайт корректно отобразился пользователям.

Даже когда невозможно взять его запрос, тебе все равно надо аккуратно пользователю об этом сказать.

Да, абсолютно. Потому что существует сценарий, например, программисты иногда делают следующим образом. Хорошо, у меня не получился запрос, я его повторю.

Ой-ой-ой.

То есть вообще-то это правильно. Вообще-то логичное правильное поведение. Если не получилось, надо просто повторить. Скорее всего, получится второй раз. В абсолютном

большинстве случаев такая логика приведет к трагедии. Потому что если запрос не получился, то, наверное, на это была какая-то причина. А если мы начнем бездумно повторять запросы, то у нас нагрузка на базу данных возрастет лавинообразно просто.

А приведи пример такого запроса, который обычно повторяется.

Ну, например, у тебя сервис спрашивает у базы данных, покажи мне всех Teddy Bear.

Всех мишек на сайте.

Вот, а база данных при этом очень занята, и тебе load balancer тут же говорит вот этот промежуточный слой, который отвечает за то, чтобы слишком базу данных не нагружать. Он тебе отвечает, ой, извини, у нас все слишком плохо, мы не справляемся. А твой сервис, тут же я снова говорю, нет, ты все-таки мне отдай его. И тогда уже к Load Balancer будет очень много запросов от всех таких же клиентов. И в итоге у нас Load Balancer уже начнет задыхаться, а не база данных.

Окей.

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

Сколько таких праздников в год бывает?

У нас мир большой. У нас существует Рождество, которого есть Black Friday, Cyber Monday в европейских странах.

Чёрная пятница, Киберпятница, даже в России они уже есть.

Да, в Индии я забыл название праздника.

Дивали, кажется.

Да, да, да. Вот, очень-очень важный праздник. По всему миру разные традиции и такое количество ивентов, их достаточно много.

Офигеть! То есть ты знаешь праздники всех народов мира, потому что каждый праздник, это значит на Амазон придёт куча людей, будут покупать подарки даже друг другу.

Да, у нас был специальный календарь по праздникам народов мира, по большому счёту.

И перед каждым праздником тебя уже протестируют, что на этот праздник вы не упадете?

Перед каждым большим праздником, да.

Слушай, ты сейчас рассказываешь про довольно сложные архитектурные штуки, то есть про суть того, как устроен сервис.

Это не просто на кнопочки тыкать.

Кто этим занимается?

Этим занимаются разработчики, по крайней мере в Амазоне. В конце концов, это сводится к тыкать кнопочки.

Да, но тебе нужно тыкать кнопочки на десятках компьютеров, тысячу кнопочек в секунду, и при этом замерять скорость ответа кнопочек. Это уже не так просто, как у меня на столе семь телефонов лежали.

Опять же, в Амазоне существует такая должность, называется SDET. инженер по разработке программного обеспечения. А SDAT – это Software Development Engineering, то есть это разработчик тестов Но это не только тестов, по большому счету обязанности SDAT – это разрабатывать инфраструктуру для того, чтобы разработчики могли тестировать То есть он

даже не сам тесты пишет, а он пишет программы для того, чтобы программистам было проще писать тесты для своих программ?

Абсолютно И, среди прочего, они занимаются тем, что готовят нагрузочные тестирования, готовят машины для нагрузочного тестирования, готовят сценарии, готовят данные, которые будут пытаться воспроизвести. занимаются либо SDE, либо SDET.

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

Да. Ручным тестированием, как правило, SDET не занимаются, это слишком дорого, потому что SDET очень мало. Их сильно меньше, чем SDE. О!

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

Абсолютно.

То есть это более такая высокая каста, можно сказать, программистов?

Это параллельная каста. Почему-то в среде программистов принято считать, что тестировщик— это те, кто не умеют программировать.

Да, это правда.

Так вот, SDAT, их сильно меньше, и работа, я не скажу, что она сложнее, она параллельная, и это другая сфера работы. У SDAT более горизонтальное покрытие.

Что это значит?

Один SDAT работает сразу на несколько команд и готовит инфраструктуру, чтобы несколько команд могли делать, например, нагрузочное тестирование.

То есть он сидит не внутри только одного проекта, а он типа обслуживает сразу несколько проектов?

Да. Если проект очень большой, то у него могут быть задачи для одного проекта. Но, как правило, поскольку мы худо-бедно работаем в одном и том же стеке технологий, примерно одни и те же языки программирования используем, одни и те же сервисы и так далее, несколько проектов могут использовать одну и ту же инфраструктуру для тестов. При этом программисты сами пишут и UI-тесты, они могут сами запускать нагрузочные тестирования, но для того, чтобы это подготовить и для того, чтобы сделать им удобно вот это вот все, существуют SDET. Я могу еще про одно направление работы с DAT рассказать, которым я в том числе занимался.

А ты был как раз таким программистом тестирования?

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

И ты писал тест на то, чтобы проверить, что программа типа всегда будет продолжать работать так же, как она работала раньше?

По большому счету, да. Потому что у нас пришла новая команда, нам отдали старый проект, и нужно было с этим что-то делать. И, в общем, так получилось, что я начал фокусироваться на тестах, и, в конце концов, это привело к тому, что перешёл в SDET… один из проектов SDET, над которым я работал, хаос-тестирование.

давай про него и поговорим подробно.

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

Тут вообще надо пояснить, что типа условные Google или тот же самый Amazon— это типа 10 тысяч серверов или там 100 тысяч серверов, я не знаю, сколько сотен тысяч серверов. При таких объемах у тебя постоянно что-то

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

Расскажи дальше, я не хочу просто давать определение хаос-тестированию, расскажи ты, как ты это видишь лучше.

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

Во-первых, дофига ждет, а потом понимает, что ошибка.

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

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

Не только.

То, что ты описал,— это задача Load Balancer. У нас задача, например, представь себе, на компьютере по какой-то причине процессор занят на 100%, неважно чем. Пришел пользователь и говорит, вот, пожалуйста, тебе запрос.

Запросы, значит, открыть страницу или добавить товар в корзину, это все в конечном счете переводится в запросы к серверу.

Абсолютно. Приходит и говорит, дай мне список мишек. А вот этот физический компьютер, который сидит где-то в дата-центре, он говорит, сейчас дам. И по-прежнему у него 100% загрузки процессора, он не может ничего сделать, но он пообещал. Это не очень правильно. Например, у нас есть такая штука, называется тайм-аут. Через какое-то время запрос должен прекратиться. Через какое-то время мы должны сказать, ой, слушай, извини, мы не можем. Мы прям сильно-сильно заняты, все, не могу. Сходи к кому-нибудь еще. Мы должны протестировать, что вот эта штука работает правильно, что мы тайм-ауты правильно отдаем. Мы должны убедиться, что когда процессор освободится, что мы снова начали нормально работать, что у нас нету какого-нибудь другого затыка. Мы должны убедиться, что если у нас память, например, полностью была занята и потом упала, то у нас тоже все хорошо. А с жестким диском это все нужно проверять.

Господи, Максим, остановись.

Вот ты сейчас описываешь количество проблем, которые могут быть, я просто офигеваю. Ну в смысле, надо пояснить, что когда ты пишешь программу, happy path («хэппи пас»), то есть то, когда всё нормально идёт, ты думаешь, как работает моя программа? Вот человек отправляет запрос, вот он получает ответ, всё нормально.

Это типа 10% твоей программы, а остальные 90%— это описать, что происходит, когда что-то не

так. Тут очень хорошая аналогия— это медицина. В ней одна книжка—

это «Анатомия здорового человека», а дальше 10 книг о том, что может пойти не так и что в этой ситуации делать. И вот тут ровно такая же проблема.

Ты прямо сейчас идеально описал мою работу.

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

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

Тогда они работают.

Обычно там на графике показано количество пользователей, количество запросов в секунду. Дальше то, с какой скоростью мы отвечаем на эти запросы в среднем. Или, например, то, с какой скоростью мы отвечаем 95% пользователей. Вот эти все графики показывают жизнеспособность твоей системы под нагрузкой. Слушай, мы начали все это со слова хаос-тестирования, а мы вроде как вернулись к нагрузочному тестированию. Объясни, где разница между нагрузочным тестированием и хаос-тестированием.

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

А, то есть ты ломаешь свой компьютер,

по сути, по разному, разными способами?

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

на другой дата-центр. Хаос-тестирование, это довольно сложная техническая штука. И это привилегия IT-гигантов или это все делают?

Это начал делать Netflix. Они это сделали open-source, и теперь кто угодно может это использовать. Большинство больших компаний. Если это достаточно небольшая компания, это просто слишком дорого.

И можно реально просто перезагрузить сервер или

там что-нибудь такое сделать, и все нормально будет.

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

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

Вот да, у нас все равно такая история была.

Макс, какие мы виды тестирования важные еще не затронули?

Эта достаточно специфическая тема называется mutation testing, мутационное тестирование. Я очень люблю эту тему, она не очень популярна, к сожалению, но прям очень люблю. Идея следующая. Она, к сожалению, работает только на юнит-тестах, на самых низкоуровневых тестах. Это программы, которые тестируют небольшой кусочек моего кода.

Но, тем не менее, Давайте чуть помедленнее. Значит, мы сейчас с тобой обсуждали UI-тесты, то есть интерфейсные тесты. Это то, когда программа условно нажимает на кнопки в твоей программе. Потом абсолютное нагрузочное тестирование. Это когда мы всю систему в целом проверяем на то, как она относится к тому, когда к ней приходит в 10 тысяч раз больше людей, чем обычно. Потом хаус-тестирование, когда у программы становится гораздо меньше ресурсов. А теперь мы опускаемся на самый низкий уровень. То есть вот у тебя программа, в ней есть отдельные модули, кусочки программы, которые делают какие-то маленькие задачки. И ты вот проверяешь именно их, да?

Абсолютно. Это называется юнит-тесты. Мой самый любимый пример юнит-тестов, когда у нас была следующая проблема. У нас был очень небольшой кусок логики, который проверяет, какой квартал сейчас есть по дате. Что можно пойти не так? Первый квартал начался 1 января, второй квартал начался 1 апреля, а вот 1 июля третий квартал не начался.

Почему?

А потому что квартал это же 4 месяца. Вот мы делили на 4. Но при этом, чтобы сошлось, мы вычитали где-то еще единицу. И так получилось, что 1 апреля начался 2 квартал, а вот в июле нет.

Так, при чем тут тесты?

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

А, то есть unit test выглядел бы так. Модуль программы, который проверяет квартал вот есть, и test ему выглядел бы так. Проверишь, что такого числа начинается первый квартал, такого числа второй, такого числа третий. То есть ты подаешь кусочку своей программы на вход дату и проверяешь, что он возвращает, что да, квартал начался.

Абсолютно. Я говорю, 1 июля третий квартал, а 30 июня второй. Ну как бы хорошо. Ну там проверяешь вот каждый квартал.

Офигеть.

На самом деле юнит-тесты— это религия моего партнера Феди, он вообще не берет на работу программистов, которые не пишут юнит-тесты.

Достаточно сложно программировать, если у тебя нет юнит-тестов, потому что ты узнаешь о проблемах, которые ты сам создал, слишком поздно. Очень поздно. И их потом будет очень сложно решать. Поэтому очень важная вещь. Так вот, моя любимая тема— это мутационное тестирование. Мутационное тестирование следующее. Вот ты написал какой-то модуль, написал юнит теста для него, и дальше есть такая метрика, называется coverage— покрытие тестами. По сути, что ты делаешь? Запускаешь тест, и существует специальная программа, которая проверяет каждую строчку кода, заходила ли программа проверки в каждую твою строчку кода.

А, то есть условно берем весь наш текст программы и закрашиваем зеленым те кусочки, которые проходились, когда работал тест?

Абсолютно.

И таким образом ты можешь найти те кусочки, которые не были покрыты тестами. То есть они не покрашены зелененькими, значит в них может быть проблема, и мы они не узнаем, потому что тестов на нее нет.

Абсолютно. Если не зелененькая линия, это значит, что в эту линию тест никогда не заходил, и что там подтворится, никто не знает. А мутационное тестирование следующее? Если мы прошли через какую-то строчку кода, это не значит, что мы ее проверили Даже если она зеленая, это еще не значит, что она точно протестирована Если она

осталась беленькой, то это точно проблема, а вот если она стала зелененькой, мы еще

не уверены Так, и как стать уверенным? Мы меняем эту строчку То есть просто

программа случайным образом что-то там нафигачивает.

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

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

Не обязательно безумные, то есть... Ну, оно

как бы меняет суть твоей программы.

Иногда да, иногда нет. То есть иногда, если ты поменял больше на больше равно, ты говоришь, ну хорошо, это приемлемый риск, я с этим живу. Но тем не менее, когда ты знаешь, что именно ты протестировал, это сильно проще для разработчика. Посмотреть на кавер-репорт после своей работы – это обязательное дело. Если ты не посмотрел, откуда ты знаешь, что ты вообще сделал. Посмотреть на mutation-репорт – это еще получить подсказки о том, что ты протестировал или не протестировал.

Классно!

Да, я на самом деле не слышал о такой штуке, и она звучит просто дико весело.

Я постоянно это слышал, что тестирование— это такой вход в профессию. Многие люди, которые хотят стать программистами, начинают с того, что они становятся тестировщиками. Почему так происходит? Почему такое мнение есть?

Скорее всего, идея следующая. Для того, чтобы тестировать, тебе нужен здравый смысл. Для того, чтобы программировать, тебе нужен здравый смысл и знания конкретные о языках программирования и так далее. Если ты занимаешься тестированием, то с помощью здравого смысла ты приходишь к каким-то сценариям, ты их проверяешь, и дальше тебе понятно, зачем тебе нужно программировать. То есть тебе естественным образом приходит в голову идея, что неплохо бы автоматизировать часть моей работы, не правда ли? чтобы не проверять один и тот же релиз. И ты начинаешь программировать потихоньку, но при этом ты все еще приносишь пользу. И начинаешь делать все больше и больше, тестировать все больше и больше.

Знаешь, мне кажется, что весь наш разговор— это на самом деле ответ на этот вопрос, но я все-таки его еще раз задам, давай поговорим. Тестирование— это программирование или это попроще?

На мой взгляд, тестирование— это сложнее. Как ты упомянул, Happy Path— это только 10% наших сценариев. 90% нашей работы— это предупредить то, что пойдет не так. И вот это очень тесно связано с тестированием. По большому счету, тебе нужно это все тестировать. Поэтому 90% нашей работы— это предупредить проблемы. Поэтому с этой точки зрения я считаю, что тестирование сложнее, чем программирование само по себе.

То есть предугадать, что может пойти не так, конечно, сложнее, чем просто придумать идеальный сценарий. Happy path—

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

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

А зарплата тестировщиков при этом ниже, чем у программистов, или как? Как вообще зарплата соотносится?

Если мы говорим про SDET и SDE, то вилка одинаковая. Если мы говорим про ручных тестировщиков, ну понятно, что если человек не программирует, а занимается ручным трудом, то у него оплата будет несколько ниже.

Окей, поговорили про теорию, давайте про тебя. Расскажи, как ты вообще сам попал в тестирование?

Первый мой проект с тестированием, очень тесно связанный с тестированием, был SKB Contour SKB Contour—

это компания российская, которая делает решения для электронно-цифровых подписей, для сертификатов Они делают даже такие штучки, которые вот втыкают в компьютер, и там внутри у тебя электронно-цифровая подпись Если вы открывали ИП, то вы знаете,

что это такое Есть такая технология, называется TDD— Test Driven Development Идея следующая. Прежде чем писать код, ты пишешь тест, и он у тебя ломается. И потом ты пишешь код, чтобы этот тест проходил, и, собственно, становится счастье. То есть сначала пишешь тест, а потом пишешь код. Сначала думая, что именно ты хочешь реализовать, и потом это реализовываешь.

Как оно должно работать?

Я пришел в проект, в котором ребята были большие фанаты этой идеологии. И у нас тестов было, по-моему, 2000 UI-тестов. Вот такого порядка цифры были.

Неплохо.

Это было прекраснейшее время. И чуть-чуть до того, как я попал в эту команду, к нам на Урал, опять же, SKB Contour, спасибо им большое, привозил к нам Кента Бека, идеолога TDD, Test Driven Development.

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

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

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

Абсолютно. Мне очень повезло быть в то время в том месте и да, вдохновился этой идеей. Я занимался в основном веб-разработкой и оно все время было как-то связано с тестированием.

Максим, то есть ты был программистом в Контуре, но при этом в ваших проектах все программирование крутилось вокруг тестов, то есть вы очень сильно используете тестирование в своей работе.

Абсолютно.

Как ты вообще перешел из Контура в Амазон, потому что Амазон это типа одна из ведущих IT-компаний на свете, а ты

на Урале прогаешь для Контура?

Я на Урале пробую для контура и по политическим причинам решаю уехать за рубеж. Я еду работать на небольшой стартап в Германии, в Берлине, но потом в определенный момент стартап закрылся, что бывает с 90% стартапов, и я пошел работать в Амазон. Там была прямо такая метафизическая история, как я пошел работать туда. Шел август 2015 года. Я читаю в новостях, что идут персеиды. Я думаю, о, как классно персеиды, звезды падают. Пойду посмотрю.

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

Звездный дождь. Сижу, смотрю на небо, звезды не падают. Мне скучно. Я думаю, так, надо придумать какое-нибудь желание, чтобы вот звезда упала. Я такой, хоп, желание загадал, и молодец. И какой-нибудь абсолютно безумный, чтобы вот прям точно без звезды вообще никак. А я хочу в гугле работать. Отличное желание, да, все, классно. Сижу, звезды не падают, и не падают, и не падают. И у меня в голове мысль, так, я хочу работать в гугле, а все, что я для этого делаю, я сижу и смотрю на небо. Наверно, в этом плане есть какой-то подвох. Я думаю, а что сделать, если я хочу работать в Google, кроме как смотреть на небо? Наверно, надо загуглить. Я гуглю, как устроиться на работу в Google. Первая страница выдачи рекомендует мне одну и ту же Cracking the Coding Interview. Классическая книжка, прекраснейшая, рекомендую абсолютно всем. Заказываю эту книжку, начинаю решать оттуда задачи, и заодно пишу своему другу, который работает в Гугле, говорю, всё, я хочу работать в Гугле, давай сделаем мне реферал (referral). Вот, съездил на собеседование, собеседование провалил, и попутно решил сходить на собеседование в Амазон, потому что они приезжали в Берлин, и я подумал, я сейчас потренируюсь перед Гуглом на Амазоне, и в Гугл потом пойду. Прошел собеседование в Амазон, они мне прислали оффер, и пошел работать в Амазоне.

Идеальная история, Максим. Друзья, если хотите поработать в какой-нибудь крутой компании, возможно, вам нужно для этого что-то сделать.

И вот ты попал в Amazon, и ты говоришь, что ты как раз начал писать тесты. Но ты попал просто как фронтенд-разработчик, да?

Нет, фулстек-разработчик (full-stack), потому что просто фронтендом еще в предыдущей фирме мне надоело заниматься только фронтендом, и я занимался, ты не поверишь, еще и тестами. Так вот, пришел Amazon, у нас проект старый, люди новые, у нас достаточно мало людей, которые понимают, что там происходило. У меня от этого дикий стресс, я не понимаю, как оно работает. Я начинаю писать тесты, чтобы зафиксировать, чтобы понять, как оно работает, и чтобы сделать так, чтобы оно работало так же всегда. По крайней мере, чтобы оно не изменило работу без моего ведома.

Ты идеальный программист. Если бы ты у меня работал, я был бы счастлив, потому что, наконец-то, хоть кто-то понимает вообще, как поддерживать Legacy Code. А у тебя был, по сути, Legacy Code, о котором ты не разбираешься. Надо дописать тесты, черт побери, чтобы оно перестало падать.

Абсолютно.

Какой это был проект, ты помнишь?

Это все еще был Gift Receiver, то

есть, по большому счету... Это вот как раз подарки.

Да, это проект с подарками был, да. Там тесты были, но просто покрытие было не очень большое, и я дописывал то, что я не понимал.

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

Мне очень повезло с менеджером в тот момент. Менеджер понимал, что мы переняли Legacy проект, и что нам нужно время для того, чтобы его как-то перенять. И один из проектов моих и личных был, это как раз написание UI-тестов для Gift Receiver. Это был мой проект, моя инициатива, и менеджер поддержал, сказал, ну да, давайте, а то там прям никто не знает, как это работает и работает ли вообще.

Слушай, тебе очень сильно повезло. Ты сталкивался в своей практике вот с тем, что я тебе сказал, когда менеджеры говорят, типа, давайте срочно фичи дальше писать, нечего писать тесты? Есть ли какой-то рецепт? Потому что вот я делаю очень много аудитов, и почти все программисты говорят, ну да, тестов нет. Я говорю, а че ж так? Они говорят, ну мы понимаем, что тесты нужны, но бизнес не хочет ждать. Есть ли у тебя какой-то совет таким ребятам, как себя вести?

С точки зрения бизнеса, я прекрасно понимаю, что это дорого. Если у тебя разработчик, вместо того, чтобы писать фичи, он занимается тестами и инфраструктурой, он не выкладывает фичи. Поэтому я бы рекомендовал просто простить и понять бизнес. По большому счету, бизнесу неважно, сколько у тебя тестов. Бизнесу важно, чтобы бизнес работал, бизнес приносил деньги, и он работал стабильно. И он работал стабильно, оно стоит на третьем месте. А тесты— это как раз про то, чтобы он работал стабильно. Если бизнес вообще не приносит денег, то владельцу все равно, какое у него покрытие тестов и сколько у него mutation coverage. Абсолютно все равно. У него нет денег.

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

Тестирование всегда было в фокусе моего внимания, мне это было всегда интересно. И в определенный момент мой менеджер говорит, вот у нас позиция SDET? Потому что по большому счету тебе тогда не нужно будет пилить фичи и сможешь заниматься тем, что тебе нравится.

Идеальный менеджер.

Было достаточно сложно отказаться от такого предложения, поэтому стал SD&T.

Что происходило дальше? Просто сейчас ты уже не работаешь в Амазоне.

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

Так, насколько я помню, полгода между собеседованием

Первым и вторым, по-моему, два года даже было, а потом еще год и да.

Вот это настойчивость. Это прям реально внушает уважение. Расскажи, почему они тебя отсекали в первые два раза? У меня такое ощущение, что после того, как ты в Амазоне поработал, в Google

ты вообще уже просто поменял работу.

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

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

Абсолютно.

Еще вопрос. Финальный. Я у всех гостей его спрашиваю. Посоветуй что-нибудь, что ты сам читаешь в интернете, что тебе очень нравится. Просто про свое личное. Что ты любишь читать в интернете? Или смотреть YouTube, может, какой-то?

Лично каналы в Телеграме в основном сейчас.

Скажи какие-нибудь два канала, которые тебе больше всего нравятся.

«Типичный программист»

Отлично. Это мемасики по программированию. Ссылку на этот канал я положу в описании к этому эпизоду. Окей.

Это офигенное интервью. Спасибо тебе огромное.

Мне прям так интересно.

Про то, как ты пробивался в компании, меня это на самом деле поразило, наверное, больше всего. Это прям такой кремень реально.

Респект.

Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. Над подкастом работали редактор Юлия Яковлева, продюсер Павел Боровков, звукорежиссер Нина Мамотина. За джингл спасибо Алексею Зеленскому.