Статья подготовлена по результатам Мирового кафе на встрече наших замечательных выпускников! Некоторые из них уже успели поработать тестировщиками, некоторые только столкнулись с тестированием документации на практике.
Что же интересного мы выявили в ходе деловой игры?
К обязательным документам, понятным разработчикам и тестировщикам, отнесли:
- Documents flow (от PM к ВА)
- Possible cases (от ВА к QA)
- Прототип (с текстовым описанием функций и элементов)
- Глоссарий
Также отметили, что доступными для тестировщика должны быть документы с высокоуровневыми требованиями и общим описанием среды, в которой будет использоваться разрабатываемый продукт. Это позволит тестировщику лучше понять уровень навыков будущих пользователей и спрогнозировать их действия во время тестирования системы.
Проблема состоит из нескольких частей.
2.1) Часто требования и ограничения возникают в беседах (телефон, skype, email, разные чаты). Но не переносятся в документацию (или переносятся с запозданием).
В итоге - документацию не читают (ведь в ней все равно неполная и недостоверная информация). Проще додумать или напрямую спросить ВА.
В итоге - ВА тратит тучу времени на объяснения, выдает информацию, иногда несогласованную, неполную, обрывочную.
Было предложено несколько разных вариантов выхода из проблемы:
- запретить любые утверждения и принятия решений вне документации (оставить только email для подтверждения изменений и информирования);
- создать автоматическое логирование резолюшенов: вести обсуждение решений и требований только в специальных чатах, которые (при отметке текста спец.тегами) сами разнесут части диалога по полочкам электронной документации (прикрепят к комментариям, укажут в документах наличие изменений);
- ВА оперативно (по ходу беседы) вносить изменения в документацию: создавать резервную копию, вносить отметки с выделением маркерами или документировать в электронном Блокноте (потом из него проще скопировать документ, перенести сведения в основную версию требований и решений).
2.2) Сложно найти актуальную версию документа.
Не считая путаницы, которая возникает при большом числе версий документов, если их ведут несколько человек, также компании нередко вынуждены подписывать документы с требованиями у Заказчика (чтобы составить договор на проведение работ), фиксируя эталон в неизменном состоянии. Но требования со временем начинают изменяться (уточняются, исправляются, дополняются). Компании начинают "мудрить" с версиями - создают списки версий документов, в которых указывают где хранятся актуальные уточнения по тому или иному разделу документов.
В итоге - проще спросить ВА, чем тратить часы на выяснения, что делаем и где читать. Хотя, порой, и сам ВА через месяц-два, уже с трудом контролирует процесс уточнений.
Для тех, кто сталкивается с подобными проблемами, было предложено следующее:
- "мапинг" изменений документов (актуальный документ, навигатор по актуальным документам проекта)
- в дополнении к логированию резолюшенов, вести автоматический учет версий документов и логировать авторов и места изменений.
При этом актуальная версия документа для разработчика должна быть только одна! А что у Заказчика - то лишь приложение к договору, определяющее только высокоуровневые требования.
Никаких "мапингов" и "кросс-мапингов" изменений документов. Все изменения должны быть в самом документе!
- делить проект на небольшие части и отдавать в тестирование (как правило в маленьком кусочке изменений происходит немного, их проще отследить)
2.3) Если дорабатывается часть существующей системы, то нужно ставить рамки тестирования системы и документации. А также указывать, где находится актуальная информация по другим частям системы (чтобы знать, что косяк, что фишка системы).
Сюда же снова добавился Глоссарий. Как оказалось, говорим на одном языке, но одинаковые слова понимаем по-разному. А также в среде разработчиков и тестировщиков есть ряд "зарезервированных" слов. Без дополнительных пояснений, эти слова тестировщик поймет так, как привык понимать, а не как ожидает ВА.
При неполных требованиях (или простом игнорировании документации из-за п.2), тестировщик и разработчик становятся перед выбором:
- делать, как понял, и сэкономить время и силы;
- отправить документы на доработку и, возможно, сорвать сроки проекта;
- устно уточнить, что нужно делать, и, возможно, получить потом расхождение документов и результата.
Ребята посоветовали сделать следующее:
- при наличии второго ВА в компании, дать ему прочесть документацию и показать прототип (чтобы был "свежий" "незамыленный" взгляд на проект);
- отдавать тестировщику документацию на тестирование до того, как она уйдет разработчику, и прислушиваться к советам тестировщика по тому, как сделать документы и требования лучше, понятнее.
Важно оперативно вносить изменения согласно пожеланий и (!) тестировать требования после изменений.
Оказалось, что бывает рассогласование требований после внесения изменений.
Крайне желательно, чтобы комментарии и замечания сохранялись непосредственно в документе. А вносимые изменения документировались (что где изменено, когда и кем).
- обсуждать требования к проекту, выявлять возможные проблемы, т.д. на онлайн или личных встречах с тестировщиками не реже 1 раза в 2 недели (в этом плане скрам с ежедневными митингами очень хорош).
5) На запросы тестировщика к ВА нужно реагировать молниеносно
Тестировщику часто не остается времени на доскональное изучение документации (если она сложная, не имеет удобных для тестировщика cases). Просто потому, что ему приходит документ уже тогда, когда сроки "горят" и нужно срочно проверять и сдавать Заказчику продукт. Любые баги, выявленные тестировщиком, часто оттягивают сдачу проекта и даже, бывает, раздражают команду.
Хотя, он один из тех, кто защищает качество продукта и лицо всей команды разработчиков.
Поэтому, даже если всё горит, нужно с понимаем и спокойствием относится к вопросам и замечаниям тестировщика. Поощрять его вопросы и диалог.
Очень в этот момент тестировщику помогает список важнейших технических рисков в системе, описание валидации полей форм, указание глубины и границ тестирования.
Ребята, если есть еще что ценного добавить, пишите :)
Еще раз благодарим за интересную встречу!
Что же интересного мы выявили в ходе деловой игры?
1) Документы должны быть
Как ни странно, но неоднократно ребята говорили о том, что документы должны быть, а их нет или документы не те. Часто формальные, которые идут на подпись Заказчику.К обязательным документам, понятным разработчикам и тестировщикам, отнесли:
- Documents flow (от PM к ВА)
- Possible cases (от ВА к QA)
- Прототип (с текстовым описанием функций и элементов)
- Глоссарий
Также отметили, что доступными для тестировщика должны быть документы с высокоуровневыми требованиями и общим описанием среды, в которой будет использоваться разрабатываемый продукт. Это позволит тестировщику лучше понять уровень навыков будущих пользователей и спрогнозировать их действия во время тестирования системы.
2) Документы должны быть актуальны
В целом, документы должны быть актуальными. И это, как оказалось, на практике серьезная проблема.Проблема состоит из нескольких частей.
2.1) Часто требования и ограничения возникают в беседах (телефон, skype, email, разные чаты). Но не переносятся в документацию (или переносятся с запозданием).
В итоге - документацию не читают (ведь в ней все равно неполная и недостоверная информация). Проще додумать или напрямую спросить ВА.
В итоге - ВА тратит тучу времени на объяснения, выдает информацию, иногда несогласованную, неполную, обрывочную.
Было предложено несколько разных вариантов выхода из проблемы:
- запретить любые утверждения и принятия решений вне документации (оставить только email для подтверждения изменений и информирования);
- создать автоматическое логирование резолюшенов: вести обсуждение решений и требований только в специальных чатах, которые (при отметке текста спец.тегами) сами разнесут части диалога по полочкам электронной документации (прикрепят к комментариям, укажут в документах наличие изменений);
- ВА оперативно (по ходу беседы) вносить изменения в документацию: создавать резервную копию, вносить отметки с выделением маркерами или документировать в электронном Блокноте (потом из него проще скопировать документ, перенести сведения в основную версию требований и решений).
2.2) Сложно найти актуальную версию документа.
Не считая путаницы, которая возникает при большом числе версий документов, если их ведут несколько человек, также компании нередко вынуждены подписывать документы с требованиями у Заказчика (чтобы составить договор на проведение работ), фиксируя эталон в неизменном состоянии. Но требования со временем начинают изменяться (уточняются, исправляются, дополняются). Компании начинают "мудрить" с версиями - создают списки версий документов, в которых указывают где хранятся актуальные уточнения по тому или иному разделу документов.
В итоге - проще спросить ВА, чем тратить часы на выяснения, что делаем и где читать. Хотя, порой, и сам ВА через месяц-два, уже с трудом контролирует процесс уточнений.
Для тех, кто сталкивается с подобными проблемами, было предложено следующее:
- "мапинг" изменений документов (актуальный документ, навигатор по актуальным документам проекта)
- в дополнении к логированию резолюшенов, вести автоматический учет версий документов и логировать авторов и места изменений.
При этом актуальная версия документа для разработчика должна быть только одна! А что у Заказчика - то лишь приложение к договору, определяющее только высокоуровневые требования.
Никаких "мапингов" и "кросс-мапингов" изменений документов. Все изменения должны быть в самом документе!
- делить проект на небольшие части и отдавать в тестирование (как правило в маленьком кусочке изменений происходит немного, их проще отследить)
2.3) Если дорабатывается часть существующей системы, то нужно ставить рамки тестирования системы и документации. А также указывать, где находится актуальная информация по другим частям системы (чтобы знать, что косяк, что фишка системы).
3) Соблюдать требования к требованиям
Это простое утверждение тестировщики скромно повторили несколько раз. В частности указали, что "понятно" слово весьма относительное.Сюда же снова добавился Глоссарий. Как оказалось, говорим на одном языке, но одинаковые слова понимаем по-разному. А также в среде разработчиков и тестировщиков есть ряд "зарезервированных" слов. Без дополнительных пояснений, эти слова тестировщик поймет так, как привык понимать, а не как ожидает ВА.
4) Общаться с тестировщиком
Удивительное открытие: есть команды, где общение тестировщика и ВА происходит в конце проекта (когда всё, аут, проект провален или тестировщик не может понять, то ли сделал разработчик, что хотелось Заказчику, или намудрил).При неполных требованиях (или простом игнорировании документации из-за п.2), тестировщик и разработчик становятся перед выбором:
- делать, как понял, и сэкономить время и силы;
- отправить документы на доработку и, возможно, сорвать сроки проекта;
- устно уточнить, что нужно делать, и, возможно, получить потом расхождение документов и результата.
Ребята посоветовали сделать следующее:
- при наличии второго ВА в компании, дать ему прочесть документацию и показать прототип (чтобы был "свежий" "незамыленный" взгляд на проект);
- отдавать тестировщику документацию на тестирование до того, как она уйдет разработчику, и прислушиваться к советам тестировщика по тому, как сделать документы и требования лучше, понятнее.
Важно оперативно вносить изменения согласно пожеланий и (!) тестировать требования после изменений.
Оказалось, что бывает рассогласование требований после внесения изменений.
Крайне желательно, чтобы комментарии и замечания сохранялись непосредственно в документе. А вносимые изменения документировались (что где изменено, когда и кем).
- обсуждать требования к проекту, выявлять возможные проблемы, т.д. на онлайн или личных встречах с тестировщиками не реже 1 раза в 2 недели (в этом плане скрам с ежедневными митингами очень хорош).
5) На запросы тестировщика к ВА нужно реагировать молниеносно
Тестировщику часто не остается времени на доскональное изучение документации (если она сложная, не имеет удобных для тестировщика cases). Просто потому, что ему приходит документ уже тогда, когда сроки "горят" и нужно срочно проверять и сдавать Заказчику продукт. Любые баги, выявленные тестировщиком, часто оттягивают сдачу проекта и даже, бывает, раздражают команду.
Хотя, он один из тех, кто защищает качество продукта и лицо всей команды разработчиков.
Поэтому, даже если всё горит, нужно с понимаем и спокойствием относится к вопросам и замечаниям тестировщика. Поощрять его вопросы и диалог.
Очень в этот момент тестировщику помогает список важнейших технических рисков в системе, описание валидации полей форм, указание глубины и границ тестирования.
Ребята, если есть еще что ценного добавить, пишите :)
Еще раз благодарим за интересную встречу!
