Продолжая тему взаимодействия тестировщиков с проектной документацией (см. часть 1, часть 2), в этой части хочу коротко упомянуть, как технически у нас осуществляется тестирование требований и какие вообще есть проблемы с этим процессом.
Как я писала в части 2, под тестированием требований я понимаю их ревью, которое у нас осуществляется очень просто:
1) на ревью выделяется определённое время, в течение которого в предоставленном документе каждый рецензент оставляет свои комментарии (о каком бы формате документации у нас речь ни шла - MS Office Word, pdf, xwiki - внесение комментариев в том или ином виде везде возможно).
2) в конце отведённого на ревью срока автор документации получает комментарии от всех рецензентов и обрабатывает их: если замечание однозначно требует исправления - вносит эти исправления, ну а если есть какие-то спорные моменты, то у нас это обычно разрешается либо в процессе e-mail переписки, либо по телефону, либо ещё как-то.
3) исправленная на основании результатов ревью версия документа снова предоставляется всем заинтересованным лицам, после чего возможен ещё один раунд рецензирования.
Конечно, это формальный путь ревью, но также работает и неформальный путь, когда приходит ко мне кто-либо из команды и говорит, что у него есть такой-то вопрос по спецификации - мы вместе смотрим, разбираемся и так или иначе решаем этот вопрос. Ну прям как с багами - можно проблему официально через багтрекер провести, а можно быстренько и так с ней разобраться; плюсы и минусы примерно те же :)
Разумеется, есть у нас с этими ревью и проблемы, и вопросы - а куда же без них? Все они достаточно стандартные и понятные - так что вот коротенько их список:
Самый главный вопрос - когда? Вопрос на самом деле состоит из двух частей:
1) Во-первых, на само ревью нужно выделенное время; если его отдельно не выделяют или выделяют слишком мало - вряд ли что-то хорошее из всей затеи получится.
Решение: ничего другого кроме как пытаться выбить из начальства время на ревью я и не вижу, одно хорошо - аргументация пользы от такого тестирования очень хорошо в соответствующих книгах описана.
2) Во-вторых, и написание самой документации, и её ревью должны выполняться своевременно - желательно до разработки самого приложения. У нас это получается далеко не всегда. Конечно, даже если разработка началась, от качественного ревью толк всё равно будет, но ценность его снизится.
Решение: работать над улучшением процессов, пытаться лучше придерживаться графиков и т.п., что проще сказать, но сделать достаточно трудно.
И ещё несколько моментов:
3) Ревью необходимо делать качественно. Звучит очень банально, но реально постоянно приходится сталкиваться как с очень толковыми замечаниями от одних людей, так и с очень бестолковыми - от других. А ведь отреагировать я как автор документации должна на каждое замечание, и приходится строчить письма, чтобы объяснять простые вещи, которые в той же спецификации написаны, но которые кто-то не потрудился прочитать и понять - только время зря тратишь. Так что ревью надо делать хорошо, либо лучше не делать вообще.
Решение: как минимум разъяснять участникам ревью, что оно должно выполняться на основании внимательного, вдумчивого и полного прочтения, что опять же может быть не слишком просто.
4) Проверяемая документация и проверяющие люди должны соответствовать друг другу. Тут всё просто - сделать нормальное ревью документации могут только те, кто хотя бы что-то способен в ней понять. Ну нет смысла отдавать очень техничное описание сложных внутренних команд тестировщикам графических интерфейсов - может и поймут что-то и даже может что полезное скажут, но скорее всего только время потеряют.
Решение: разумно составлять список рецензентов.
5) Люди слишком увлекаются не самыми существенными деталями. Это как в обычном тестировании - человек, допустим, увлекается проверкой правильно расставленных знаков препинания во всём приложении. В принципе - дело нужное, но если из-за него упускаются из виду гораздо более значительные вещи - это уже не очень хорошо.
Решение: пытаться проводить разъяснительные беседы и расставлять приоритеты; но не очень помогает.
6) Люди ревьюят не то, что нужно. Это проблема больших документов, которые не пишутся каждый раз с нуля, а в которые вносятся дополнения. Люди умудряются вносить свои замечания не по новым правкам, о которых сейчас речь идёт, а к старому тексту. Может оно и не лишено смысла - если действительно находятся важные проблемы, но с таким я практически не сталкивалась; а замечания эти и отвлекают, да и незапланированные изменения в уже устоявшихся частях приложения далеко не всегда будут приветствоваться как руководством, так и разработчиками.
Решение: чётко разграничивать материал, подлежащий и не подлежащий ревью.
7) Люди ревьюят тогда, когда этого никто не ждёт. А это уже проблема таких форматов ведения документации, как вики - которые постоянно доступны всем online. Тут проблема очень простая - если речь идёт о большом объёме документации, то такие неожидаемые комментарии очень легко просто не заметить, ну ведь не пересматриваю же я постоянно все-все странички в вики в поисках новых комментариев!
Решение: чётко оговаривать время для ревью
Пожалуй, и хватит пока, и так месячную графоманскую норму за день выполнила :) Может кому-то будет полезно, а нет - хоть самой себе о некоторых вопросах напомнила :)
Часть 1: А не проще ли у аналитика спросить?
Часть 2: И какая от тестировщика польза?
1) на ревью выделяется определённое время, в течение которого в предоставленном документе каждый рецензент оставляет свои комментарии (о каком бы формате документации у нас речь ни шла - MS Office Word, pdf, xwiki - внесение комментариев в том или ином виде везде возможно).
2) в конце отведённого на ревью срока автор документации получает комментарии от всех рецензентов и обрабатывает их: если замечание однозначно требует исправления - вносит эти исправления, ну а если есть какие-то спорные моменты, то у нас это обычно разрешается либо в процессе e-mail переписки, либо по телефону, либо ещё как-то.
3) исправленная на основании результатов ревью версия документа снова предоставляется всем заинтересованным лицам, после чего возможен ещё один раунд рецензирования.
Конечно, это формальный путь ревью, но также работает и неформальный путь, когда приходит ко мне кто-либо из команды и говорит, что у него есть такой-то вопрос по спецификации - мы вместе смотрим, разбираемся и так или иначе решаем этот вопрос. Ну прям как с багами - можно проблему официально через багтрекер провести, а можно быстренько и так с ней разобраться; плюсы и минусы примерно те же :)
Разумеется, есть у нас с этими ревью и проблемы, и вопросы - а куда же без них? Все они достаточно стандартные и понятные - так что вот коротенько их список:
Самый главный вопрос - когда? Вопрос на самом деле состоит из двух частей:
1) Во-первых, на само ревью нужно выделенное время; если его отдельно не выделяют или выделяют слишком мало - вряд ли что-то хорошее из всей затеи получится.
Решение: ничего другого кроме как пытаться выбить из начальства время на ревью я и не вижу, одно хорошо - аргументация пользы от такого тестирования очень хорошо в соответствующих книгах описана.
2) Во-вторых, и написание самой документации, и её ревью должны выполняться своевременно - желательно до разработки самого приложения. У нас это получается далеко не всегда. Конечно, даже если разработка началась, от качественного ревью толк всё равно будет, но ценность его снизится.
Решение: работать над улучшением процессов, пытаться лучше придерживаться графиков и т.п., что проще сказать, но сделать достаточно трудно.
И ещё несколько моментов:
3) Ревью необходимо делать качественно. Звучит очень банально, но реально постоянно приходится сталкиваться как с очень толковыми замечаниями от одних людей, так и с очень бестолковыми - от других. А ведь отреагировать я как автор документации должна на каждое замечание, и приходится строчить письма, чтобы объяснять простые вещи, которые в той же спецификации написаны, но которые кто-то не потрудился прочитать и понять - только время зря тратишь. Так что ревью надо делать хорошо, либо лучше не делать вообще.
Решение: как минимум разъяснять участникам ревью, что оно должно выполняться на основании внимательного, вдумчивого и полного прочтения, что опять же может быть не слишком просто.
4) Проверяемая документация и проверяющие люди должны соответствовать друг другу. Тут всё просто - сделать нормальное ревью документации могут только те, кто хотя бы что-то способен в ней понять. Ну нет смысла отдавать очень техничное описание сложных внутренних команд тестировщикам графических интерфейсов - может и поймут что-то и даже может что полезное скажут, но скорее всего только время потеряют.
Решение: разумно составлять список рецензентов.
5) Люди слишком увлекаются не самыми существенными деталями. Это как в обычном тестировании - человек, допустим, увлекается проверкой правильно расставленных знаков препинания во всём приложении. В принципе - дело нужное, но если из-за него упускаются из виду гораздо более значительные вещи - это уже не очень хорошо.
Решение: пытаться проводить разъяснительные беседы и расставлять приоритеты; но не очень помогает.
6) Люди ревьюят не то, что нужно. Это проблема больших документов, которые не пишутся каждый раз с нуля, а в которые вносятся дополнения. Люди умудряются вносить свои замечания не по новым правкам, о которых сейчас речь идёт, а к старому тексту. Может оно и не лишено смысла - если действительно находятся важные проблемы, но с таким я практически не сталкивалась; а замечания эти и отвлекают, да и незапланированные изменения в уже устоявшихся частях приложения далеко не всегда будут приветствоваться как руководством, так и разработчиками.
Решение: чётко разграничивать материал, подлежащий и не подлежащий ревью.
7) Люди ревьюят тогда, когда этого никто не ждёт. А это уже проблема таких форматов ведения документации, как вики - которые постоянно доступны всем online. Тут проблема очень простая - если речь идёт о большом объёме документации, то такие неожидаемые комментарии очень легко просто не заметить, ну ведь не пересматриваю же я постоянно все-все странички в вики в поисках новых комментариев!
Решение: чётко оговаривать время для ревью
Пожалуй, и хватит пока, и так месячную графоманскую норму за день выполнила :) Может кому-то будет полезно, а нет - хоть самой себе о некоторых вопросах напомнила :)
Часть 1: А не проще ли у аналитика спросить?
Часть 2: И какая от тестировщика польза?
тестировщиком работаю пару месяцев. недавно пришла документация на ревью, смотрю БТ и ничего не понимаю, смотрю ФС - та же картина.. ваш пост помог во многом разобраться и правильно расставить приоритеты. спасибо :)
ОтветитьУдалитьВот это да! Большое спасибо за ваш комментарий! Со вчерашней ночи мучаюсь, что чего-то не слишком интересного понаписывала, а тут оказывается, что это уже кому-то пригодилось... Это очень приятно.
УдалитьУспехов вам! А разбираться с новой документацией - это никогда не просто...
Спасибо большое! :)
ОтветитьУдалитьТеперь понятно, почему у меня отношения с этим видом тестирования ну никак не складываются)
О, очень интересно - и почему же?
УдалитьНу, и времени мало на вдумчивое прочтение.
УдалитьИ тз объёмные (порядка 100 страниц в среднем), поэтому да, иногда проверяю не то, что надо. И зачастую бывает, что уже всё делается не по ТЗ, но при этом оно даётся всем, как основа. Поэтому и пристаю к аналитикам, а из тз только общие сведения могу почерпнуть.
Время - это, конечно, вечная проблема. Если на ревью время отдельно не выделено, и если все не понимают, что во время ревью человек не может параллельно ещё все свои обычные обязанности выполнять - то ничего путного, по-моему, и не наревьюится.
УдалитьНу а если на проекте документация неактуальная, то, разумеется, вообще всякий смысл исчезает с этой документацией вплотную работать. Бороться с неактуальностью надо, но сама знаю, как это непросто...
Лена, а посоветуйте, пожалуйста, как перейти от тестирования в аналитику. Что почитать, чему поучиться?
ОтветитьУдалитьЭх, надо поскорее описать всё-таки, как я род деятельности сменила, потому что - увы - с тем, как это вышло у меня, я вряд ли смогу что-либо толкового посоветовать.
УдалитьАнна, мне в другой моей заметке задали подобный вопрос - надеюсь, это не будет очень некрасиво, если я сейчас просто сюда свой ответ скопирую... Вон он (вряд ли я могу что-то путное добавить):
"Ох-ох, боюсь, что вопрос не очень по адресу. Честно говоря, неспроста я написала, что "вроде как" уже не тестировщик, потому что я, наверное, "неправильный" аналитик - в данный момент работаю практически без теоретической базы, в основном основываясь на своём тестерском виденьи, как же нужно делать мою аналитическую работу (как я писала выше, история перехода в аналитики у меня достаточно забавная, всё-таки надо будет о ней отдельно рассказать).
Поэтому я сама сейчас задумываюсь о том, откуда бы полезной информации поднабраться. Могу поделиться той ссылочкой http://analyst.by/forum/topics/literatura-dlya-novichkov/, которую я для себя нашла - это конкретные рекомендации по поводу того, что бы почитать начинающему аналитику, да и сам сайт любопытен, может как раз сюда стоит Ваши вопросы адресовать?"
Спасибо за статью, очень интересен опыт!
ОтветитьУдалитьМы достаточно недавно начали проводить ревью требований со стороны тестировщиков, польза и грабли примерно схожие) Но пока эксперимент считаем достаточно удачным)
red_foks, спасибо за комментарий :)
УдалитьНа самом деле это здОрово, когда подобные нововведения сразу становятся хотя бы относительно удачными - на моём предыдущем проекте из всей затеи вообще ничего не вышло. Так что успехов вам в этом непростом деле! :)
Интересный доклад от Натальи Руколь - http://www.req-labs.ru/conf2012/agenda/498/ Может будет интересно)
УдалитьСпасибо за ссылочку!
Удалить