Наталья Скоробогатова

Младший тестировщик в ГК Юзтех

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

В интернете можно найти много статей по запросу «ЧТО НУЖНО знать начинающему тестировщику»… КАК ПРАВИЛЬНО… ЧТО ВАЖНО… ПРИМЕРЫ… ШАБЛОНЫ…

Но очень мало где разбирают то, что получается на деле и как прийти от «неправильно» к тому самому «вот так надо». Предлагаю рассмотреть 5 не совсем выдуманных, а даже очень реальных ситуаций. Завариваем чашку чая, закутываемся в плед и начинаем!:)

Ситуация #1. «Тестировать! И как можно скорее»

Зачастую на первых порах начинающий специалист впадает в одну из крайностей: полный ступор (теорию знает, а как подступиться к тестированию на практике — нет) и «в омут с головой», желая протестировать всё и вся. Поговорим о последнем состоянии. Часто, когда просят «Проверь работу вот этой штуки», мы бросаемся писать проверки или даже сразу тыкать формочку, чтобы поскорее сказать «Вот! Вот тут не работает». И нам не особо‑то интересно, а что же будет служить доказательством некорректной работы приложения?

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

  • Можно накинуться с изощрёнными издевательствами на валидацию полей.

  • Английский, японский, хинди, а может эльфиский?

  • Амперсанд забыли!

  • Затереть до дыр кнопочку «отправить», посылая кучу спама на почту сервиса.

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

Вот и готов чек‑лист с 50+ проверками. Мы старались, перебрали все варианты — теперь‑то баги точно не пробегут мимо нашего всеобъемлющего чек‑листа!

Только одного мы не учли… Нужно было удостовериться, что юзернейм и почта из формочки отправляются в место хранения данных, формируя тем самым список потенциальных клиентов. И функционал этот, увы, не работает, мы же его не проверили. Получается не узнали, ЧТО именно нужно проверить, и заполняли ожидаемый результат так, как НАМ кажется правильным. Выходит, что какую‑то работу выполнили, а ответ никому неинтересен.

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

Ситуация #2 «Нельзя отвлекать коллег»

Представим следующую ситуацию: утром нам приходит письмо с просьбой срочно провести тестирование продукта и узнать, отвечает ли он новым дополнительным требованиям, которые только что прислал заказчик.

Глаза зацепились за некоторые пункты документа:

  1. Две кнопки должны быть в виде кошачьих лапок;

  2. Онлайн платформа должна соответствовать ФЗ и ГОСТу;

  3. Время загрузки главной страницы не более 1.2 с;

  4. На сайте должен быть реализован поиск по частичному совпадению.

А вопросов после прочтения оказалось даже больше:

  1. Закрадываются опасения, что чего‑то тут не хватает. А какие именно федеральные законы тут подразумеваются? Их же очень много!

  2. А госстандарты? Их точно не меньше!

  3. Время загрузки… Но при каких условиях? А если будет несколько тысяч параллельных пользователей нашего функционала одновременно?

  4. Реализован поиск. Хорошо… А где? В каком разделе? По каким полям будет искать? А если я по одной букве захочу искать. Найдёт?

  5. И самое интересное, лапки какого котика? Рыжего или серого? Точно ничего не забыли?

  6. Да, требования явно сырые, за полчаса разобраться не вышло, но тестировать‑то по ним нужно. Лучше всего узнать детали у аналитика. Только будет ли у него время объяснить? Или стоит поискать в других документах уточнения и не отвлекать коллегу?

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

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

Ситуация #3 «Да ну, глупый какой-то вопрос»

Иногда решая, стоит ли отвлечь коллегу, в голове возникает мысль: насколько важен этот вопрос? Может это вовсе глупость какая‑то, и я покажусь некомпетентным специалистом? Скажу честно, однозначного критерия оценки важности придумать невозможно. Разумеется спрашивать «Чай или кофе предпочитает коллега на завтрак?» не стоит. А вот если вопрос по рабочим моментам — придётся подумать. Для этого можно задать себе следующие вопросы:

  1. Позволит ли полученный ответ быстрее решить задачу?

  2. Есть ли возможность быстро найти ответ самостоятельно?

  3. На самостоятельные поиски нужно менее 30 минут?

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

