Особенности подготовки начинающих тестировщиков

Все мы когда-то были новичками: в тестировании или в другой сфере – не важно. Мы одинаково спотыкались, блуждали в поисках правильного пути и далеко не всегда быстро находили решение. Порой у нас опускались руки от многократных ошибок, и в голове прочно утверждалась мысль: «Я – неудачник и все делаю не так!».

Я хорошо помню свой самый первый проект с реальными задачами, свои большие от страха глаза, когда мне поручили составление тестов. Я совершенно не знала, с чего начинать. И больше всего меня мучило не абстрактное «как это делается?», а «как это сделать правильно?».

С тех пор прошло почти три года, я многому научилась – самостоятельно и с помощью замечательных коллег, с которыми мне посчастливилось работать. А еще за все это время я успела неоднократно побывать в роли наставника новичков, которые приходили в нашу компанию, и стать одним из тренеров курса «Школа успешных тестировщиков» Натальи Руколь.

Наставничество в «Лаборатории Качества», регулярная проверка домашних заданий и мой собственный опыт на старте карьеры сформировали ряд принципов, которым я стараюсь следовать при подготовке начинающих тестировщиков.

От теории к практике

Мне нередко приходится встречать ребят, которые только-только окончили курсы по тестированию. Их головы на 200% забиты теорией, а практики за плечами нет почти никакой. В этой части статьи я расскажу о том, какие кирпичики нужно заложить в фундамент знаний джуниоров, чтобы они могли в будущем качественно выполнять поставленные задачи.

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

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

На одном из проектов я столкнулась с такой проблемой: мне дали очень длинные чек-листы со словами: «Сначала проверь основное». Найти это «основное» так и не удалось, поскольку в тестах важные проверки смешались со второстепенными, а негативные – с позитивными. Я не знала ничего о продукте и задачах, которые он должен решать, а требований или хорошей тестовой документации не было. Тестировала я, как потом оказалось, не совсем то, что было нужно.

Меня еще на самом первом проекте научили расставлять в тестах приоритеты: высокий, средний и низкий. Со временем я убедилась, что это действительно эффективный прием, особенно при отсутствии требований. Он дает возможность не только выделить основные функциональности, но и понять, что проверять в последнюю очередь.

Гораздо проще сказать новичку: «Сначала пройди тесты с высоким приоритетом – это главное», чем: «Вот тебе 400 тестов, но ты самое важное сперва пройди». В первом случае у джуниора формируется представление о продукте и его особенностях; во втором он получает полную свободу действий и, как результат, проверяет все, что взбредет в голову.

2. Четко описанные задачи.
Поскольку джуниоры склонны углубляться в менее важные вещи, упуская из виду самое главное, им нужно четко задавать направление, в котором следует двигаться. На проектах с хорошо поставленным процессом сделать это очень легко, дав новичку готовые тесты. Пусть потихоньку их проходит.

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

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

Останется выбрать контрольные точки для проверки результата и корректировки направления. Например, пусть джуниор сначала выпишет все разделы продукта, потом – доступные действия, в самом конце – значения. В итоге задача не только обретет четкие очертания, но и будет разбита на маленькие кусочки, которые проще «проглотить».

3. От простого к сложному.
Мне часто приходилось наблюдать, как начинающим тестировщикам без какого-либо практического опыта первым делом поручали составлять чек-листы и тест-кейсы. Результат работы в основном оказывался довольно печальным и требовал существенной доработки: тесты были плохо структурированы, не покрывали важные функциональности, но при этом содержали много мелких проверок. А некоторые ребята и вовсе обходились простым «копипастом» требований к продукту. Грусть и тоска!

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

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

Еще одна важная деталь в подготовке начинающих тестировщиков – научить их грамотно локализовывать ошибки и оформлять качественные багрепорты. Это базовый навык, которым должен владеть каждый хороший специалист по тестированию. Грош цена грамотно составленным тестам, выявляющим критические проблемы, если все дефекты описаны «на тяп-ляп» и никому не понятны.

4. Документация – всему голова.
Впервые приходя на работу в качестве тестировщика, сотрудники задают множество вопросов: как организационных, так и касающихся разрабатываемого продукта. В потоке информации легко запутаться и многое забыть, особенно когда профессионального опыта мало или вообще нет.

Это не так критично при изучении продукта – практически всегда есть тесты или требования, которые можно дать новичку. Но вот нюансы рабочего процесса, особенно в мелких компаниях, нередко передаются в устном виде (или в чатах, при удаленной форме работы). В итоге упустить из виду что-то важное – проще простого.

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

То же самое касается и тестовой документации: багрепортов, чек-листов, тест-кейсов, стратегий, тест-планов и отчетов. Заранее подготовленные шаблоны позволят джуниорам правильно составлять документы и не отклоняться от стиля, принятого в компании. Не менее ценными являются и глоссарии терминов, используемых внутри команды. Это избавит документы от аббревиатур и слов, известных лишь части сотрудников (если не кому-то одному).

5. Активное участие в жизни проекта.
Некоторые опытные тестировщики стараются посильнее загрузить джуниоров задачами, чтобы те меньше путались под ногами и не отвлекали от важных дел. Это позволяет им сосредоточиться на серьезных вопросах – вроде планирования времени, необходимого для выполнения задач.

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

