Добрый день. В связи с расширением штата сильно увеличивается количество задач от программистов на тестирование. В связи с этим возникла потребность каким то образом регламентировать входящие в отдел задачи.
Раньше они влетали в произвольной форме, в 90% случаев требовалось сразу бежать к разработчикам, что бы вникнуть в суть задачи. Но так как теперь на это особо времени нет, нужно как то на уровне компании утвердить шаблон постановки задачи для отдела тестирования.
Кто сталкивался с такой задачей, как ее решали? Какие нормативные документы посоветуете почитать, или может у кого то есть шаблон где четко по пунктам указано в каком виде должна быть поставлена задача? Как удобнее организовать это дело? Буду очень благодарен за направление в правильную сторону)
Ну вопрос очень обширный и затрагивает очень много разных аспектов управления не только тестированием, но и управления самим проектом.
Я так понимаю, вы хотите формализировать проект. Обычно это решает процессуально, т.е. вы садитесь вместе с программистами за круглым столом и обсуждаете пути решения возникшей ситуации. Но обычно это заканчивается введением какой-то новой системы (или же ее видо изменение) с соответствующим изменением процесса разработки.
Я бы предложил вам ввести какую-то систему например Jira или trello, или любую другую. Согласовать критерии создания и обработки задач вашим отделом. А дальше все нужно регулировать в зависимости от нагрузки вашего отдела и принимать дальнейшие решения. В данном случае подход kanban (конвеерный процесс) будет хорошо работать.
Кидать какие-то шаблоны и т.д. это бессмысленно потому как все очень индивидуально и зависит от контекста проекта.
Дело в том, что мы используем Jira, но тем не менее это не мешает разработчику поставить задачу на тестирование с текстом, к примеру “Протестировать все”. По этому хочется предложить руководству какой то адекватный регламент, по которому будут приниматься задачи. То есть из чего должна состоять задача. Для себя я накидал некий шаблон, но мне еще интересно мнение более опытных людей)
Пока не понятно, каких собственно процессов вы придерживаетесь в компании / на проекте?
Вообще выглядит немного дико, что разработчики создают таски для тестировщиков.
У нас, к примеру, на проекте в ходу Scrum. Все саб-таски создаются во время планирования / рефайнмента. В том числе и QA. При этом, вся команда принимает участие в обсуждении. Но тут по дефолту не может быть варианта “протестировать все”, ибо саб-таски привязываются к конкретной стори. Ну а для смоук / регрешена существуют automated tests.
Ну не у всех компаниях существует такой идеальный процесс)…и пока до него еще далековато у нас, хочется как то облегчить себе работу, и предоставить для разработчиков шаблон постановки задач для нас.
Еще раз… Почему вы считаете, что это должны делать разработчики?
У вас есть QA Lead / PM? Откуда вообще заходят таски на разработку? Все еще не ясны процессы. Тестирование должен планировать ваш лид, а не девелоперы. У вас не должно быть рассинхронизации. Лид всегда должен быть в курсе того, что сейчас разрабатывается. К тому же с джирой то… Какая проблема отфильтровать текущие дев задачи и подготовить план тестирования? Какая проблема сходить к Dev лиду и за чайком обсудить какие фичи собираются выкатываться и какие области могут быть заафекчены? Ведется ли какая-то тестовая документация? Хотя бы банальный чеклист? Вы просите совета, но категорически отказываетесь описывать то, что у вас имеется на текущий момент. Весьма странный подход…
действительно, попробуйте внедрить в процесс QA Lead или PM-а. Я так понял у вас после написания какой-то фичи, таск уходит на QA, который понятия не имеет, что происходит, если это не баг, который он завел ранее. В таком случае в процесс вклинивается PM или QA Lead, который в курсе всего происходящего, и он разруливает уже кому и какой тикет уходит. То есть если разработчик написал какой-то функционал он отправляет его на PM/QA Lead, затем уже этот человек анализирует что к чему и решает куда таску уходить на QA или на уточнение или на доработку. Если вам что-то непонятно, идете к нему или в таске спрашиваете.
Но также странно как-то звучит - “в 90% случаев требовалось сразу бежать к разработчикам”. На этом моменте может быть два нюанса:
тестировщики с маленьким опытом, которые сами разобраться не могут в ТЗ к таску
таски пишутся уже очень как-то сложно, понятным языком только для разработчиков
Понятное дело, что не все таски звучат понятно, темболее когда проект специфический, но все же 90% - это большой процент
Я конечно могу ошибаться, так не до конца знаю как у вас там все устроено…
В команде есть лид, на него приходят задачи, он раскидывает таски на тестировщиков. Проблема в том что ТЗ по задачам полностью отсутствует, и в итоге ни ему ни тестировщикам не понятно что в этой задаче было реализовано. Задач очень много, и лид физически просто не успеет по всем задачам выбить у разработчиков инфу. Собственно для этой цели нужно сделать так, что разработчик когда ставит таску на тестирование описал в ней что он сделал и как оно должно работать.
Тогда понятно, сложность в том, что разработчик пишет все своими терминами и со своей колокольни, я с этим столкнулся на одном волонтерском проекте, местами было сложно. Но как по мне, ТЗ должно быть написано человеком, который умеет излагать мысли и суть новой фичи всем понятным языком. Бывает такое, что до таска добирается маркетинг или еще кто, кто ваще не понимает термины разработчиков. Возможно стоит проговорить вам этот момент.
Надо наверное как-то так сделать, обсуждаете функционал который будет реализован в данном спринте - Lead + разработчик, далее Lead прописывает ТЗ всем понятным языком, таск делает разработчик и скидывает вам, вы уже как инженеры по качеству думаете над сценариями, если есть сложности только тогда идете к разработчику. Представляю как ваши разработчики рады тому факту, что вы к ним так часто бегаете
[quote=“evgmoskalenko, post:9, topic:8443”]
Надо наверное как-то так сделать, обсуждаете функционал который будет реализован в данном спринте - Lead + разработчик
[/quote] как то у нас в компании не могут к этому дойти, уже были попытки, задача натухую влитела на разработчика, он сделал, а на нас летит тикет на тестирование, у тут мы впервые узнаем что задача была реализована
[quote=“evgmoskalenko, post:9, topic:8443”]
таск делает разработчик и скидывает вам, вы уже как инженеры по качеству думаете над сценариями
[/quote]этот этап наступает сразу после длительного разговора с разработчиками.
Так вот получается сценарий: задача влитела на нас, мы идем к разработчикам, потом пишем доку, потом тестируем. И вот второй этап " мы идем к разработчикам" очень хочется минимизировать)))
это как ? девелоперы себе сами задачи придумывают от скуки ?
если в девелопмент пришла “фича” на разработку, то у данной “фичи” должны быть требования от product managers (или других ответственных за продукт лиц) => тестировщики могут начать тестирование фичи по данным требованиям, если они более менее адекватные. а если они не адекватные - то не понятно как они (требования) добрались до разработки (хотя всё бывает…)
А как разработчики реализовывают функционал? На основании какой информации? Кто ее поставляет и каким образом?
Опять 25… Да не должен разработчик ставить таски тестировщикам! Сколько можно одно и то же повторять? Берите лида за уши, и пусть шагает туда, откуда материализуются требования к фичам (не важно, в словесном или письменном формате). Девелоперы ведь их не сами придумывают? Пусть берет блокнот и все записывает, задает вопросы. Выделяйте больше времени на такие митинги, чтобы детально обсудить требования. Если нужно просидеть целый день, чтобы все покрыть, - сидите целый день. Но фразы в стиле:
звучат так, будто ваш лид с другой планеты. Разобрав все по полочкам, можно выделить следующую позицию лида:
Привет, я - лид. У меня отлично получается делегировать полномочия. Я искренне убежден, что планирование - задача для слабаков, а все задачи должны поступать от наших верных рабов друзей - девелоперов. Если я не вижу четкого ТЗ, я обязательно придумаю способ, чтобы другие насоздавали мне тасков - обязательно в удобном для меня формате -, которые я успешно делегирую моей команде.
По-моему, вам просто нужен новый лид. Либо намекните ему, что если отсутствует прокси, предоставляющий требования, выяснять их должны вы сами. Да хоть напрямую звоните заказчику среди ночи. Если хотят качественный продукт, пора начинать что-то менять. Но не путем снятия с себя ответственности.
У нас построено так. Разработчику дается ТЗ на разработку. И тестировщику дается это ТЗ. Тестировщик составляет приемочные тесты на проверку функционала заявленного. И далее уже идут всякие извращения. А тестировать без ТЗ - это имхо не представляю как. Когда только устроился, зачастую вообще был таск просто написан. Скажем CRUD доп услуг. Без дескрипшена и т.д. Я в таком случае отправлял к ПМу с описанием требований. Ну а в последствии построили процесс таким образом, что все изменения идут в вики. Если отдается таск на тестирование и нет описания в вики. То такой таск не тестируется до тех пор, пока не будет актуального описания.
Думаю примерно понятно где у вас самое слабое звено
таск должен исходить от Менеджеров ваших
разработчик идет сугубо по ТЗ тикета на реализацию фичи, иначе там и накодить можно много чего лишнего
все обсуждения идут в тикете
когда тикет дойдет до вас - у вас будет прозрачное и понятное ТЗ в начале тикета, дальше будут идти уточнения разработчика в комментариях. Происледуя так тикет, вы сможете в нем разобраться.
И самое главное, написанное ТЗ не должно быть от разработчика. Я так понимаю у вас есть требования и разработчик читая их, придумывает как и что ему делать, так быть не должно, есть же люди, которые отвечают за бизнес процессы. По итогу вы можете получить продукт, который будет сделан но не по той логике, которую хотел заказчик…
ну пришел заказчик, сказал хочу зеленую кнопку на синем фоне, разработчики пилят ту самую кнопку
[quote=“ArtOfLife, post:12, topic:8443”]
Опять 25… Да не должен разработчик ставить таски тестировщикам!
[/quote] у нас воркфлоу такой, задача от проджекта идет на разраба, он ее выполняет и она сразу летит на тестировщиков, на их лида.
Ну так построен процесс в компании, и изменить его очень тяжело так сразу. И к тому же, я думаю, если как то регламентировать процесс постановки задачи тестировщикам, это упростит всем жизнь даже и в проєктах где все так круто как вы говорите.
дык, в задаче должны быть требования написанные проджектом и понятные ВСЕМ кто участвует в процессе
если это не так, то тут проблема не в разработчиках и тестировщиках - а изначально проблема в проджектах и начинать надо с них.
А PM’у слабо собирать всех вместе перед асайном задачи и объяснять, что нужно сделать? Ну или хотя бы внятно ее описывать. Как-будто всех закрыли в разных комнатах с забитыми дверьми и без средств связи.
Кстати интересно, а не была ли это идея PMa - делегировать свои полномочия на остальных? Мол, не понятно, - разбирайтесь сами. Придумайте так, чтоб было понятно.
Ну думаю там у них не два человека работает, и не два таска в день, чтобы собирать всех вместе перед асайном каждой задачки и объяснять. Наверное такое всем будет сложно сделать, но для больших и сложных тасков - это все таки конечно неизбежно…
Но вы правы, тут скорее надо им грамотно ТЗ описывать. Пришел заказчик и сказал что хочет кнопку - это ок, но это понятно. Бывает сложнее ситуация, приходит заказчик и хочет себе что-то словами объяснимое очень просто, но для реализации приходиться использовать API, тестировать API и еще что-то (не суть). Так вот тут то, грамотный менеджер и сможет сформировать ТЗ понятное всем, кто задействован в процессе и проследить, чтобы от ТЗ не отошли и реализация совпала с бизнес логикой… Да и все обсуждение может быть задокументировано посредством комментариев к таску в джире…
За тем и придумали планирование / рефайнменты - чтобы вся команда периодически собиралась в назначенное время и решала подобного рода вопросы. Не нужно это делать для каждой маленькой задачи в отдельности.
testomat.io управление авто тестами
