3) Выяснить, к кому с какими вопросами вы можете подойти. Тут я хотела бы обратить внимание, что к вам, как к единственному тестировщику, скорее всего, будет приходить бизнес. И это хорошо! Вам нужно выстраивать коммуникацию с бизнесом. Ваш бизнес может вам рассказать не только про приоритеты, но и про ближайшие цели, дать вам вектор развития продукта, но, самое важное, — он может помочь вам встретиться с конечными пользователями, а это кладезь полезной информации.
4) Закрепить это всё письмами, документами, на которые можно будет опереться в дальнейшем. Бюрократия, письма, артефакты – это лучшие друзья тестировщика. Во-первых, мы все люди, память нас иногда подводит, и бывает сложно вспомнить какие-то договоренности. А во-вторых, к тестировщику, как к последнему звену, всегда приходят со всеми ошибками и вопросами, и здорово, если у вас есть возможность на что-то опереться в этот момент.
Чем отличается погружение в новый проект и в проект с бэкграундом?
Старт в продукте с нуля — это очень классная история. Когда продукт только зарождается, бизнес очень открыто и подробно делится планами, вектором развития, и это всегда помогает команде сфокусироваться на результате. А у нас есть время продумать процессы и документацию, какие артефакты нам бы хотелось сохранять, какими инструментами удобно пользоваться.
Проект с нуля — это, конечно, единорог. У меня было два таких проекта: на первом я еще не поняла все эти фишки, а вот когда перешла в «ХоумБанк» — это был восторг: глаза горели, мы все знали куда мы идём, чего мы хотим. Это было очень драйвово.
Таких плюшек, как время на погружение, как правило, нет в проекте с бэкграундом. Если проекту есть хотя бы год, то в нем уже есть база для изучения, и конечно, погружение в такой проект будет занимать время. Оно уже будет зависеть от размеров самого проекта.
Как выстраивать погружение в проект с бэкграундом?
Я всегда начинаю своё погружение в проект с бизнес-требований. Мне важно понимать бизнес-смысл и основные бизнес-процессы. На что обращать внимание при тестировании? С чего вообще начать? Я считаю, что начинать стоит с важных для бизнеса фич.
Если у вас вся логика на сервере, то серверные разработчики должны быть вашими лучшими друзьями. Важно найти с ними общий язык, попросить рассказать вам все, обратить внимание на какие-то важные моменты. После этого можно идти ещё раз в документацию и смотреть — то, что вам рассказали серверные разработчики, оно вообще совпадает с тем, что хотел бизнес или нет? Если нет, то запишите это себе — возможно, когда-то так было, а потом что-то поменялось.
Мне было комфортно такое погружение: я читала документацию, затем ходила с вопросами к разработчикам и аналитикам, и через 2,5 месяца я уже успешно выпустила в прод отдельный продукт — абсолютно новый процесс, в котором были задействованы новые интеграции.
Процессы
Очень часто я слышу, что в проекте нет никаких процессов, или процессы неправильные, нужно всё снести и построить заново.
Я призываю к тому, чтобы вы не рубили с плеча, не говорили: «Так, все неверно, давайте делать по-другому», а посмотрели и спросили, почему именно так устроены эти процессы?
Когда я пришла в свой последний проект, наши стендапы длились по часу, и мне казалось, что это неправильно, дейлик не может быть таким долгим. А потом я задала вопрос нескольким разработчикам: «Ребят, почему так?». И мне честно сказали, что у команды большая загрузка по встречам в течение дня, очень сложно найти время одновременно у серверных и клиентских разработчиков и аналитиков для обсуждения какой-то проблемы в конкретной задаче, а сразу после дейлика это очень удобно делать, для нашей команды это работает. То есть мы на дейлике собрались, обсудили, и дальше побежали делать, потому что прямо с утра у нас все вопросы снялись.
Таким образом, вот этот «неправильный» процесс стал частью моей жизни, и я не стремлюсь его исправлять, потому что я вижу, что он дает эффект.
Выстраивание этапов тестирования