Home

Автор: Тан Хайн (Thanh Huynh)

Оригинал статьи: http://www.asktester.com/new-tester-stop-worrying-these-things-and-youll-be-fine/

Перевод: Ольга Алифанова

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

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

Термины и определения

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

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

Знаете, в чем красота терминов и определений? В том, что люди могут определять что угодно как угодно внутри своего контекста. Если только вы не стремитесь собрать коллекцию терминов и определений тестирования, прекратите нервничать по этому поводу. Выберите что-то одно и используйте его.

Возврат багов

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

Вам кажется, что отказали лично вам, а не вашему багу, и начинаете переживать:

• "У меня в этом месяце убито уже несколько багов, повлияет ли это на оценку моей эффективности как тестировщика?"
• "Разработчики смеются мне в лицо, потому что я пишу репорты о такой ерунде".
• "Моя ценность падает".
• "Разработчики меня ненавидят".
• "С моей способностью тестировать что-то не так".

РАССЛАБЬТЕСЬ.

Когда вы тестируете, есть вещи, которые вы знаете о своей системе – но есть и то, чего вы пока не знаете. Тестирование – это процесс обучения. Тестируя, вы идете от известного к неизвестному. Если ваш баг убит, возможно, вы не в курсе специфики новой функциональности (или даже не знаете, что она внедрена). Извлеките из этого урок и двигайтесь вперед.

Я пытаюсь сказать, что не надо расстраиваться из-за убитых багов – это не повод прекратить искать хорошие, годные проблемы!

Заметка для менеджеров: если вы судите тестировщика по количеству багов, немедленно прекратите!

"Я упустил баг".

Наверно, это самое страшное, что тестировщик может услышать от руководителя. Это не так, и это одно из наиболее ошибочных мнений о тестировании.

Вы чувствуете вину и волнуетесь, если баг сбежал от вас и оказался в продакшене, так как:

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

Если это так, то это отличный повод начать поиск козла отпущения, или не менее распространенную игру "Прикрой свою задницу".

"Нет, это не моя вина. Баг упущен, потому что кто-то сделал что-то".

Как вариант, вы начнете искать и передавать в разработку абсолютно все баги и настаивать, чтобы разработчики исправили абсолютно все до релиза. Чего, конечно, никогда не произойдет – вы не можете найти все-все-все баги, а у разработчиков никогда не будет времени, чтобы исправить все-все-все.

Вместо того, чтобы нервничать об упущенных багах, делайте вот что:

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

Еще одна заметка для менеджеров: если вы судите тестировщика по количеству багов, немедленно прекратите!

"Я всего лишь ручной тестировщик"

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

На картинке ниже – результаты поиска по фразе "is manual testing dead".

Выглядит пугающе! Судя по всему, ручной труд умирает – или, как минимум, это беспокоит тестировщиков.

Недавно я брал интервью у Аугусто (оно тут), и он прокомментировал эту ситуацию:

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

Если я вас еще не убедил, прочитайте, что об этом пишет Майкл Болтон:

http://www.developsense.com/blog/2013/02/manual-and-automated-testing

http://www.developsense.com/blog/2009/08/testing-vs-checking

Нет, ручное тестирование не умрет, пока автотесты не научатся задавать хорошие вопросы про продукт, который тестируется.

"У меня нет документации, как мне тестировать?"

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

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

Без паники! Отсутствие документации – это не конец света!

Вместо того, чтобы доводить себя до нервного срыва, попробуйте вот что:

• Если вы не нашли документацию, спросите о ней.
• Поговорите с теми, кто поможет вам разобраться в системе.
• Займитесь исследовательским тестированием, используя эвристику HICCUPS. Рекомендую статью Майкла Болтона по этой тематике (статья тут).

"Как получить работу в тестировании?"

Все вышеперечисленные поводы для волнения не стоят выеденного яйца, если вы не можете найти работу.

Это, возможно, самый мощный стимул начать паниковать, особенно если вы только что закончили институт или находитесь в процессе смены карьеры.

Давайте я озвучу, что именно вас беспокоит:

• Мир кишит экспертами с многолетним стажем в тестировании.
• Ваш опыт равен нулю.
• Большинство вакансий требуют как минимум пары лет опыта в этой области… на позицию джуниор-тестировщика.

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

Нет опыта? Приобретите его!

В мире куча организаций, которые позволяют вам подключаться к проектам для поиска багов. Что еще лучше – за это платят, и не надо выходить из дома. Лично я рекомендую uTest.

Как насчет тестирования реальных продуктов?

Вы можете попрактиковаться на Facebook, LinkedIn, и даже на моем собственном сайте (AskTester). Это можно добавить в резюме как нечто вроде "Нашел несколько багов на Facebook/LinkedIn, при этом один из них крашил систему. Вот что я делал:…".

Суть в том, чтобы продемонстрировать, как именно вы тестируете.

Регистрируйтесь на профессиональных форумах, подключайтесь к чатам, задавайте вопросы. Чем больше вопросов вы задаете, тем быстрее учитесь. Это не только поможет вам узнать что-то новое, но и сделает вас заметнее. Кто знает, может, вас заметят как раз благодаря вашим метким вопросам и страсти к тестированию, и предложат вам работу?

"Я боюсь перемен"

Люди не любят перемен, и это факт.

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

Вы сопротивляетесь переменам, потому что вас тревожит неопределенность. Вы не имеете ни малейшего понятия, что вас ждет впереди, и достаточно ли вы опытны, чтобы справиться с переменами.

Хорошая новость: бояться тут нечего.

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

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

Вместо того, чтобы бегать по потолку и протестовать против перемен, будьте храбрее – приветствуйте их!

"Меняться трудно, потому что люди переоценивают значимость того, что у них уже есть, и недооценивают значимость того, что они могут получить, отказавшись от имеющегося" – Джеймс Беласко, Ральф Стайер.

Заключение

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

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