Работодателям не нужны "зрители", им нужны "умеющие". Именно поэтому после онлайн-лекций и вебинаров, где нужно просто посидеть и послушать, а потом сделать домашние задания, обычно так сложно найти первую работу. Знания на лекциях получить можно - но не столь нужные работодателю практические навыки.
Есть хорошая и плохая новость о получении новичками практических навыков.
Хорошая - сейчас на многих онлайн-курсах появилась возможность в конце обучения пройти стажировку на реальном IT-проекте.
Плохая - продолжительность подобных стажировок обычно пара недель. Для такого короткого периода работы никто на проекте не будет проводить полноценный онбординг QA-интерна. В результате ему достается или тестирование легаси, или что-то совершенно поверхностное. Такой опыт на будущем собеседовании не произведет впечатления на лида - если до собеседования вообще дойдет дело. В результате всё это обычно заканчивается предложением новичку все-таки пририсовать себе полгода-год фейкового опыта в резюме.
К сожалению или к счастью, с 2022 года у меня в Mentorpiece накопился большой опыт запуска продолжительных, 2-4 месяца, интернатур. И это действительно непростые в плане организации проекты - ведь интернатуры проходят в американских компаниях, а участвуют в н��х удаленно русские QA-джуны.
Эта статья про чек-лист подготовки такого непростого проекта, который позволяет избежать наиболее типичных проблем. Проблем, которые лишают интернов возможности получить ценный опыт, а компании - пользу.
Паспорта
Приходилось ли вам когда-нибудь при переговорах направлять потенциальному заказчику ссылку на сайт госдепа? Мне - да.
Многие интерны Mentorpiece являются обладателями красных паспортов. Примерно половина из них проживает пока на территории РФ, другая половина - уже находится в разных частях планеты - от США и Европы до ЮАР и Японии. И те и другие хотят начать международную карьеру в IT с нуля, но текущая международная обстановка создает определенные сложности. Особенно учитывая то, что интернатуры я организовываю в американских IT-компаниях.
Почему именно в американских? Потому что здесь много хорошо финансируемых стартапов. Потому что опыт работы в американской IT-компании котируется в любой части света (но не наоборот). Потому что здесь есть возможность получить передовой опыт - на всех организованных мной интернатурах сейчас идет тестирование AI-продуктов. Уже в начале карьеры интерны получают опыт, которого нет у большинства нынешних мидлов и сеньоров.
К счастью, тот самый госдеп на своем сайте разъясняет, что находящиеся на несанкционной территории обладатели санкционных паспортов ни под какие ограничения не попадают. И поэтому американские компании могут работать с ними без каких-либо рисков. Так как у меня сформировался пул принимающих интернатуры компаний, то есть пространство для маневра. Находящиеся вне санкционных территорий интерны подтверждают это документами и удаленно участвуют в интернатурах тех компаний, где юридические требования высокие. Компании, для которых санкционный вопрос не принципиален и местонахождение интернов не имеет значения, работают с остальными интернами.
Совмещение интересов компании и интернов
Что лучше - несколько сеньоров или десяток джунов?
Для любой компании выгодней иметь меньше сотрудников, но более высокой квалификации. Меньше управленческих расходов, меньше горизонтальных и вертикальных связей, проще коммуникация, выше качество.
На наше счастье, небольшие компании не могут позволить себе нужное число сеньоров. А джунов, особенно которые готовы поработать “за опыт”, могут.
Обычно главное опасение со стороны компании - “нам десяток джунов не нужен”. CTO вполне обоснованно боится, что такое количество неопытных тестировщиков может наломать дров и парализовать отдел разработки. Как это “купируется”, я писала два года назад на Хабре в статье Идеальные интернатуры после QA-курса: «едем» в солнечную Калифорнию и не только.
Если коротко, то это:
наличие двух лидов - один лид-ментор с опытом в тестировании 20+ лет от Mentorpiece (это я), который ставит процессы, и другой лид-интерн, который буферизирует все вопросы к владельцу продукта и разработчикам;
изначально правильное выстраивание всех процессов с правильным инструментарием;
максимальное следование Agile-практикам с ежедневными стендапами, еженедельными грумингами и ретроспективами - чем раньше узнаем про проблему, тем быстрее ее решаем.
Вообще переговоры между принимающей IT-компанией и нами начинаются в среднем за полгода. За это время нам нужно утрясти десятки вопросов.
Общие технические вопросы
Подготовку к интернатуре обычно начинаем с того, что определяем степень “разрушений” на проекте в общих чертах.
Какая на текущий момент есть функциональность, ее объем?
Что планируется сделать по функциональности в ближайший месяц? Три месяца?
Как сейчас организован процесс разработки?
Как сейчас в команде происходит коммуникация?
Кто руководит разработкой?
Кто владелец продукта?
Здесь обычно никаких проблем не возникает, так как речь идет про общие материи.
Что тестируем и как
Затем углубляемся в детали более предметно. Определяем объем работы (и приоритеты) на интернатуре с точки зрения всего, что касается Quality Assurance.
Выясняем что, как и в каком объеме нужно тестировать:
Повторное тестирование дефектов: ? (если да, то примерный объем за спринт)
Функциональное тестирование: ? (примерный объем за спринт)
Нефункциональное тестирование: ? (примерный объем за спринт)
Документация: проверяем/исправляем/создаем? (если да, то какую?)
Регресс и сопутствующее: ? (нагрузка, периодичность?)
Другие активности: ?
AI: какие задачи ?
Если в большинстве случаев “?” заменено на “да”, то всё в порядке.
Если “нет” - то пытаемся выяснить, почему принимающая интернатуру компания так уверена, что им это не нужно. В большинстве случаев после расспросов выясняется, что всё-таки нужно. В этот момент принимающая интернатуру компания, как правило, перестает волноваться по поводу того, а будет ли чем загрузить десяток джунов.
Затем идет кроющийся в деталях дьявол. Пытаемся понять, что происходит с процессами сейчас и какой здесь опыт смогут получить интерны. Если с процессами плохо, что в небольших компаниях скорее правило, чем исключение - то ничего страшного. Поможем, настроим, отладим.
Какому процессу следует команда?
Есть ли готовность вовлечь QA-интернов Mentorpiece во все ритуалы?
Число разработчиков? (Оптимально 5-7, минимально 2).
Их роли и ответственность?
Будет ли у интернов прямая коммуникация с ними?
Бизнес- и/или функциональные требования: в каком виде они есть (если есть), получат ли QA-интерны к ним доступ?
В подавляющем большинстве случаев требования восстанавливаем мы сами. Работаем часто со стартапами, а у них нет ни ресурсов, ни особого запроса их формировать - “все равно через полгода-год продукт изменится до неузнаваемости”. Но за эти полгода появившаяся документация очень сильно помогает команде разработки, а также ощутимо снимает нагрузку с владельца продукта.
После этого плавно переходим к главному - выясняем, какие технические скиллы смогут прокачать интерны в ходе работы:
Вид архитектуры (ожидаем DB + BE + FE)
БД (ожидаем реляционную): наличие и готовность предоставить QA-интернам доступ
Отсутствие жестких горящих сроков
Тестовая среда: она есть и к ней будет доступ
Тестовая среда: есть консольный доступ к бэкенду и/или логам
Тестовая среда: есть доступ к мониторингу (DEV/QA)
Багтрекинг: есть доступ (+ инструкции по работе с дефектами при их наличии)
Документация: есть доступ (how-to, руководства, описание, документы по тематике...)
Трекеры: какие используются?
Обычно самым большим камнем преткновения почему-то становится доступ к базе данных. Несмотря на подписанное NDA и готовность с нашей стороны получить базу пустой и заполнять ее тестовыми данными самостоятельно. На части проектов проблему удается решить, на части заказчик считает схему слишком большим ноу-хау. В последнее время в такой ситуации мы не упираемся, а пытаемся найти какое-то обходное решение, чтобы интерны все-таки получили опыт работы с DB. Например, на несколько дней подключаем их на интернатуру с открытой базой данных.
Проблемы, которые чаще всего приходится разъяснять “на пальцах” в стартапах:
Не понимают, зачем нужен project management tool для задач по тестированию. Говорят - пишите просто в слак то, что вы делаете. Как обходим: показываем наглядно, как выглядит наш процесс и как организуются наши задачи и наши спринты. Обычно это производит впечатление.
Не понимают, зачем вообще писать баги в какой-то баг-трекер. Считают, что большинству небольших компаний Google Sheets вполне достаточно. Решаем так же - подробно объясняем, какой у нас процесс, как мы линкуем баги с задачами и тест-кейсами.
Естественно, не понимают, зачем вообще нужны тест-кейсы и зачем тратить на них время. Очень помогают расчеты сколько денег в конечном итоге получится сэкономить.
Организационные вопросы
Как любой IT-проект редко может похвастаться тем, что всё идет по плану, так и редкая интернатура не сталкивается с проблемами. Но это не значит, что любому “косяку” можно найти оправдание перед интернами. Делаем выводы и пытаемся подстелить соломку заранее.
Поэтому в финальном чек-листе Mentorpiece следующие пункты:
Есть прямой контакт «лица принимающего решения», проявившего интерес к проекту (не ниже CEO/CTO)
Компания готова принять N интернов (не менее 10)
Команда находится в близких часовых поясах (лучше восточное побережье США, чем западное)
Степень доступности контактного лица со стороны заказчика
Нет необходимости посещать офис (на всякий случай проговариваем)
Не нужна образовательная лицензия в США от организатора с нашей стороны (на всякий случай проговариваем)
Есть ли бюджет для найма нескольких интернов после интернатуры и какой его размер?
Упоминание опыта работы интернов в конкретной компании не запрещено NDA (и они могут указать его в резюме)
CEO готов дать видеоотзыв о работе по окончании интернатуры
И, наконец, главное:
Все вышеуказанные условия зафиксированы «на берегу» минимум за 30 календарных дней до старта интернатуры
Результаты
Окупаются ли все эти затраты, которые только с точки зрения организации требуют до полугода подготовки?
Однозначно да.
Для заказчика можно было бы упомянуть снижение стоимости разработки, повышение кач��ства продукта и, как ни странно, снижение нагрузки на владельца продукта через вытаскивание “требований из его головы”.
Но ключевой KPI здесь другой - в конце интернатуры зачастую даже компании, которые изначально говорили, что у них нулевой бюджет на найм QA, в результате берут нескольких интернов в постоянный штат и совершенно по-другому начинают относиться к QA-процессам. И, что важно, потом сами приходят за следующей группой интернов.
Для интернов Mentorpiece польза тем более очевидна - те, кто прошли интернатуры ранее, сейчас уже работают в компаниях США, Канады и многих европейских стран. Будучи изначально “с нуля”, работу они получили без необходимости рисовать фейковый опыт в резюме - опыт продолжительной интернатуры удовлетворяет работодателя.
Приведу цитату одного из интернов:
Как я сказал на финальной ретроспективе, возможность поработать на полноценном бизнес-проекте в IT-компании - это то, что реально спасает на собеседованиях. Когда ты был вовлечен в рабочий процесс, это позволяет уверенно отвечать на вопросы собеседующего “Не знаю, как устроено у вас, но у нас на проекте было организовано вот таким образом”. И потенциальный работодатель видит, что ты действительно понимаешь, о чем говоришь.
Выводы
Приведенный чек-лист появился в результате двухлетнего опыта организации Mentorpiece международных интернатур для QA-джунов.
Каждая из них - это высокорисковый IT-проект с крайне высокой степенью динамики. Но при глубокой и правильной подготовке она причиняет максимальную пользу обеим сторонам.
Для принимающей компании она проходит не в режиме “ладно, из гуманитарных соображений возьмем несколько интернов, может быть, один окажется толковым”, а всего за несколько месяцев показывает, что рентабельность разработки можно резко повысить фактически с нулевым бюджетом.
А для интерна качественная интернатура позволяет в глазах работодателя превратиться из темной лошадки в того, кто начнет приносить пользу если не в первый месяц работы, то во второй точно.
Анонсы следующих Хабр-статей появятся в телеграм-канале “Становимся тестировщиком”.
Спойлер: одна из следующих статей - про best practices тестирования AI. По результатам постановки QA-процессов уже на трех AI-проектах.
