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