Кто играл в Need for Speed, угадает эту мелодию с четырёх нот: э‑рон‑дон‑дон… Драйв, эмоции на максимум, бесконечные повторы неудачных заездов и кайф после утомительного прохождения — вот с чем до сих ассоциируется у меня эта серия игр. И это те же самые слова, которые я произношу, когда меня спрашивают о работе тестировщика.

Вопрос «Как вкатиться в айти?» я слышу чаще, чем «Как прожить в ІТ долгую и счастливую рабочую жизнь?». Мне удаётся сохранить вдохновение и успешно строить карьеру в quality assurance — и потому я хочу поделиться опытом, подкрепив его ссылками на актуальные тексты авторов Хабра.

Итак, сегодня я — [капитан очевидность] штурман в нашей команде :) Давайте знакомиться: меня зовут Василиса (@vasenka), я работаю QС в одной из продуктовых компаний. Под катом — мой тест-драйв карьерного трека QA, а в качестве навигатора — статьи авторов Хабра. Погнали!

Подъезжаем к старту. Как начать

Первую статью нашей коллекции тестировщика я посвящу тому, что быть тестировщиком не обязательно. В IT много возможностей для самореализации и повышенный спрос на дизайнеров, маркетологов и специалистов поддержки может изменить приоритеты в поиске работы. Я хотела начать карьеру именно тестировщика, но мониторила и смежные направления. Это дало понимание спроса и дополнительный опыт собеседований.
Когда я входила в ІТ, приток соискателей в тестирование обеспечивали два устойчивых взаимосвязанных стереотипа:
  • это пропуск туда, где «много платят»™;
  • это просто по сравнению с разработкой.
Они формируют ложные ожидания, из-за которых у входящих в айти создаётся негативное впечатление о работе, а у принимающих — что выбор кадров большой, хотя по факту выбрать не из кого.
Что может быть проще, чем найти десять отличий между спецификацией и реальным поведением тестируемого приложения? Кажется, что достаточно трёх классов церковно-приходской школы, умения нажимать на кнопки и клепать баг-репорты. Похоже на заводской конвейер, только платят больше. Именно так думала и я, когда решила начать карьеру тестировщика. Сейчас такой подход кажется мне наивным.

Необходимый базис: разница QA/QC и понимание профессии

«Профессия — тестировщик»: чтобы понять, что вообще такое тестирование

Легко и подробно о мифах, плюсах и минусах работы, ожиданиях от работы и, самое интересное, средней зарплате (статистика за прошлый год). Все описанные пойнты вполне коррелируют с реальностью.
Остановлюсь на наиболее волнующем новичка — «Базовые требования к профессионалу»:
  • опыт технической поддержки;
  • основы программирования (желательно Java, SQL, Python, но сойдёт буквально всё);
  • знание методологии Agile, умение встроиться в микрокоманды;
  • основы Linux;
  • основы архитектуры ПК;
  • модель OSI и сети (базовое понимание, знание структуры заголовков пакетов и прочее);
  • инструменты управления тестированием — Bugzilla, Jira или любой другой баг-трекер;
  • Selenium — инструмент для автоматизации действий веб-браузера (от себя добавлю, что Selenium долго считался чуть ли не единственным инструментом, но уже существует и поддерживается разработчиками альтернатива — Katalon);
  • желательно понимание стратегий тестирований чёрного, белого, серого ящиков.
У меня на старте были только опыт техподдержки и умение встроиться в микрокоманды.
Актуальные данные по средней зарплате с делением по странам и формой работы (фриланс, удалёнка, офис), а также списком навыков, за которые платят. Ребята упоминают о разнице между QA и QC. Если просто прогоняешь тесты — OK, ты специалист по тестированию. Если продумываешь стратегию тестирования, описываешь тест-дизайн — можешь называть себя QC. Если обеспечиваешь качество продукта в более широком понимании, включая выбор инструментов тестирования и разработки, поддержку на релизном и пострелизном этапе — отлично, ты настоящий QA.
Я встречала компании, где эти понятия не разведены и один-два человека заменяют целую команду тестировщиков и техподдержки, отвечая сразу за всё. Это осложняло работу: ответственность несли все — а по факту никто.
В этом же гайдлайне сделан акцент на soft skills. На старте соискатели прокачивают hard skills, но по мере движения по карьерному треку софт-скилы приобретают всё большее значение. Лично мне они помогают найти подход и к ворчливому сисадмину, и к интроверту-разработчику, и к говорливой команде саппорта. А иногда и ответить на фразу вроде «Опять не так? Я тебе сегодня уже исправил одну ошибку на другую» :)

