Все мы когда-то были новичками: в тестировании или в другой сфере – не важно. Мы одинаково спотыкались, блуждали в поисках правильного пути и далеко не всегда быстро находили решение. Порой у нас опускались руки от многократных ошибок, и в голове прочно утверждалась мысль: «Я – неудачник и все делаю не так!».
Я хорошо помню свой самый первый проект с реальными задачами, свои большие от страха глаза, когда мне поручили составление тестов. Я совершенно не знала, с чего начинать. И больше всего меня мучило не абстрактное «как это делается?», а «как это сделать правильно?».
С тех пор прошло почти три года, я многому научилась – самостоятельно и с помощью замечательных коллег, с которыми мне посчастливилось работать. А еще за все это время я успела неоднократно побывать в роли наставника новичков, которые приходили в нашу компанию, и стать одним из тренеров курса «Школа успешных тестировщиков» Натальи Руколь.
Наставничество в «Лаборатории Качества», регулярная проверка домашних заданий и мой собственный опыт на старте карьеры сформировали ряд принципов, которым я стараюсь следовать при подготовке начинающих тестировщиков.
От теории к практике
Мне нередко приходится встречать ребят, которые только-только окончили курсы по тестированию. Их головы на 200% забиты теорией, а практики за плечами нет почти никакой. В этой части статьи я расскажу о том, какие кирпичики нужно заложить в фундамент знаний джуниоров, чтобы они могли в будущем качественно выполнять поставленные задачи.
1. Тестирование с умом.
Первое, с чего начинают тестирование многие джуниоры, – это проверка классов эквивалентности и граничных значений, оценка внешнего вида продукта, поиск опечаток и ошибок. Они вводят кучу данных в поля, перебирают символы, высматривают верстку с линейкой (а некоторые идут дальше и «натягивают» на сайт матричную сетку), но не пытаются по-настоящему изучить продукт. Я сама поступала точно так же.
Опытные тестировщики знают, что чаще всего заказчиков интересует именно корректность реализации бизнес-логики. Это те функциональности, которыми привлекают пользователей – то, что является основным в продукте. Если, к примеру, начать тестирование с перебора символов, можно упустить критические ошибки, найдя при этом кучу мелких багов, до которых разработчики доберутся «когда-нибудь потом».
На одном из проектов я столкнулась с такой проблемой: мне дали очень длинные чек-листы со словами: «Сначала проверь основное». Найти это «основное» так и не удалось, поскольку в тестах важные проверки смешались со второстепенными, а негативные – с позитивными. Я не знала ничего о продукте и задачах, которые он должен решать, а требований или хорошей тестовой документации не было. Тестировала я, как потом оказалось, не совсем то, что было нужно.
Меня еще на самом первом проекте научили расставлять в тестах приоритеты: высокий, средний и низкий. Со временем я убедилась, что это действительно эффективный прием, особенно при отсутствии требований. Он дает возможность не только выделить основные функциональности, но и понять, что проверять в последнюю очередь.
Гораздо проще сказать новичку: «Сначала пройди тесты с высоким приоритетом – это главное», чем: «Вот тебе 400 тестов, но ты самое важное сперва пройди». В первом случае у джуниора формируется представление о продукте и его особенностях; во втором он получает полную свободу действий и, как результат, проверяет все, что взбредет в голову.
2. Четко описанные задачи.
Поскольку джуниоры склонны углубляться в менее важные вещи, упуская из виду самое главное, им нужно четко задавать направление, в котором следует двигаться. На проектах с хорошо поставленным процессом сделать это очень легко, дав новичку готовые тесты. Пусть потихоньку их проходит.
Но что же делать, если проект только начался, и пока нет ни тестов, ни документации, ни налаженного процесса? Раньше я совершала ошибку и отправляла джуниоров выполнять исследовательское тестирование, чтобы в это время сосредоточиться на организационных вопросах. Однако в итоге пришло понимание, что они «ковыряют» первые попавшиеся на глаза части продукта, после чего приходится разгребать хаос в багтрекере.
На мой взгляд, хороший способ «занять» джуниора на только-только стартовавшем проекте – поручить ему составление карты продукта. Во-первых, у новичка появится конкретная цель, во-вторых, он будет изучать систему в процессе работы, а в-третьих – приобретет полезный навык. Карта же послужит прекрасной основой для составления стратегии тестирования и наглядным хранилищем информации о продукте.
Останется выбрать контрольные точки для проверки результата и корректировки направления. Например, пусть джуниор сначала выпишет все разделы продукта, потом – доступные действия, в самом конце – значения. В итоге задача не только обретет четкие очертания, но и будет разбита на маленькие кусочки, которые проще «проглотить».
3. От простого к сложному.
Мне часто приходилось наблюдать, как начинающим тестировщикам без какого-либо практического опыта первым делом поручали составлять чек-листы и тест-кейсы. Результат работы в основном оказывался довольно печальным и требовал существенной доработки: тесты были плохо структурированы, не покрывали важные функциональности, но при этом содержали много мелких проверок. А некоторые ребята и вовсе обходились простым «копипастом» требований к продукту. Грусть и тоска!
В условиях крупных и длительных проектов, где никто и никуда не спешит, такое еще можно допустить. Ведь времени на переделывание предостаточно – пусть себе джуниор неспешно «копает грядку». Но часто ли встречаются такие проекты? Обычно есть и четкие сроки реализации продукта, и список задач, которые нужно выполнить. В таких ситуациях нет времени на длительное обучение с кучей правок и корректировок.
Как я уже говорила, начинающие тестировщики не умеют структурировать информацию и разбивать продукт на маленькие кусочки. Именно поэтому составление тестов для них является слишком сложной задачей. На старте лучше давать им для прохождения готовые тесты – пусть посмотрят, как это правильно делается. В процессе тестирования не только сформируется некий шаблон хорошей проверки, но и запомнятся разные варианты тестов, ведь джуниорам сложно придумывать свои. Составление проверок лучше поручить более опытным специалистам.
Еще одна важная деталь в подготовке начинающих тестировщиков – научить их грамотно локализовывать ошибки и оформлять качественные багрепорты. Это базовый навык, которым должен владеть каждый хороший специалист по тестированию. Грош цена грамотно составленным тестам, выявляющим критические проблемы, если все дефекты описаны «на тяп-ляп» и никому не понятны.
4. Документация – всему голова.
Впервые приходя на работу в качестве тестировщика, сотрудники задают множество вопросов: как организационных, так и касающихся разрабатываемого продукта. В потоке информации легко запутаться и многое забыть, особенно когда профессионального опыта мало или вообще нет.
Это не так критично при изучении продукта – практически всегда есть тесты или требования, которые можно дать новичку. Но вот нюансы рабочего процесса, особенно в мелких компаниях, нередко передаются в устном виде (или в чатах, при удаленной форме работы). В итоге упустить из виду что-то важное – проще простого.
Хорошим способом передачи знаний о внутренней «кухне» компании в целом и проекта в частности, как это ни банально прозвучит, является документация. Любые правила работы, инструкции по настройке окружения, описание того, как распределяются задачи в команде, кто и что обычно делает, помогут начинающему специалисту разобраться во многих деталях и сэкономят массу времени его коллегам. Да и в случае появления вопросов всегда можно дать ссылку на документ, где все это подробно описано.
То же самое касается и тестовой документации: багрепортов, чек-листов, тест-кейсов, стратегий, тест-планов и отчетов. Заранее подготовленные шаблоны позволят джуниорам правильно составлять документы и не отклоняться от стиля, принятого в компании. Не менее ценными являются и глоссарии терминов, используемых внутри команды. Это избавит документы от аббревиатур и слов, известных лишь части сотрудников (если не кому-то одному).
5. Активное участие в жизни проекта.
Некоторые опытные тестировщики стараются посильнее загрузить джуниоров задачами, чтобы те меньше путались под ногами и не отвлекали от важных дел. Это позволяет им сосредоточиться на серьезных вопросах – вроде планирования времени, необходимого для выполнения задач.
Действительно, начинающим тестировщикам, на первый взгляд, рано принимать участие в каких-то важных обсуждениях в силу недостатка опыта – им надо еще многому научиться. С другой стороны, нет ничего плохого в том, чтобы позвать джуниора на важное совещание, хотя бы в качестве слушателя. Это так же полезно, как и выполнение задач на практике. Да и новички избавятся от ощущения, что вся жизнь проекта проходит мимо, а проблемы решаются в тесном кругу менеджеров и ведущих специалистов.
Еще на своем первом проекте я всегда любила просто послушать менеджера и других более опытных коллег – я столько всего узнавала в процессе! Кроме того, у меня в результате появлялись какие-то идеи, которыми я с удовольствием делилась с командой. Уверена, что возможность участия в таких обсуждениях дала мне ровно столько же ценного опыта, сколько и оттачивание навыков на практике.
Не нужно бояться привлекать начинающих тестировщиков к выяснению стратегических вопросов. Во-первых, им будет полезно просто послушать. Во-вторых, они еще теснее интегрируются в проект, лучше изучат его проблемы, а также потребности заказчика и команды. В-третьих, и новички вполне могут высказать какие-то ценные предложения. Возможно, они заметят то, что постоянно упускали из виду опытные сотрудники. Мне кажется, сплошная польза – вреда никакого.
Коммуникации
Смена работы – это всегда стрессовая ситуация. Даже самые смелые из нас переживают: как их примут в коллективе, какими будут коллеги, и получится ли «прижиться» на новом месте. Добавьте к этому кардинальную смену деятельности или вообще первый трудовой опыт – и получится поистине «взрывная смесь».
Умелый подход к общению с новичками помогает смягчить ситуацию и позволяет им быстрее адаптироваться в незнакомой среде. О том, каким образом лучше построить взаимодействие с начинающими специалистами, я расскажу ниже.
1. Джуниор – личность.
Порой опытные специалисты забывают, как сложно им было на старте, и нетерпимо относятся к ошибкам новичков. А кто-то даже смеется над ними. И хорошо, если только про себя! Однако самое ужасное, что можно сделать – это жестко раскритиковать сотрудников, дать им понять, насколько мизерными и ничтожными являются их знания. Или со смехом рассказывать остальным коллегам, как «лажает» новобранец. Это отбивает мотивацию продолжать выполнение задачи и может надолго поселить в человеке неуверенность в своих силах.
При появлении джуниора в коллективе важно дать ему понять, что он – часть команды, а не лишний винтик, который путается у всех под ногами. Просит помощи – прекрасно, это шанс передать ему полученные знания. Запутался – наводящие вопросы и советы помогут ему найти правильную дорогу. Но стоит ему услышать: «Да ты же совершенно ничего не знаешь! И чему тебя учили вообще?!» – и он не только расстроится от осознания своей неудачи, но и затаит обиду на коллегу за такие слова.
Совершенно иная тактика – относиться к ошибкам джуниора с пониманием, подбадривать его и мягко подталкивать в нужном направлении. Такой подход надолго запомнится новичку, и он не раз, пусть и мысленно, поблагодарит своего наставника. Позитив и вежливые советы работают не менее качественно, чем постоянные пинки и стресс, и при этом не задевают чужие чувства.
2. Не только кнут, но и пряник.
Я встречаю разных ребят на курсах и на работе: кто-то более сообразительный, кто-то – менее. У одних прогресс идет быстрыми темпами, другие долго не могут «врубиться». Иногда очень трудно отвертеться от мысли: «Ну столько раз уже объяснила, все разжевала – куда же еще понятнее?! Почему все так туго идет?». Но и в таких ситуациях я всегда стараюсь вспомнить о важности похвалы. Постоянный шквал замечаний может чрезмерно утомить и погубить желание что-либо делать.
Каждый раз, когда начинающий специалист хорошо выполнил задачу, ему нужно об этом сказать. Критика – это прекрасно, она дает возможность развиваться и не останавливаться на достигнутом. Но не стоит забывать, как приятно любому человеку узнать, что он не зря старался. Простые слова, вроде «ты замечательно справился», придадут джуниору уверенности в себе и добавят мотивации. И конечно же, стоит поблагодарить его за проделанный труд, ведь он потратил столько сил.
Часто возникает и другая ситуация, когда новичок все делает плохо: и тесты у него неудачные, и багрепорты оформляет криво, и ошибки не до конца локализовывает. Кажется, что он вообще не старается и абсолютно ничему не учится. Не за что хвалить совершенно! Но и тут есть выход из положения: если сравнить первые шаги джуниора с тем, что получилось в результате упорных правок, наверняка обнаружится пусть и маленький, но прогресс. Это уже само по себе достойно похвалы: «Ты так продвинулся вперед – молодец!».
3. Помогать, но не нянчить.
Иногда я в искренних попытках помочь и научить увлекалась процессом и превращалась в эдакую няньку. В итоге джуниор вместо того, чтобы хорошенько подумать и поискать ответ в интернете, каждый раз обращался ко мне. Порой дело доходило до каких-то совсем простых вопросов, которые можно было быстро нагуглить без посторонней помощи. В какой-то момент я всерьез задумалась: как же найти баланс, чтобы не бросить новичка одного, но в то же время научить его принимать решения самостоятельно.
Как-то я наткнулась на статью о замечательном «Правиле 15 минут». Его суть в том, чтобы в течение указанного времени попытаться самому найти ответ на свой вопрос, а затем уже спрашивать остальных. Мне кажется, это хороший метод, который может помочь сразу в двух ситуациях:
- если джуниор постоянно что-то спрашивает, не пытаясь думать, эта техника подтолкнет его к попыткам разобраться в проблеме, прежде чем отвлекать коллег;
- если сотрудник настолько стеснителен, что боится задавать вопросы, правило вынудит его «высунуться из норы» и попросить о помощи.
Конечно, можно сказать: «Пойди – погугли», но я стараюсь не поступать так без крайней необходимости, чтобы не отбить у начинающих тестировщиков охоту обращаться ко мне за советом. Если же вопросы становятся уж слишком элементарными и никак не относятся к нюансам текущего проекта, приходится отправлять ребят искать ответы в интернете.
4. Идеал – понятие растяжимое.
Я – жуткий перфекционист, особенно когда дело доходит до работы. Это, с одной стороны, очень хорошее для тестировщика качество, но, с другой, невероятно мешает. Порой, дав новичку задачу, я пытаюсь подогнать результаты его труда под свои ожидания, привести к тому идеалу, к которому бы сама стремилась, поручи мне кто-нибудь эту работу.
Иногда в этом действительно есть необходимость. В конце концов, сотрудник учится, а освоение новых навыков лучше начать с правильных техник. Но бывает и такое: новичок довольно неплохо справляется со своей работой с самого начала, но мне не дает покоя мысль, что я бы сделала это по-другому. В эти моменты важно посмотреть на все под другим углом и задать себе вопрос: «Действительно ли стоит тратить время и силы, чтобы «вылизать» все до состояния идеала?».
Да и что такое «идеал»? Это абсолютно субъективное понятие. Если работа в целом выполнена хорошо, то возможно, что текущее решение – действительно лучшее. Оно просто другое – не такое, к которому мы привыкли. У джуниоров тоже стоит учиться, ведь они обладают свежим взглядом на вещи. Именно поэтому в таких спорных ситуациях необходимо абстрагироваться от устоявшихся практик и попробовать объективно взглянуть на новый подход.
5. Доверяй и совсем немножко проверяй.
Новый человек в команде, а особенно джуниор, который пока еще не показал себя на практике, – это всегда риск. Наверняка у некоторых опытных специалистов хотя бы раз возникали мысли вроде: «Вот уже прошло несколько часов, а он молчит. Точно ли он работает над поставленной задачей?». В этом нет ничего плохого: многие хотят держать руку на пульсе и вовремя реагировать на возникающие проблемы. Но очень важно не идти на поводу у своих опасений и доверять коллеге.
Дали задачу новичку – позвольте ему спокойно разобраться, все изучить, найти нужную информацию. Не стоит дергать человека каждый час вопросами: «Ну как там твоя задача?» – или (о ужас!) – «Сколько тебе еще нужно времени?». На старте никому не удается выполнять свою работу так же быстро, как опытным специалистам. Постоянные напоминания о себе заставят джуниора лишний раз нервничать и переживать, что он ничего не успевает.
Достаточно периодически (например, пару раз в день) спрашивать его, есть ли какие-нибудь вопросы и все ли понятно? Главное – делать это ненавязчиво, не создавая ощущения тотального контроля. И, как я уже говорила выше, задача должна быть разбита на маленькие части. Так легче видеть, возникают ли у новичка сложности, на каком именно этапе появляются проблемы, и в какой момент стоит скорректировать выбранный сотрудником курс.
Резюме
Появление любого джуниора в команде – это прекрасная возможность как поделиться своим опытом, так и научиться чему-то новому. Насколько невозможно построить надежный дом без прочного фундамента, настолько же нельзя стать хорошим специалистом без базовых навыков. Неважно, какие курсы прошел сотрудник до прихода на работу и какие книги читал, – знания, полученные новичком на реальном проекте, навсегда останутся в его памяти и заложат основу для дальнейшего развития.
При этом не стоит забывать, что мы работаем с людьми, зачастую совершенно на нас не похожими. Одни из них более смелые, другие – менее, кому-то легко дается обучение, а кому-то – гораздо труднее. Какой бы «сильной» ни была программа подготовки, плохо налаженные коммуникации с джуниором могут свести все обучение на нет. Грамотное же общение, напротив, способно значительно ускорить прогресс начинающего тестировщика и быстрее приблизить его к званию настоящего профессионала своего дела.
