Наталья Скоробогатова
Младший тестировщик в ГК Юзтех
Введение
Путь, который проходят если не все, но очень многие — это этап выхода на первый проект в качестве джуна. Как это было и как могло быть? Как может проходить твой день в качестве младшего тестировщика?
Кажется, что всем известно, чем занимается программист, как проходит его день. Об этом написано достаточно статей в сети. А чем занимается тестировщик? А младший? Допустим, вы пришли в тестирование из совершенно другой сферы. Есть ли у вас представление, как будет проходить ваш день и что в целом вы будете делать? Для тех, кто только хочет попробовать себя в новой профессии или уже занимается на курсах и посещает собеседования, я расскажу о своём опыте.
Для начала пара слов обо мне. Это поможет лучше понять и прочувствовать то, о чём я говорю. Меня зовут Наталья, мне 23. В прошлом году я получила степень бакалавра в сфере Информационных систем и технологий. После этого около полугода я искала себя и наконец в феврале 2022 пришла в IT. Сейчас я младший тестировщик в ГК Юзтех. Три месяца я обучалась по внутрикорпоративной программе менторства и только после этого присоединилась к настоящему проекту по разработке внутреннего веб-продукта “Программа лояльности”.
Первые дни на проекте
Тут и начинается самое интересное. Казалось бы, я – джун, значит сейчас буду под руководством старшего коллеги, мне будут выдавать поручения, а я — старательно их выполнять. Как бы не так! Я оказалась первым и единственным тестировщиком на маленьком внутреннем проекте. Значило это только то, что налаживать процесс тестирования и выполнять все функции этого «старшего коллеги» мне придётся самостоятельно. Вся тестовая документация, заведение баг-репортов, отчёты по проделанной работе, коммуникация с командой – всё это ложилось на меня, джуна без опыта работы на проектах.
В тот момент передо мной был проект, где тестирования, как отдельного этапа разработки не было. Мне предстояло показать важность этого этапа и органично внедрить его в слаженный процесс работы команды над продуктом.
Мои ощущения в первые дни на проекте – это смесь шока, непонимания и неподдельного интереса. Чтобы влиться в проект любому сотруднику понадобится время, а джуну – так тем более! Интересно, как этот этап проходит в других компаниях? В Usetech на период обучения я была прикреплена к ментору, к которому и приходила плакаться, когда меня одну «бросили» на проект. Именно он рассказал, с чего нужно приступать к работе, какую информацию собрать и какие плюсы есть в моей ситуации. И теперь, пройдя этот этап, я могу попробовать поделиться своим опытом и, возможно, помочь начинающим тестировщикам на старте их карьерного пути.
«Тестировщик должен знать продукт лучше всех» — отличная цитата моего ментора. А что ещё необходимо сделать кроме этого:
Пообщаться о продукте с аналитиком и Проектным Менеджером (ПМ);
Ознакомиться с документацией;
Узнать главных героев истории, без которых не было бы продукта, — разработчиков, дизайнеров, кто за что отвечает;
Получить доступы (к стендам, к БД, к таск-менеджмент системе);
И многое другое…
С чего начать работу?
На мой взгляд, лучший вариант знакомства с продуктом — это общение с командой. Ребята расскажут, зачем, почему и кому нужен продукт, над которым они трудятся. Аналитик и продуктовый менеджер ответят на все эти вопросы и обрисуют “бизнесовую” картину проекта. А также обязательно узнайте, как проходит процесс разработки на проекте: какой длительности спринты, как и когда проходят митинги.
Для каждого специалиста важно «влиться» в проект правильно. Проекты растут, и всегда есть вероятность подключения новых членов команды. Так, например, от того, как сложится мой выход на проект, будет зависеть успешность подключения новых тестировщиков или передача проекта другому специалисту.
Следующим этапом будет ознакомление с документацией. Это может быть файл Word, с описанием того, что должно быть реализовано, как, когда и зачем, но в более сухом и формальном виде, нежели рассказы аналитика и ПМ-а в первом пункте. Тем не менее знание документации и работа с ней необходима, потому как тестирование продукта осуществляется именно в соответствии с заявленными требованиями. Если продукт сложный, то познакомиться с ним может быть проще через инструкцию пользователя. Это небольшой гайд, рассказывающий как пользоваться продуктом, но без технических подробностей. Поэтому ограничиваться только им не стоит.
Всё! С теоретической частью знакомства покончено, можно заглянуть под капот и идти знакомиться с разработчиками и другими членами команды. Как минимум стоит узнать у первых, на каких языках пишут ребята, где хранят данные проекта и как у них строится коммуникация. Как максимум — стоит попросить не выкатывать на тестовые и продовские стенды наработки втихаря :D У дизайнеров можно попросить доступы к макетам, они точно понадобятся для дальнейшего тестирования UI.
Если команда большая, на мой взгляд, очень хорошей практикой вначале будет ведение таблички в гугл-доках с контактами и важными ссылками. Это существенно облегчит поиск человека, к которому обращаться в случае необходимости. Путать аналитика и бэкера всё-таки нехорошо :D Со временем люди запомнятся, а ссылки перекочуют в закладки браузера. И, как говорил физик в универе: “Всегда делайте бэкапы”.
Поговорим о ссылках. Даже на самых маленьких проектах будет как минимум 2 стенда, в лучшем случае, 3 и больше. И на каждый нужно получить (или потребовать) ссылку. Как продолжение беседы с разработчиками, нужно попросить дать явки и пароли к этим стендам. Если ролей в системе несколько(админ и пользователь), то нужны доступы к каждому виду аккаунта.
На каждом хорошем проекте обязательно будут таск- и тест-менеджмент системы. Первая нужна для обрисовки задачек и отслеживания прогресса всей команде, а вторая — собственная вотчина тестировщика, где будут собираться чек-листы и тест-кейсы. Доступы могут быть как у ПМа, так и у разработчиков. В моём случае систему для чек-листов я настраивала сама и раздавала доступы команде.
Говоря о хранении данных, будет странно не упомянуть, что нужно попросить доступы к базам данных, к тестовым стендам доступы дадут без проблем. Совет: просите доступы ко всему, если хотите разобраться в структуре продукта. Навредить вряд ли получится, вам просто сразу дадут ограниченные права.
Заключение
И напоследок пара небольших универсальных советов, которые я часто слышала в начале своего обучения, и уверена, что их должен слышать каждый.
Часто, чтобы получить всю нужную информацию, нужно спрашивать. Много спрашивать. Иногда ОЧЕНЬ много. Это один из самых полезных советов, который во многом помогает мне даже в повседневной жизни. Когда мне случается понять что-то не до конца, я начинаю сомневаться: спросить еще раз или потом подумать и надеяться, что само дойдет. «Лучше спросить сейчас, боясь показаться глупым, но выполнить задание, чем промолчать, и в итоге подвести всю команду». Мне повезло, у меня замечательные коллеги по проекту, которые помогают разобраться во всех вопросах и изучить новые технологии.
Безусловно, развиваться в своей профессиональной области важно и нужно (вначале так это вообще первостепенная задача), но также не менее полезно приобретать навыки из смежных дисциплин. Мне, например, очень интересны дизайн и программирование. Навыки в этих сферах, на самом деле, помогают на проекте и при взаимодействии с командой. Например, при работе с веб-продуктами даже небольшие знания графических программ существенно облегчают жизнь тестировщику. То же можно сказать о понимании вёрстки и работе в DevTools.
Такая вот вышла моя первая статья. Хочется надеяться, что она будет многим полезной. Сейчас большинство вещей проще и удобнее найти в виде статей. Некоторые из них даже содержат уникальный собственный опыт. И я очень рада быть в ряду людей, которые не стесняются делиться своими наработками, исследованиями и знаниями. Я верю, что мой скромный опыт поможет другим тестировщикам не потеряться в пучине больших и интересных проектов, даже если ты единственный тестировщик на проекте.
Расскажите о своих первых днях на проекте? Какие у вас были ощущения?