![](https://habrastorage.org/getpro/habr/upload_files/d0c/a3e/236/d0ca3e2368400328316bfcb187c0027b.jpg)
Наталья Скоробогатова
Младший тестировщик в ГК Юзтех
Введение
Путь, который проходят если не все, но очень многие — это этап выхода на первый проект в качестве джуна. Как это было и как могло быть? Как может проходить твой день в качестве младшего тестировщика?
Кажется, что всем известно, чем занимается программист, как проходит его день. Об этом написано достаточно статей в сети. А чем занимается тестировщик? А младший? Допустим, вы пришли в тестирование из совершенно другой сферы. Есть ли у вас представление, как будет проходить ваш день и что в целом вы будете делать? Для тех, кто только хочет попробовать себя в новой профессии или уже занимается на курсах и посещает собеседования, я расскажу о своём опыте.
Для начала пара слов обо мне. Это поможет лучше понять и прочувствовать то, о чём я говорю. Меня зовут Наталья, мне 23. В прошлом году я получила степень бакалавра в сфере Информационных систем и технологий. После этого около полугода я искала себя и наконец в феврале 2022 пришла в IT. Сейчас я младший тестировщик в ГК Юзтех. Три месяца я обучалась по внутрикорпоративной программе менторства и только после этого присоединилась к настоящему проекту по разработке внутреннего веб-продукта “Программа лояльности”.
![](https://habrastorage.org/getpro/habr/upload_files/b60/e64/8c9/b60e648c9aa234f035cb2f84dd134522.png)
Первые дни на проекте
Тут и начинается самое интересное. Казалось бы, я – джун, значит сейчас буду под руководством старшего коллеги, мне будут выдавать поручения, а я — старательно их выполнять. Как бы не так! Я оказалась первым и единственным тестировщиком на маленьком внутреннем проекте. Значило это только то, что налаживать процесс тестирования и выполнять все функции этого «старшего коллеги» мне придётся самостоятельно. Вся тестовая документация, заведение баг-репортов, отчёты по проделанной работе, коммуникация с командой – всё это ложилось на меня, джуна без опыта работы на проектах.
В тот момент передо мной был проект, где тестирования, как отдельного этапа разработки не было. Мне предстояло показать важность этого этапа и органично внедрить его в слаженный процесс работы команды над продуктом.
Мои ощущения в первые дни на проекте – это смесь шока, непонимания и неподдельного интереса. Чтобы влиться в проект любому сотруднику понадобится время, а джуну – так тем более! Интересно, как этот этап проходит в других компаниях? В Usetech на период обучения я была прикреплена к ментору, к которому и приходила плакаться, когда меня одну «бросили» на проект. Именно он рассказал, с чего нужно приступать к работе, какую информацию собрать и какие плюсы есть в моей ситуации. И теперь, пройдя этот этап, я могу попробовать поделиться своим опытом и, возможно, помочь начинающим тестировщикам на старте их карьерного пути.
«Тестировщик должен знать продукт лучше всех» — отличная цитата моего ментора. А что ещё необходимо сделать кроме этого:
Пообщаться о продукте с аналитиком и Проектным Менеджером (ПМ);
Ознакомиться с документацией;
Узнать главных героев истории, без которых не было бы продукта, — разработчиков, дизайнеров, кто за что отвечает;
Получить доступы (к стендам, к БД, к таск-менеджмент системе);
И многое другое…
![](https://habrastorage.org/getpro/habr/upload_files/831/f6e/947/831f6e947c4fac51f84208c69243dda2.png)
С чего начать работу?
На мой взгляд, лучший вариант знакомства с продуктом — это общение с командой. Ребята расскажут, зачем, почему и кому нужен продукт, над которым они трудятся. Аналитик и продуктовый менеджер ответят на все эти вопросы и обрисуют “бизнесовую” картину проекта. А также обязательно узнайте, как проходит процесс разработки на проекте: какой длительности спринты, как и когда проходят митинги.
Для каждого специалиста важно «влиться» в проект правильно. Проекты растут, и всегда есть вероятность подключения новых членов команды. Так, например, от того, как сложится мой выход на проект, будет зависеть успешность подключения новых тестировщиков или передача проекта другому специалисту.
![](https://habrastorage.org/getpro/habr/upload_files/c11/ba2/cb6/c11ba2cb6843e22aa0c55a7e4ee2a43d.png)
Следующим этапом будет ознакомление с документацией. Это может быть файл Word, с описанием того, что должно быть реализовано, как, когда и зачем, но в более сухом и формальном виде, нежели рассказы аналитика и ПМ-а в первом пункте. Тем не менее знание документации и работа с ней необходима, потому как тестирование продукта осуществляется именно в соответствии с заявленными требованиями. Если продукт сложный, то познакомиться с ним может быть проще через инструкцию пользователя. Это небольшой гайд, рассказывающий как пользоваться продуктом, но без технических подробностей. Поэтому ограничиваться только им не стоит.
-
Всё! С теоретической частью знакомства покончено, можно заглянуть под капот и идти знакомиться с разработчиками и другими членами команды. Как минимум стоит узнать у первых, на каких языках пишут ребята, где хранят данные проекта и как у них строится коммуникация. Как максимум — стоит попросить не выкатывать на тестовые и продовские стенды наработки втихаря :D У дизайнеров можно попросить доступы к макетам, они точно понадобятся для дальнейшего тестирования UI.
Если команда большая, на мой взгляд, очень хорошей практикой вначале будет ведение таблички в гугл-доках с контактами и важными ссылками. Это существенно облегчит поиск человека, к которому обращаться в случае необходимости. Путать аналитика и бэкера всё-таки нехорошо :D Со временем люди запомнятся, а ссылки перекочуют в закладки браузера. И, как говорил физик в универе: “Всегда делайте бэкапы”.
![](https://habrastorage.org/getpro/habr/upload_files/37c/0ce/692/37c0ce692e8f4bd8ee5ccfc865e2cb4d.png)
-
Поговорим о ссылках. Даже на самых маленьких проектах будет как минимум 2 стенда, в лучшем случае, 3 и больше. И на каждый нужно получить (или потребовать) ссылку. Как продолжение беседы с разработчиками, нужно попросить дать явки и пароли к этим стендам. Если ролей в системе несколько(админ и пользователь), то нужны доступы к каждому виду аккаунта.
На каждом хорошем проекте обязательно будут таск- и тест-менеджмент системы. Первая нужна для обрисовки задачек и отслеживания прогресса всей команде, а вторая — собственная вотчина тестировщика, где будут собираться чек-листы и тест-кейсы. Доступы могут быть как у ПМа, так и у разработчиков. В моём случае систему для чек-листов я настраивала сама и раздавала доступы команде.
Говоря о хранении данных, будет странно не упомянуть, что нужно попросить доступы к базам данных, к тестовым стендам доступы дадут без проблем. Совет: просите доступы ко всему, если хотите разобраться в структуре продукта. Навредить вряд ли получится, вам просто сразу дадут ограниченные права.
Заключение
И напоследок пара небольших универсальных советов, которые я часто слышала в начале своего обучения, и уверена, что их должен слышать каждый.
Часто, чтобы получить всю нужную информацию, нужно спрашивать. Много спрашивать. Иногда ОЧЕНЬ много. Это один из самых полезных советов, который во многом помогает мне даже в повседневной жизни. Когда мне случается понять что-то не до конца, я начинаю сомневаться: спросить еще раз или потом подумать и надеяться, что само дойдет. «Лучше спросить сейчас, боясь показаться глупым, но выполнить задание, чем промолчать, и в итоге подвести всю команду». Мне повезло, у меня замечательные коллеги по проекту, которые помогают разобраться во всех вопросах и изучить новые технологии.
Безусловно, развиваться в своей профессиональной области важно и нужно (вначале так это вообще первостепенная задача), но также не менее полезно приобретать навыки из смежных дисциплин. Мне, например, очень интересны дизайн и программирование. Навыки в этих сферах, на самом деле, помогают на проекте и при взаимодействии с командой. Например, при работе с веб-продуктами даже небольшие знания графических программ существенно облегчают жизнь тестировщику. То же можно сказать о понимании вёрстки и работе в DevTools.
Такая вот вышла моя первая статья. Хочется надеяться, что она будет многим полезной. Сейчас большинство вещей проще и удобнее найти в виде статей. Некоторые из них даже содержат уникальный собственный опыт. И я очень рада быть в ряду людей, которые не стесняются делиться своими наработками, исследованиями и знаниями. Я верю, что мой скромный опыт поможет другим тестировщикам не потеряться в пучине больших и интересных проектов, даже если ты единственный тестировщик на проекте.
Расскажите о своих первых днях на проекте? Какие у вас были ощущения?
Комментарии (5)
SolFJ
21.09.2022 10:41В таких компаниях, обычно тестирование за разработчиками - проблема самих разработчиков, вот и всё.
UseTech Автор
21.09.2022 11:07Как автор уточнил выше — он попал на внутренний небольшой проект. Наданный момент в компании более 70 тестировщиков, как ручников, так и автоматизаторов
volchenkodmitriy
Здравствуйте! Спасибо за статью! Меня бы очень насторожило "Я оказалась первым и единственным тестировщиком на нашем проекте." Не могу ничего сказать про Вашу компанию. Но меня бы это навело на мысль что компания не очень много внимания уделяет тестированию, а значит и качеству самого выходящего продукта, что может привести к нестабильности продаж и доходов компании, а это уже плохо для всех работников.
ggo
Вы видите прямую корреляцию между количеством тестировщиков и качеством конечного продукта?
UseTech Автор
Добрый день. Поделились кейсом начинающего джуна на небольшом внутреннем продукте, который находится в экосистеме компании. На всех коммерческих проектах и продуктах иерархия - классическая, и, в результате, не страдает качество проекта.