четверг, 13 декабря 2012 г.

Зачем тестировщику доки читать. Часть 3: Как? Когда? И немного граблей :)

Продолжая тему взаимодействия тестировщиков с проектной документацией (см. часть 1, часть 2), в этой части хочу коротко упомянуть, как технически у нас осуществляется тестирование требований и какие вообще есть проблемы с этим процессом.


Как я писала в части 2, под тестированием требований я понимаю их ревью, которое у нас осуществляется очень просто:

1) на ревью выделяется определённое время, в течение которого в предоставленном документе каждый рецензент оставляет свои комментарии (о каком бы формате документации у нас речь ни шла - MS Office Word, pdf, xwiki - внесение комментариев в том или ином виде везде возможно).

2) в конце отведённого на ревью срока автор документации получает комментарии от всех рецензентов и обрабатывает их: если замечание однозначно требует исправления - вносит эти исправления, ну а если есть какие-то спорные моменты, то у нас это обычно разрешается либо в процессе e-mail переписки, либо по телефону, либо ещё как-то.

3) исправленная на основании результатов ревью версия документа снова предоставляется всем заинтересованным лицам, после чего возможен ещё один раунд рецензирования.

Конечно, это формальный путь ревью, но также работает и неформальный путь, когда приходит ко мне кто-либо из команды и говорит, что у него есть такой-то вопрос по спецификации - мы вместе смотрим, разбираемся и так или иначе решаем этот вопрос. Ну прям как с багами - можно проблему официально через багтрекер провести, а можно быстренько и так с ней разобраться; плюсы и минусы примерно те же :)

Разумеется, есть у нас с этими ревью и проблемы, и вопросы - а куда же без них? Все они достаточно стандартные и понятные - так что вот коротенько их список:

Самый главный вопрос - когда? Вопрос на самом деле состоит из двух частей:

1) Во-первых, на само ревью нужно выделенное время; если его отдельно не выделяют или выделяют слишком мало - вряд ли что-то хорошее из всей затеи получится.
Решение: ничего другого кроме как пытаться выбить из начальства время на ревью я и не вижу, одно хорошо - аргументация пользы от такого тестирования очень хорошо в соответствующих книгах описана.

2) Во-вторых, и написание самой документации, и её ревью должны выполняться своевременно - желательно до разработки самого приложения. У нас это получается далеко не всегда. Конечно, даже если разработка началась, от качественного ревью толк всё равно будет, но ценность его снизится.
Решение: работать над улучшением процессов, пытаться лучше придерживаться графиков и т.п., что проще сказать, но сделать достаточно трудно.

И ещё несколько моментов:

3) Ревью необходимо делать качественно. Звучит очень банально, но реально постоянно приходится сталкиваться как с очень толковыми замечаниями от одних людей, так и с очень бестолковыми - от других. А ведь отреагировать я как автор документации должна на каждое замечание, и приходится строчить письма, чтобы объяснять простые вещи, которые в той же спецификации написаны, но которые кто-то не потрудился прочитать и понять - только время зря тратишь. Так что ревью надо делать хорошо, либо лучше не делать вообще.
Решение: как минимум разъяснять участникам ревью, что оно должно выполняться на основании внимательного, вдумчивого и полного прочтения, что опять же может быть не слишком просто.

4) Проверяемая документация и проверяющие люди должны соответствовать друг другу. Тут всё просто - сделать нормальное ревью документации могут только те, кто хотя бы что-то способен в ней понять. Ну нет смысла отдавать очень техничное описание сложных внутренних команд тестировщикам графических интерфейсов - может и поймут что-то и даже может что полезное скажут, но скорее всего только время потеряют.
Решение: разумно составлять список рецензентов.

5) Люди слишком увлекаются не самыми существенными деталями. Это как в обычном тестировании - человек, допустим, увлекается проверкой правильно расставленных знаков препинания во всём приложении. В принципе - дело нужное, но если из-за него упускаются из виду гораздо более значительные вещи - это уже не очень хорошо.
Решение: пытаться проводить разъяснительные беседы и расставлять приоритеты; но не очень помогает.

6) Люди ревьюят не то, что нужно. Это проблема больших документов, которые не пишутся каждый раз с нуля, а в которые вносятся дополнения. Люди умудряются вносить свои замечания не по новым правкам, о которых сейчас речь идёт, а к старому тексту. Может оно и не лишено смысла - если действительно находятся важные проблемы, но с таким я практически не сталкивалась; а замечания эти и отвлекают, да и незапланированные изменения в уже устоявшихся частях приложения далеко не всегда будут приветствоваться как руководством, так и разработчиками.
Решение: чётко разграничивать материал, подлежащий и не подлежащий ревью.

