Home

Автор: Кудинов Илья, Lead QA Engineer, Badoo Development

Оригинальная публикация: http://habrahabr.ru/company/badoo/blog/345478/

Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик.
Все: Здравствуй, Илья!

Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.

О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…

Дисклеймер

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

Если вы со мной в чём-то не согласны — добро пожаловать в комментарии. Я всегда открыт к диалогу.

Про меня

Моя история как тестировщика началась в 2011 году. К этому времени я уже успешно бросил учёбу в МГТУ имени Н. Э. Баумана, побывал в армии и поработал курьером техническим специалистом. После всех этих приключений я искал работу программистом, потому что кое-что в этой области умел и мне это нравилось. Но из-за отсутствия высшего образования и, мягко говоря, небольшого официального опыта работы очередь из радостных работодателей за мной не выстроилась (по крайней мере, именно этим мне объясняли отказы). Поэтому, когда мне предложили «А давай ты поработаешь у нас тестировщиком веб-сайтов, и если всё будет хорошо, мы переведём тебя в программисты», я с радостью согласился. Спойлер: всё было хорошо, но программистом меня так и не сделали.

Всё начиналось очень скучно и обыденно. Я был единственным тестировщиком на семь программистов. Разработчики писали код на локальных машинах, скидывали его на тестовый сервер, просили меня его там потестировать, а потом вручную заливали код на продакшн (я наивно полагал, что все так делают). Что-то заливали на прод без моего ведома ( «Забыл сказать, извини!» ), что-то делали сразу на проде по требованию менеджмента. В общем, тихий ужас.

Спустя несколько недель я узнал про существование систем контроля версий. Мир перевернулся. Несколько людей могут работать над одним и тем же кодом, и это будет УДОБНО! Я прожужжал все уши начальнику и добился установки SVN. Всего через месяц после этого мы начали работать в ветках (!), заливать изменения на продакшн организованными протестированными пачками (!!) и даже заимели какое-то подобие расписания релизов (!!!). Когда я смотрел на это всё, у меня начало зарождаться ощущение, что разработка и тестирование — это не хаотичный процесс, у всего этого может быть какая-то организация. Почитать интернеты? Вы что, я был молод и горяч, мне было не до этого.

Итак, помимо тестировщика, я стал ещё и релиз-инженером. Работа стала более интересной и менее топорной. Из-за снижения уровня хаоса у меня появилось больше свободного времени, и я стал интересоваться, что же это за зверь такой — «Автоматизированное тестирование». Нашёл в интернете информацию о только-только вышедшем Selenium WebDriver, и мои глаза снова полезли на лоб: можно заставить программу ТЫКАТЬ КНОПОЧКИ НА САЙТЕ ЗА ТЕБЯ??? Воображение рисовало идиллическую реальность, в которой человеку не нужно заниматься регрессионным тестированием (нет, этого термина в тот момент я не знал). И я тут же начал тратить всё свободное время на разработку тестов. Честно говоря, написаны они были ужасно, но свою функцию выполняли.

К тому времени я работал в компании уже девять месяцев. И всё ещё получал свою изначальную зарплату ручного тестировщика (поверьте, она была не очень впечатляющей). Безумно гордившийся мной начальник повёл меня к руководству — выбивать повышение. Я рассказал о переходе к релизной системе и своих обязанностях в этой области, показал свои автотесты, рассказал о том, как они сокращают время на рутинную работу. И продемонстрировал, что количество ошибок, попадающих на продакшн, за последние полгода упало драматически. Я уже практически не хотел быть программистом!

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

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

Я начал снова искать работу. Разуверившись в тестировании, опять стал смотреть в сторону программирования. Даже успел получить оффер на позицию младшего С-разработчика в одной брокерской фирме… А потом мне позвонили из Badoo.

