В моем случает обязательное можно совместить с полезным. Документация к моему ПО должна выполняться по ГОСТ 19, начиная с технического задания. Многим ГОСТ 80-х может казаться анахронизмом, но он все равно работает при правильном применении.
Разрабатывая техническое задание часто хочется указать в нем все требования подробно с описанием выходных данных и поведения, но тогда это задание долго писать и согласовывать. Вот в чем ошибка - это ЗАДАНИЕ, а не спецификация требований. Задание описывает вехи, промежуточные точки по которым можно определить успех выполнения задания. Подробные требования помещаем в документ вида 51 Программа и методика испытания приемочных испытаний (оно и есть тест-план), в нем как раз в разделе методик и описываем конкретные требования по пункту ТЗ и как проверить, что он выполнен. Проверка одного пункта ТЗ может выполняться несколькими пунктами методики, т.е. каждый пункт ее подробно описывает все выполняемые функции этого пункта ТЗ и как определить, что они реализованы верно.
Я сам только после прочтения статьи понял, что программа и методика на самом деле и есть тест-план. Оказывается я уже много лет их пишу )
http://gaperton.livejournal.com/49867.html
Разрабатывая техническое задание часто хочется указать в нем все требования подробно с описанием выходных данных и поведения, но тогда это задание долго писать и согласовывать. Вот в чем ошибка - это ЗАДАНИЕ, а не спецификация требований. Задание описывает вехи, промежуточные точки по которым можно определить успех выполнения задания. Подробные требования помещаем в документ вида 51 Программа и методика испытания приемочных испытаний (оно и есть тест-план), в нем как раз в разделе методик и описываем конкретные требования по пункту ТЗ и как проверить, что он выполнен. Проверка одного пункта ТЗ может выполняться несколькими пунктами методики, т.е. каждый пункт ее подробно описывает все выполняемые функции этого пункта ТЗ и как определить, что они реализованы верно.
Я сам только после прочтения статьи понял, что программа и методика на самом деле и есть тест-план. Оказывается я уже много лет их пишу )
http://gaperton.livejournal.com/49867.html
In my case, compulsory can be combined with useful. The documentation for my software should be performed in accordance with GOST 19, starting with the technical specifications. To many, GOST of the 80s may seem an anachronism, but it still works if used correctly.
When developing a technical task, one often wants to indicate in it all the requirements in detail with a description of the output data and behavior, but then this task should be written and coordinated for a long time. That is the mistake - it is a JOB, not a specification of requirements. The task describes milestones, intermediate points by which you can determine the success of the task. We place the detailed requirements in a document of type 51. The program and test procedure for acceptance tests (it is the test plan), it’s just in the methodology section and we describe the specific requirements under item TK and how to verify that it has been completed. Checking one item of TK can be performed by several points of the methodology, i.e. each paragraph of it describes in detail all the functions performed by this paragraph of the ToR and how to determine that they are implemented correctly.
After reading the article, I myself realized that the program and methodology are actually a test plan. It turns out I have been writing them for many years)
http://gaperton.livejournal.com/49867.html
When developing a technical task, one often wants to indicate in it all the requirements in detail with a description of the output data and behavior, but then this task should be written and coordinated for a long time. That is the mistake - it is a JOB, not a specification of requirements. The task describes milestones, intermediate points by which you can determine the success of the task. We place the detailed requirements in a document of type 51. The program and test procedure for acceptance tests (it is the test plan), it’s just in the methodology section and we describe the specific requirements under item TK and how to verify that it has been completed. Checking one item of TK can be performed by several points of the methodology, i.e. each paragraph of it describes in detail all the functions performed by this paragraph of the ToR and how to determine that they are implemented correctly.
After reading the article, I myself realized that the program and methodology are actually a test plan. It turns out I have been writing them for many years)
http://gaperton.livejournal.com/49867.html
У записи 1 лайков,
0 репостов,
91 просмотров.
0 репостов,
91 просмотров.
Эту запись оставил(а) на своей стене Дмитрий Синявский
