Комментарии 17
Эй, а где аргументы?)) Поделитесь, что не так? Постараюсь быть полезнее и интереснее
Думаю заминусили за очевидность, все советы даже не база, а азы, а совет про видео уроки вообще выглядит как то слишком уж специфически. Я представил что мне бы кто-то на проекте сказал записывать видео уроки по тестированию, я бы уволился в тот же день :) они ещё могут быть актуальны если проект максимально статичный и не развивается, а если он в процессе разработки, то придется выделять отдельного человека, который будет заниматься исключительно поддержкой этих уроков в хоть сколько-нибудь актуальном состоянии.
Спасибо! Знаете, бывает человек в курсе какой-то простой вещи, вроде существования клея БФ-6 (а бывает нет :)). Или взять с собой в путь забывает. Так и тут.
Я была бы рада, если мысль про запись пришла ко мне раньше. Мы записывали уроки по взаимодействию с инструментами и базовым функционалом. Вроде куда пойти, чтобы достать логи на шине. Кейсы по тестированию в видео формате не дублировали, боже упаси)
Просто, когда отдел расширяется, лучше один раз нажать на кнопку запись, объясняя типовые особенности проекта, чем повторять одно и тоже или ждать, что человек быстро освоится в накопившейся документации. Тут посмотрел выжимку и можешь сразу работать. Классно.
А сколько раз я слышала, что команда проводит тестирование документации на этапе, когда уже задача готова, ух! А собеседования в стиле Элен и ребята? Скажите, у кого их не было))
видео смотреть очень нудно и долго
А на Ютубе тоже нудно и долго?)
Да. Более того по видео не работает поиск, видео нельзя посмотреть по дороге в метро( можно, но даже в хороших наушниках слышимость порой оставляет желать лучшего ). Видео сложно обновить частично, если изменилась только часть его содержимого.
Да. Читать текст всегда проще и быстрее, особенно когда тебе нужно найти конкретный момент и пересматривать его несколько раз.
А еще, нету такой видеомысли котороую нельзя переложить в текст с фотографиями. С гифками на крайний случай.
Я думаю, минусы за то что вы написали статью про то как прийти на проект джуном, а в статье написали о том как прийти но проект менеджером. За это несоответсвие отхватили минусов.
А ведь так тоже можно - влиять на организацию не только своей работы в отделе тестирования.. Хочется верить, что ребята, которые только начинают свой путь смогут найти что-то ценное и подсказать коллегам важность декомпозиции задач и проведения ретро, например (если это будет нужно). Соглашусь заранее - собесы могут проводить другие ребята. И еще никаких ненавистных видяшек))
Я не знаю точно как вы себе представляете среднестатистического Джуна. Но 99.9 процентов того что вы написали не имеет (и не должно иметь) ничего общего с его работой на проекте по крайней мере в первое время.
Это задачи QA менеджера. Его уровень ответственности. То что стартапы в желании сэкономить нанимают на эти должности джунов должно считаться моветоном.
Таким образом ваша статья не отвечает на вопрос в заголовке.
Я представляю себе джуна как человека, которые знает базу тестирования, но не имеет значительного практического опыта. При этом человек как специалист в моем понимании не статичен. В процессе работы он растет.
Давайте разберем вместе список:
Согласовывать чек-листы с проверками
Планомерно создать пошаговые кейсы на базовый функционал
Поддерживать актуальность регрессионной модели
Собирать документацию на ресурсах общего доступа
Это скорее всего прямые обязанности джуна. +/- в зависимости от проекта
Использовать кейсы для обучения коллег
Можно, если кейсы пишутся хорошо. Видео можно не использовать, это обговорили выше
Тестирование требований, Uat-тестирование, Автоматизация регресса
Это точки роста для проекта и нашего джуна (не исчерпывающие)
Планерки и ретро, планирование задач, декомпозиция большого на части
Здесь скорее всего джуны будут принимать участие как специалисты. Если же у человека сильнее софт скиллы, он может вырасти в лида, вы правильно заметили.
Моя статья называется как не угробить проект даже если ты джун. Следуя этому плану нам удалось справиться с задачей, обозначенной в заголовке. Уверенна это один из множества вариантов. Хотя, как отмечали выше, для кого-то это понятная база.
Думаю, для людей без особого практического опыта, не все очевидно. Нужное можно взять на заметку, остальным голову не забивать.
Господи, ну давайте пройдемся по вашим пунктам.
1 Согласовать чек листы с проверками - с кем ? Из вашей статьи следует что вы на проекте один с кем и что вы собрались согласовывать ? С ПМом ? Да ему все равно вообще ревьюить их он не будет галку себе поставит "тестирование есть" и все на этом.
2 Это в целом тот максимум на который способен среднестатистический Джун. И конечно не в полной мере.
3 для того что бы поддерживать актуальность регрессионной модели - она для начала должна существовать, а для этого кто то должен ее написать а для этого сначала кто то должен выполнить пункт два. Ты на проекте один и ты Джун (это не я придумал это у вас так написано)
4 Тут я подозреваю "что то про документацию" но с точки зрения формализма написана белиберда. А с ресурсов к которым доступ есть только у вас а общего нет нельзя собирать ?
5 Каких коллег ? Кто вам сказал что в обозримом будущем будет расширение штата ? Некоторые люди годами работают на проектах в соло. Этот пункт полностью безсмысленен. Так как если изначально набирают не одного Джуна а отдел - то первым набирают как раз Лида что бы он нанял остальных.
6 Uat тестирование - это процесс сложный не столько технически сколько бюрократически. Обычно под него выделяется отдельный человек - бизнесу надо выделить каких то людей которые будут тратить на это свое время. Иногда согласование и подготовка занимает до полугода. Должна быть написана UAT документация для фокусгруппы.
7 Планерки и ретро, планирование задач, декомпозиция большого на части - тут у вас смешаны задачи организации процесса (которые вообще не имеют ничего общего с вашими обязанностями ни в каком качестве за это отвечает скрам мастер или ПМ в зависимости) и технические задачи.
У вас в статье нет вообще никакого плана что делать когда ты только пришел на проект. У вас в статье план - как строить свою карьеру в быстроразвивающейся проекте с хорошим финансированием если до этого вы поработали несколько лет в ентерпрайзе. Отсюда и минусы (я кстати не ставил )
В целом очень сильно чувствуется отсутствие опыта. С обучающими статьями я бы пока сильно повременил.
@SentarshiКажется, я поняла. Вы исходите из позиции, что джун не должен, а я с той, что он может. Может согласовывать кейсы с аналитиками, РП, бизнесом, в зависимости от проекта. Может начать продумывать регрессионную модель если ее нет и лучше узнать функционал. И далее по списку. Конечно, речь скорее идет про работу в крупных компаниях потому, что, как вы заметили, на стартап вероятнее возьмут сеньора. Спасибо, что нашли время расписать подробно. Ваше мнение очень ценно.
Как прийти в тестирование первым джуном и не лишить всех работы