Пара слов обо мне:

Я Senior QA Engineer DexSys, ментор программы «Mentor in tech» и фасилитатор «IAmRemarkable».
Я работаю тестировщиком уже чуть больше 9 лет, и за это время я трижды была единственным, или почти единственным тестировщиком на проекте.

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

Теперь поговорим про плюсы и минусы.

Когда ты единственный тестировщик на проекте – с одной стороны, вся нагрузка ложится на твои хрупкие плечи, а с другой стороны — у тебя же полный карт-бланш! Ты можешь работать с теми инструментами, с которыми ты любишь работать, и внедрять те техники и практики, которые кажутся тебе наиболее эффективными.

Например, я обожаю Postman и не привыкла работать в Insomnia. Поэтому в моём проекте мы используем Postman.

Ты выстраиваешь процессы самостоятельно, и у тебя есть право на ошибку. Твои первые шаги будут не всегда удачными, но, скорее всего, никто на это не обратит внимание. Главное — суметь вынести из ошибок уроки и двигаться дальше.

Из минусов — я столкнулась с таким моментом: когда ты работаешь единственным тестировщиком, становится очень сложно следить за тенденциями рынка. Ты всё время варишься в собственном проекте, в каких-то технологиях, которые используются только на твоём проекте, и, так как загрузка довольно большая, не хватает времени остановиться, отдышаться, посмотреть, что вокруг.

Я однажды так сходила на собеседование и была крайне удивлена – мне казалось, что я прямо супер-спец, но неожиданно узнала о пробелах в своих знаниях. С тех пор я стараюсь гораздо шире смотреть на мир, обязательно сравнивать себя с рынком и задавать себе такие вопросы: «Я развиваюсь и иду туда куда мне хочется и так, как этого ожидает рынок? Мои действия совпадают с моими планами на будущее?»

С чего начать ваше погружение в продукт?

1) Прояснить ожидания от вас и вашей работы: определить круг полномочий и ответственности, который будет закреплён за вами. Если в проекте до этого не было тестировщика, ожидания могут быть сильно размазаны.
С кем вы можете прояснить эти ожидания? С техлидом или лидом тестирования. Возможно, он есть не в этой команде, а просто где-то в компании. Если у вас есть возможность его привлечь на такие встречи — пользуйтесь этим.

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

3) Выяснить, к кому с какими вопросами вы можете подойти. Тут я хотела бы обратить внимание, что к вам, как к единственному тестировщику, скорее всего, будет приходить бизнес. И это хорошо! Вам нужно выстраивать коммуникацию с бизнесом. Ваш бизнес может вам рассказать не только про приоритеты, но и про ближайшие цели, дать вам вектор развития продукта, но, самое важное, — он может помочь вам встретиться с конечными пользователями, а это кладезь полезной информации.

4) Закрепить это всё письмами, документами, на которые можно будет опереться в дальнейшем. Бюрократия, письма, артефакты – это лучшие друзья тестировщика. Во-первых, мы все люди, память нас иногда подводит, и бывает сложно вспомнить какие-то договоренности. А во-вторых, к тестировщику, как к последнему звену, всегда приходят со всеми ошибками и вопросами, и здорово, если у вас есть возможность на что-то опереться в этот момент.

Чем отличается погружение в новый проект и в проект с бэкграундом?

Старт в продукте с нуля — это очень классная история. Когда продукт только зарождается, бизнес очень открыто и подробно делится планами, вектором развития, и это всегда помогает команде сфокусироваться на результате. А у нас есть время продумать процессы и документацию, какие артефакты нам бы хотелось сохранять, какими инструментами удобно пользоваться.

Проект с нуля — это, конечно, единорог. У меня было два таких проекта: на первом я еще не поняла все эти фишки, а вот когда перешла в «ХоумБанк» — это был восторг: глаза горели, мы все знали куда мы идём, чего мы хотим. Это было очень драйвово.

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

Как выстраивать погружение в проект с бэкграундом?

