Сообщений в теме: 8

[Натали]

Во время чтения рекомендаций в ветке "Что делать в условиях ограниченного времени?" у меня возник вопрос - а что, по мнению уважаемых форумчан является необходимым минимумом из документации для нормальной работы тестера?
Под документацией я прошу понимать все - от планов до скриптов...

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

[barancev]

Ответ очевиден -- минимумом является полное отсутствие документации. Меньше уже никак нельзя.

А для того, чтобы от этого минимума подняться, нужно немного прояснить требования. Что значит "для нормальной работы тестера"? "Нет никаких записанных требований" -- это нормальная работа? Иногда да, иногда нет. Мы какой случай рассматриваем?

[Натали]

Мда...
Попробую пояснить.

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

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

И вот исходя из этой ненормальности - что мне надо фиксировать, записывать и прочее, чтобы моя работа была эффективной?

Вернее так - что бы Вы записывали и документировали в такой ситуации?

[Viktor]

Вот о чем-то подобном сначала рассуждали здесь, но Вы же там были? :)
PS. Многие (мы все?) практически влюбились там в Сергея, но потом он почему-то рассердился.

[SALar]

1. Сначала совсем ничего, все на словах.
2. Затем баг лист. Это основной документ. Настоятельно рекомендуется вести в неком средстве, хотя иногда удобней на бумаге.
3. Список сценариев будет следующим документом. Excell или Word, в свободной форме. На бумаге писать не рекомендую, т.к. переделывается часто.
Ну принято так. Сначало дом построить, потом перенести вход на другую сторону, увеличить толщину фундамента, сдвинуть крышу вбок, и закрасить окна черной краской. Ах да, еще надстроить пару этажей.
4. А с планом, по разному бывает. Он нужен для самоконтроля и для согласования работ в фирме. Согласованием планов в наших фирмах занимаются достаточно редко, а для самоконтроля ежедневник удобнее.

И уж совсем потом появляются всякие другие документы. Стратегии тестирования, внутрикорпоративный глоссарий, методические наработки, паспорта тестовых стендов, планы тренингов...

[barancev]

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

Вот это хорошее замечание, про "как положено". Собственно, кем положено? Кем-то, кто построил в организации определённый процесс. Чем более этот процесс структурирован, формализован, тем более строгие требования предъявляются к документации, к её структуре и полноте. В том числе это относится и к тестированию. Это не потому, что так лучше, а потому, что без этого в большой организации не выжить. Это не цель, а средство. Потому что люди общаются по установленной модели.

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

Ну, в самом деле, не придумывать же каждый раз чек-лист заново? Конечно имеет смысл его записать. И пополнять по мере небходимости. Нужно ли аккуратно и педантично записывать тест-планы по некоторому шаблону? Конечно, если это помогает. Если шаблон "стесняет движения" -- его нужно выбросить. Через некоторое время выработается свой, как раз по фигуре и по росту.

Современные процессы для небольших мобильных команд, типа XP, даже пытаются зафиксировать этот отказ от лишней документации в основных постулатах -- документировать нужно только то, что действительно нужно. То, необходимость чего вы ЛИЧНО понимаете, без чего вы ЛИЧНО не можете работать.

Более того, крупные организации тоже понимают, что структуризация часто мешает работать, именно поэтому в последнее время становится очень популярным принцип "проектных команд", когда в организаци созадаётся небольшая относительно обособленная команда, которая с внешним миром общается "как положено", а внутри организовывает менее формальное и потому более эффективное взаимодействие.

[Натали]

Виктор, хорошо, что Вы напомнили - перечитала всю ветку. Появились новые мысли.

SALar, спасибо. Я сейчас как раз на третьем этапе.

Алексей, меня смущало то, что я одна, и, соответственно, все решаю сама - что писать, что не писать. И нужно ли все документировать сразу, а не постепенно.

Большое всем спасибо.
У меня появились новые идеи и ушло ощущение неверного пути. :)

[van]

Для меня проблема документирования - шаблоны документации, оформление документации, хранение документации и т.п. стоит тоже достаточно остро.
Дело в том, что в моей команде по независящим от меня причинам (которые я очень стараюсь изменить) происходит довольно частая смена кадров. Поэтому я вынужден требовать от своих тестеров (и от самого себя :) ) определенный набор документации, чтобы вся работа не канула в небытие вместе с уходом сотрудника.
В настоящий момент в своей деятельности я использую следующий виды документации:
1. Конечно - же чек - листы, которые создаются в самую первую очередь, и являются страховочным тросом, если по каким - либо причинам не удастся написать основной набор тестов (тест - кейсов)
2. Спецификация проектирования тестов
3. Спецификация тестов (непосредственное описание тестов, тест - кейсы)
4. Спецификация процедуры тестирования (оформляется по мере необходимости, если стандартная процедура тестирования чем - то отличается от предыдущих)
5. Полноценный план тестирования ведется в настоящее время только для автоматизации тестирования, поскольку весь проект начинался еще без меня и план для этого никто не писал. А поскольку автоматизированное тестирование я поднимал с нуля, то решил и полноценный план написать. Пригодится для потомства :)
6. Различные отчеты, необходимый топ - менеджменту.

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

[Натали]

2. Спецификация проектирования тестов
4. Спецификация процедуры тестирования

А что из себя представляют эти две спецификации?
Проектирование тестов(2) - просто шаблоны, или что-то другое?