Только если на все три вопроса есть уверенное «да‑да‑да», то в этом случае лучше приложить усилия и решить вопрос, не прибегая к посторонней помощи.

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

В любом случае помните, что обращаться за помощью не плохо и не стыдно. Стыдно утаить проблему и подвести команду.

Ситуация #4 “Тестировать? Без требований? Без проблем!”

Поговорим о некоторой вариации тестирования «на скорую руку» — тестировании без требований.

Для начала представим ситуацию: на проекте два тестировщика, помимо остальных членов команды. Разработчики залили новый функционал, и тестировщик (будем дальше для ясности называть Тестер1) берет его в работу.

Требований нет, вообще нет! Либо где‑то есть, но никто не знает где. Выхода тоже нет — тестирует AD‑HOC (интуитивным) методом, сам додумывая на основании пользовательского опыта, как должно работать. И в итоге находит несколько багов. Заводит, назначает на разработчиков, а на следующий день уходит в отпуск.

В дело вступает Тестер2. Баги пофиксили, залили. Ждать две недели нельзя, пока Тестер1 вернётся к работе, поэтому надо тестировать. А требований‑то нет. То, какую картину составил себе Тестер1, осталось в тайне. Тестер2 уже по своему опыту проверяет работу системы. Проверяет и понимает, что некоторые баги совсем и не баги, а вот другой функционал, который Тестер1 уже проверил и закрыл, не работает как следует!

А дальше вы уже знаете… Не самая приятная ситуация, согласны?

На самом деле сам процесс тестирования уже подразумевает сравнение фактического результата с ожидаемым, то есть требуемым. Ожидаемый результат нельзя брать просто так из головы или подразумевать. Всё, что получит пользователь при работе с продуктом, должно быть четко зафиксировано в документах. Даже если их нет, то стоит их где‑то зафиксировать — в вики, в тестовой документации (чек‑листах, тест‑кейсах, баг‑репортах). Только в таком случае в итоге получится изначально задуманный продукт. И также всегда стоит уделять особое внимание тестированию требований. Они наши лучшие друзья! Именно в требованиях можно узнать что и как должно работать (Если, конечно, документы в актуальном состоянии. Но об этом в другой раз).

Если вспомнить ситуацию 1 и раскрутить дальше, то выходит, что нам, как и в этот раз, нужно было узнать требования. ЧТО тестируем? ЧТО получим в ИТОГЕ? А если в требованиях нет ответа на наш вопрос, то вспоминаем ситуацию 2 и идём за уточнениями к аналитику.

Ситуация #5 “Профессионал всегда должен быть на связи”

Теперь немного о том, как работать при ненормированном графике. Сейчас это особенно актуально.

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

Нет, это не значит, что вам придётся работать больше 8 часов, но может потребоваться оставаться на связи +‑ 1 или 2 часа, чтобы, например, ответить на срочный небольшой вопрос.

В начале многим новичкам кажется, что они должны выкладываться не только на 100, но и на все 150%. Замечу, что это в итоге может сыграть злую шутку. В результате такой напряжённой и сверхурочной работы можно получить все признаки профессиональной усталости: от переутомления до выгорания.

Я верю, что можно быть хорошим специалистом, не отдавая работе все 24 часа в сутках.

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

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

А далее следует перейти к самому сложному, это — …

Вывод

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

Мы с вами разобрали всего пять разных ситуаций, но их гораздо больше. А все потому, что тестирование — это очень творческая и порой неординарная работа. Каждый день нам приходится учиться, прокачивая как хард, так и софт скиллы.

Но всего предусмотреть невозможно, поэтому приходите за помощью к коллегам и делитесь своим опытом, чтобы сделать свою и чью‑то жизнь чуточку легче. Ведь самое главное — получать от работы радость и позитив!

Комментарии (0)