среда, 12 декабря 2012 г.

ТЗ? Не, не слышала...

Я не умею работать с техническим заданием.
Ну, как не умею.
Если я его вижу (а вижу я его редко), то я его читаю и получаю общее представление о том, что же за систему мы будем писать.

Учитывая, что во всех технических заданиях, которые мне попадались, всегда присутствует куча воды, то его рациональность для меня стремится к нулю.

В одном ТЗ вообще мы с коллегами встретили очень милую фразу: "Программа должна меняться в соответствии с изменениями в законодательстве, не меняя программного кода". Смеялись долго, да. Отпаивались тоже потом. Это же реализовывать, да.

Так к чему это я?, А, да.  У тестировщиков есть одна активность, вроде как:, под названием "тестирование требований". И тут вопрос: а как это делается правильно?

Выписываются функции из тз?
Просто проверяется, чтобы вот таких фраз не было?
Ещё что-то делается, чего я пока что не знаю?

Сейчас я выписываю функции, которые должны быть реализованы. Раньше пунктами, теперь составляю из них майнд-карту, чтобы видеть, как они взаимосвязаны между собой. А потом иду к аналитику и задаю вопросы, как именно должна работать та или иная функция.

Что делаете вы, когда получаете ТЗ?
И видели ли вы идеальное ТЗ, в котором всё расписано по пунктам и прям сразу понятно, что да как?

И чтобы два раза не вставать: не переоценивают ли ТЗ? Может, реально проще общаться с аналитиком, чем читать? Он как человек, больше поможет-то, чем бумажки...

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

  1. Когда получаю ТЗ - читаю, потом в приложение, только потом вопросы человеку.

    Идеальное не видел, но видел очень хорошие, в которых не было ответа на все вопросы, но был ответ именно на те, которые я бы задал человеку.

    ТЗ - способ коммуникации, один ко многим. Мне, как читающему ТЗ действительно проще пообщаться с аналитиком, вот только бедному аналитику тяжело по десять раз на одни и те же вопросы разным людям отвечать.

    ОтветитьУдалить
    Ответы
    1. Когда получаю ТЗ - читаю, потом в приложение(с)
      То есть вы не видите тз ДО того, как ребята начинают что-то программировать. У меня, если я его и вижу, то одновременно с программистами. Так что не особо вариант в приложение лезть :)

      ТЗ - способ коммуникации, один ко многим.(с)
      Хм, никогда не смотрела на тз как способ коммуникации.

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

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

      Удалить
    2. Отлично! Постараюсь оперативно отписаться...

      Удалить
    3. Ой, что-то разошлась я... Аж вот в трёх частях получилось, хорошо бы хоть в одной из частей что разумное нашлось... %)

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

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

    ОтветитьУдалить
    Ответы
    1. Ну этот же результат может получиться просто при разговоре, когда аналитик говорит с тестировщиком, не? Ты ведь тоже будешь задавать вопросы. Да и аналитик поймёт, что какую-то фигню сказал.

      Я не против тз, я, наверное, против такого моления на него, что это панацея.

      Удалить
    2. А никто не говорит, что это панацея. Это способ держать информацию в виде, который в итоге согласуется с заказчиком (не понесёшь же ты заказчику карты? или понесешь и эта проблема только из-за гос.специфики? =)).

      И потом, у меня неоднократно были ситуации, когда один и тот же вопрос задаётся аналитику раз 8 за полгода (с периодичностью некой) — и всегда получается "чуть-чуть" отличающийся ответ. Причем в таком случае доводы о том, что говорилось ранее, не помогают, к сожалению. Даже с демонстрацией мапы с этим изменением. А вот ссылка на ТЗ — более чем.

      Удалить
  4. А что отдается Заказчику, если нет ТЗ?
    Советую тебе Карла Вигерса, если уж книжки по тестированию не хочется, то вот - про аналитику :)
    Человеческий мозг не способен все запомнить. Не будет ТЗ - будет несчастный аналитик, к которому каждую минуту прибегают с уже оговоренными ранее вопросами...

    ОтветитьУдалить
    Ответы
    1. Но! Я не считаю, что тз не нужно - не надо тут :). Мне кажется, что оно просто переоценено для работы тестировщика.

      Что мешает раз спросить у аналитика, записать, преобразовать в карту/пункты и радоваться жизни, попутно обновляя?
      Разве у тебя не было такого, что тз под конец разработки вааащеее неактуально?

      Удалить
  5. Гуглите два видео:
    "Написание тестов как вид тестирования требований"
    "Приоритезация методов верификации требований"
    Первое полезней.

    А также, найдите / купите / выпросите / ... (если надо украдите) "Сколько стоит программный проект" Фаулера.

    ОтветитьУдалить