7) Люди ревьюят тогда, когда этого никто не ждёт. А это уже проблема таких форматов ведения документации, как вики - которые постоянно доступны всем online. Тут проблема очень простая - если речь идёт о большом объёме документации, то такие неожидаемые комментарии очень легко просто не заметить, ну ведь не пересматриваю же я постоянно все-все странички в вики в поисках новых комментариев!
Решение: чётко оговаривать время для ревью

Пожалуй, и хватит пока, и так месячную графоманскую норму за день выполнила :) Может кому-то будет полезно, а нет - хоть самой себе о некоторых вопросах напомнила :)

Часть 1: А не проще ли у аналитика спросить?
Часть 2: И какая от тестировщика польза?

12 комментариев:

  1. тестировщиком работаю пару месяцев. недавно пришла документация на ревью, смотрю БТ и ничего не понимаю, смотрю ФС - та же картина.. ваш пост помог во многом разобраться и правильно расставить приоритеты. спасибо :)

    ОтветитьУдалить
    Ответы
    1. Вот это да! Большое спасибо за ваш комментарий! Со вчерашней ночи мучаюсь, что чего-то не слишком интересного понаписывала, а тут оказывается, что это уже кому-то пригодилось... Это очень приятно.

      Успехов вам! А разбираться с новой документацией - это никогда не просто...

      Удалить
  2. Спасибо большое! :)
    Теперь понятно, почему у меня отношения с этим видом тестирования ну никак не складываются)

    ОтветитьУдалить
    Ответы
    1. О, очень интересно - и почему же?

      Удалить
    2. Ну, и времени мало на вдумчивое прочтение.
      И тз объёмные (порядка 100 страниц в среднем), поэтому да, иногда проверяю не то, что надо. И зачастую бывает, что уже всё делается не по ТЗ, но при этом оно даётся всем, как основа. Поэтому и пристаю к аналитикам, а из тз только общие сведения могу почерпнуть.

      Удалить
    3. Время - это, конечно, вечная проблема. Если на ревью время отдельно не выделено, и если все не понимают, что во время ревью человек не может параллельно ещё все свои обычные обязанности выполнять - то ничего путного, по-моему, и не наревьюится.

      Ну а если на проекте документация неактуальная, то, разумеется, вообще всякий смысл исчезает с этой документацией вплотную работать. Бороться с неактуальностью надо, но сама знаю, как это непросто...

      Удалить
  3. Лена, а посоветуйте, пожалуйста, как перейти от тестирования в аналитику. Что почитать, чему поучиться?

    ОтветитьУдалить
    Ответы
    1. Эх, надо поскорее описать всё-таки, как я род деятельности сменила, потому что - увы - с тем, как это вышло у меня, я вряд ли смогу что-либо толкового посоветовать.

      Анна, мне в другой моей заметке задали подобный вопрос - надеюсь, это не будет очень некрасиво, если я сейчас просто сюда свой ответ скопирую... Вон он (вряд ли я могу что-то путное добавить):

      "Ох-ох, боюсь, что вопрос не очень по адресу. Честно говоря, неспроста я написала, что "вроде как" уже не тестировщик, потому что я, наверное, "неправильный" аналитик - в данный момент работаю практически без теоретической базы, в основном основываясь на своём тестерском виденьи, как же нужно делать мою аналитическую работу (как я писала выше, история перехода в аналитики у меня достаточно забавная, всё-таки надо будет о ней отдельно рассказать).

      Поэтому я сама сейчас задумываюсь о том, откуда бы полезной информации поднабраться. Могу поделиться той ссылочкой http://analyst.by/forum/topics/literatura-dlya-novichkov/, которую я для себя нашла - это конкретные рекомендации по поводу того, что бы почитать начинающему аналитику, да и сам сайт любопытен, может как раз сюда стоит Ваши вопросы адресовать?"

      Удалить
  4. Спасибо за статью, очень интересен опыт!

    Мы достаточно недавно начали проводить ревью требований со стороны тестировщиков, польза и грабли примерно схожие) Но пока эксперимент считаем достаточно удачным)

    ОтветитьУдалить
    Ответы
    1. red_foks, спасибо за комментарий :)

      На самом деле это здОрово, когда подобные нововведения сразу становятся хотя бы относительно удачными - на моём предыдущем проекте из всей затеи вообще ничего не вышло. Так что успехов вам в этом непростом деле! :)

      Удалить
    2. Интересный доклад от Натальи Руколь - http://www.req-labs.ru/conf2012/agenda/498/ Может будет интересно)

      Удалить
    3. Спасибо за ссылочку!

      Удалить