Про Badoo я впервые услышал буквально за несколько месяцев до этого — на мастер-классе Алексея Рыбака на DevConf 2012. Компания тогда моментально встала для меня в один ряд с Google и Facebook. Мне казалось, Badoo — это что-то невероятно крутое, куда я, простой смертный, никогда не попаду. Поэтому на собеседование я согласился исключительно ради опыта. Я ни на что не рассчитывал — просто излил Илье Агееву всю свою фрустрацию по поводу того, чего я хотел добиться и чего меня лишили. А через несколько дней я уже стал частью этой компании, которую, к слову, всем сердцем люблю по сей день.

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

Про индустрию

В первые дни работы в Badoo я испытывал культурный шок. И дело вовсе не в катающихся по офису на самокатах и кричащих во всё горло разработчиках. Хорошо, не только в них. А ещё и в том, что здесь старались организовать, оптимизировать и автоматизировать каждый шаг. Я подумал: «Так вот как должно быть!» — и всеми силами старался соответствовать: участвовал в разработке процессов и средств тестирования, неустанно искал места, где можно что-то улучшить.

А потом я начал ездить и рассказывать о наших решениях на конференциях. Боялся, что для всех всё будет очевидно — ведь все вокруг тестируют так же круто, как мы в Badoo! Но на деле…

Внушительная часть российских компаний, а особенно IT-департаменты крупных неайтишных компаний, видели процесс тестирования примерно так же, как мои предыдущие работодатели. Вопросы после докладов ставили меня в тупик.
«А как вы заставляете разработчиков писать тесты?»
«Как это, вы можете отложить релиз фичи? Вот прям достаточно баг найти?»
«Автотесты вы пишете сами? Если вы умеете программировать, почему вы не программист?»

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

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

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

Про путь тестировщика

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

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

Уровень 1. Почти тестировщик. Человек, которому доверили работу тестировщика и который пытается её выполнять. Не просто пользуется приложением, а настырно им пользуется. Иногда даже нажимает на одну и ту же кнопку несколько раз. Он всё ещё не обладает никакими навыками, в его действиях нет никакой системы — есть только желание найти баг. Либо чтобы не уволили с работы, либо из врождённой ненависти к несовершенствам — так сразу и не скажешь.

Уровень 2. Тестировщик. Понимает, что он делает. Может быть, прочитал пару книжек об основах тестирования. Берясь за каждую новую задачу, может построить план своих действий (либо прочитать документацию и следовать ей). Цель постепенно смещается от «найти какой-нибудь баг» к «контролировать качество продукта». Примерно на этом уровне я находился в свои лучшие дни на предыдущем месте работы.

Уровень 3. Продвинутый тестировщик. Действительно понимает, что он делает. Прекрасно знает проект и может проанализировать влияние на него тех или иных изменений. Может оценить, насколько тестируемый функционал соответствует остальному проекту не только в плане качества, но и в плане UX и прочих важных вещей. Может не только найти баги, но и предупредить возникновение ошибок в планировании и дизайне того или иного функционала.

Уровень 4. Инициативный тестировщик. Он не просто работает в организованной среде и процессах — он старается их улучшить. Цель из «контроля качества» превращается в «обеспечение качества». Развитие и разработка средств оптимизации и автоматизации, бесконечные идеи об улучшении рабочего процесса — вся эта прелесть начинается где-то здесь.

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

Уровень 6. Гуру-тестировщик. Как вы можете заметить, квалификация предыдущих уровней сильно завязана на проект. Переходя в другую компанию, а тем более на другой стек технологий, обычный тестировщик теряет часть своего профессионализма. Её придётся восстанавливать. Гуру-тестировщики же смотрят на вещи с более высокой точки. Они могут в кратчайшие сроки разобраться с любой системой, найти как явные, так и скрытые связи между компонентами за счёт своего опыта и понимания работы IT-систем (и IT-специалистов). Волшебные люди. Вот бы мне так.