Я всегда начинаю своё погружение в проект с бизнес-требований. Мне важно понимать бизнес-смысл и основные бизнес-процессы. На что обращать внимание при тестировании? С чего вообще начать? Я считаю, что начинать стоит с важных для бизнеса фич.

Если у вас вся логика на сервере, то серверные разработчики должны быть вашими лучшими друзьями. Важно найти с ними общий язык, попросить рассказать вам все, обратить внимание на какие-то важные моменты. После этого можно идти ещё раз в документацию и смотреть — то, что вам рассказали серверные разработчики, оно вообще совпадает с тем, что хотел бизнес или нет? Если нет, то запишите это себе — возможно, когда-то так было, а потом что-то поменялось.

Мне было комфортно такое погружение: я читала документацию, затем ходила с вопросами к разработчикам и аналитикам, и через 2,5 месяца я уже успешно выпустила в прод отдельный продукт — абсолютно новый процесс, в котором были задействованы новые интеграции.

Процессы

Очень часто я слышу, что в проекте нет никаких процессов, или процессы неправильные, нужно всё снести и построить заново.
Я призываю к тому, чтобы вы не рубили с плеча, не говорили: «Так, все неверно, давайте делать по-другому», а посмотрели и спросили, почему именно так устроены эти процессы?

Когда я пришла в свой последний проект, наши стендапы длились по часу, и мне казалось, что это неправильно, дейлик не может быть таким долгим. А потом я задала вопрос нескольким разработчикам: «Ребят, почему так?». И мне честно сказали, что у команды большая загрузка по встречам в течение дня, очень сложно найти время одновременно у серверных и клиентских разработчиков и аналитиков для обсуждения какой-то проблемы в конкретной задаче, а сразу после дейлика это очень удобно делать, для нашей команды это работает. То есть мы на дейлике собрались, обсудили, и дальше побежали делать, потому что прямо с утра у нас все вопросы снялись.
Таким образом, вот этот «неправильный» процесс стал частью моей жизни, и я не стремлюсь его исправлять, потому что я вижу, что он дает эффект.

Выстраивание этапов тестирования

Приходя в проект, где нужно выстраивать тестирование, вы наверняка будете опираться на классический «Software Testing Life Cycle»: анализ требований, планирование, разработка тест-кейсов, подготовка тестового окружения и, собственно, выполнение тестов и завершение тестирования.

Но реальность показывает, что мы не всегда можем точно придерживаться этого цикла. Например, вы попадаете в проект, где нет аналитики, где требования, в лучшем случае, описаны в таске. А в худшем случае — требования обсудили на оценке, сделали оценку, теперь, собственно, на это и опираемся. И тут вместо этапа анализа документации нам нужно провести дополнительную аналитику: собрать требования, понять с серверными разработчиками, как они планируют это делать, прояснить, с какими системами потребуется интеграция, если это есть проекте. То есть ещё до этапа планирования тестирования у нас будет отдельный большой этап работы с документацией, который я назвала бы «сбор требований». И это, конечно, абсолютно меняет наш взгляд на задачу.

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

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

Тестовая документация

Тут я хочу рассказать свой классный фейл: во времена работы в своем первом проекте с 0 я использовала написанные на коленке чек-листы. И, когда меня определили на проект с банковским приложением, я радостно понесла эту практику туда. А через полгода, когда мы вышли в прод, я поняла, что этого совсем недостаточно.
Дело в том, что когда мы начинали, я чётко помнила какой метод что нам должен возвращать. Через полгода — я не помнила ничего. Я тогда потратила все свои новогодние праздники, чтобы написать хоть какие-то тест-кейсы.
Нам сообщили о планах набрать вторую команду разработки и тестирования на другую функциональность этого приложения. И тут я почувствовала себя очень некомфортно! У меня было ощущение: «придут люди, а дома не прибрано». Придут тестировщики, а тут нет тестовой документации!

