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