Ошибки, из-за которых тестировщик может потерять работу

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

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

У вас сразу возникает вопрос: почему так кардинально? Вы же вроде изучили основные базисы профессии, прочитали несколько книг, следовали советам новых коллег. А тут такие новости…

Данная статья как раз и будет наполнена материалом касательно того, почему даже при должном выполнении работы тестировщика ПО, человек может запросто лишиться должности, и как нужно действовать чтобы такого точно не случилось именно с вами!

Причины, по которым компания может не принять человека на постоянную основу, весьма разнообразны, а значит и критерии подобного «отбора» можно поделить на некоторые составляющие.

Ошибки тестировщика

Человеческая невнимательность

Как только вы оказались в новой для себя команде тестировщиков, вы на подсознательном уровне будете стремиться понравиться всем и сразу.

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

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

Пример:

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

Советы по улучшению навыка внимательности:

1. Выполняйте одно дело, не хватайтесь одновременно за выполнение сразу двух и более сложных задач. Многозадачность – это отменный навык, но труднозадачность – это боль любой компании;
2. Концентрация на 100%. Перед выполнением поставленной задачи внимательно изучайте ее требования, ведь в 85% всех задач содержится универсальный алгоритм их решения;
3.  Делайте лишь то, что необходимо, старайтесь избегать лишних шагов. Тут все очень просто и понятно: менеджер поставил перед вами задачу декомпозировать функционал ПО – просто декомпозируйте;
4.  Записывайте выполненные задачи. Человеческая память когда-то может вас подвести, а значит нужно вести список минимально срочных и средне-срочных дел, постепенно выполняя их.

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

Скорее всего, это одно из наиболее распространенных качеств среди начинающих тестировщиков.

Какой результат по итогу будет правильным? Именно его вы ожидали достигнуть? Может, стоит обратиться за советом к аналитику или разработчику?

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

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

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

Золотое правило: никогда не верьте на слово разработчикам!Если они клянутся, что через пять минут исправят дефект и просят вас не заводить его в баг-трекинговую систему, знайте, в 70% случаев ошибка останется неисправленной, а вас потом могут обвинить в том, что вы пропустили дефект.

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

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

Проблемы, связанные с правильностью ведения баг-трекинговой системы

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

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

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

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

Именно для предотвращения подобных ситуаций, в кругу настоящих профессионалов дела, QA-инженеры используют мнемонику: «Что, где, когда»!

Вот ее расшифровка:

Что?

Что конкретно происходит или не происходит, по личному мнению тестировщика, когда он проверяет ПО?

Где?

В каком конкретном месте системной архитектуры была обнаружена ошибка?

Когда?

В какой конкретный момент функционирования ПО проблему можно обнаружить?

Если отчет об ошибке начинающего тестировщика не содержит этих условий – это очень плохой отчет.

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

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

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

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

Итоги

Каждый из нас может рано или поздно начать совершать даже самые простые и очевидные ошибки. Бояться подобного не стоит.

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

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

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

Помните, ваши ошибки – ваш опыт!