«Кто ты, QA-инженер или тестировщик?»: в продолжение темы дефиниций

Ребята из Dodo Engineering определяют QA и QC через зоны ответственности. Это выглядит как пересекающиеся сферы, где тестирование — узкая область контроля качества, контроль качества — часть обеспечения качества, ну, а само обеспечение качества — наиболее широкая область и измеряется соответствием реализации требованиям к продукту, техническому заданию и так далее.
«Не позволяйте сложившимся правилам, должностным инструкциям и прочей фигне мешать вам делать продукт ещё более качественным, чем сейчас» — это мой девиз. Хороший QA знает, что тестирование начинается ещё на этапе подготовки технического задания, включая тестирование требований и другой проектной документации. Схожую мысль высказала знакомая QA, показывая мне косяк на сайте одного государственного учреждения, который не был критичным, но мешал взаимодействию: «Это потому, что у них тестировщика нормального не было». Дьявол в деталях.

«ISTQB. Как проходит сдача экзамена онлайн»: почему тестерам полезен сертификат ISTQB

Личный опыт прохождения со ссылкой на бесплатный пробный вариант подробно описала @bazyakina. Как происходит бронирование и регистрация на экзамен, какие технические условия должны быть соблюдены, как лучше готовиться и как проходит сам экзамен — всё это подробно и по пунктам.
Впрочем, эти корочки в русскоязычном сегменте IT по востребованности сильно уступают опыту и хард-скилам. В статье приводится занятный факт: на 20 декабря 2020 из 5833 вакансий только 64 содержали ключевое слово ISTQB. Моя личная статистика такова: среди знакомых тестировщиков есть лишь один с сертификатом ISTQB. Говорит, что никаких бонусов с этого не получил.
Как говорит знакомый разработчик: «Наши отношения были хорошими до первого релиза» :)

Гонка за первым оффером

На старте в бэкграунде у меня было исключительно гуманитарное образование (психолог) и полное непонимание того, куда я хочу попасть и что такое вообще это ваше тестирование.
Первое собеседование я проходила, имея опыт работы в контент-студии и три прочитанные книги: «Тестирование DOT COM» Романа Савина, «Искусство тестирования программ» Гленфорда Майерса и «Тестирование программного обеспечения. Базовый курс» Святослава Куликова.
У меня не было плана развития карьеры. О том, что его надо строить, я узнала, уже проработав несколько лет. Не будьте как я, будьте лучше: включаем навигатор!

Как построить свой карьерный трек

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

То же самое и с подготовкой к типовым вопросам вида «кем вы видите себя через пять лет». Понимая доступные опции карьерного трека QA, сверяя их со своими желаниями и способностями, можно построить отличную самопрезентацию через этот ответ на такой вопрос. Так, у кого-то уже есть опыт управления людьми и проектами, и тогда стоит задумываться о карьере тест-менеджера, затем QA-лида. Кому-то интересна автоматизация тестирования, и тогда есть два варианта: начать с тестирования руками, чтобы научиться тестированию как жанру, или сразу нырять совсем стажёром в автотесты. От этого выбора зависит и построение рассказа о себе, и реакция на него в разных компаниях.

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

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

«План начинающего тестера» от инженера по тестированию Exness

