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

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

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

1. Не нужна мне эта теория

Мы с вами уже обсуждали вопрос о необходимости изучения теории тестирования. Вывод был таким — изучать теорию нужно. Хотя бы самые основы.

Вот тут можно посмотреть что именно надо знать начинающему тестировщику https://vk.com/wall-172009645_1106

Для чего нужна теория?
Знание теории повышает шанс успешного исхода собеседования. Обычно собеседование состоит из теоретических вопросов и практических заданий. Если у вас в голове информация, что тестирование — это что-то связанное с поиском ошибок, и больше ничего нет, то вы даже не поймете основную часть вопросов. И о каком положительном исходе собеседования тогда может идти речь?

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

Вы можете сказать, что задание могут просто присылать и давать время на его выполнение. Хорошо, вы нагуглите ответы. А практическая часть? Как ее выполнить? Допустим, опять нагуглили. Даст ли это результат? Думаю, что при живой встречи сразу станет понятно, понимаете вы что-то в тестировании или нет.

Да и будет очень трудно общаться с командой на одном языке и выполнять поставленные задачи. Будет уходить много времени на осмысление и выполнение. И тут велика вероятность просто не пройти испытательный срок.

2. Думаете, что в продукте куча ошибок и все они лежат на поверхности

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

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

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

3. Невнимательное изучение ТЗ

Чем это чревато? Хотя бы тем, что вы будете тестировать не так, как надо и не то, что надо. Повысится вероятность принятия фичи за баг. Или вообще пропустите тестирование важного функционала.

Суть в том, что это ухудшит результат работы. А оно вам надо?

4. Несерьезно относитесь к оформлению баг-репорта

Криво оформленные баг-репорты — это, наверное, один из самых частых кошмарных снов разработчиков)

Многие начинающие тестировщики не до конца осознают важность этого документа. Почему-то считается, что главное — выловить баг. А уж описать его — это как-то второстепенно.

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

Если что, то вот тут я ранее писал как качественно оформлять баг-репорты https://vk.com/wall-172009645_243

5. Тишина вместо вопроса

Для руководителя и наставника самое ужасное, что новые сотрудники не задают вопросов. Я иногда вижу, что что-то идет не так и сотруднику явно не понятно, что нужно делать. Конечно, в таких случаях я сам начинаю «докапывать» его на предмет этого «непонятно». Но я то вижу это не всегда. И зачем это разглядывать и терять время, если сотрудник может просто спросить.

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

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

6. Не слушаете более опытных коллег

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

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

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

7. Верите на слово

Как говорится: доверяй, но проверяй.

Разработчик сказал, что это не баг и об этом давно известно? Проверяем в баг-трекере.
Коллега сказал, что так оформлять баг-репорт не надо? Идем к наставнику и уточняем. А заодно и спрашиваем, где вообще посмотреть требования к оформлению.
Написали в чат, что баг пофикшен? Правильно, идем и проверяем. И самое главное, не верьте разработчику, когда он говорит, что здесь багов нет и тестировать не надо.

Понятно, что в новом коллективе и в новой должности много всего неизвестно. Но никогда не верьте на слово. Всегда все проверяйте.

***

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