Представьте классический проект в котором есть только огрызки документации. Ранее тестирование проводили аналитики, а вы первый тестировщик, да еще без особого практического опыта. Ошибки на бою могут доходить до миллионных штрафов, вплоть до отзыва лицензии на деятельность.
Думаю, по ощущениям это похоже на пилотаж болида Формулы-1 без подготовки.
Коллеги, доброе утро. На этой неделе заканчиваем работу по доработкам swift-rur. На следующей готовим отчётность по нерезидентам. Также нас ждут изменения по санкционным спискам. И еще по дороге мы решили взять под крыло один банк — мигрировать базу будем на новогодние. Нужно обеспечить контроль.
Кстати, сегодня к нам пришел тестировщик...
Что имеем по прибытию?
Вместо обучения мне досталась задача на проверку целого модуля. Аналитик написал инструкцию по воспроизведению на почту, приложил доку в ворде и пошел в отпуск.
Это было недели две ада. Одна проверка могла длиться до 4х часов. А в конце она падала. И непонятно — то ли я не очень, то ли оно не работает. В перерывах я готовила данные, изучала материалы, а в моменты отчаяния звонила аналитику в отпуске и периодически заглядывала проверить результаты в ночи.
Не повторяйте такое погружение у себя на проекте. Вы рискуете тем, что человек либо не справится и найдет миллион оправданий почему работа сделана плохо/не сделана, либо с такими процессами он просто сгорит.
Ну, а мне за старания досталась задача на другой модуль, который забросили еще в прошлом году. Только на изучение требований и уточнения работы ушло часов 60. В процессе я узнала, что в 7м файле 5й разработки есть дополнения. Была еще проблема с неучтенным влиянием на смежный функционал. А потом разработчик уволился.
Как из этого выбираться? Коротко
Согласовывать чек-листы с проверками
Планомерно создать пошаговые кейсы на базовый функционал
Использовать эти кейсы для обучения коллег
Записать серии видео-уроков для новых сотрудников
Поддерживать актуальность регрессионной модели
Планировать задачи в релиз заранее
Обязательно декомпозировать большое на части
Проводить не только планерки, но и ретро
Собрать документацию на ресурсах общего доступа
Внедрить тестирование требований
Автоматизировать регресс
Организовать uat-тестирование
Что нас ждало на практике? За что мы взялись в начале?
Я начала с составления пошаговых кейсов на весь функционал с которым мне приходилось сталкиваться. Бывало, что где-то в запаре детали воспроизведения шли к черту. Предусловия? Запомню, ага.
Наивнее того, что с нашей нагрузкой и разнообразием задач я смогу воспроизвести это спустя хотя бы месяц придумать сложно... Важное пришлось переделать. Остальное похоронили как есть.
Даже если вы думаете, что никто во веки вечные не увидит ваши кейсы — соблюдайте правила их создания. Хотя бы для себя. А если напарник все-таки будет, то вы сможете использовать нажитое добро для обучения. Больше воспроизводимых кейсов — меньше дергают по пустякам.
Но что если у вас появится второй напарник, а потом третий?
Тут мне стало ясно как глупо было не записывать видео-уроки с самого первого дня. Пришлось повторить одно и тоже трижды до того как я внедрила обязательную запись на часто задаваемые вопросы при погружении.
Думаете масштабироваться? Создавайте базу для обучения и легкого получения необходимых доступов. При возможности делегируйте административные вопросы отдельному специалисту.
К слову, через наш отдел в том году прошло человек 8. Мы уже отточили процесс адаптации и это отдельная история на миллион, но в кратком обзоре нас уже ждет проблема самого найма.
К этому рабочему снаряду можно подходить по-разному, но я вижу огромные плюсы участия в собеседованиях специалистов, знающих особенности проекта. Так, с большей вероятностью вы наймете тех, кого нужно. И перестанете тратить ресурсы отдела на обучение впустую.
Не сложно догадаться, что на собеседования я начала звать себя. Позже подключила ребят, которые имеют достаточно опыта. Оказалось, два специалиста с разными скиллами сильно лучше, чем один.
Только не зовите на собеседования всю команду, ей богу. Один человек с развитыми хард скиллами, второй с софт. И еще, по возможности продумайте заранее как будете мотивировать коллег на сотрудничество по факту их роста.
Не забывайте, после того как вы избавитесь от необходимости зарезать людей на испытательном сроке, можно столкнуться с тем, что вам нечего предложить талантливым специалистам позднее.
А что там по тестированию, кроме организации?
Поднятие регрессионной модели с нуля. Сейчас мы смочим базовый функционал в релизном цикле на регулярной основе и находимся на стадии автоматизации проверок. Еще чуть-чуть и вырастем до присоединения отдельной регрессионной команды.
Проведение и поддержка регресса — это отдельная активность, которая требует постоянного внимания. Но она дает отличные результаты, вроде уменьшения инцидентов на бою.
Не меньше сил мы вложили в описание модулей на ресурсах общего доступа. Зато!
Документация на ресурсах общего доступа не только оберегает проект от фактора автобуса, но и позволяет выработать внутренний регламент тестирования документации. А значит вы сможете внедрить эту активность не по форме, а по содержанию.
Мы прошли этот путь за 1,5 года. У нас были свои победы и поражения. Но главное, террористы остались без сладкого на Новый год.
Комментарии (16)
TipTopych
21.05.2022 19:31+2Думаю заминусили за очевидность, все советы даже не база, а азы, а совет про видео уроки вообще выглядит как то слишком уж специфически. Я представил что мне бы кто-то на проекте сказал записывать видео уроки по тестированию, я бы уволился в тот же день :) они ещё могут быть актуальны если проект максимально статичный и не развивается, а если он в процессе разработки, то придется выделять отдельного человека, который будет заниматься исключительно поддержкой этих уроков в хоть сколько-нибудь актуальном состоянии.
DinaSays Автор
21.05.2022 20:18Спасибо! Знаете, бывает человек в курсе какой-то простой вещи, вроде существования клея БФ-6 (а бывает нет :)). Или взять с собой в путь забывает. Так и тут.
Я была бы рада, если мысль про запись пришла ко мне раньше. Мы записывали уроки по взаимодействию с инструментами и базовым функционалом. Вроде куда пойти, чтобы достать логи на шине. Кейсы по тестированию в видео формате не дублировали, боже упаси)
Просто, когда отдел расширяется, лучше один раз нажать на кнопку запись, объясняя типовые особенности проекта, чем повторять одно и тоже или ждать, что человек быстро освоится в накопившейся документации. Тут посмотрел выжимку и можешь сразу работать. Классно.
А сколько раз я слышала, что команда проводит тестирование документации на этапе, когда уже задача готова, ух! А собеседования в стиле Элен и ребята? Скажите, у кого их не было))
hellamps
22.05.2022 04:59видео смотреть очень нудно и долго
DinaSays Автор
22.05.2022 06:50А на Ютубе тоже нудно и долго?)
Ritan
22.05.2022 19:50Да. Более того по видео не работает поиск, видео нельзя посмотреть по дороге в метро( можно, но даже в хороших наушниках слышимость порой оставляет желать лучшего ). Видео сложно обновить частично, если изменилась только часть его содержимого.
DinaSays Автор
22.05.2022 20:18Все обучающие каналы на Ютубе в топку, правильно)) И у себя все сожгу завтра. А то вдруг ребята вместо погружения на рабочем месте начнут подрубаться к удаленке в метро, не смогут открыть видео и ничего не услышат. Не буду никого расстраивать больше))
Ritan
22.05.2022 21:13Вы можете играть в сарказм сколько угодно, фактов это не изменит. Видео - довольно плохой формат для обучающих материалов и просто неприемлемо ужасный - для справочных.
Обучающие каналы на ютубе - развлекательный материал. Сейчас очень многие люди верят в идею, что можно чему-то научиться, играя
AnonimYYYs
22.05.2022 23:04Да. Читать текст всегда проще и быстрее, особенно когда тебе нужно найти конкретный момент и пересматривать его несколько раз.
А еще, нету такой видеомысли котороую нельзя переложить в текст с фотографиями. С гифками на крайний случай.
Sentarshi
22.05.2022 20:20Я думаю, минусы за то что вы написали статью про то как прийти на проект джуном, а в статье написали о том как прийти но проект менеджером. За это несоответсвие отхватили минусов.
DinaSays Автор
22.05.2022 21:33А ведь так тоже можно - влиять на организацию не только своей работы в отделе тестирования.. Хочется верить, что ребята, которые только начинают свой путь смогут найти что-то ценное и подсказать коллегам важность декомпозиции задач и проведения ретро, например (если это будет нужно). Соглашусь заранее - собесы могут проводить другие ребята. И еще никаких ненавистных видяшек))
Sentarshi
22.05.2022 21:39Я не знаю точно как вы себе представляете среднестатистического Джуна. Но 99.9 процентов того что вы написали не имеет (и не должно иметь) ничего общего с его работой на проекте по крайней мере в первое время.
Это задачи QA менеджера. Его уровень ответственности. То что стартапы в желании сэкономить нанимают на эти должности джунов должно считаться моветоном.
Таким образом ваша статья не отвечает на вопрос в заголовке.
DinaSays Автор
22.05.2022 23:01Я представляю себе джуна как человека, которые знает базу тестирования, но не имеет значительного практического опыта. При этом человек как специалист в моем понимании не статичен. В процессе работы он растет.
Давайте разберем вместе список:
Согласовывать чек-листы с проверками
Планомерно создать пошаговые кейсы на базовый функционал
Поддерживать актуальность регрессионной модели
-
Собирать документацию на ресурсах общего доступа
Это скорее всего прямые обязанности джуна. +/- в зависимости от проекта
-
Использовать кейсы для обучения коллег
Можно, если кейсы пишутся хорошо. Видео можно не использовать, это обговорили выше
-
Тестирование требований, Uat-тестирование, Автоматизация регресса
Это точки роста для проекта и нашего джуна (не исчерпывающие)
-
Планерки и ретро, планирование задач, декомпозиция большого на части
Здесь скорее всего джуны будут принимать участие как специалисты. Если же у человека сильнее софт скиллы, он может вырасти в лида, вы правильно заметили.
Моя статья называется как не угробить проект даже если ты джун. Следуя этому плану нам удалось справиться с задачей, обозначенной в заголовке. Уверенна это один из множества вариантов. Хотя, как отмечали выше, для кого-то это понятная база.
Думаю, для людей без особого практического опыта, не все очевидно. Нужное можно взять на заметку, остальным голову не забивать.
Sentarshi
23.05.2022 07:21Господи, ну давайте пройдемся по вашим пунктам.
1 Согласовать чек листы с проверками - с кем ? Из вашей статьи следует что вы на проекте один с кем и что вы собрались согласовывать ? С ПМом ? Да ему все равно вообще ревьюить их он не будет галку себе поставит "тестирование есть" и все на этом.
2 Это в целом тот максимум на который способен среднестатистический Джун. И конечно не в полной мере.
3 для того что бы поддерживать актуальность регрессионной модели - она для начала должна существовать, а для этого кто то должен ее написать а для этого сначала кто то должен выполнить пункт два. Ты на проекте один и ты Джун (это не я придумал это у вас так написано)
4 Тут я подозреваю "что то про документацию" но с точки зрения формализма написана белиберда. А с ресурсов к которым доступ есть только у вас а общего нет нельзя собирать ?
5 Каких коллег ? Кто вам сказал что в обозримом будущем будет расширение штата ? Некоторые люди годами работают на проектах в соло. Этот пункт полностью безсмысленен. Так как если изначально набирают не одного Джуна а отдел - то первым набирают как раз Лида что бы он нанял остальных.
6 Uat тестирование - это процесс сложный не столько технически сколько бюрократически. Обычно под него выделяется отдельный человек - бизнесу надо выделить каких то людей которые будут тратить на это свое время. Иногда согласование и подготовка занимает до полугода. Должна быть написана UAT документация для фокусгруппы.
7 Планерки и ретро, планирование задач, декомпозиция большого на части - тут у вас смешаны задачи организации процесса (которые вообще не имеют ничего общего с вашими обязанностями ни в каком качестве за это отвечает скрам мастер или ПМ в зависимости) и технические задачи.
У вас в статье нет вообще никакого плана что делать когда ты только пришел на проект. У вас в статье план - как строить свою карьеру в быстроразвивающейся проекте с хорошим финансированием если до этого вы поработали несколько лет в ентерпрайзе. Отсюда и минусы (я кстати не ставил )
В целом очень сильно чувствуется отсутствие опыта. С обучающими статьями я бы пока сильно повременил.
DinaSays Автор
23.05.2022 08:54@SentarshiКажется, я поняла. Вы исходите из позиции, что джун не должен, а я с той, что он может. Может согласовывать кейсы с аналитиками, РП, бизнесом, в зависимости от проекта. Может начать продумывать регрессионную модель если ее нет и лучше узнать функционал. И далее по списку. Конечно, речь скорее идет про работу в крупных компаниях потому, что, как вы заметили, на стартап вероятнее возьмут сеньора. Спасибо, что нашли время расписать подробно. Ваше мнение очень ценно.
Sentarshi
24.05.2022 07:33Вы исходите из того что Джун теоретически может, если ему на проекте не надо заниматься собственно тестированием.
Пожалуйста.
DinaSays Автор
Эй, а где аргументы?)) Поделитесь, что не так? Постараюсь быть полезнее и интереснее