Home

Автор: Елена Колбанова

Меня зовут Лена и я QA Engineer в Brickit, приложении для сканирования кубиков Lego. До этого мне довелось поработать в крупном зеленом банке. В этой статье я расскажу об отличиях корпорации и стартапа в разрезе процессов тестирования и разработки, а также дам несколько практических советов, которые в свое время пыталась отыскать в интернете. Так как все компании разные, интересно узнать, чем ваш опыт отличался от моего

1. Отличия корпорации от стартапа

Онбординг

В корпорации онбординг был выстроен так, что первое время я ничем, кроме него, не занималась. Мне давали задания только на взаимодействие с экосистемой компании, по сути меня учили заводить тикеты в Jira. И был у меня Buddy - дружочек для эмоциональной поддержки в период адаптации.

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

Документация

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

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

Процессы

В современной IT корпорации вы скорее всего столкнулись бы с интерпретацией Agile подхода, с внутренними гайдлайнами разработки и деплоя и в целом с очень хорошо выстроенными процессами. Например, на моем предыдущем месте работы на десятки команд был один независимый релизный цикл. Cтабильность цикла стояла над выполнением KPI и за этим следила безкопромисная релизная команда, в которую бизнесу иногда приходилось упираться. Поэтому к планированию относились очень серьезно. TMS были развиты настолько, что можно было узнать статус, зависимости и временную оценку всего.

А в стартапе релизного цикла может не быть. Процессы вполне могут заменяться переписками в Slack. На команду может быть одна Kanban доска, куда пишется совершенно все, что угодно. QA может проводиться на продe или вообще не проводиться. Все это разумные допущения в пользу скорости и гибкости до тех пор, пока стартап не начинает драматически расти.

Баги

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

Чтобы справиться с тучей багов на каждой итерации, придется учиться заводить баги быстрo и немного понизить свои стандарты баг-репорта. Но в этом есть 1 плюс: если бы меня после корпорации спросили “Какой самый интересный баг в твоей карьере?”, я бы долго и неловко молчала. Сейчас с десяток таких приходит на ум.

Право на ошибку

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

Знания и рост

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

В корпорации я по грейду была мидлом, но не ответила бы на вопросы “В чем отличия Android и iOS ” , “Как проводить UI тестирование” или “Чем альфа тестирование отличается от бета тестирования”. Потому что все эти вещи не входили в скоуп нашей команды. Наш маленький фронт не затрагивал ни один из platform specific функций. Мы пользовались готовыми UI-компонентами, тестировать которые - не наша работа. Тем более, мы ничего не знали про группы тестировщиков приложения. То есть, выходя из корпорации, я обладала очень специфическим набором знаний.

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

2. Что стоит “забрать” из корпорации?

Уметь масштабировать процессы - это круто.  Именно поэтому полезно видеть “большие” процессы, как в корпорациях.

Конечно, масштабированию не всегда место и время. Когда у продукта условно 1 сценарий использования, 1 тысяча пользователей и 5 человек в команде, не надо туда лезть. Но если у стартапа дела идут хорошо, рано или поздно эти цифры критически подрастут. Вырастет ответственность за качество продукта. В то же время нужно будет поддерживать динамику, выпуская больше фичей. В такие моменты процессы “интуитивные”, основанные на переписках и тестировании методом пристального взгляда, ломаются.

Меня наняли в стартап как первого тестировщика как раз в такой переходный момент. Я сразу оказалась в ступоре из-за того, насколько было непонятно, что и как команда делает.

Это стало триггером всей истории с развитием релизного процесса в Brickit. Спойлер: далеко не все big tech практики приживутся в стартапе, но что-то точно может. Пробовать такое - одна из самых ценных возможностей для QA.

3. Еще несколько практических советов

• Скомпенсируйте отстуствие онбординга welcome 1:1 встречами с членами команды и регуляркой с вашим менеджером/тимлидом, если он есть

• Не пытайтесь вести документацию, как вы делали это раньше. Не пытайтесь создавать исполняемые тест-раны, как вы делали в Jira, если cейчас вы работаете в “Блокноте” типа Notion или Trello. Заведите плоский список тест-кейсов с “что делать” и “чего ожидать”. Для багов оставьте главное: название, шаги воспроизведения, ОР+ФP, скриншоты/логи, статус. Все!

• Ориентируйтесь на Ad-hock и Monkey Testing подходы в той же степени, что и на тест-кейсы по документации. Регулярно будет ломаться в местах, о которых вы даже не догадывались

• Если нет своей документации, возьмите максимум от чужой, особенно, если тестируете интеграцию. Например, что можно нагуглить, если вы внедряете подписки: официальные доки Google Play, iOS sandbox, и вспомогательных сервисов типа RevenueCat или Adapty. В корпорации можно растерять навык гуглить, тк все полезное лежит в закрытой базе знаний типа Confluence. Так что про гугл не забываем!

• Сначала наденьте кислородную маску на себя, а потом помогите соседу. Перед тем, как думать в сторону улучшения процессов, организуйте свою документацию: баг трекер, таск-трекер, чек-листы. Выпустите пару релизов в прод

Заключение

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

Обсудить в форуме