Писать не по шаблону, принятому в команде
В каждой компании есть свои правила оформления ТЗ, и не важно, какие конкретно - кто-то пишет по ГОСТУ, кто-то вставляет информацию для тестирования, а кто-то нет, важно одно: внутри одного проекта все ТЗ должны быть оформлены по максимуму одинаково для удобства тех, кто их читает.
Можно провести аналогию с конвейером: представьте, что вы собираете детские пирамидки. Перед вами стоит лента, по которой в определенной последовательности проезжают кольца для пирамидки: от самого большого до самого маленького, затем снова самое большое - уже для новой. Вы просто механически берете и каждое насаживаете на палку для пирамидки в той последовательности, в которой они приезжают, и вам не нужно сравнивать их размеры. А теперь представьте, что конвейер выдает вам все кольца в разной последовательности: сначала вам придется дождаться всех колец, потом сравнить их по размеру, и только потом собрать пирамидку. На сколько % упадет ваша скорость сбора пирамидок в этом случае?
То же самое с ТЗ: когда остальная команда вынуждена искать ссылку на протокол то в начале, то в конце документа, или тестировщик видит сценарии то в начале, то в середине - это повышает вероятность того, что многие пункты из ТЗ будут просто пропущены или вас достанут вопросами "а где это находится".
Поэтому, если по какой-то причине вы пишете не по шаблону:
- Если есть на то адекватные причины, обсудите с теми, кто пишет ТЗ и поменяйте общий шаблон ,чтобы все писали по-новому. Покажите остальным участникам команды, где были изменения.
- Если стандартный шаблон не подходит (задача слишком необычная), то напишите не по шаблону, но лучше всего в дальнейшем сесть с разработчиком, тестировщиком и пройтись с ними по ТЗ, чтобы убедиться, что все моменты поняты.
- Если нет адекватных причин и вы просто привыкли писать по-другому, отвыкайте.
Если у вас в команде нет единого стандарта описания, шаблона ТЗ - самое время его завести.
В каждой компании есть свои правила оформления ТЗ, и не важно, какие конкретно - кто-то пишет по ГОСТУ, кто-то вставляет информацию для тестирования, а кто-то нет, важно одно: внутри одного проекта все ТЗ должны быть оформлены по максимуму одинаково для удобства тех, кто их читает.
Можно провести аналогию с конвейером: представьте, что вы собираете детские пирамидки. Перед вами стоит лента, по которой в определенной последовательности проезжают кольца для пирамидки: от самого большого до самого маленького, затем снова самое большое - уже для новой. Вы просто механически берете и каждое насаживаете на палку для пирамидки в той последовательности, в которой они приезжают, и вам не нужно сравнивать их размеры. А теперь представьте, что конвейер выдает вам все кольца в разной последовательности: сначала вам придется дождаться всех колец, потом сравнить их по размеру, и только потом собрать пирамидку. На сколько % упадет ваша скорость сбора пирамидок в этом случае?
То же самое с ТЗ: когда остальная команда вынуждена искать ссылку на протокол то в начале, то в конце документа, или тестировщик видит сценарии то в начале, то в середине - это повышает вероятность того, что многие пункты из ТЗ будут просто пропущены или вас достанут вопросами "а где это находится".
Поэтому, если по какой-то причине вы пишете не по шаблону:
- Если есть на то адекватные причины, обсудите с теми, кто пишет ТЗ и поменяйте общий шаблон ,чтобы все писали по-новому. Покажите остальным участникам команды, где были изменения.
- Если стандартный шаблон не подходит (задача слишком необычная), то напишите не по шаблону, но лучше всего в дальнейшем сесть с разработчиком, тестировщиком и пройтись с ними по ТЗ, чтобы убедиться, что все моменты поняты.
- Если нет адекватных причин и вы просто привыкли писать по-другому, отвыкайте.
Если у вас в команде нет единого стандарта описания, шаблона ТЗ - самое время его завести.