Как не растеряться на новом проекте, когда ты джуниор-тестировщик: 5 главных советов

Как Junior QA вы можете попасть в действующий проект или только стартующий. В любом случае для начинающего это стресс. Вы можете нервничать, от этого растеряться и не знать наверняка с какой стороны лучше зайти в проект. Надеюсь, мои рекомендации облегчат вам этот путь.

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

1Узнайте о проекте и ваших задачах

Вход в проект начните с разговора с руководителем. Он — основной источник информации о проекте. Узнайте у него следующее:

• конкретные цели и задачи на проекте;
• ваши полномочия в команде;
• обязательные задачи;
• сроки на knowledge transfer, обучение, адаптацию в команде и начало работы.

Сопоставьте цели на проекте со своим планом профессионального развития (при его наличии). В идеале ваши карьерные и проектные цели должны сочетаться. Если есть несоответствия, поговорите об этом со своим лидом.

Возможно, следует скорректировать ваш личный план. Всегда лучше сделать это на старте.

Следующий разговор, скорее всего, будет с контактным лицом по проекту. Это может быть тест-лид, техлид или проектный менеджер. На встрече вам нужно хотя бы поверхностно узнать о проекте, его бизнес-домене, ориентировочно понять специфику задач, которые перед вами поставят. Эти задачи нужно сравнить с задачами от вашего непосредственного руководителя. Если руководитель сказал, что вы будете 100% времени заниматься автоматизацией, а техлид отрицает автоматизацию в принципе, это уже повод задуматься . Выясните, какова реальная ситуация на проекте и какой в ​​нем будет ваша роль. От этого зависят ваши дальнейшие действия.

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

• детали проекта, его архитектуру, имеющиеся модули и «ваш» модуль, если он предусматривается по плану;
• виды тестирования, проверяемые платформы и браузеры, используемые инструменты, технологии;
• задачи, которые будет ставить ментор, и ваши личные пожелания по собственной работе;
• оценка выполненных вами задач и общих результатов работы на проекте.

Наконец у вас должно сложиться целостное понимание того, что вы будете тестировать, как это будете делать и с кем.

2Подготовьтесь к работе

Как бы странно это ни звучало, советую начать с обустройства рабочего места. Оно должно быть удобным, в меру тихим, достаточно освещенным и эргономичным. Если работаете из home office в эвакуации вдали от дома, старайтесь сохранять душевное равновесие. Если это трудно, найдите другое место: уютное кафе, библиотеку с интернетом или коворкинг.

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

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

Такая минимальная подготовка позволит вам спокойно перейти к работе вместо того, чтобы паниковать и писать во все чаты с просьбой помочь.

3Познакомьтесь с коллегами и настройте коммуникацию

• Роли QA. Старайтесь определить, кто из тестировщиков за что отвечает. Уточняйте подробно, скажем, к кому обращаться за интеграцией с Salesforce, кто расскажет о логике приложения в целом, кому задавать вопросы по дизайну и т.д.
• Принципы существования проекта. Узнайте нюансы проектной команды в целом. Например, есть ли бизнес-аналитики или кто из программистов отвечает за тот или иной тестируемый модуль.
• Взаимодействие. Обязательно познакомьтесь с каждым специалистом, причастным к «вашему» модулю, обменяйтесь контактами, расспросите, чем конкретно они занимаются на проекте.

Что касается настройки работы, то первым пунктом будет овладеть Jira или любой другой системой менеджмента, которую использует ваша команда. Допускаю, что начинающий понимает, как устроена Jira и куда там смотреть. Советую прежде всего обратить внимание на следующие моменты:

• Формат тикетов и статусы, которые использует команда QA и проектная команда.
• Жизненный цикл тикетов и их воркфлоу — в какой последовательности передвигать тикеты по доске, в какие столбцы это делать и т.д.
• Формат баг-репортов — какие поля есть при создании отчета, нужно ли заполнять фикс-версию и в каких случаях нужны лейбы и т.д.
• Поиск существующих багов по проекту в Jira и имеющиеся фильтры.
• Незакрытые баги. Эта информация позволит лучше понять проект, избегать дублей и видеть наиболее проблемные части, на которые следует обращать особое внимание.

Выяснили все это? Теперь попытайтесь самостоятельно завести баг в Jira и отработать его стандартный воркфлоу.

4Изучите документацию

Следующий шаг — ознакомиться с базой знаний по проекту (Confluence или ей подобная), почитать рабочие Google Docs и всю информацию из других хранилищ, узнать специфические проектные знания, мануалы и программы обучения. Если времени на чтение маловато, попытайтесь понять хотя бы структуру этих знаний. Так вы будете знать, где искать нужную вам информацию в будущем.

Отдельно познакомьтесь с тестовыми артефактами и их форматом. Нелишне будет попрактиковаться в написании собственных — по аналогии с имеющимися. А еще узнайте о существовании перекрестного ревью ваших кейсов – о его принципах, порядке и роли.

5Переспросите у опытных коллег, что непонятно

И снова время для разговоров. Вернитесь к ментору и расспросите обо всем, что вам непонятно или о чем вам не хватает информации.

Иногда что-то выглядит вполне понятным, но немного странным — об этом тоже спросите.

Запуск нового проекта предполагает наличие большого количества вопросов. Поэтому максимально используйте это время с пользой для себя.

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

• Почему нужно заводить именно такой баг?
• Почему его нужно перемещать в Jira в указанный статус?
• Почему этот митинг в графике есть, а вы в нем не участвуете?
• Можно ли сократить количество митингов, чтобы вы могли больше времени уделить своим задачам?

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

Со своим непосредственным руководителем можете поделиться впечатлениями от проекта, что нравится, а что нет. Обсудите то, что вам показалось непонятным или странным, попытайтесь узнать причины этого. Самое время запланировать первые таски и дедлайны. Нелишне здесь будет посоветоваться, как вам действовать в случае возникновения какой-либо проблемы. И, наконец, вы готовы к работе!

Чтобы дальше развиваться как специалист, советую уделять внимание следующим основным аспектам деятельности QA:

• изучать новые инструменты и подходы в тестировании;
• развивать коммуникативные навыки;
• быть инициативным;
• обеспечивать качество на проекте или хотя бы стремиться к этому.

Мой главный совет всем джунам: всегда думайте, что вы делаете, как и зачем. Старайтесь улучшать каждый свой шаг от проекта к проекту. Так вы быстрее станете профессионалом в своем деле.