Смотрите на свой проект сразу реально. Если вы понимаете, что вектор развития подразумевает что-то масштабное — большую интеграцию, какое-то дальнейшее развитие, то, возможно, стоит сразу заморочиться с подробными тест-кейсами, с обращениями к серверу, с вызовами методов и разбором ответов, или хотя бы интеграций, и артефактами тестирования.
На моем текущем проекте с этим всё строго. У нас периодически пишутся даже видеопротоколы. Почему это важно? Чтобы бизнес видел, как проходит процесс.
Также, у нас по каждому большому процессу пишется памятка для бизнеса, со всеми скриншотами и логами. Я обожаю логи! Они помогают мне вообще во всём: писать моки для интеграционных сервисов, разбираться, что происходило на этапе тестирования, возвращался ли нам параметр, если вдруг в какой-то момент он перестал возвращаться.
Вам нужно подумать, какие артефакты тестирования нужно сохранять, чтобы через полгода зайти в таску, которую вы тестили, и понять, что там вообще происходило.

Оценка и приоритизация задач

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

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

Во-первых, наш мозг любит понятные и конечные действия. Если мы понимаем, сколько займет задача, то нам проще на ней сфокусироваться или разделить на такие части, на которых мы сможем сфокусироваться.

И вторая важная история: я не знаю ни одного мидла или сеньора, которому ни разу в жизни не пришлось делать оценку. Рано или поздно вы с этим столкнетесь.
Поэтому, если сейчас от вас этого не требуют — делайте это самостоятельно. Так у вас будет определенная аналитика: как часто вы попадаете в свою оценку, какая активность сколько времени у вас занимает.

Как оценивать задачи, если раньше никогда не оценивали?
1) Заведите табличку в Exel
2) Если боитесь белого листа, посмотрите Personal Software process. У них есть таблички с готовыми скриптами.

Кто должен приоритизировать задачи?

Часто бывает так, что тестировщику приходят семь задач от семи разработчиков, и возникает вопрос: «Что же делать? Какая самая важная?»
Так вот, приоритизация — это не задача тестировщика. Это задача бизнеса, продакт-оунера, команды, но не тестировщика. Бизнес лучше понимает стратегии и векторы развития продукта, и если у вас не принято приоритизировать задачи — вы должны приучить бизнес к этому.
То есть, вы должны каждый раз приходить и говорить: «Вот у меня есть семь задач, если сделаю вот эти три, то выйдет эта фича, если другие три, то вот эта фича, а если я не сделаю вот эту одну, то не выйдет никакая фича. Понятно, что с вот этой одной я начну, но какие задачи мне брать следующими, что важнее?».

Чему меня научила работа в проектах, как единственного тестировщика:

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

О себе нужно заботиться. В какой-то момент я забывала об этом, и у меня были двенадцатичасовые рабочие дни. Иногда я вставала в 4-5 утра, потому что нужно было протестировать функциональность, и заканчивала в 7-8 вечера. Это неплохо, такие переработки бывают обоснованы. Но в какой-то момент я поняла, что больше не люблю свою работу. Я не хочу идти в офис, а необходимость возвращаться в проект после отпуска вызывает у меня дрожь.

И тогда в моей жизни появился спорт. Я хожу в тренажерный зал три раза в неделю, вместо обеда или вечером, но обязательно три раза. Для меня это важно. Это очень сильно поменяло моё отношение к своему телу, у меня перестала болеть спина, и я поняла, что, в общем-то, есть жизнь за пределами работы.

Прогулки. Прогулки помогают мне справляться с переизбытком информации. Если у меня был стрессовый день — я обязательно одеваюсь и иду с квадратными глазами, ничего не видя, просто иду, и через час-полтора меня отпускает. У нас есть несколько путей вывода кортизола из организма, один из них — поплакать, другой — спорт, физическая активность, прогулки.

Хобби, не связанные с работой. Я обожаю читать книги, готовить, путешествовать, открывать для себя какие-то новые места, я получила сертификат Open Water Divers. Это то, что не связывает меня с работой.

Во всё остальное время я снова люблю свою работу. Берегите себя от выгорания, сейчас об этом очень много информации. А когда вы работаете единственным тестировщиком — вы единственный не только у себя, но и у команды. Команда на вас рассчитывает. И ходите в отпуск обязательно, не забывайте об этом.