За какие ошибки могут уволить начинающего тестировщика?

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

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

Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?

Банальная невнимательность

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

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

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

Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.

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

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

Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!

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

  • Беритесь только за одно дело. Не хватайте сразу и побольше. Многозадачность – это круто, но очень трудозатратно. Наш бедный мозг не успевает обрабатывать несколько дел одновременно и какое-то точно пустит на самотек. 
    Получив задачу на тестирование, занимайтесь только ей, а не говорите по телефону с подругой и не серфите в соцсетях.
  • Сконцентрируйтесь! Внимательно (несколько раз!) прочитайте постановку задачи, в 90% случаях в ней уже содержится алгоритм выполнения или какая-то подсказка.
  • Делайте необходимое, избегая лишнего. Тут все банально просто: попросили вас декомпозировать функционал – декомпозируйте, попросили предоставить список дефектов на версии – предоставьте, а не выдумывайте от себя.
  • Записывайте задачи. Память может подвести, поэтому ведите список краткосрочных (на день) и среднесрочных (неделя, спринт) дел, и отмечайте их выполнение.

Принятие всего на веру

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

“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.

Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.

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

Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.

Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”. 
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?

Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:

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

Ошибки, связанные с баг-трекингом

Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!

Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.

Дорогие мои тестировщики, по заголовку вашего бага разработчик должен понимать: что случилось и где, а при чтении описания (steps to reproduce) – он должен знать строку кода, которую необходимо править. А что же получается у нас? 
Мало того, что по заголовку бага совсем непонятно о какой ошибке в какой форме и какого продукта идет речь, так еще и 4 разных ошибки имеют одинаковый заголовок. Представляете, сколько лишнего времени разработчика и менеджера вы потратите такими баг-репортами?

Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”

  • Что? 
    Что происходит, или же не происходит, согласно вашему представлению о нормальной работе тестируемой системы.
  • Где?
    В каком месте интерфейса или архитектуры системы найдена ошибка.
  • Когда?
    В какой момент работы системы, по наступлению какого события или при каких условиях, проблема проявляется.

Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт. 

Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание  в summary ожидаемого и фактического результатов для каждого шага. 
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:

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

Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не  информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.

Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.

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

Вместо заключения

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

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

Метки
#Тестирование ПО (3)Android (1)Cache (1)Cookie (1)courses (1)HR (1)iOS (2)istqb (1)ISTQB FL (1)IT (2)java (1)Jedi Point (11)JSON (1)kaizen (2)pairwise (1)QA (18)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)SOAPUI (1)softskills (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)web (1)XML (1)Анна Палей (1)БАГИ (1)Исследовательское тестирование (2)Истории поинт (9)История успеха (1)Команда разработки (1)Курс тестирования для начинающих (1)Кэш (1)Лаборатория Качества (1)Мнемоники (1)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)ПОИНТ (42)ПРомо-вебинар (1)Подготовка к istqb (1)Роман Буданов (3)Скриншот (3)Таблица решений (1)Тестирование (20)Тестирование ПО (3)Тест менеджмент (1)Тренер (12)Туры (1)автоматизация (2)алгоритмы (1)баг (1)безопасность (1)бесплатный вебинар (1)введение в тестирование (1)граничные значения (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (9)как надо тестировать (2)комбинаторика (1)конференция (2)котик (1)курс для начинающих тестировщиков онлайн (1)лайфхак (1)минутка юмора (1)мобилки (3)мобильное тестирование (4)настройка мозгов (1)начать карьеру (1)начать карьеру в IT (1)начинающий тестировщик (8)негативное тестирование (2)обучение (1)обучение тестированию (11)ограничения (1)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)смена работы (1)сопроводительное письмо (1)стать тестировщиком (1)с чего начать (1)тайм-менеджмент (1)тест дизайн (2)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование веб (2)тестирование игр (3)тестирование мобильных приложений (1)тестировщик (5)тесткейс (1)удаленная работа (1)улучшайзинг (1)ученик (2)фреймворки (1)чеклист (4)чит-листы (1)чит лист (2)что должен делать тестировщик (1)ятренерпоинт (1)
С 20.04 по 22.06, ОНЛАЙН Зарегистрироваться