Как писать тест-планы? Нет единственно правильного шаблона и | Shoo and Endless Agony

Как писать тест-планы?

Нет единственно правильного шаблона или формата для написания тест-планов.

Как и любой документ (особенно для внутреннего использования) он может быть написан миллионом разных способов и с разной степенью детализации.
Единственный критерий "правильности" - действительно ли созданный вами тест-план отвечает на те вопросы, ради ответов на которые вы начали его писать.
Более того, часто вместо описания тех или иных блоков тест-плана может быть полезнее оставить в нём ссылку на внешний документ, содержащий всю нужную информацию.
Так, Лиза Криспин, в своей прекраснейшей книжке "Agile Testing" резонно отмечает, что если тебе не нужно каждый раз переписывать тест-план с нуля для очередного релиза (а в случае с итеративной моделью разработки так обычно и происходит), то значительную
часть вопросов из тест-плана ты можешь вынести в отдельные документы - описание принципов тестирования, тестовую стратегию, quality gate`ы и прочее.

Когда их нужно писать?

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

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