Еще на своем первом проекте я всегда любила просто послушать менеджера и других более опытных коллег – я столько всего узнавала в процессе! Кроме того, у меня в результате появлялись какие-то идеи, которыми я с удовольствием делилась с командой. Уверена, что возможность участия в таких обсуждениях дала мне ровно столько же ценного опыта, сколько и оттачивание навыков на практике.

Не нужно бояться привлекать начинающих тестировщиков к выяснению стратегических вопросов. Во-первых, им будет полезно просто послушать. Во-вторых, они еще теснее интегрируются в проект, лучше изучат его проблемы, а также потребности заказчика и команды. В-третьих, и новички вполне могут высказать какие-то ценные предложения. Возможно, они заметят то, что постоянно упускали из виду опытные сотрудники. Мне кажется, сплошная польза – вреда никакого.

Коммуникации

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

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

1. Джуниор – личность.
Порой опытные специалисты забывают, как сложно им было на старте, и нетерпимо относятся к ошибкам новичков. А кто-то даже смеется над ними. И хорошо, если только про себя! Однако самое ужасное, что можно сделать – это жестко раскритиковать сотрудников, дать им понять, насколько мизерными и ничтожными являются их знания. Или со смехом рассказывать остальным коллегам, как «лажает» новобранец. Это отбивает мотивацию продолжать выполнение задачи и может надолго поселить в человеке неуверенность в своих силах.

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

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

2. Не только кнут, но и пряник.
Я встречаю разных ребят на курсах и на работе: кто-то более сообразительный, кто-то – менее. У одних прогресс идет быстрыми темпами, другие долго не могут «врубиться». Иногда очень трудно отвертеться от мысли: «Ну столько раз уже объяснила, все разжевала – куда же еще понятнее?! Почему все так туго идет?». Но и в таких ситуациях я всегда стараюсь вспомнить о важности похвалы. Постоянный шквал замечаний может чрезмерно утомить и погубить желание что-либо делать.

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

Часто возникает и другая ситуация, когда новичок все делает плохо: и тесты у него неудачные, и багрепорты оформляет криво, и ошибки не до конца локализовывает. Кажется, что он вообще не старается и абсолютно ничему не учится. Не за что хвалить совершенно! Но и тут есть выход из положения: если сравнить первые шаги джуниора с тем, что получилось в результате упорных правок, наверняка обнаружится пусть и маленький, но прогресс. Это уже само по себе достойно похвалы: «Ты так продвинулся вперед – молодец!».

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

Как-то я наткнулась на статью о замечательном «Правиле 15 минут». Его суть в том, чтобы в течение указанного времени попытаться самому найти ответ на свой вопрос, а затем уже спрашивать остальных. Мне кажется, это хороший метод, который может помочь сразу в двух ситуациях:
    • если джуниор постоянно что-то спрашивает, не пытаясь думать, эта техника подтолкнет его к попыткам разобраться в проблеме, прежде чем отвлекать коллег;
    • если сотрудник настолько стеснителен, что боится задавать вопросы, правило вынудит его «высунуться из норы» и попросить о помощи.

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

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

Иногда в этом действительно есть необходимость. В конце концов, сотрудник учится, а освоение новых навыков лучше начать с правильных техник. Но бывает и такое: новичок довольно неплохо справляется со своей работой с самого начала, но мне не дает покоя мысль, что я бы сделала это по-другому. В эти моменты важно посмотреть на все под другим углом и задать себе вопрос: «Действительно ли стоит тратить время и силы, чтобы «вылизать» все до состояния идеала?».

Да и что такое «идеал»? Это абсолютно субъективное понятие. Если работа в целом выполнена хорошо, то возможно, что текущее решение – действительно лучшее. Оно просто другое – не такое, к которому мы привыкли. У джуниоров тоже стоит учиться, ведь они обладают свежим взглядом на вещи. Именно поэтому в таких спорных ситуациях необходимо абстрагироваться от устоявшихся практик и попробовать объективно взглянуть на новый подход.

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

Дали задачу новичку – позвольте ему спокойно разобраться, все изучить, найти нужную информацию. Не стоит дергать человека каждый час вопросами: «Ну как там твоя задача?» – или (о ужас!) – «Сколько тебе еще нужно времени?». На старте никому не удается выполнять свою работу так же быстро, как опытным специалистам. Постоянные напоминания о себе заставят джуниора лишний раз нервничать и переживать, что он ничего не успевает.

Достаточно периодически (например, пару раз в день) спрашивать его, есть ли какие-нибудь вопросы и все ли понятно? Главное – делать это ненавязчиво, не создавая ощущения тотального контроля. И, как я уже говорила выше, задача должна быть разбита на маленькие части. Так легче видеть, возникают ли у новичка сложности, на каком именно этапе появляются проблемы, и в какой момент стоит скорректировать выбранный сотрудником курс.

Резюме

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

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

Об авторе

В «Лаборатории Качества» с 2013 года. Начинала с тестировщика, выросла в полноценного тест-менеджера. Приняла участие в тестирование ряда мобильных и web-проектов. С 2016 года совмещает основную деятельность с преподаванием на курсе «Школа успешных тестировщиков» Натальи Руколь.

Поиск
Облако меток
8 марта (1)api (5)ISTQB FL (1)IT (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (22)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (3)обеспечение качества (13)обучение (8)онлайн-конференция (1)оптимизация тестирования (12)оффлайн тренинги (1)поздравление (2)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удаленная работа (1)удобство использования (2)управление проектами (3)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет