Блог седого тестировщика

говориМ о тестировании
простым языком

7 ошибок начинающего тестировщика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

Share on vk
Vkontakte
Share on facebook
Facebook
Share on linkedin
LinkedIn
Share on twitter
Twitter

Автор статьи:

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Ближайшие события

Вам также может понравится