Если программирование, как утверждает известная шутка, — это процесс внесения ошибок в кодовую базу проекта, то должны быть и супергерои, не жалеющие нервов и глаз своих, чтобы число багов и недоработок не зашкаливало слишком уж сильно. Эти люди живут среди нас, и, поверьте, близко к сердцу воспринимают каждое дурное слово, сказанное по поводу очередного проявившегося в той или иной программе бага: это значит, что их работа не закончена, что их крестовый поход против поиск проблем продолжается.
Одним из устоявшихся мифов по поводу тестирования является идея, что тестировать ПО — дело как раз для стажеров. Другим мифом можно назвать мысль, что тестированием как таковым называется сам процесс ловли багов, а успешность ловли определяется числом зарепорченных проблем (особенно это актуально для ручного тестирования, а не просто для прогонов автотестов). И тот, и другой мифы весьма живучи не просто среди ИТ-шников, но даже среди разработчиков — факт довольно удивительный, поскольку уж кто-кто, а они кухню процесса создания действительно хорошего ПО знают отлично. Однако живём с тем, с чем живём, остаётся лишь по мере сил менять ситуацию.
Ради такой темы мы пригласили к общению двух специалистов в области тестирования: Никиту Макарова, занимающегося тестированием в Одноклассниках, и Юлию Атлыгину, отвечающую за то же направление в ALM Works.
Юлия Атлыгина в тестировании более 9 лет, последние из которых провела в ALM Works, разрабатывая плагины для Atlassian JIRA и Confluence. Роль тестировщика совмещает с ролями Product Owner'а и SAFe-консультанта. Классическое окончание краткой биографии Юли в последнее время — «Если есть вопросы по JIRA — не стесняйтесь задавать!»
— Юлия, сразу спрошу: в чем мера «хорошести» тестировщика?
Хороший тестировщик должен быть в каком-то смысле перфекционистом, и в первую очередь переживать не столько за сам продукт, сколько за работу пользователя в нем. Ведь не выровненные на 1 пиксель блоки в UI — это тоже проблема, так же, как и непонятное поведение, когда в цифровом поле по ошибке написали пробел перед числом, или вообще только пробел.
Другое дело, что тикеты про съехавший пиксель обычно не самые важные. Если мы говорим о пользе для юзера, то надо ранжировать тикеты по пользе и исправлять, по возможности, самые неприятные. Конечно, это несёт за собой и неприятные решения о том, что мы будем устранять (или, точнее, постараемся успеть устранить) в рамках времени выпуска текущего релиза, а что — нет.
— Откуда возникла мысль, что тестирование, особенно ручное — это работа для практикантов? Насколько вообще важны в работе тестировщика опыт и знания?
Опыт, и даже, я бы сказала, некая интуиция вообще много означат в работе тестировщика. Если посадить за ручное тестирование десяток неопытных практикантов, они наверняка найдут несколько сотен недоработок, однако важными из них окажутся совсем немногие — ребятам не хватит опыта, а где-то и знаний, чтобы понять, где ищутся самые важные баги, и что из найденного имеет смысл репортить. И здесь, как нигде, нужен ментор, который объяснит, научит, выступит тем первичным фильтром, который и позволит набрать первый опыт.
— Что отличает хорошего тестировщика от плохого? Не число же заведенных в трекере багов?
Работу тестировщика трудно оценить какими-то количественными метриками. Двадцать заведенных тикетов про сдвиги на один пиксель и один, но трудновылавливаемый баг внутри программы, в определенных обстоятельствах портящий данные — скорее всего, для пользователя (и для тестируемой программы) важнее будет именно второй, но это не значит, что «мелочи» в UI, особенно видимые пользователям, не следует искать, репортить и исправлять. Мой личный, «ментальный», критерий работы тестировщика — сколько из зарепорченных этим тестировщиком багов было убрано в текущем релизе.
Тестировать, конечно, можно по-разному. Там, где у нас есть четкие спецификации тестов (вплоть до указания, скажем, того, какие значения мы должны внести в какие поля и какой ответ на выходе должна показать нам программа), нам лучше всего применить автоматизированные тесты, но они никогда не заменят человеческого участия в тестировании. Когда у нас есть план тестирования, в нем порой встречаются довольно общие указания — скажем, «завести пользователя с логином из не-ASCII символов» — и эти указания человек каждый раз выполняет чуть по-разному, что на выходе дает новые варианты при каждом выполнении теста. Кроме того, только ручное тестирование может обнаружить досадные недоработки верстки, непонятное либо нелогичное с точки зрения пользователя поведение программы и прочие плохо формализуемые для автоматизации вещи.
Бывает, что ручным тестированием пренебрегают, полагаясь на автоматизированные тесты, однако опыт подсказывает, что есть много ситуаций, когда так делать не стоит, и это особенно справедливо, если программа меняется, дорабатывается, меняется в т.ч. ее UI, а тесты написаны для проверки внутренней логики работы программы и просто не рассчитаны на поиск недоработок в новом UI.
— Предположим, мы создаем с нуля новый проект. Мы нашли разработчиков, дизайнеров и теперь мы ищем специалистов по тестированию. Как много нужно специалистов этой области?
Вопрос не такой простой. Конечно, кратко: что чем больше — тем лучше! На самом деле, ответ очень зависит от проекта, от требований к нему, от самого процесса разработки. В каких-то случаях будет мало двух тестировщиков на одного разработчика, в каких-то — этого соотношения может быть и много.
— А все же — не скучна ли работа тестировщика?
По моему мнению, тестировщик должен быть перфекционистом, и его до глубины души должны огорчать любые, даже самые мелкие, огрехи в программе. И это не только пресловутые однопиксельные ошибки верстки, но и, в определенных случаях, верстка какой-то формы целиком: скажем, исходно на ней разместили два поля ввода, сопроводительный текст и кнопку «ОК», и, с точки зрения пользователей, это было удобно и понятно. Если позже, в процессе расширения функционала программы, на ту же форму накидали еще десяток элементов UI, которые оказались связаны между собой не очень простым образом, почти наверняка никто, кроме тестировщика, не скажет, что формой стало неудобно пользоваться: действительно, автотесты проходят, разработчики уверены, что форма сама по себе работает правильно. Правильно работает, но неудобна.
Поэтому, волей-неволей тестировщик должен быть в курсе работы всей системы в целом и довольно неплохо понимать работу каждой из ее частей. Для меня некоторым критерием работы тестировщиков является то, что к ним, а не к разработчикам, идут люди с вопросами рода «если мы поменяем вот здесь вот эту часть системы, как, на ваш взгляд, это отразится на всей системе?»
Мы в компании нашли для себя решение в том, что устраиваем обучение «мальков», как я их называю, и готовим из практикантов молодых, но уже более опытных специалистов по тестированию. Среди прочего, эта подготовка дает возможность и «малькам», и нам понять, кто в силу склада характера хорошо подходит для работы тестировщиком, а кому такая работа (и вообще образ мыслей) не будет в радость.
Никита Макаров работал в аутсорсинге и продуктовых компаниях. Занимался автоматизацией встраиваемых операционных систем на базе Linux, комплексных VPN-решений для бизнеса, программно-аппаратных комплексов. С января 2012 года является руководителем группы автоматизации тестирования в проекте Одноклассники.
— Никита, для начала спрошу: у вас не ПО, которое поставляется покупателю в виде «коробки», а онлайн-сервис. Такая ситуация как-то облегчает ловлю недоработок? Чем отличаются эти варианты с точки зрения тестирования?
Прежде всего пониманием того, насколько контролируемо для нас использование разрабатываемого и тестируемого продукта.
Коробочное ПО клиент покупает, а затем устанавливает, настраивает и использует так, как ему удобно и кажется правильным. Это может и не совпадать с представлением, имеющемся в процессе его создания у разработчиков — а значит, не избежать недовольства со стороны покупателя. Чтобы такого не случилось, мы заранее садимся, придумываем все, даже самые невероятные сценарии использования и тестируем ПО с учетом всего этого многообразия. Плюс подхода — мы отловим существенно большее число недоработок, даже такие, которые при «обычном» использовании никогда не проявились бы. Минус — сил на такую разработку уходит существенно больше, а это находит отражение и в стоимости, и в длительности работ. Если же какой-то баг находится уже после установки ПО у клиента, диагностика и ловля проблемы может затянуться на продолжительное время.
С ПО для собственного онлайн-сервиса дело обстоит по-другому: мы заранее отлично знаем условия эксплуатации (более того, мы контролируем их — от физических серверов, сетевой инфраструктуры, и до версий используемого ПО), и можем проводить нужные нам тесты в любой момент, даже в процессе «боевой» работы. При этом у нас есть возможность запускать, скажем, новую версию какого-то модуля только для небольшого процента посетителей сервиса и сравнивать две версии в работе под настоящей нагрузкой — более чем удобная возможность!
В качестве примера: мы никогда не можем себе позволить выпустить откровенно сырой код на продакшн, поскольку негативное мнение о нем может вылиться в отток пользователей с сервиса: этот такой негативный вариант, которым никто не станет рисковать. При этом сервис у нас работает с очень большими нагрузками, настолько большими, что собрать тестовый стенд, способный воспроизвести их, практически невозможно. Как в такой ситуации провести тестирование? К счастью, мы можем себе позволить развернуть новый код на отдельной группе серверов и направить на него запросы не всех посетителей, а небольшой их доле: если увидим, что изменения плохи, то просто переведём людей назад на старую версию, иначе просто будем плавно увеличивать процент получающих новую версию до сотни.
— Что вы на проекте тестируете вручную, а что перекладываете на плечи автоматики? Нужно ли вообще ручное тестирование при подобном динамичном проекте? Какого рода ошибки ловятся вручную?
Мы хотим (и стараемся добиться этого) автоматически проверять, что если пользователь на нашем сайте делает что-то правильным образом, то он получит понятные ему, правильные вещи. Другими словами, мы стараемся автоматически прогонять альфа-тесты — все, что можно в них автоматически проверить.
Вручную, наоборот, мы ловим то, что автоматика не в силах сделать: в частности, разбираемся с недоработками, на которые пожаловались пользователи, или шаг за шагом собираем информацию о том, почему изменения в одной подсистеме сервиса могли повлиять на какую-то другую его подсистему.
— Стоит ли отнести ловлю недоработок UI и верстки к работе тестировщиков или этим должны заниматься дизайнеры, верстальщики, а тестировщики занимаются именно работоспособностью в техническом понимании?
Мы стараемся тестировать в т.ч. и UI, причём сначала все вместе — и дизайнеры, и тестировщики. После этого тестировщики отдельно проводят свое тестирование, потому что между дизайном и пользователем находится вёрстка, и самый красивый и удобный дизайн может нарваться на суровую действительность, в которой тот же продуманный и выверенный дизайн выглядит чуть по-разному или работает чуть по-другому на разных устройствах, а устройств, как мы понимаем, сегодня на рынке великое множество. Более того, нам важно удобство пользователя, и мы тратим время на изучение и понимание того, как же будет сделать удобнее.
— Как оценить качество работы тестировщика? Не числом же заведенных в единицу времени багов?
Здесь надо сделать небольшое отступление. Дело в том, что весь наш большой проект внутри разбит на достаточно независимые команды, со своими графиками релиза, со своим подходом к разработке и со своими приоритетами в тестировании: где-то важно с самого начала провести глубокое планирование всех действий, где-то — разобраться с результатами альфа-тестирования и делать выводы, исходя из них.
Составы команд обычно постоянны, чтобы в голове сохранялось видение продукта и чтобы члены команды понимали, получается ли у них сделать «хорошо».
Так вот, качество работы тестировщика у нас оценивают по тому, насколько он делает все нужное, чтобы релизы команды выпускались по графику.
— Вопрос планирования и, вероятно, финансов: нет ли смысла вместо десятка опытных тестировщиков посадить на тот же объем работы бОльшее количество (скажем, полсотни) практикантов, в надежде, что они «возьмут» числом, а не умением, и с ними одного-двух опытных специалистов, которые бы отсортировывали зарепорченное? Это «тупо и грубо», но, возможно, в перспективе эффективнее?
Думаю, нет. Скорее наоборот: «закидывать проблему мясом» имеет хоть какой-то смысл, только если проблема простая, и ее в принципе возможно «закидать» вот так, не включая голову. Слишком сложная у нас система, и слишком много нужно о ней знать, чтобы для нас такой вариант прошел. Даже среди опытных тестировщиков, только что принятых к нам на работу, мало кто сможет сразу разобраться во всем многообразии систем проекта, так что мы привыкли давать примерно полгода только на понимание, что и как устроено — и, повторюсь, здесь речь про опытного работника, которого не нужно учить профессии.
Да, мы с удовольствием берем стажеров — и будем их учить до тех пор, пока мы не увидим их готовность (а они не чувствуют в себе силы) стать полноценным тестировщиком.
— Тестировщики находят куда больше недоработок, чем реально исправляется. Наверняка при этом возникает какое-то личное отношение к скорости внесения исправлений — или нет? Какое отношение ближе тестировщикам, «баг найден — работа сделана» или «пока есть баги — нельзя расслабляться»?
Конечно, в развивающемся проекте всегда будут появляться новые недоработки, и тестировщикам никогда не придется сидеть сложа руки. Но при этом каждый найденный баг в конечном итоге окажется поводом для очередного улучшения — а значит, в результате мы сможем сделаем мир немного лучше.
Вот и подошло к концу это интервью. Напоследок хочется отметить, что Никиту и Юлию можно встретить на конференции Heisenbug 2017 Moscow, которая пройдет 8-9 декабря. У Юлии будет доклад об инструментах тестировщика, а Никита раскроет тему тестирования белого ящика. На конференции будут организованы дискуссионные зоны, так что можно будет подойти и задать спикерам интересующие вас вопросы.
Автор: Олег Чирухин