Статью стоит изучить ради чётко размеченного карьерного трека. Там есть схема «Путь развития в тестировании», которая может стать путеводителем. Правда, базовую самоподготовку я бы не ограничивала только свободным владением офисными программами. Я бы добавила понимание клиент-серверной архитектуры, основы про базы данных и в целом порекомендовала попробовать себя на какой-нибудь платформе вроде utest.com. Эта и ей подобные дают пощупать тестирование.
К сожалению, я на начальном этапе о таких платформах не знала, но мне помогли навыки написания макросов, когда я фактически была на бенче и бралась за любые задачи. Это не имело прямого отношения к тестированию, но помогало в тренировке абстрактного мышления.
Здесь предлагается список возможных вопросов на интервью и рассказывается, как написать в резюме об опыте работы, которого пока нет. Основной совет — приложить свой текущий опыт и навыки к профессии тестировщика. Каждый так или иначе взаимодействовал с разным ПО, будь то игра в телефоне, снятие наличных в банкомате или работа с офисными программами. А если даже писал разработчику о проблеме в приложении — можно считать это первым баг-репортом. Любой подобный опыт стоит указать в резюме — это многое скажет работодателю об умении будущего тестировщика мыслить как QA.
Курсы тестировщиков (как и любые курсы) хороши тем, что дают информацию структурированно, постепенно и с фидбэком. И всё же важно продолжать читать книги и откликаться на собеседования.
Пост содержит дельные рекомендации, как составлять резюме, проходить интервью и обсуждать зарплату. Автор формулирует 3 правила при составлении резюме:
    1. оно должно быть лаконичным;
    2. описание по принципу «зона ответственности + достижение»;
    3. опыт и инструменты соответствуют.
    У меня есть опыт подбора сотрудников, и такое резюме действительно помогает «продать» себя в течение той минуты, пока работодатель читает его. При обсуждении зарплатной вилки важно быть честным и уметь аргументировать свою ценность. Честность в этом вопросе производит приятное впечатление и способствует конструктивному диалогу между компанией и будущим сотрудником, а рациональная аргументация вызывает желание пойти навстречу соискателю.
    Если компания, куда хочется попасть, ориентирована на зарубежный рынок, стоит почитать. В моём замкадье от соискателя в среднем ожидают уровня не ниже B1 (Pre-intermediate), но если кандидат адекватный и соответствует остальным требованиям, то подойдёт и A1–A2. Однако это всё же зависит от того, есть ли у компании русскоговорящие заказчики: без уверенного английского устроиться в компанию, ориентированную на англоязычный рынок, сложнее. Свою карьеру в ІТ я начинала как раз в такой компании. И всё же отмечу, что привычка гуглить информацию на английском многое мне дала в плане развития хард-скилов.
    Я получила оффер уже после первого собеседования. Мои минусы удалось обратить в плюсы. Сыграли природное [задротство] занудство и педантизм, внимание к мелочам, здоровый перфекционизм, готовность много учиться и убеждение, что конечный пользователь должен испытывать кайф от взаимодействия с приложением.

    Тюнинг карьеры: пришло время поговорить о карьерном плане и грейдах

    Как правило, HR в формате 1 to 1 (то есть наедине) озвучивает возможные варианты карьерного роста на ближайшие полгода-год. А в продвинутых компаниях встречи, где можно обсудить текущий статус, скилы и дальнейшие грейды, проходят регулярно. Там можно осознанно оценивать свои перспективы на рынке и вести переговоры о зарплате с опорой на конкретику.
    Грейды — это условные способы классификации сотрудников. Они дают возможность оценивать их достижения по неким заранее согласованным параметрам. Эффективность подхода можно оспаривать (об этом ниже), но понимание чётких критериев даёт сотрудникам и работодателям определённые маркеры для оценки работы, давая возможность прогнозирования и выстраивания карьеры.
    Наиболее известна система junior → middle → senior. Но если с разработчиками всё более-менее понятно, то для тестировщиков я чаще встречала грейды в применении к специалистам-автоматизаторам, то есть тем, кто уже имеет n-летний опыт работы и в качестве дальнейшего развития карьеры выбирает разработку.

    Подходы к карьерным грейдам и прокачка по ним своего персонажа

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

    Когда тестировщик дорастает до сеньора, одна из логичных точек роста — стать руководителем команды тестирования. Эта роль подразумевает взаимодействие со смежными командами. Также на уровне сеньора можно начать думать в сторону должности автоматизатора. Это хороший вектор развития, когда не хочешь руководить. Оптимальный вход в специальность — перенять опыт у коллег, но бывает, что автоматизатором становятся и самостоятельно (без команды, которая ввела бы в курс дела): нередки истории, когда функциональный тестировщик начал автоматизировать, чтобы облегчить себе выполнение задач, и не заметил, как стал крутым автоматизатором.

    Я сам занимался автоматизацией, но мне не хватало драйва тестирования и взаимодействия с людьми. В какой-то момент я понял, что можно совмещать несколько ролей, и стал наставником в Яндекс.Практикуме, продолжая руководить тестированием и автоматизировать параллельно.
    Эрик Бурыгин
    руководитель тестирования мобильного приложения Яндекс.Недвижимость. Наставник в Яндекс.Практикуме
    Первая из статей блога «Конференции Олега Бунина», на которые я ссылаюсь: в ней представлена общая для IT-специалистов схема. На этапе, когда ручной работы становится меньше, появляется время осмотреться и осознать карьерные цели. Для построения хорошего карьерного плана важно понимать, что ты хочешь получить. Вопрос «Зачем мы вообще работаем в ІТ?», озвученный в посте, отсылает к пирамиде Маслоу — её можно взять за основу или с нуля построить свою. Понимание собственных целей даст рычаги для движения по карьерному треку.
    Когда я разобралась со своей мотивацией, я смогла осознанно сформулировать свои ожидания от карьеры на ближайшие несколько лет и искать/выбирать работу в соответствии с моими планами. А периодически сверяться с собственными целями — примерно как смотреть на приборную панель во время движения: важно для оценки движения и состояния машины.
    Статья из того же блога, но здесь уже описан свой подход, с основательной проработкой вопроса и масштабной аналитической подготовкой. Ребята ввели понятие Area of Effect, которое измеряет постоянное позитивное влияние компетенции в компании от 1 до 5. Таким образом удалось построить таблицы компетенций для сотрудников, создавать планы развития и балансировать команды. Более того, для каждого уровня ввели минимальные требования, что наверняка упростило процесс собеседования новых сотрудников. Такая прозрачная система и возможность видеть карьерные перспективы уже на старте даёт ощущение некой стабильности и уверенности в будущем.
    Интересный опыт аутсорс-агентства тестирования «Кавычки», который, как мне кажется, подтверждает, что существующие грейды до сих пор не могут быть сведены к единой системе. Жить без грейдов, как амбициозно заявляется в первом абзаце, думаю, всё же не удалось, скорее речь просто о другой системе, построенной для достижения тех же целей. В качестве метрик ребята установили параметры:
    • количество задач, которые сотрудник может взять;
    • уровень сложности, неопределённости и стоимости этих задач;
    • востребованность навыков, которыми он владеет;
    • общая прибыль компании.
    Кратко такой подход иллюстрирует цитата: «Какая мне разница, сеньор он или не сеньор, если он не может сделать то, что нужно проекту?». Он мне нравится, поскольку упрощает оценку трудоёмкости и ресурсных затрат на работу. Лучших результатов в своей работе я добилась в компании, где вопрос ценностей ставился именно так.
    Принято считать, что рост для тестировщика — это в первую очередь переход в автоматизацию. Автор разделил их на три блока: тестирование, программирование и девопс.
    • Что касается тестирования, то здесь стоит подготовиться по теории (тест-дизайн, техники тестирования), автоматизации тестирования Web (протокол HTTP, связка HTML/CSS/JavaScript), мобильной автоматизации (понимание операционных систем iOS/Android, особенности тестирования на симуляторах) и освежить знания по тестированию API (методы HTTP-запросов, коды и форматы ответа сервера).
    • В блоке вопросов о программировании стоит ожидать вопросов по ООП и… почти всё. Из-за трудоёмкости эта проверка обычно сводится к решению небольших задач, по которым будет легко понять, насколько соискатель в теме.
    • В части девопса, как правило, звучат вопросы по работе с различным софтом и инструментами: опыт работы с системами СІ и контроля версий, навыки работы с Bash. Здесь же могут быть вопросы по работе с базами данных, в частности на умение писать запросы (SQL).
    Любой тестировщик неизбежно будет прокачивать технические скилы, хочет он этого или нет. И да, вопрос, исчезнет ли когда-нибудь потребность в мануальщиках, всё ещё всерьёз обсуждается моими знакомыми. Нет, не исчезнет, но это тема для отдельного поста :) Мой опыт говорит, что мануальщики лучше справляются с обдумыванием и подготовкой тест-стратегий и тест-дизайном, чем «чистые» автоматизаторы.
    Он последовательно рассказывает, как найти «ту самую»:
    • выбирать продукты, которые интересны лично тебе;
    • не бояться раз в 3–4 года переходить из одной компании в другую;
    • приходить на собеседование, предварительно узнав о компании побольше, в идеале — потестив продукт;
    • задавать вопросы на собеседовании (вообще задавать вопросы), соотнося ответы со своими ожиданиями относительно зарплаты, и в целом показывать свой интерес к организации рабочих процессов.
    Алексей даёт много информации, полезной и для начинающих. Приводит вопросы, которые сам задаёт джунам (про клиент-серверную архитектуру, инструменты для локализации дефектов, какие виды тестирования вообще нужны). Напоминает, что «реальный опыт можно получить бесплатно». Я уже упоминала сервис uTest, помимо него Алексей добавляет Testbirds и полноценные программы бета-тестирования.
    Что касается превращения QA в тимлида, главную мысль автор формулирует кратко: «Важны не столько навыки, сколько черты характера». И это вполне коррелирует с моей мыслью, что по мере карьерного роста увеличивается степень ответственности, а с ней — и важность soft skills.

    «The state of soft skills» от «Конференции Олега Бунина»

    Этот пост мне нравится по-настоящему математическим подходом. По результатам исследования LinkedIn, 57 % всех опрошенных считают, что сейчас софт-скилы важнее, чем хард-скилы. Но автор провёл собственное исследование и составил формулу расчёта полезности навыков на основе индекса потребительской лояльности (Net Promoter Score) и цену развития навыка. Полученные результаты свёл в таблицу координат и получил дешёвые и бесполезные, дорогие и бесполезные, дорогие и полезные, дешёвые и полезные навыки. Получилось, что самый полезный навык — рефлексия. Затем идёт поиск и анализ информации, эмоциональный интеллект, многозадачность и убеждение. Свой успех на первом же интервью я приписывала своей красоте и обаянию, но по факту помогла честная рефлексия и умение аргументировать свою позицию.
    В итоге от любого подхода должны выигрывать обе стороны: и сотрудник, и работодатель. Система грейдов пока справляется с этой задачей, давая возможность привести к единому знаменателю усилия и оплату труда.
    Но рано или поздно всё меняется. И однажды может наступить момент, когда дальнейшее развитие карьеры в тестировании покажется бессмысленным.
    Мой коллега-разработчик сказал: «Если машина не делает то, что ты хочешь, сразу понятно, кто из вас дурак». Сколько раз я ощущала бессилие, проклиная день, когда села за баранку этого пылесоса, — пока не находила досадную опечатку в какой-либо строке… Поэтому я люблю ІТ: результат работы зависит от тебя.

    Пит-стоп: что означает желание уйти из тестирования

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

    Открываем новые трассы

    Бывших тестировщиков не бывает. Но из них могут вырасти хорошие:
    • Cистемные аналитики. Наконец-то можно отыграться за все неправильно составленные ТЗ :) Богатый опыт тестирования требований будет отличным фундаментом для работы аналитиком и облегчит вхождение в процесс.
    • Бизнес-аналитики. На этой позиции легко удовлетворить интерес к новым сферам, услышать заказчика, наконец понять, что ему действительно нужно, и сформировать грамотное представление о том, как сделать его мир лучше.
    • Менеджеры. Проектный, тест-менеджер и так далее. Отлично подойдёт тем, кто умеет брать, а главное, нести ответственность.
    • Разработчики. Внезапно можно обнаружить в себе потребность производить баги :) Полезно побывать с другой стороны рабочего процесса.
    И ещё две статьи, которые я бы рекомендовала для более чёткого понимания своих мотивов и карьерных желаний. Ведь даже если тестирование однажды разочарует, репутация (как результат хорошо выстроенной карьеры) всегда будет работать на тебя.
    Пример того, как можно разочароваться в профессии, если нет командной поддержки, аргументированной обратной связи и возможностей для движения вперёд. В этой истории хеппи-энд: девушка нашла компанию, где поддерживается дружественная атмосфера, есть пространство для горизонтального роста и сотруднику дают понять, что его труд важен и нужен.

    «Почему не надо бояться менять работу» — крутая статья о том, как принять необходимость перемен и понять, что пришло их время

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

    Финиш?

    Сейчас я мысленно качу на своей оранжевой Lamborghini, глядя прямо в закатное небо, под тот самый «рон-дон-дон» :) Этот тест-драйв мне нравится до сих пор, хотя я думаю, что он не может быть вечным.
    На финише поста я собрала основные чек-пойнты, которые будут полезны по мере прохождения карьерного трека:
    • Определись с тем, чего ты хочешь. На любом этапе найдутся бесплатные инструменты и множество возможностей для достижения результата.
    • Будь открыт всему новому и учись. В ІТ нельзя выучиться один раз и навсегда остаться на этом уровне. Команда/проект будет постоянно предлагать новые вызовы и задачи.
    • По мере развития цели и ценности как сотрудника, так и работодателя могут меняться. И это хорошо, поскольку означает достижение определённого уровня, который станет фундаментом для перемен к лучшему.
    • Регулярно (например, раз в год) ходи на собеседования — это даст более реалистичное понимание своей стоимости на рынке специалистов.
    • Вкладывайся в себя. Своё образование, баланс работы и отдыха, разностороннюю прокачку. Гармоничное развитие сделает тебя физически и ментально здоровым, а также расширит возможности карьерного роста.
    По сути, не так важно, кем ты хочешь быть в ІТ: тестировщиком, аналитиком, разработчиком или кем-то ещё. Лучшей мотивацией для входа мне кажется любовь, но, если эта любовь только к деньгам, а не к своей работе, будет в тысячу раз сложнее.

    Комментарии 9

      +2
      Кто играл в Need for Speed, угадает эту мелодию с четырёх нот: э‑рон‑дон‑дон…

      Справедливо только к NFS:Underground. Для человека, застрявшего на NFS5 Porsche Unleashed, это может и не быть истиной.


      А ещё я поймал NFSU за читерством, притерев в Enduro компа в столб на повороте в/из тоннеля, приезд в который игрока сбрасывает его скорость ровно в ноль — комп меня на этом же повороте обогнал по внешнему радиусу, и только через секунду где-то сбросил скорость, отработав столкновение. К вопросу о теме :D

        –1
        Кто играл в Need for Speed, угадает эту мелодию с четырёх нот: э‑рон‑дон‑дон…

        Первоисточник этого рэпового недотрека: The Doors — Riders On The Storm, 1971 год.
        Дальше не читал.
          +1
          Вы путаете, «рон-дон-дон» это не Riders On The Storm Snoop Dogg'а, а вот эти ребята
            –7
            Честно говоря, мне перпендикулярно.
            0
            Вы перепутали треки Lil Jon — Get low (из первой части NFS:Underground) и Snoop Dogg — Riders on the storm (из второй части).
              0
              Этот «рэповый недотрек»(Snoop Dogg & The Doors — Riders On The Storm) играет в основном меня, во время тюнинга и прочего. А «э-рон-дон-дон»- это Lil Jon & The East Side Boyz — Get Low
                0
                Вообще-то это Lil Jon, трек Get Low. А то, что вы назвали, полагаю, Snoop Dog, как раз с песней Riders On The Storm.
                  0

                  Вы имеете в ввиду ремикс Снуп Дога, а под э-рон-дон-дон подразумевается песня Lil' Jon & the Eastside Boyz - Get Low.

                  +1
                  У вас в разделе «Кто ты, QA-инженер или тестировщик?»: в продолжение темы дефиниций, повторяется два раза одно предложение «Хороший QA знает, что тестирование начинается...»

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