Меню
Войти
Первую в жизни программу Тимур Хайруллин написал в 1984 году, на зелёном мониторе компьютера «Д3-28». Через двадцать лет он начал — шаг за шагом — обустраивать русскоязычную индустрию тестирования ПО.
А к 30-летию той первой программы Тимур рассказал Смартии о жизни тестировщиков и о том, как он был первым пользователем сервисов Яндекса и «ронял» весь Яндекс одним нажатием кнопки.
Хакерство вместо китаеведения
— В 1991 году я закончил школу и собирался поступать на открывающуюся кафедру синологии и китаеведения истфака Казанского государственного университета. Но кафедра так и не открылась, пришлось поступать на ВМК («вычислительная математика и кибернетика»).
Папа мой работал в Институте математики и механики, где считали всякое: крыловые профили, фильтрацию жидкостей и газов в движении, параметры взрывов. Он — основатель и главный теоретик плотин на Рогунской и Нурекской ГЭС, например. И ему приходилось время от времени прибегать к этим самым ЭВМ'ам. Так я познакомился с Д3-28 и прочими страшными аббревиатурами. Стало интересно — и понеслось, и покатилось.
Ультравинтаж: «Электроника ДЗ-28»
В том же 1991-м, уже обучаясь в университете, я преподавал основы программирования деткам в Малом университете, была такая подготовительная школа перед поступлением в ВУЗ. И работал в одной конторе «эникейщиком». Контора торговала всем подряд, компьютерами торговать по объёму было выгодно, поэтому они гнали в Москву фуры, затаривали компьютерами и везли обратно с какими-то охранами, с какими-то бандитами. А меня брали, чтоб я проверял товар. «Это нормальные компьютеры, слышь?». Классическая история из 90-х.
1992. На меня напал модем на 2400 бит. Вместе с университетскими друзьями занимался, извините, хакерством на ЕС-1046 (советский аналог IBM 370). Часть друзей даже устроилась в вычислительные центры при университете, чтобы хакерствовать более-менее легально. И вот туда приволокли первую интернет-ветку во всём Казанском университете. Большой университет, третий вуз по размеру на тот момент, и вот Интернет: 9600/4800 на весь университет.
Фидо, news-группы какие-то, РЕЛКОМ — сойти с этой дорожки было уже невозможно.
1994. Продолжая учиться на дневном отделении ВМК, я работал в банке «Заречье», в «группе передачи данных». Банк общался с внешним миром, прости Господи, через SWIFT, X.25, X.400, филиалы часто выходили на связь по каким-то витым парам, черт знает как положенным по крышам, железным дорогам и подвалам.
1999. Меня позвали делать первый в Москве коммерческий провайдер домашнего интернета TOR-Info. Не «домашние сети», очень тогда популярные, а именно сети коммерческие. Проект был достаточно успешен технологически, из него вырос Netbynet, позже проданный Мегафону.
Уйдя оттуда, я ещё поболтался возле телекома, а потом почти случайно попал в тестирование: товарищ позвал строить с нуля команду тестировщиков, я повёлся и пошёл. Влез в эту историю, собрал команду, а потом её продали вместе со мной в большую контору — RTSoft. Тогда они занимались железом со встроенным Линуксом, в первую очередь для госзаказов: на какие-то производства, предприятия, ГЭС они ставили свои хитрые железки.
А еще там аутсорсили разработку и тестирование для одной американской компании.
Хорошо помню один трёхсторонний meeting. Заказчик сидит в Японии, PM сидит в Штатах, мы — в Москве. Единственное время, в которое можно нормально общаться — четыре утра по Москве.
Посидев в RTSoft полтора года, я плюнул и ушёл в Яндекс.
«Почему у меня ничего не работает?»
Когда я впервые оказался в офисе Яндекса, там работало, может, 40 человек. Точнее, в тот момент они не работали, а праздновали — приближался 2002 год, и я заявился с бутылкой вина, потому что там был мой школьный друг Бацек, он же Василий Чекалкин. Я когда-то притащил его в Москву, потом подтолкнул пойти на собеседование в Яндекс, и он там построил внутреннюю коммуникационную архитектуру, на которой работали почти десять лет.
И когда я на ту новогоднюю вечеринку пришел, меня разве что не ощупывали: «Первый живой пользователь Яндекса, ааааа!». Потому что жили мы с Бацеком в одной квартире, и с 2000 года я действительно был первым — после разработчика — пользователем Яндекс.Народа, Яндекс.Почты и других сервисов. Он что-то лабал, подзывал, показывал: «Посмотри, как тебе?».
Путь от «первого пользователя» до сотрудника Яндекса, занял еще несколько лет.
В 2005 году их штат составлял уже человек двести, но тестированием создаваемых продуктов не занимался никто. Вообще никто. И Бацек позвал меня стать первым тестировщиком, «инженером по тестированию», если официально.
В первый же рабочий день случилась история из сборника «Карма Тестировщика»
Мне выдали компьютер. Новый, из коробки. И диск с операционной системой Debian, взятой «у производителей» — с ftp.debian.com. Начинаю ставить Debian — не ставится. Компьютер говорит: «А у тебя жесткого диска-то нету». Разбираю машину, лезу в BIOS — диск есть. Оказалось, что драйвер контроллера IDE на этой конкретной машине видит либо CD-привод, либо жесткий диск. Я их попытался рассадить на разные контроллеры — никак. Или операционка, или место, куда её можно ставить, выбирай.
Взяли мы этот драйвер, сели с Бацеком и кем-то ещё, расковыряли драйвер, попатчили, засунули на дискету. В момент, когда загружается CD, подменили этот драйвер и кое-как поставили систему. Начали с шутками и прибаутками, продолжили уже с матюками, закончили только на следующий день. «Вышел тестировщик на работу».
«-24 — это якобы значение «кармы» настоящего тестировщика. Эту штуку в 2006 или 2007 году мне подарили команда Яндекс.Карт и Маша Лауфер, руководитель этой команды».
Поначалу никто из нас не понимал, что нужно Яндексу конкретно в условиях Яндекса и как это делать. Но у всех было ощущение, что «пора, надо, уже надо». Что-то невербальное: даже нельзя было это ощущение сформулировать. И мы начали ковыряться, ставить всякие эксперименты, подбирать инструменты... ручное тестирование, полуручное тестирование, какая-то автоматизация... Наняли человека, выгнали человека, запустили Яндекс.Карты, запустили Яндекс.Новости. Куча багов, куча исправлений, куча факапов и странных случаев.
2006. Компания Borland резко закрывает свой офис в Питере, на обломках Борланда остается человек 60 разных ребят. Часть мы подобрали, так появился питерский офис Яндекса. Как раз там набирали тестировщиков, и я этот эпизод хорошо запомнил. Потому что вечером приехал в Шереметьево, там выяснил, что отравился; всю ночь не спал, утром улетел в Питер и в понятно каком состоянии провел за день девять (!) интервью с кандидатами.
Другой эпизод — когда я в одиннадцать вечера при нагрузочном тестировании ошибся ноликом в большую сторону и положил весь кластер. Упала «морда» Яндекса, и остальное эффектом домино — «бум-бум-бум-бум-бум». Прибегает Волож: «Ааааа! Почему у меня ничего не работает?». А я в ответ: «Щас-щас-щас-щас!».
«Очень неприятно случился запуск одного из сервисов, когда мы пропустили баг производительности. В момент, когда открылись на публику, всё легло. Весь интернет увешан баннерами «У Яндекса новый проект», Лента.ру про него пишет, ещё кто-то пишет, заходишь — а проект валяется в пятисотке. Возможно, это отчасти послужило причиной его скорой смерти».
Светлые, Тёмные, разнообразные
Как правило, «тестировать» означает «верифицировать» — подтверждать, что заявленная функциональность исполняется так, как она заявлена. Или не исполняется. Но между разными «тестировщиками» полно различий.
Англоязычное название этого умения — test management.
По предметной области бизнеса. Тестируют и программы, и автомобили, и медтехнику, и много чего еще. Я люблю собирать «лучшие практики»: мы в софтвере вообще-то не знаем, что делается в автомобилях, но если туда внимательно посмотреть, можно утаскивать к себе хорошие идеи. Но и софтвер, тестирование программного обеспечения (ПО), тоже заставляет погружаться в предмет: работаешь с 1С — углубляешься в складские темы, возишься с программами для вертолетов — изучаешь вертолеты.
В «продуктовой» компании или в «аутсорсинговой». Одни делают (и тестируют) свои продукты программные, другие — разрабатывают ПО на заказ, по сути торгуют человеко-часами, сдают в аренду головы своих сотрудников. Лет пять назад мы делали доклад про Светлую и Тёмную сторону разработки. Шоу-терминология такая.
У Тёмной стороны — аутсорса — свои цели и задачи, они немножко ортогональны процессам в продуктовом девелопменте. Нужно в срок распилить максимум денег, затратив как можно меньше усилий. А что на самом деле происходит с продуктом разработки, исполнителей часто не волнует. Это же не их продукт! Как заказчик им будет пользоваться, насколько велика стоимость сопровождения потом — это, в целом, похрену.
Особенно если заказчик за сопровождение им и платит — тогда аутсорсеру невыгодно делать сопровождение дешевым.
Как это может выглядеть? Вот сейлы, например, продали какой-то большой заказ, и под это дело спешно — ААААА, БЫСТРЕЕ! — набираются шестьдесят человек. Неважно, какого качества, но чтоб они начали педалить, чтоб прошёл первый транш. Закончился проект — люди засунули палец в нос и сидят на пособии по безработице. Или их вообще увольняют. Или перебрасывают на какой-то унылый проект, на котором никто не хочет работать.
Классический пример — это Luxoft. Luxoft работает на нескольких больших заказчиков и вагон маленьких. Больших — в смысле, Boeing, например. Или Deutsche Bank. Реально крупные проекты, которые длятся десятилетиями. А маленький проект, «Сбертех» какой-нибудь, быстро заканчивается и закрывается. Соответственно, там очень высокая ротация между проектами (обычно подневольная), так что тестировщику не удаётся углубиться в предметную область вглубь, зато удаётся много нахватать вширь. «Ага, мы работали вот на таком проекте, там примерно то-то происходило, помню. Если надо, я нужное доучу в процессе».
В аутсорсе больше возможностей попробовать разное. Это плюс. Минус: нельзя задержаться там, где понравилось. Полгода поработал на проекте — проект кончился, команду расформировали, тебя перевели.
Хотя и в продуктовых компаниях бывает проектное направление, которое предполагает кучу разных проектов и ротацию между ними. То есть чуваки собрались, проект сделали — разбежались. И говорят: «Нам было приятно вместе работать, у нас будут ещё вот такие проекты, хочешь — давай дальше работать с нами. Не хочешь — найдем другого». Есть возможность выбирать, с кем работать.
В Яндексе я прикоснулся ко всем продуктам Яндекса, потому что отдел тестирования там как бы перпендикулярен продуктовым отделам. Например, несколько команд делают Яндекс.Музыку. И вот сбоку туда внедряется нагрузочный тестировщик, какое-то время с ними работает, а потом убирает руки. И у него таких проектов единовременно, скажем, дюжина.
По предметной области софта. И продуктовые компании (ребята в Касперском или Яндексе), и аутсорсники разделяются ещё и по критерию «в какой предметной области софтового девелопмента работают». Java, высокие нагрузки, говносайты на php, сложные встроенные разработки... очень много вариантов. Это сильно влияет на выбор скиллов тестировщика. В ситуации «требуется тестировщик, хорошо умеющий читать java-код» мне, конечно, нафиг не нужен тестер, знающий только php: продукт-то на джаве.
Отмечу, что в разных конторах — разные процессы разработки и разные ритуалы приседаний. Тестировщик в одной конторе делает верификацию + какой-то Y, а потом переходит в другую контору, где делают верификацию + какой-то Z. И переучивается. Вокруг тестирования накручено много попутного газа, и этот газ везде разный — то ли сожалению, то ли к счастью.
По видам тестирования. Когда я провожу собеседования, то иногда заканчиваю их так. «А теперь мы играем в игру. Я засекаю две минуты, а вы называете всё, что может создать сочетания вроде «???? тестирование» или «тестирование ????» — виды тестирования, типы, названия всякие. Если такая штука действительно существует, я загибаю палец. Поехали!».
Называют в среднем от 10 до 18 штук. А я сообщаю, что проходной балл — 30 и, «знаете, а ведь маловато у вас...» Потом говорю: «Шутка!».
«Шутки шутками, но эта игра позволяет очень хорошо оценить профессиональный кругозор кандидата».
Общепринятых строгих классификаторов для видов тестирования не существует. Можно выделить ключевые направления.
Функциональное тестирование — тест на соответствие требованиям. Заявлено, что должно работать вот так, проверяем, что действительно работает вот так, а не иначе. У тебя есть калькулятор, ты вводишь «2+3» и должно получиться пять. А если пытаешься «2++3» сделать — должна получиться ошибка.
Нагрузочное тестирование — большой кластер, в который входит тестирование производительности, тестирование стабильности, объёмное тестирование, тестирование отказоустойчивости, стресс-тестирование, приёмочное и исследовательское оценочное тестирование и много ещё чего. Это про много операций, много транзакций, много пользователей, большие объёмы информации под ногами. Разрабатываются отдельные специальные требования, которые называются «нефункциональными требованиями», в том числе требования по производительности и требования по объёму.
Пример: интернет-магазин. Сто пользователей. Тысяча товаров. Приходит каждый день сто пользователей и в этой тысяче товаров выбирают. И вдруг: «Ура, мы заключили новый контракт! У нас теперь не тысяча товаров, а десять тысяч». Без предварительного нагрузочного тестирования вы заметите, что магазин стал «тормозить» уже тогда, когда с этим столкнутся пользователи.
Автоматизированное тестирование. Этот раздел ортогонален предыдущим. Часто тестировщиков делят на ручных и автоматизированных. Есть целая куча разнородных инструментов для автоматизации работы тестировщика. Примерно все они сводятся к «выполнить какое-то действие и сравнить результат этого действия с эталоном». Автоматизированные тестировщики — и тестировщики, и программисты, потому что вся автоматизация — в той или иной степени программизм.
Тестирование юзабилити. Вплотную примыкает к «управлению качеством» (quality assurance) — деятельности, которая даже шире, чем тестирование. Здесь очень много психологических нюансов, эргономики, каких-то абсолютно неформализуемых критериев.
Интеграционное тестирование. Окей, мы разработали, собрали, потестировали и пофиксили баги в разных частях нашей огромной информационной системы. Причём обычное дело, когда эти части являются самостоятельными продуктами и выполняют свою собственную бизнес-задачу. А теперь нам нужно проверить, будут ли эти разрозненные части общаться друг с другом без ошибок. Это, пожалуй, один из самых сложных разделов тестирования, который требует широчайшего кругозора и максимум координации.
Конфигурационное тестирование. Проверяет работоспособность продукта в условиях большого разнообразия окружений. Самый яркий и больной пример из современности — программы на Андроиде. Куча версий операционной системы с разломанной обратной совместимостью, огромная прорва устройств с разными характеристиками, масса различных экранов (диагональ, соотношение сторон, разрешение) — всё это нужно поддерживать или хотя бы представлять, как программа поведет себя в таких условиях. А есть ещё соседи: антивирусы, оболочки, моды, разные менеджеры памяти и прочие любители вмешиваться.
Тестирование безопасности. Смысл его в том, чтобы при любых действиях пользователя или злоумышленника наша информационная система отвечала нескольким критериям. Во-первых, мы не должны показывать данные тому, кому не положено их видеть: сохраняем конфиденциальность. Во-вторых, мы должны заботиться о целостности данных: даже если они не видны, они могут быть испорчены. В-третьих, мы должны сохранять работоспособность и доступность продукта при любых нештатных ситуациях и самых невероятных сценариях использования.
Яндекс.Финиш
Итак, я занимался тестированием производительности в Яндексе и растил группу, которая вскоре стала «отделом системного тестирования». Мы тогда даже троллили питерскую группу функционального тестирования, называя её отделом бессистемного тестирования.
«Системное тестирование» — это когда мы берём и проводим целый комплекс всяких испытаний, как функциональных, так и нефункциональных. Можно сказать, что это название области, собравшей не очень привычные методы обеспечения качества. Например, тестирование производительности ребята до сих пор делают не в первую очередь. И я пытался объединить такие вещи, которые делаются не в первую очередь, под одной крышей — чтобы мы о них тоже не забывали.
В 2007 году я осознал, что людей на рынке «тестирование и производительность» нет вообще. И пошел этот рынок строить.
Поговорил на конференции с ребятами из Google, мы с удивлением обнаружили, что вещи называем одними и теми же словами, действуем примерно в одном направлении. Потом пришел на первую конференцию HighLoad, прочитал доклад, ещё где-то засветился, начал нести в массы, что называется, язык предметной области. «Ребята, вот эта штука называется вот такими словами».
Через пару лет начал пожинать плоды: во-первых, появилось больше людей, которые этим занимаются, во-вторых, эти люди разговаривали примерно на одном языке — на том, который я придумал. И это было очень полезно, потому что можно их нанимать, и при этом не нужно вводить их в профессию. Появились специалисты, которых можно быстро встраивать, и потихонечку у нас выросла команда по тестированию производительности, самая крутая — без шуток! — во всём русскоговорящем софтварном девелопменте. А может быть даже и самая крутая в Европе.
В 2012 году я понял, что есть два пересекающихся круга — вещи, которые я умею, и вещи, которые мне интересны. А третий круг — вещи, которые от меня нужны Яндексу, — с ними не пересекается вообще никак.
И мы с Яндексом расстались к вящему обоюдному удовольствию, со взаимными поцелуями в рот и с пониманием, что у нас дальше разные пути.
Большая часть того, что я построил — работает до сих пор и будет работать ещё: предметная область создана, процессы выстроены.
Мой отдел системного тестирования аккуратно разобрали на запчасти, людей оттуда или высадили в выделенное «тестирование производительности», или распихали по разным другим командам. Внутреннее бета-тестирование спорной функциональности закрасили полностью — руководители проектов и продуктов посчитали, что оно им не нужно.
А я уехал отдыхать в Черногорию — потому что был выжжен полностью.
Лес подпорок на подпорках на подпорках
Моя любимая тема — управление качеством в софте, так называемое quality assurance. Рядовой тестировщик — это обычный землекоп, задача которого — верифицировать. Он берет кусок, читает, как кусок должен работать, исполняет сценарии работы, ставит галочку, берет следующий.
«SQA Days — единственная на русскоговорящем просторе профессиональная конференция, которая специализируется на quality assurance, тестировании и смежных областях».
А quality assurance — намного шире и глубже, потому что подразумевает предотвращение дефектов. Допустим, мы родили идею, продукта нет, ни строчки кода нет, но уже пора заботиться о том, чтобы предупреждать какие-то дефекты всех уровней.
Дефект в разработке — это ерунда: баг, посаженный разработчиком и пойманный в тот же момент, — дешевый. Баг, посаженный в требования, — «так, у нас эта кнопочка должна называться вот так вот» — гораздо дороже. Если идти по этапам software development cycle назад-назад-назад, это удорожание примерно x10 на каждом шаге. Если 10 долларов стоит поправить баг в разработке, то 1000 долларов стоит поправить баг в требованиях.
И на следующем своём месте работы, в «Ламоде», я сознательно пошел на эксперимент.
Сразу сказал: «Не хочу называться никаким директором, не хочу вот этого всего блестящего, а хочу попробовать построить процесс управления качеством в отдельно взятом департаменте».
Я пришёл, когда в IT-департаменте народу было в районе 50 человек всего. Вся офисная жизнь в Ламоде сосредоточена в Москве, а в других городах и странах — только обеспечение операционного процесса, транзитные склады, службы доставки, вот это вот всё. За исключением офиса разработки в Вильнюсе, где дюжина человек сидит, в том числе два мульти-тестировщика.
Часть lamoda.ru, которую видит пользователь, — это 10% всех айтишных систем компании. Вершина айсберга. Основная жизнь сосредоточена внизу, под водой. Там — эпических размеров система обеспечения склада: хранение, приёмка, отгрузка, транспортировка, разбор инцидентов. По автоматизации это один из самых крутых складов в рамках Москвы и Московской области.
Там ходят люди-робокопы с компутерами, к которым присобачен сканер штрих-кодов.
Простой алгоритм работы picker'a, собирающего посылочки, выглядит вот как. Он приходит в специальное место, считывает штрих-код со стенки, говорит: «Пиик!», ему сообщают: «Возьмите тележку №84». Он находит и берёт тележку 84, на ней наклеен штрих-код. Он говорит: «Пиик!». «Ага, взял тележку 84? Молодец, дуй на четвёртый этаж». Он заталкивает тележку в лифт, идет на четвёртый этаж, достаёт тележку из лифта и чекинится на четвёртом этаже: «Пиик!». Ему говорят: «Ага, молодец, ты на четвёртом этаже. Бери тележку и неси свою задницу в ряд №15, там полка №70, позиция №122. Он приходит туда: «Пиик! Я на месте». Говорят: «Достань оттуда жёлтую футболку, пикни на неё и положи в тележку». Он это проделывает. Говорят: «Молодец, теперь твой ряд — №28».
Тележка заполняется — говорят: «Молодец, давай на консолидацию». Так picker ходит всю восьмичасовую смену и, значит, пикает по разным местам. Точнее, их ходит несколько десятков, в тяжелых случаях — пара сотен. В день приезжает несколько фур с барахлом, их надо разгрузить и все вещи принять.
Есть у нас контракт на поставку из, не знаю, Германии 200 пар кроссовок Nike рыжего цвета. Начинаешь их принимать: открываешь коробочку — кроссовки на месте, окей, закрыл коробку, наклеил на неё стикер, отправил. Это значит, что специальный чувак с таким же компьютером получает указание положить её на четвёртый этаж на место номер такое-то. И, соответственно, каждая кроссовка лежит на своём месте. И так принимаются 198 оранжевых кроссовок и ещё 2 серые. И ещё одни синие. И одна из оранжевых кроссовок продолбана, нет её в коробке. Ещё одна повреждена.
Включаются разные процедуры, c одной компанией мы эти остатки просто принимаем на склад и говорим: «Окей, это тоже продадим», а кому-то сообщаем: «Эта пересортица не нужна, забирайте её обратно», кому-то: «Эта пересортица будет валяться на складе до тех пор, пока мы её не выкинем, верните деньги».
Отгрузка — отдельная история, каждый день в 20 городов Российской Федерации улетает 20 самолётов с разными грузами.
И я был потрясён тем, насколько из глины и палок было сделано техническое обеспечение всего этого. В некоторых местах даже и палок не было.
Специалист по quality assurance моделирует ранние стадии проекта ёлки.
Три года назад ламодовцы приехали вчетвером из Германии. Им дали с собой несколько коробок: одна коробка — это интернет-магазин, вторая коробка — это склад и т.д. Открываешь, запускаешь, всё как-то работает. Некоторое наследие тех коробок используется до сих пор и будет использоваться ещё долго. Но когда ты перестаёшь продавать 100 пар обуви и начинаешь продавать 300 пар обуви и шмотки, и майки, и аксессуары, и ещё что-то, те коробки уже не годятся.
Можно брать и аккуратно рефакторить, смотря вперёд, а можно устанавливать везде подпорочки какие-то. Когда я пришёл, то увидел лес подпорок на подпорках на подпорках.
Захотелось, чтобы это заработало по-человечески, потому что тогда работало, скорее, по недоразумению и вопреки всему.
Получил в руки готовую команду тестирования, месяц понаблюдал и начал потихонечку действовать.
Очень многое получалось сразу. Опыта много, приходишь и говоришь: «смотрите, делайте вот так и будет хорошо. Я вам помогу, рядом постою, плечом подопру, если надо». Приходишь, подпираешь и сразу, вот моментально видны улучшения: тут поскрёб, там протёр — засияло. Процесс-то был очень невзрослый и хаотичный. Настроили релизный цикл — стало лучше. Начали регулярно делать оперативное планирование —стало еще лучше. Какие-то простые практики приносишь, вводишь и становится хорошо.
Какие-то вещи вводились быстро, какие-то — медленнее, но за полтора моих года в Ламоде процессы явно улучшились. На этом я эксперимент закончил и уволился весной 2014, так как стало понятно: я опять делаю штуки, у которых нет явного заказчика. Высший менеджмент компании считает важными другие вещи. А с позиции уровня middle невозможно управлять качеством, и при устройстве на следующую работу я это учту.
«Я бы эту карьерную лестницу демонтировал»
Если вернуться от необъятного quality assurance к собственно тестированию, то карьерный рост для тестировщика — не обязательно вверх по иерархической лестнице. Я бы эту лестницу вообще хотел бы демонтировать, если честно. На мой взгляд, идеальный рост для тестировщика — это рост в экспертизе тестирования. Прокачивать свои тестировочные скиллы: учить новые языки, учиться преследовать баги... «Вот у меня такое приложение, я знаю, где может баг спрятаться, и когда увижу новый билд, сразу на реестр ткну сюда и сюда — и сразу всё пойму».
Почему я против роста вверх? Потому что много лет наблюдаю, как из хорошего технического специалиста человек превращается в плохого руководителя.
И очень редко при переводе человека из технологической работы в управляющую ему его руководство объясняет, что задачи сильно изменились теперь. «Ты яму копал, да? А теперь, чувак, ты — резчик по стеклу. Все твои навыки копания ям тебе, может быть, пригодятся, но работа совсем другая теперь, учись резать стекло».
Тестировочной магии, на самом деле, очень много разной. Я всю жизнь стараюсь из тестировщиков готовить больше, чем тестировщиков, то есть, ребят, которые могут взяться и подставить плечо руководителю проекта, а иногда его и заменить. Аналитика заменить, руководителя проекта заменить, организовать что-то, сказать «Ребята, собираемся каждый день на пять минут». Вот, весной на конференции в Новосибирске я слышал реплику: «Из тестировщиков получаются отличные менеджеры проектов и отличные программисты...»
Есть сценарий похуже: когда сразу рассматривают работу тестировщика как входной билет в IT, в разработку. «Посижу год тестировщиком, а потом меня возьмут в менеджеры проектов или в программисты». Это, как правило, означает: «я — х..вый программист, в программисты меня не берут, пусть возьмут в тестировщики хотя бы». Из таких людей, конечно, и тестировщики получаются х..вые.
Не все землекопы одинаково хороши.
Профессии пока не хватает престижа, чтобы приходили не только новички, чтобы топы технологических компаний не думали, что зайца можно научить курить, а бабушку можно быстро научить нажимать на кнопки и тестировать. Многие руководители предпочитают на тестерах экономить. При том, что мы сейчас находимся на переднем крае демографической ямы и весело съезжаем по краю ямы вниз и вниз.
Молодых, весёлых, мотивированных, желающих развиваться — вообще нет. Я по 6-8 собеседований в неделю в Ламоде проводил, часто приходили натурально животные какие-то. В какой-то момент пришлось стукнуть кулаком по столу и сказать: «Больше не берём на уровень junior! Вообще». Потому что некогда развивать, растить этих junior'ов, без того все заняты текучкой по уши. Я бы с удовольствием набрал молодежи и прикрепил к команде серьёзных ребят, чтоб активно росли. Но ресурсов на инвестиции в рост junior'ов — не было.
«Разумно сомневаться — редкое качество»
Что важнее всего в работе?
Упорство. Тестировщикам-верификаторам доставляет особое удовольствие найти ключевую проблему, root cause. Это называется «баг хантинг» в моей классификации, когда человек преследует дефект до причины его возникновения. «Окей, у нас вот здесь ошибка, на самом деле это потому, что... а вот те синтегрировались, а вот эти налажали»... И в конце цепочки берёшь биту, идёшь и добиваешься, чтобы именно исправили причину, а не замазали поверху.
Терпение, но не терпимость. Позиция «моё дело маленькое» тестировщикам мешает. У хорошего тестировщика — всегда активная позиция и прокачанный критический подход. В смысле не «постоянно критиковать», а, в первую очередь, сомневаться. Уметь разумно сомневаться — это довольно редкое качество. «Раз уж разработчик сказал, что там ничего не менялось, то ОК» — классическая история, да? «Да нет, минуточку, — говорит опытный тестер, — подождите. А если мы вот так вот...». И ага, баг.
Коллектив единомышленников вокруг, довольные клиенты, отличный климат в семье, быстрое гашение конфликтов… Учитесь убеждать — и заполучите всё, что вам понадобится.
Хороший коммуникационный скилл. Устный и письменный, потому что тестировщик часто является клеем между разными другими группами, процессами и держателями разных интересов. Важно уметь доносить свою точку зрения: «Ребята, смотрите, это действительно баг».
Сохранять спокойствие. Бывает, оказывается, в какой-то момент, что усилия тестировщика ортогональны общему направлению деятельности компании и часть этих усилий просто выбрасывается в помойку. Я сам такого очень не люблю, может сильно демотивировать. Хорошо, когда вся команда продукта (это обычно 5-20 человек) хорошо понимает, что они сознательно идут на «ладно, у нас тут баг, жёваный стыд, страшно с этим запускаться, но придется». Тогда тестировщик, ощущая себя членом команды, понимает свой вклад и осознаёт, что беда — общая.
Но это зависит от профессионализма PM'а и руководства. С чем у нас большие проблемы везде. Поэтому «зря делал» — главная жалоба тестеров. Важно не принимать близко к сердцу все командные выплески. Важно продавать свой результат — это всех касается, но тестировщики часто продавать не умеют.
Внимательность. Однажды в Яндексе один байт, один лишний байт в коммите положил нам кластер из нескольких сотен машин. Положил так, что мы не могли даже в логах эту ошибку увидеть, пришлось делать следующее: засунули перед этим кластером проксю, на ней собирали логи и пытались сопоставить эти логи с моментом падения машины в кластере. Нашли, и это оказался пропущенный знак >. До двух ночи ловили эту херню, потому что весь коммуникационный кластер Яндекса не работал. Внимательность, усидчивость — качества, которые, по-моему, невозможно натренировать.
Умение считать. Что значит «тренированный тестировщик производительности»? Как-то рассчитывали нагрузку на один из сервисов: cколько народу придёт из Петербурга и Ленинградской области? Тестер засел за исследование, посмотрел, поприкидывал, посчитал ручкой и за полчаса выдал цифру в районе 1700000. На следующий день запустились, подкрутили, посчитали — он ошибся на 81 хит!
Непрерывное образование. Есть входной минимум про сети, про архитектуры, про принципы разработки, про какие-то языки программирования, про то, как что происходит. Но даже входной минимум постоянно меняется. Android прибавится, Nokia убавится. Если ты не смотришь на происходящее в мире, ты свою квалификацию теряешь. Жизнь меняется, причём иногда очень быстро и в рамках одной компании. «Мы от этой схемы маршрутизации заказов отказываемся и притащим сюда новую маршрутизацию от другого поставщика». Человек выходит из отпуска: «Как, бл...?! А вот было же... вот мы же привыкли так приседать!» — «Нееее, чувак, теперь всё по-другому». Меняются железки, процессы, приоритеты, надо всегда держать нос по ветру.
«Лучше не знать, как делается программное обеспечение»
Мои приключения с установкой Debian — это не уникальный случай. Обычно тестировщик поднимает руку — и мир вокруг рушится.
Опасный момент!
Я на собеседованиях спрашиваю «Когда последнюю чашку разбили? Что у вас вокруг происходит?». На той же конференции в Новосибирске прихожу в зал, там идет третий доклад за день. Руку поднимаю: «Дайте мне микрофон, я задам вопрос». Дают один микрофон, он не работает. Продолжаю: «Ну, дайте другой». Мне дают второй, и он тоже не работает. И они там спешно: «Батарейки нормальные же! Чего вообще?». В итоге мне принесли микрофон докладчика, я задал вопрос, унесли обратно. Такие истории про карму тестировщика происходят постоянно.
Экспресс-доставка тестировщика не похожа на экспресс-доставку здорового человека.
Многим наша работа добавляет фрустрации. «Сотрудники Luxoft никогда не летают на Боингах» — шутка с долей шутки, как говорится.
Говорят, что простому обывателю не нужно знать, как делается колбаса и как делается политика, вот так же лучше не знать, как делается программное обеспечение и с каким количеством дефектов оно приезжает в продакшн. А тестировщики это знают лучше всех.
Дефекты есть везде: в фотоаппарате, в микроволновке, в айпаде и в системах обеспечения ПВО. Чем этот дефект когда-нибудь может обернуться, не угадать. Тестирование крылатых ракет — это печаль и боль, потому что качество там обеспечивается троекратным дублированием, а не внимательной чисткой багов.
Бывают моменты разочарования: «Вечно всё не так, вечно всё плохо, и я постоянно вижу, как же всё плохо...». Это — серьёзный риск нашей профессии, и хорошие руководители не забывают напоминать команде о светлых сторонах работы.
Вне работы склад ума тестировщика и его опыт — очень полезны! Привычка задавать неприятный вопрос «А что случится, если..?» — помогает и семейный бюджет планировать, и автомобиль чинить, и стиральную машину покупать, и вечеринки устраивать. Критический взгляд, умение общаться и находить информацию, активная позиция — это пригодится в любое время и в любом месте.
Я вижу, что именно так ведут себя настоящие тестеры: они — энергичные, рассудительные, взрослые, ответственные, заботятся о результате, способны брать на себя организацию процессов и вовремя входить в роль скептика и перфекциониста. За это их и любят.
