Comments 8
Сверх-исчерпывающий пост, спасибо! А что у вас насчёт ПО, если не секрет — для чек-листов и багтрекинга используете что-то своё или Jira/Redmine. И насколько комфортно ПО позволяет использовать вот эти чек-листы?
вообще у нас JIRA, да. задачи на доске представляют собой стори, внутри которых поставлены подзадачи на каждую роль, например, «Аналитика», «Бекенд», «Фронтенд», «Тестирование».
Обычно на планировании мы решаем, нужен ли чеклист задаче или нет, и если да, то в стори добавляется 2 подзадачи «Написать чек-лист» и «Пройти чек-лист». По опыту, подзадачи «Нпписать чек-лист» должны иметь бОльший приоритет, чем задачи типа «Протестировать» (я говорю в принципе о всех задачах в спринте), потому что после окончания разработки и переключения разработчика на другую задачу, чек-лист уже не имеет особого смысла.
Ну и, собственно, сначала тестировщик таскает свою задачу про написание чек-листа (сам чек-лист кладем в комментарии к общей стори — ну, нам так удобнее), потом разработчик, после того, как закончил, тащит задачу «пройти чек-лист» и по итогам пишет коммент к чек-листу. Как-то так :)
Обычно на планировании мы решаем, нужен ли чеклист задаче или нет, и если да, то в стори добавляется 2 подзадачи «Написать чек-лист» и «Пройти чек-лист». По опыту, подзадачи «Нпписать чек-лист» должны иметь бОльший приоритет, чем задачи типа «Протестировать» (я говорю в принципе о всех задачах в спринте), потому что после окончания разработки и переключения разработчика на другую задачу, чек-лист уже не имеет особого смысла.
Ну и, собственно, сначала тестировщик таскает свою задачу про написание чек-листа (сам чек-лист кладем в комментарии к общей стори — ну, нам так удобнее), потом разработчик, после того, как закончил, тащит задачу «пройти чек-лист» и по итогам пишет коммент к чек-листу. Как-то так :)
А в чем чеклисты создаете и насколько удобно там работать с ними?
С ходу на ум приходят trello и google spreadsheets, но хочется узнать конкретно.
С ходу на ум приходят trello и google spreadsheets, но хочется узнать конкретно.
Ну тут нет какого-то централизованного инструмента на самом деле :) прелесть этих чек-листов для разработчиков именно в их краткости, это не те километровые чек-листы, про которые мы привыкли говорить в тестировании. Я писала просто в джировских комментах к задаче, для списка из ≈ 10-15 пунктов этого было достаточно
насколько я понимаю, это не совсем чек-лист из примера в статье:
Перейти на /hotel/3442/ (страница без параметров поиска) — это test step
Там нет плашки «отправить ссылку на туры» — actual result
Перейти на ХХХ (пример ссылки на страницу отеля с параметрами) — test step
Плашка присутствует — actual/expected result
чеклист, это что-то типа такого
1. Проверить, что: на странице /hotel/3442/ (страница без параметров поиска) плашка «отправить ссылку на туры» отсутствует
2. Проверить, что: на странице ХХХ (пример ссылки на страницу отеля с параметрами) плашка присутствует
и т.д.
насчет
Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?
Из моего опыта в тяжелом динамическом аджайле:
— тест кейсы лучше писать для критической функциональности, которая редко меняется
— юзкейсы — это обычно почти стори
— чек-листы — только краткие и нормальные — очень хороший заменитель тест-кейсов для команды, которая давно работает с проектом. Но они, к сожалению, не могут заменить хороших тест-кейсов в момент, когда добавляюся новые тестировщики в команду.
У нас было в отдельно взятом проекте хорошая практика тратить время начала спринта для написания/обновления регрессионнных тейс-кейсов на основе стори, чеклистов и тест-кейсов из фич прошлого спринта
Перейти на /hotel/3442/ (страница без параметров поиска) — это test step
Там нет плашки «отправить ссылку на туры» — actual result
Перейти на ХХХ (пример ссылки на страницу отеля с параметрами) — test step
Плашка присутствует — actual/expected result
чеклист, это что-то типа такого
1. Проверить, что: на странице /hotel/3442/ (страница без параметров поиска) плашка «отправить ссылку на туры» отсутствует
2. Проверить, что: на странице ХХХ (пример ссылки на страницу отеля с параметрами) плашка присутствует
и т.д.
насчет
Можно перейти на следующий шаг при клике на цену предложения
Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?
Из моего опыта в тяжелом динамическом аджайле:
— тест кейсы лучше писать для критической функциональности, которая редко меняется
— юзкейсы — это обычно почти стори
— чек-листы — только краткие и нормальные — очень хороший заменитель тест-кейсов для команды, которая давно работает с проектом. Но они, к сожалению, не могут заменить хороших тест-кейсов в момент, когда добавляюся новые тестировщики в команду.
У нас было в отдельно взятом проекте хорошая практика тратить время начала спринта для написания/обновления регрессионнных тейс-кейсов на основе стори, чеклистов и тест-кейсов из фич прошлого спринта
вообще, как я писала в статье, да и в предыдущем комментарии, это правильно называется acceptance criteria, то есть это не чек-лист как тестовая документация — это нечто иное, нам просто удобно называть это «чек-листом» для разработчиков. Хотите, можно назвать это набором проверок, чем-то еще, это неважно. Смысл в том, чтобы дать разработчику небольшой, но максимально полезный список необходимых проверок, обозначить области риска с нашей стороны, ну и того, что должно быть точно сделано в задаче. Этакое «проверь себя»
Еще раз: чек-листы для разработчика — это не тестовая документация, вообще никакого отношения к ней они не имеют :)
Про документацию — это отдельная тема, у нас есть регрессионные тест-кейсы, которые мы сейчас активно переносим вообще в php-doc к автотестам, кейсы на новый функционал сразу не пишем — только когда понимаем, что уже пора… чек-листы — я бы сказала, что массово и централизованно мы их не используем, разве что отдельные тестировщики при работе с новыми задачами
Вы пишете детерминированную документацию или пожелания для тестировщиков? как гарантировать покрытие в таком случае?
Еще раз: чек-листы для разработчика — это не тестовая документация, вообще никакого отношения к ней они не имеют :)
Про документацию — это отдельная тема, у нас есть регрессионные тест-кейсы, которые мы сейчас активно переносим вообще в php-doc к автотестам, кейсы на новый функционал сразу не пишем — только когда понимаем, что уже пора… чек-листы — я бы сказала, что массово и централизованно мы их не используем, разве что отдельные тестировщики при работе с новыми задачами
тогда чуть яснее, спасибо, тогда это чек-лист для acceptance testing на стороне девелопмента перед отдачей билда тестировщикам. На самом деле очень хорошая практика, не всегда применяемая.
но держать отдельный чеклист для девелоперов, а отдельный для тестировщиков — излишество, ведь надо поддерживать два отдельных артефакта документации. А кто пишет и обновляет эти дев-чек-листы?
Если вы сумеете покрыть автотестами регрессию хотя бы на 70% — это огромное достижение, главное потом не забывать выделять всегда время и саппортить их. К сожалению, это накладнее, обычно, чем просто написать 1 раз
но держать отдельный чеклист для девелоперов, а отдельный для тестировщиков — излишество, ведь надо поддерживать два отдельных артефакта документации. А кто пишет и обновляет эти дев-чек-листы?
да нет двух отдельных чек-листов :) смотрите:
1. у нас есть задача. задача-эксперимент.
2. разработчик делает задачу
3. в это время тестировщик пишет для него чек-лист, это занимает минимум времени, около получаса, чек-лист небольшой. это в посте все написано, кстати
5. разработчик закончил свой, так сказать, девелопмент и затем проходит чек-лист, написанный тестировщиком. Если есть что — правит по итогам.
6. задача попадает в тестирование, а после этого в мастер (ну тут +- итерации на правки)
Как тестировщик тестирует конкретно эту новую задачу — его личное дело.
Все, по данной задаче мы НЕ пишем больше никакой документации. Потому что кто знает — вдруг мы по результатам аналитики через 2 недели эту фичу выпилим? А вот когда мы понимаем, что да, фичу эту стоит развивать и мы будем это делать — тогда она уже заносится в регрессионные кейсы, на нее пишутся автотесты и так далее. Потом в определенные дни из мастера собирается RC — релиз-кандидат, и основная, глобальная регрессия, в которую как раз включены критичные вещи, проверки имеющегося функционала и вот это все — происходит именно здесь. Автотесты у нас есть, да, ну и покрытие в районе 70% и более тоже имеем почти во всех проектах. Согласна, на саппорт тестов уходит время, но мы это вписали в процесс и посему забыть или пренебречь этим — невозможно
Sign up to leave a comment.
Все лучшее из методологии Lean Startup, и как с этим жить тестировщикам