но держать отдельный чеклист для девелоперов, а отдельный для тестировщиков — излишество, ведь надо поддерживать два отдельных артефакта документации. А кто пишет и обновляет эти дев-чек-листы?
да нет двух отдельных чек-листов :) смотрите:
1. у нас есть задача. задача-эксперимент.
2. разработчик делает задачу
3. в это время тестировщик пишет для него чек-лист, это занимает минимум времени, около получаса, чек-лист небольшой. это в посте все написано, кстати
5. разработчик закончил свой, так сказать, девелопмент и затем проходит чек-лист, написанный тестировщиком. Если есть что — правит по итогам.
6. задача попадает в тестирование, а после этого в мастер (ну тут +- итерации на правки)
Как тестировщик тестирует конкретно эту новую задачу — его личное дело.
Все, по данной задаче мы НЕ пишем больше никакой документации. Потому что кто знает — вдруг мы по результатам аналитики через 2 недели эту фичу выпилим? А вот когда мы понимаем, что да, фичу эту стоит развивать и мы будем это делать — тогда она уже заносится в регрессионные кейсы, на нее пишутся автотесты и так далее. Потом в определенные дни из мастера собирается RC — релиз-кандидат, и основная, глобальная регрессия, в которую как раз включены критичные вещи, проверки имеющегося функционала и вот это все — происходит именно здесь. Автотесты у нас есть, да, ну и покрытие в районе 70% и более тоже имеем почти во всех проектах. Согласна, на саппорт тестов уходит время, но мы это вписали в процесс и посему забыть или пренебречь этим — невозможно
вообще, как я писала в статье, да и в предыдущем комментарии, это правильно называется acceptance criteria, то есть это не чек-лист как тестовая документация — это нечто иное, нам просто удобно называть это «чек-листом» для разработчиков. Хотите, можно назвать это набором проверок, чем-то еще, это неважно. Смысл в том, чтобы дать разработчику небольшой, но максимально полезный список необходимых проверок, обозначить области риска с нашей стороны, ну и того, что должно быть точно сделано в задаче. Этакое «проверь себя»
Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?
Еще раз: чек-листы для разработчика — это не тестовая документация, вообще никакого отношения к ней они не имеют :)
Про документацию — это отдельная тема, у нас есть регрессионные тест-кейсы, которые мы сейчас активно переносим вообще в php-doc к автотестам, кейсы на новый функционал сразу не пишем — только когда понимаем, что уже пора… чек-листы — я бы сказала, что массово и централизованно мы их не используем, разве что отдельные тестировщики при работе с новыми задачами
Ну тут нет какого-то централизованного инструмента на самом деле :) прелесть этих чек-листов для разработчиков именно в их краткости, это не те километровые чек-листы, про которые мы привыкли говорить в тестировании. Я писала просто в джировских комментах к задаче, для списка из ≈ 10-15 пунктов этого было достаточно
вообще у нас JIRA, да. задачи на доске представляют собой стори, внутри которых поставлены подзадачи на каждую роль, например, «Аналитика», «Бекенд», «Фронтенд», «Тестирование».
Обычно на планировании мы решаем, нужен ли чеклист задаче или нет, и если да, то в стори добавляется 2 подзадачи «Написать чек-лист» и «Пройти чек-лист». По опыту, подзадачи «Нпписать чек-лист» должны иметь бОльший приоритет, чем задачи типа «Протестировать» (я говорю в принципе о всех задачах в спринте), потому что после окончания разработки и переключения разработчика на другую задачу, чек-лист уже не имеет особого смысла.
Ну и, собственно, сначала тестировщик таскает свою задачу про написание чек-листа (сам чек-лист кладем в комментарии к общей стори — ну, нам так удобнее), потом разработчик, после того, как закончил, тащит задачу «пройти чек-лист» и по итогам пишет коммент к чек-листу. Как-то так :)
да нет двух отдельных чек-листов :) смотрите:
1. у нас есть задача. задача-эксперимент.
2. разработчик делает задачу
3. в это время тестировщик пишет для него чек-лист, это занимает минимум времени, около получаса, чек-лист небольшой. это в посте все написано, кстати
5. разработчик закончил свой, так сказать, девелопмент и затем проходит чек-лист, написанный тестировщиком. Если есть что — правит по итогам.
6. задача попадает в тестирование, а после этого в мастер (ну тут +- итерации на правки)
Как тестировщик тестирует конкретно эту новую задачу — его личное дело.
Все, по данной задаче мы НЕ пишем больше никакой документации. Потому что кто знает — вдруг мы по результатам аналитики через 2 недели эту фичу выпилим? А вот когда мы понимаем, что да, фичу эту стоит развивать и мы будем это делать — тогда она уже заносится в регрессионные кейсы, на нее пишутся автотесты и так далее. Потом в определенные дни из мастера собирается RC — релиз-кандидат, и основная, глобальная регрессия, в которую как раз включены критичные вещи, проверки имеющегося функционала и вот это все — происходит именно здесь. Автотесты у нас есть, да, ну и покрытие в районе 70% и более тоже имеем почти во всех проектах. Согласна, на саппорт тестов уходит время, но мы это вписали в процесс и посему забыть или пренебречь этим — невозможно
Еще раз: чек-листы для разработчика — это не тестовая документация, вообще никакого отношения к ней они не имеют :)
Про документацию — это отдельная тема, у нас есть регрессионные тест-кейсы, которые мы сейчас активно переносим вообще в php-doc к автотестам, кейсы на новый функционал сразу не пишем — только когда понимаем, что уже пора… чек-листы — я бы сказала, что массово и централизованно мы их не используем, разве что отдельные тестировщики при работе с новыми задачами
Обычно на планировании мы решаем, нужен ли чеклист задаче или нет, и если да, то в стори добавляется 2 подзадачи «Написать чек-лист» и «Пройти чек-лист». По опыту, подзадачи «Нпписать чек-лист» должны иметь бОльший приоритет, чем задачи типа «Протестировать» (я говорю в принципе о всех задачах в спринте), потому что после окончания разработки и переключения разработчика на другую задачу, чек-лист уже не имеет особого смысла.
Ну и, собственно, сначала тестировщик таскает свою задачу про написание чек-листа (сам чек-лист кладем в комментарии к общей стори — ну, нам так удобнее), потом разработчик, после того, как закончил, тащит задачу «пройти чек-лист» и по итогам пишет коммент к чек-листу. Как-то так :)