Всем привет, нужен совет бывалых особенно кто был в похожей

ситуации
Скажите кто сталкивался с ситуацией когда вы Джун qa один в компании, вообще тестирования раньше не было, есть вообще смысл начинать писать тест план? Кто какие советы вообще даст буду рад выслушать, я думаю я не один такой

хороший смысл начать первым

Стоит начать и выстроить процесс, не упираясь только в тестплан и тесткейсы)

он джун. стоит начать с малого

Если есть пример организации с других командах/компаниях можно надергать с вершков интересное для себя, а потом уповать, что кто-то более скиловый "прийдет и порядок наведет"

Многие бывалые бывали :) Всю вашу тестерскую деятельность можно разделить на два направления, которые я условно называю "внешнее" и "внутреннее". Внешнее направление - то, где вы взаимодействуете с другими участниками процесса разработки: собственно разработчики, техподдержка, дизайнеры и другие. Что тут нужно? Во-первых, баг-трекер. Если вдруг его еще нет, то заводить прямо первым делом. Если какой-то баг-трекер уже есть - то обсуждаете ЖЦ задач в нем. Какие статусы, на кого назначены задачи, какуие условия перехода, ну и все такое прочее. Также договариваемся, в каком формате и на каком стенде будут передаваться задачи на тестирование. Пытаемся договориться про code freeze и feature freeze. В мелком стартапе не взлетит, наверно, но начать нужно :) Внутреннее направление - это то, как вы сами будете организовывать свою работу. Если никому тест-план не нужен - то, конечно, писать не стоит. Тест-кейсы? Не уверен. Скорее всего, чек-лист в эксельке - то, с чего можно начать. По ходу решите, нужна ли вам система управление тестированием. Также сразу подумайте, как вы будете работать с тестовыми данными, тестовыми стендами. Плюс документируете все то, что напрямую к тестированию не относится, но является ценной информацией. Может оказаться так, что через год вы станете единственным человеком, который знает, как работает система в целом :)

без планов и кейсов на старте вы процесс не выстроете

спс дружище, это было полезно

Чек листы намного более атомарны для развития и в них нет монстроузных цепочек переходов итд, котороые обычно любят пихать в тест кесты. А для развития можно спокойно использовать связку документация - чеклист - распределение ответственности

ну чек лист можно автоматизировать. большую часть.

у меня такое было, но и у меня опыта не было. я писала все, до чего могла додуматьься из документации

надеюсь все успешно?

может в команде есть кто подскажет?

да что и как делать понимание есть, просто хотел послушать мнения людей которые в таких ситуациях были)

На джуновском канале был дневник джуна(поищите по хэштегу), там, как раз, ваша ситуация

+1 к сообщению от Alina выше , аналогично , все по-немногу осваивала и делала чеклисты, потом кейсы на сложные функции, потом уже как время повялялось процедуры описывала по подготовке к релизу ( регрессию) и далее. Вторая работа после этой также была с нуля - но тут уже появился опыт и получалось быстрее :)

ну... 9 месяцев я там проработала, потом ушла в лучшую компанию. опыт точно классный, но тогда мне так не казалось)

Был в начале карьеры в такой ситуации, в компании на 1000+ сотрудников начинал тестирование) я бы для начала, определился со следующим: 1. В каких проектах нужно это запустить 2. Расставить приоритеты(по важности/по рискам) 3. Берём первый в списке проект - рисуем mind map функциональности, если его нет и расставляем приоритеты в нём 4. Смотрим на то, что получилось и понимаем какие инструменты/подходы тут нужно применить(хватит чек-листа и потом расписываем кейсы или хватит чек-листа и по нему проще накидать смоук автотетсы и встроить в CI) 5. Считаем потраченное время на поддержку 6. Выходим на овнера/руководителя - показываем расчёты и на основании этого можно уже разговаривать о построении команды, найме людей и т.д. 1,2,3 пункты эскалируете к руководителю, подкрепив своим мнением и идеями как сделать(сейчас не вы будете принимать решение)

День добрый. Я в такой же ситуации. Кейсы, листы и прочие штуки делаю только при необходимости. Например, для стажёрских проектов, которые мне периодически отдают. В остальном - кидают инвайт в проект, сидишь, чекаешь свою колонку и тестишь потихоньку. Иногда что-то срочное спрашивают. Бюрократия стремится к 0. Если разработчики ещё не разработали и тестить нечего, изучаю что-нибудь из стека технологий. Стек технологий можно узнать просто погуглив. Все более-менее советуют одно и то же, а если и начнёте изучение бесполезных вещей, всегда можно остановиться (хотя порой нужны казалось бы несвязанные знания).

Я сейчас первый и единственный тестировщик в компании. По-началу писала тест-кейсы и один раз тест-план, но мне удобнее оказались просто чек-листы. Как тут советовали, важную информацию записываю в самой же созданную инструкцию для будущих тестеров.