Но постойте же, это всё про самостоятельное тестирование! Разве тестировщик не имеет возможности за счёт своего развития стать руководителем? Конечно, имеет. Но это требует целого набора других качеств и навыков, которых у него может и не быть. Не каждый хороший тестировщик может стать хорошим тест-менеджером. Однако, я твёрдо уверен в том, что каждый хороший тест-менеджер обязан быть хорошим тестировщиком.

Про навыки хорошего тестировщика

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

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

А вот те определяющие качества, которые вижу я:

• Любовь к тестированию. Да, к тестированию вообще. Не нужно считать тестирование побочным занятием в IT, не надо мечтать сбежать в разработку или руководство — надо в первую очередь получать удовольствие от работы. «Это относится вообще к любой специальности, спасибо, кэп!» — скажете вы и будете правы. Однако это не делает данный пункт менее значимым.
• Любовь к проекту. Вы не будете радеть за качество проекта, на который вам наплевать. Даже если вы будете исправно делать свою работу (деньги же надо как-то зарабатывать), вы будете закрывать глаза на замеченные вне своего компонента недостатки («Не моё дело, да и вообще проблема на вашей стороне»). Вы не будете предлагать улучшения и проявлять инициативу («Если полить г**но одеколоном, оно будет пахнуть как г**но под одеколоном!»).
• Знание проекта. Очень красивая кнопка! Прям как в ТЗ написано! И делает она всё, что от неё требуется, замечательная кнопка! Очень жаль, что она выглядит совсем не так, как все остальные кнопки на сайте, ломает шесть критических фич и вызывает Сатану в профиле пользователя. Но откуда мне было про это знать?!
• Понимание технологий проекта. Нет, не обязательно иметь возможность самостоятельно переписать весь проект с нуля, только лучше. Но хотя бы в общих чертах понимать, КАК работает то, что ты тестируешь, просто необходимо. Это позволяет находить неочевидные баги, делать подмены кода для воспроизведения тех или иных кейсов и видеть дополнительные зависимости внутри проекта.
• Соблюдение баланса между качеством и скоростью. Качество не бывает абсолютным. Каждая единица времени, которую тестировщик проводит за задачей, теоретически приближает её качество к асимптоте в 100%. В какой момент нужно остановиться? Всё зависит от проекта. Если на вашем софте будут летать самолёты с сотнями пассажиров, не стоит жалеть на тестирование ещё час-другой. А если вы разрабатываете проект с несколькими релизами в неделю и возможностью доставлять патчи пользователям за секунды, можно остановиться и раньше. Нет, я не поощряю выпуск багов на продакшн — просто скорость развития проекта иногда бывает важнее. Можно прочитать это качество как «Умение ориентироваться в приоритетах бизнеса».

Совсем же не необходимыми я вижу следующие часто приписываемые тестировщикам качества:

• Перфекционизм. Ненавидеть баги и несоответствия — это хорошо. Зацикливаться на этом — плохо. Будет страдать скорость тестирования, а требования менеджера выпустить недотестированный функционал будут вгонять в депрессию. Тестировщики софта для самолётов, не слушайте меня, будьте перфекционистами! Пожалуйста.
• Любовь к бюрократии. Ах, тестовая документация. О ней уже столько рассказано и написано, я и сам рано или поздно доберусь до этой темы. Сейчас же ограничусь тем, что скажу, что эффективное тестирование бывает и без подробной всеобъемлющей тестовой документации при условии наличия толковой технической документации. Честное слово!
• Радость от нахождения бага. Нет, хвалить себя за хитровыдуманный кейс, который сломал систему, — это нормально. Любить себя тоже надо. Но это не самоцель — не нужно надеяться на ошибку в каждой попавшейся задаче, не нужно глумиться над разработчиками, которые пропустили баг, и чувствовать своё превосходство, когда вы нашли неточность в компоненте, уже проверенном вашим коллегой. Гораздо лучше радоваться тому, что задача уехала на продакшн без ошибок и в срок. Вот это — ваше настоящее достижение, даже если вы ни разу не переоткрывали задачу.

И в заключение…

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

Обсудить в форуме