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