За что могут уволить тестировщика
За что могут уволить тестировщика
Вы успешно прошли собеседование и справились с тестовым заданием, работодатель готов предложить вашу первую работу начинающим тестировщиком. И вот, вы, воодушевленные своим успехом, рветесь в бой. Ведь перед этим вы прочли пару книг (а может и больше) по тестированию ПО, успешно окончили онлайн-курс, и даже почитали пару статей в интернете: “как же быть лучшим тестировщиком”. А теперь, уже три месяца, как внемлете рекомендациям и советам более опытных коллег, задерживаетесь, чтобы разобраться в сложном функционале, заводите миллионы багов и даже утомляете себя переработками.
Наконец, испытательный срок подходит к концу, и вы счастливо потираете ручки, уверенные в своем успехе. Но… Неожиданно руководитель мягко говорит, что продолжать сотрудничество он не намерен, а найдет другого тестировщика. Погодите-ка, но почему? Вы же вроде и книги читали по тестированию, и курсы проходили, да и советам коллег следовали. Я уж молчу про заведенные баги, коих миллионы, да и переработки никто не отменял. А тут такое…
Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?
Банальная невнимательность
Оказавшись в новом коллективе, каждый хочет понравиться, произвести хорошее впечатление, зарекомендовать себя. Именно по этой причине многие начинающие тестировщики задерживаются, перерабатывают и, порой, делают совершенно не ту работу, которую от них ожидают. А все потому, что были невнимательными.
Подобного рода ошибки для меня, как менеджера команд, являются очень показательными в профессиональном плане, ведь одно из самых важных качеств тестировщика – это его внимательность. А иначе, как я могу быть уверена в качестве его работы, если он и с заданием внимательно ознакомиться не в силах?
Для наглядности, приведу пару примеров из своего опыта.
Одна из моих команд занимается тестированием сайта, который предоставляет пользователям варианты разных кредитов. Сам сайт состоит всего из двух экранов: краткой формы и расширенной, где, задав определенные параметры и значения, можно получить информацию о кредите, срок, процентную ставку, сумму и другое.
Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.
Другая же моя сотрудница проходила юзабилити чек-лист, одним из пунктов которого была проверка быстродействия поискового механизма на сайте.
Пункт чек-листа звучит примерно: “Как быстро работает поиск”. И ожидается довольно простой ответ: “работает быстро, отклик укладывается в 3 секунды” (что, по общепринятым нормам – хорошо), но, почему-то такая простота смутила мою сотрудницу и она привела мне определение быстродействия, способы его замера, а вот на вопрос: “быстро ли работает поиск?” – так и не ответила. Как вы думаете, обрадовалась ли я такой “самодеятельности”? И вы будете правы, ответив нет. Время снова потрачено, а результат нулевой.
Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!
“А как же улучшить свою внимательность?” – спросите вы, и это справедливо. Ниже я поделюсь несколькими советами, которые опробовала на себе и на тестировщиках из своей команды.
Принятие всего на веру
Пожалуй, одно из тех качеств, которых не должно быть у тестировщика, – это принятие всего на веру.
“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.
Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.
Почему важно тестировать техническое задание? Потому что это первое, куда заглянет тестировщик при возникновении вопроса. И если вы понимаете, что ТЗ нелогично, противоречиво, содержит неточности – смело идите к аналитикам по продукту и выясняйте, как должно быть на самом деле, а не принимайте на веру все написанное.
Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.
Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”.
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?
Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:
Ошибки, связанные с баг-трекингом
Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!
Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.
Дорогие мои тестировщики, по заголовку вашего бага разработчик должен понимать: что случилось и где, а при чтении описания (steps to reproduce) – он должен знать строку кода, которую необходимо править. А что же получается у нас?
Мало того, что по заголовку бага совсем непонятно о какой ошибке в какой форме и какого продукта идет речь, так еще и 4 разных ошибки имеют одинаковый заголовок. Представляете, сколько лишнего времени разработчика и менеджера вы потратите такими баг-репортами?
Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”
Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт.
Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание в summary ожидаемого и фактического результатов для каждого шага.
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:
Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.
Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.
Ваш менеджер, увидев такие баг-репорты, явно не захочет читать морали, а просто решит сменить вас на другого специалиста, потому что умение четко и понятно заводить баги – одна из главных задач тестировщика.
Вместо заключения
Все мы люди и все мы совершаем ошибки. Не нужно этого бояться (особенно, если вы новичок). Ошибки – это хорошо, ведь благодаря им можно учиться и приобретать полезный и ценный опыт. Но когда одна и та же ошибка повторяется из раза в раз – это дает пищу для размышления вашему менеджеру и порождает желание заменить вас на другого специалиста.
Именно сейчас самое время остановиться и немного подумать: а все ли правильно я делаю? Как часто допускаю ошибки? Выношу ли из них полезный урок? Эти вопросы очень важны, чтобы определить, в верном ли направлении вы движетесь. Помните, что испытательный срок – это не повод паниковать, это — всего лишь отправная точка вашего становления как тестировщика. И чтобы он прошел гладко, без лишнего волнения, я поделюсь с вами секретами на своем курсе. На нем вы познакомитесь с миром тестирования, узнаете о его техниках, видах, научитесь правильно и хорошо заводить баг-репорты, писать отчеты по тестированию, а также тестировать требования, и, что тоже немаловажно, научитесь деловому общению.
За какие ошибки могут уволить начинающего тестировщика?
Вы успешно прошли собеседование и справились с тестовым заданием, работодатель готов предложить вашу первую работу начинающим тестировщиком. И вот, вы, воодушевленные своим успехом, рветесь в бой. Ведь перед этим вы прочли пару книг (а может и больше) по тестированию ПО, успешно окончили онлайн-курс, и даже почитали пару статей в интернете: “как же быть лучшим тестировщиком”. А теперь, уже три месяца, как внемлете рекомендациям и советам более опытных коллег, задерживаетесь, чтобы разобраться в сложном функционале, заводите миллионы багов и даже утомляете себя переработками.
Наконец, испытательный срок подходит к концу, и вы счастливо потираете ручки, уверенные в своем успехе. Но… Неожиданно руководитель мягко говорит, что продолжать сотрудничество он не намерен, а найдет другого тестировщика. Погодите-ка, но почему? Вы же вроде и книги читали по тестированию, и курсы проходили, да и советам коллег следовали. Я уж молчу про заведенные баги, коих миллионы, да и переработки никто не отменял. А тут такое…
Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?
Банальная невнимательность
Оказавшись в новом коллективе, каждый хочет понравиться, произвести хорошее впечатление, зарекомендовать себя. Именно по этой причине многие начинающие тестировщики задерживаются, перерабатывают и, порой, делают совершенно не ту работу, которую от них ожидают. А все потому, что были невнимательными.
Подобного рода ошибки для меня, как менеджера команд, являются очень показательными в профессиональном плане, ведь одно из самых важных качеств тестировщика – это его внимательность. А иначе, как я могу быть уверена в качестве его работы, если он и с заданием внимательно ознакомиться не в силах?
Для наглядности, приведу пару примеров из своего опыта.
Одна из моих команд занимается тестированием сайта, который предоставляет пользователям варианты разных кредитов. Сам сайт состоит всего из двух экранов: краткой формы и расширенной, где, задав определенные параметры и значения, можно получить информацию о кредите, срок, процентную ставку, сумму и другое.
Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.
Другая же моя сотрудница проходила юзабилити чек-лист, одним из пунктов которого была проверка быстродействия поискового механизма на сайте.
Пункт чек-листа звучит примерно: “Как быстро работает поиск”. И ожидается довольно простой ответ: “работает быстро, отклик укладывается в 3 секунды” (что, по общепринятым нормам – хорошо), но, почему-то такая простота смутила мою сотрудницу и она привела мне определение быстродействия, способы его замера, а вот на вопрос: “быстро ли работает поиск?” – так и не ответила. Как вы думаете, обрадовалась ли я такой “самодеятельности”? И вы будете правы, ответив нет. Время снова потрачено, а результат нулевой.
Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!
“А как же улучшить свою внимательность?” – спросите вы, и это справедливо. Ниже я поделюсь несколькими советами, которые опробовала на себе и на тестировщиках из своей команды.
Принятие всего на веру
Пожалуй, одно из тех качеств, которых не должно быть у тестировщика, – это принятие всего на веру.
“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.
Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.
Почему важно тестировать техническое задание? Потому что это первое, куда заглянет тестировщик при возникновении вопроса. И если вы понимаете, что ТЗ нелогично, противоречиво, содержит неточности – смело идите к аналитикам по продукту и выясняйте, как должно быть на самом деле, а не принимайте на веру все написанное.
Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.
Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”.
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?
Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:
Ошибки, связанные с баг-трекингом
Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!
Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.
Дорогие мои тестировщики, по заголовку вашего бага разработчик должен понимать: что случилось и где, а при чтении описания (steps to reproduce) – он должен знать строку кода, которую необходимо править. А что же получается у нас?
Мало того, что по заголовку бага совсем непонятно о какой ошибке в какой форме и какого продукта идет речь, так еще и 4 разных ошибки имеют одинаковый заголовок. Представляете, сколько лишнего времени разработчика и менеджера вы потратите такими баг-репортами?
Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”
Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт.
Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание в summary ожидаемого и фактического результатов для каждого шага.
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:
Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.
Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.
Ваш менеджер, увидев такие баг-репорты, явно не захочет читать морали, а просто решит сменить вас на другого специалиста, потому что умение четко и понятно заводить баги – одна из главных задач тестировщика.
Вместо заключения
Все мы люди и все мы совершаем ошибки. Не нужно этого бояться (особенно, если вы новичок). Ошибки – это хорошо, ведь благодаря им можно учиться и приобретать полезный и ценный опыт. Но когда одна и та же ошибка повторяется из раза в раз – это дает пищу для размышления вашему менеджеру и порождает желание заменить вас на другого специалиста.
Именно сейчас самое время остановиться и немного подумать: а все ли правильно я делаю? Как часто допускаю ошибки? Выношу ли из них полезный урок? Эти вопросы очень важны, чтобы определить, в верном ли направлении вы движетесь. Помните, что испытательный срок – это не повод паниковать, это — всего лишь отправная точка вашего становления как тестировщика. И чтобы он прошел гладко, без лишнего волнения, я поделюсь с вами секретами на своем курсе. На нем вы познакомитесь с миром тестирования, узнаете о его техниках, видах, научитесь правильно и хорошо заводить баг-репорты, писать отчеты по тестированию, а также тестировать требования, и, что тоже немаловажно, научитесь деловому общению.
За что могут уволить тестировщика
Что пишут в блогах
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Вы успешно прошли собеседование и справились с тестовым заданием, работодатель готов предложить вашу первую работу начинающим тестировщиком. И вот, вы, воодушевленные своим успехом, рветесь в бой. Ведь перед этим вы прочли пару книг (а может и больше) по тестированию ПО, успешно окончили онлайн-курс, и даже почитали пару статей в интернете: “как же быть лучшим тестировщиком”. А теперь, уже три месяца, как внемлите рекомендациям и советам более опытных коллег, задерживаетесь, чтобы разобраться в сложном функционале, заводите миллионы багов и даже утомляете себя переработками.
Наконец, испытательный срок подходит к концу, и вы счастливо потираете ручки, уверенные в своем успехе. Но… Неожиданно руководитель мягко говорит, что продолжать сотрудничество он не намерен, а найдет другого тестировщика. Погодите-ка, но почему? Вы же вроде и книги читали по тестированию, и курсы проходили, да и советам коллег следовали. Я уж молчу про заведенные баги, коих миллионы, да и переработки никто не отменял. А тут такое…
Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?
Банальная невнимательность
Оказавшись в новом коллективе, каждый хочет понравиться, произвести хорошее впечатление, зарекомендовать себя. Именно по этой причине многие начинающие тестировщики задерживаются, перерабатывают и, порой, делают совершенно не ту работу, которую от них ожидают. А все потому, что были невнимательными.
Подобного рода ошибки для меня, как менеджера команд, являются очень показательными в профессиональном плане, ведь одно из самых важных качеств тестировщика – это его внимательность. А иначе, как я могу быть уверена в качестве его работы, если он и с заданием внимательно ознакомиться не в силах?
Для наглядности, приведу пару примеров из своего опыта.
Одна из моих команд занимается тестированием сайта, который предоставляет пользователям варианты разных кредитов. Сам сайт состоит всего из двух экранов: краткой формы и расширенной, где, задав определенные параметры и значения, можно получить информацию о кредите, срок, процентную ставку, сумму и другое.
Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.
Другая же моя сотрудница проходила юзабилити чек-лист, одним из пунктов которого была проверка быстродействия поискового механизма на сайте.
Пункт чек-листа звучит примерно: “Как быстро работает поиск”. И ожидается довольно простой ответ: “работает быстро, отклик укладывается в 3 секунды” (что, по общепринятым нормам – хорошо), но, почему-то такая простота смутила мою сотрудницу и она привела мне определение быстродействия, способы его замера, а вот на вопрос: “быстро ли работает поиск?” – так и не ответила. Как вы думаете, обрадовалась ли я такой “самодеятельности”? И вы будете правы, ответив нет. Время снова потрачено, а результат нулевой.
Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!
“А как же улучшить свою внимательность?” – спросите вы, и это справедливо. Ниже я поделюсь несколькими советами, которые опробовала на себе и на тестировщиках из своей команды.
Принятие всего на веру
Пожалуй, одно из тех качеств, которых не должно быть у тестировщика, – это принятие всего на веру.
“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.
Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.
Почему важно тестировать техническое задание? Потому что это первое, куда заглянет тестировщик при возникновении вопроса. И если вы понимаете, что ТЗ нелогично, противоречиво, содержит неточности – смело идите к аналитикам по продукту и выясняйте, как должно быть на самом деле, а не принимайте на веру все написанное.
Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.
Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”.
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?
Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:
Ошибки, связанные с баг-трекингом
Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!
Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.
Дорогие мои тестировщики, по заголовку вашего бага разработчик должен понимать: что случилось и где, а при чтении описания (steps to reproduce) – он должен знать строку кода, которую необходимо править. А что же получается у нас?
Мало того, что по заголовку бага совсем непонятно о какой ошибке в какой форме и какого продукта идет речь, так еще и 4 разных ошибки имеют одинаковый заголовок. Представляете, сколько лишнего времени разработчика и менеджера вы потратите такими баг-репортами?
Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”
Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт.
Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание в summary ожидаемого и фактического результатов для каждого шага.
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:
Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.
Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.
Ваш менеджер, увидев такие баг-репорты, явно не захочет читать морали, а просто решит сменить вас на другого специалиста, потому что умение четко и понятно заводить баги – одна из главных задач тестировщика.
Вместо заключения
Все мы люди и все мы совершаем ошибки. Не нужно этого бояться (особенно, если вы новичок). Ошибки – это хорошо, ведь благодаря им можно учиться и приобретать полезный и ценный опыт. Но когда одна и та же ошибка повторяется из раза в раз – это дает пищу для размышления вашему менеджеру и порождает желание заменить вас на другого специалиста.
Именно сейчас самое время остановиться и немного подумать: а все ли правильно я делаю? Как часто допускаю ошибки? Выношу ли из них полезный урок? Эти вопросы очень важны, чтобы определить, в верном ли направлении вы движетесь. Помните, что испытательный срок – это не повод паниковать, это — всего лишь отправная точка вашего становления как тестировщика. И чтобы он прошел гладко, без лишнего волнения, я поделюсь с вами секретами на своем курсе. На нем вы познакомитесь с миром тестирования, узнаете о его техниках, видах, научитесь правильно и хорошо заводить баг-репорты, писать отчеты по тестированию, а также тестировать требования, и, что тоже немаловажно, научитесь деловому общению.