Наталья Скоробогатова
Младший тестировщик в ГК Юзтех
Всем привет! Меня зовут Наташа, и я уже год являюсь тестировщиком в компании Usetech. Это моя вторая статья из серии статей, посвященных начинающим специалистам, в которой я хочу поделиться своими историями и опытом работы. Предыдущую статью вы можете прочитать по ссылке. Эта статья в первую очередь предназначена для начинающих тестировщиков, а старшим коллегам, возможно, захочется поделиться своими советами в комментариях.
В интернете можно найти много статей по запросу «ЧТО НУЖНО знать начинающему тестировщику»… КАК ПРАВИЛЬНО… ЧТО ВАЖНО… ПРИМЕРЫ… ШАБЛОНЫ…
Но очень мало где разбирают то, что получается на деле и как прийти от «неправильно» к тому самому «вот так надо». Предлагаю рассмотреть 5 не совсем выдуманных, а даже очень реальных ситуаций. Завариваем чашку чая, закутываемся в плед и начинаем!:)
Ситуация #1. «Тестировать! И как можно скорее»
Зачастую на первых порах начинающий специалист впадает в одну из крайностей: полный ступор (теорию знает, а как подступиться к тестированию на практике — нет) и «в омут с головой», желая протестировать всё и вся. Поговорим о последнем состоянии. Часто, когда просят «Проверь работу вот этой штуки», мы бросаемся писать проверки или даже сразу тыкать формочку, чтобы поскорее сказать «Вот! Вот тут не работает». И нам не особо‑то интересно, а что же будет служить доказательством некорректной работы приложения?
Вот, например, возьмём обычную маленькую симпатичную формочку. Она встречается чаще, чем на каждом втором сайте, и, возможно, поэтому мы заранее уверены в том, что знаем, как ее тестировать.
Можно накинуться с изощрёнными издевательствами на валидацию полей.
Английский, японский, хинди, а может эльфиский?
Амперсанд забыли!
Затереть до дыр кнопочку «отправить», посылая кучу спама на почту сервиса.
Осведомиться, как чувствует себя бедная формочка в разных браузерах, в том числе архаичных по типу IE….
Вот и готов чек‑лист с 50+ проверками. Мы старались, перебрали все варианты — теперь‑то баги точно не пробегут мимо нашего всеобъемлющего чек‑листа!
Только одного мы не учли… Нужно было удостовериться, что юзернейм и почта из формочки отправляются в место хранения данных, формируя тем самым список потенциальных клиентов. И функционал этот, увы, не работает, мы же его не проверили. Получается не узнали, ЧТО именно нужно проверить, и заполняли ожидаемый результат так, как НАМ кажется правильным. Выходит, что какую‑то работу выполнили, а ответ никому неинтересен.
Поэтому логичнее было перед началом выполнения задания ознакомиться с требованиями, либо напрямую спросить у аналитика, каким требованиям должна отвечать форма. Отсюда вытекает плавно следующая история.
Ситуация #2 «Нельзя отвлекать коллег»
Представим следующую ситуацию: утром нам приходит письмо с просьбой срочно провести тестирование продукта и узнать, отвечает ли он новым дополнительным требованиям, которые только что прислал заказчик.
Глаза зацепились за некоторые пункты документа:
Две кнопки должны быть в виде кошачьих лапок;
Онлайн платформа должна соответствовать ФЗ и ГОСТу;
Время загрузки главной страницы не более 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 отпускных дней, не меньше. Качественно и плодотворно отдыхать — это тоже навык, который нужно обязательно развивать.
А далее следует перейти к самому сложному, это — …
Вывод
Что хочется сказать в итоге? Не нужно опрометью бросаться тестировать, как и в любом другом деле: к решению стоит подходить взвешенно и размеренно. Качественная и продуктивная работа над проектом — это общая цель команды. Поэтому обращаться за помощью не стыдно, если это поможет скорее решить задачу. Но выбирать вопросы нужно обдуманно! Кроме того, важно помнить о требованиях к разрабатываемому продукту, чтобы получить в итоге то, что было задумано. И последнее, но не менее важное — никогда не нужно забывать про отдых, здоровье и личную жизнь. Продуктивность на работе прямо зависит от морального и физического состояния человека.
Мы с вами разобрали всего пять разных ситуаций, но их гораздо больше. А все потому, что тестирование — это очень творческая и порой неординарная работа. Каждый день нам приходится учиться, прокачивая как хард, так и софт скиллы.
Но всего предусмотреть невозможно, поэтому приходите за помощью к коллегам и делитесь своим опытом, чтобы сделать свою и чью‑то жизнь чуточку легче. Ведь самое главное — получать от работы радость и позитив!