Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.
Что такое тестовая документация?
Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д.
В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).
В чем важность тестовой документации?
Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.
Понятие и назначение документов в бухгалтерском учете
Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.
И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA.
Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.
Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.
Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.
Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.
Какую тестовую документацию используют QA-команды?
Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.
План тестирования (test plan)
План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта.
8. Виды конструкторских документов
В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.
Чеклист (checklist)
Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.
Выглядит чеклист как список функций с указанием статуса — результата проверки.
Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.
Тест-кейс (test case)
В тест-кейсе содержатся:
- подробное описание шагов и действий, которые тестировщик должен выполнить для тестирования какой-то одной части функционала,
- критерии прохождения тестов.
Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.
Сценарий использования (use case)
Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением.
Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя.
При создании юзкейсов тестировщики учитывают требования и бизнес-цели.
Баг-репорт
Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага.
Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.
Требования (requirements specification)
Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения.
В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.
Как все это работает?
Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей.
А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.
Чем крупнее проект, тем больше документации нужно.
Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.
Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет.
Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.
Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.
В заключение
Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.
Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.
Источник: testengineer.ru
Техническая документация
разработка техдокументации по ГОСТ без бумаги и расстояний
Выбор (уточнение) состава комплекта документов
Выбор (уточнение) состава комплекта документов определяется предметом разработки (и документирования), а также целями и задачами документирования (видом разработки). Редакция от 12.03.2021.
Создан 17.02.2010 17:09:02
Состав комплекта документов на изделия
Состав комплекта документов на изделия регламентирован ГОСТ 2.102-68.
Документы подразделяют на виды, указанные в таблице ниже.
Документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля
Документ, содержащий изображение сборочной единицы и другие данные, необходимые для ее сборки (изготовления) и контроля. К сборочным чертежам также относят чертежи, по которым выполняют гидромонтаж и пневмомонтаж
Чертеж общего вида
Документ, определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия
Документ, определяющий геометрическую форму (обводы) изделия и координаты расположения составных частей
Документ, содержащий контурное (упрощенное) изображение изделия с габаритными, установочными и присоединительными размерами
Документ, содержащий данные, необходимые для выполнения электрического монтажа изделия
Документ, содержащий контурное (упрощенное) изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. К монтажным чертежам также относят чертежи фундаментов, специально разрабатываемых для установки изделия
Документ, содержащий данные, необходимые для выполнения упаковывания изделия
Документ, на котором показаны в виде условных изображений или обозначений составные части изделия и связи между ними
Документ, определяющий состав сборочной единицы, комплекса или комплекта
Документ, содержащий перечень всех спецификаций составных частей изделия с указанием их количества и входимости
Документ, содержащий перечень документов, на которые имеются ссылки в конструкторских документах изделия
Документ, содержащий перечень покупных изделий, примененных в разрабатываемом изделии
Документ, содержащий перечень покупных изделий, разрешенных к применению в соответствии с ГОСТ 2.124
Документ, содержащий перечень предприятий (организаций), на которых хранят подлинники документов, разработанных и (или) примененных для данного изделия
Документ, содержащий перечень документов, вошедших в техническое предложение
Ведомость эскизного проекта
Документ, содержащий перечень документов, вошедших в эскизный проект
Ведомость технического проекта
Документ, содержащий перечень документов, вошедших в технический проект
Документ, содержащий описание устройства и принципа действия разрабатываемого изделия, а также обоснование принятых при его разработке технических и технико-экономических решений
Документ, содержащий требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других конструкторских документах
Документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля
Документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу
Документ, содержащий расчеты параметров и величин, например, расчет размерных цепей, расчет на прочность и др.
Документ, содержащий указания и правила, используемые при изготовлении изделия (сборке, регулировке, контроле, приемке и т. п.)
Документ, содержащий сведения о конструкции, принципе действия, характеристиках (свойствах) изделия, его составных частей и указания, необходимые для правильной и безопасной эксплуатации изделия (использования по назначению, технического обслуживания, текущего ремонта, хранения и транспортирования) и оценок его технического состояния при определении необходимости отправки его в ремонт, а также сведения по утилизации изделия и его составных частей
Документ, содержащий сведения, необходимые для монтажа, наладки, пуска, регулирования, обкатки и сдачи изделия и его составных частей в эксплуатацию на месте его применения
Документ, содержащий сведения, удостоверяющие гарантии изготовителя, значения основных параметров и характеристик (свойств) изделия, сведения, отражающие техническое состояние данного изделия, сведения о сертификации и утилизации изделия, а также сведения, которые вносят в период его эксплуатации (длительность и условия работы, техническое обслуживание, ремонт и другие данные)
Документ, содержащий сведения, удостоверяющие гарантии изготовителя, значения основных параметров и характеристик (свойств) изделия, а также сведения о сертификации и утилизации изделия
Документ, содержащий гарантии изготовителя, значения основных параметров и характеристик (свойств) изделия, сведения о сертификации и изделия
Документ, содержащий перечень деталей и сборочных единиц изделия с иллюстрациями и сведения об их количестве, расположении в изделии, взаимозаменяемости, конструктивных особенностях и материалах
Документ, содержащий номенклатуру запасных частей изделия и их количество, расходуемое на нормируемое количество изделий в период их эксплуатации
Документ, содержащий номенклатуру материалов и их количество, расходуемое на нормируемое количество изделий в период их эксплуатации
Документ, содержащий номенклатуру, назначение, количество и места укладки запасных частей, инструментов, принадлежностей и материалов, расходуемых за срок службы изделия
Документы, содержащие сведения о конструкции изделия, принципах действия, приемах использования, техническом обслуживании, областях технических знаний с необходимыми иллюстрациями
Документ, устанавливающий комплект эксплуатационных документов и места укладки документов, поставляемых с изделием или отдельно от него
[из 1.2 ГОСТ 2.102-68]
Состав комплекта ремонтных документов на изделия
К ремонтным документам относят текстовые и графические рабочие конструкторские документы, которые в отдельности или в совокупности дают возможность обеспечивать подготовку ремонтного производства, произвести ремонт изделия и его контроль после ремонта [из 6.1.1 ГОСТ 2.602-2013]
Документы подразделяют на виды, указанные в таблице 2.
Таблица 2 — Виды ремонтных документов
Документ, содержащий указания по организации ремонта, правила и порядок выполнения капитального (среднего) ремонта, контроля, регулирования, испытаний, консервации, транспортирования и хранения изделия после ремонта, монтажа и испытания изделия на объекте, значение показателей и норм, которым должно удовлетворять изделие после ремонта
Общее руководство по ремонту
Документ, содержащий указания по организации ремонта определенной группы однотипных изделий, правила и порядок подготовки и проведения ремонта, значения показателей и нормы, которым должны удовлетворять изделия после ремонта, правила и порядок испытаний, консервации, транспортирования и хранения изделий после ремонта
Документ, содержащий технические требования, требования к дефектации изделия, значения показателей и нормы, которым должно удовлетворять данное изделие после ремонта, требования к приемке, контрольным испытаниям, комплектации, упаковыванию, транспортированию и хранению изделия после ремонта, гарантийные обязательства
Общие технические условия на ремонт
Документ, содержащий общие технические требования к ремонту определенной группы однотипных изделий, требования к дефектации, значения показателей и нормы, которым должны удовлетворять изделия после ремонта
Чертежи (модели), спецификации, схемы, содержащие данные для подготовки ремонтного производства, ремонта и контроля изделия после ремонта. Эти документы, как правило, содержат только те изображения изделия, размеры, предельные отклонения размеров, СЧ изделия, части и элементы схемы и дополнительные данные, которые необходимы для проведения ремонта и контроля изделия при выполнении ремонта и после него
Документ, содержащий номенклатуру запасных частей изделия и их количество, необходимое для подготовки ремонтного производства нормируемого количества изделий, ремонта изделия и его контроля при выполнении ремонта и после него
Документ, содержащий номенклатуру материалов и их количество, необходимое для подготовки ремонтного производства нормируемого количества изделий, ремонта изделия и его контроля при выполнении ремонта и после него
Документ, содержащий номенклатуру, назначение, количество и места укладки запасных частей, инструментов, принадлежностей и материалов, необходимых для обеспечения ремонта
Техническая документация на средства оснащения ремонта
Документация, содержащая информацию для изготовления, испытания и приемки ремонтно-технологического и имитационно-стендового оснащения ремонта. В состав документации включают:
- рабочую конструкторскую документацию на изготовление, испытания и приемку (при необходимости);
- ТУ (при необходимости);
- эксплуатационные документы
Документ, устанавливающий комплект конструкторских документов, необходимый для проведения ремонта изделия, его контроля при ремонте и после него
[из 6.1.2 ГОСТ 2.602-2013]
Состав комплекта документов на программу (программное изделие)
Состав комплекта документов на программу (программное изделие) регламентирован ГОСТ 19.101-77.
Вид программного документа
Перечень предприятий, на которых хранят подлинники программных документов
Запись программы с необходимыми комментариями
Сведения о логической структуре и функционировании программы
Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний
Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Сведения для обеспечения функционирования и эксплуатации программы
[из 2.2 ГОСТ 19.101-77]
Вид эксплуатационного документа
Основные характеристики программы, комплектность и сведения об эксплуатации программы
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Сведения для эксплуатации программы
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
[из 2.3 ГОСТ 19.101-77]
Состав комплекта документов на автоматизированную систему
Состав комплекта документов на автоматизированную систему регламентирован ГОСТ 34.201-89.
Наименования конкретных документов, разрабатываемых при проектировании системы в целом или ее части, приведены в таблице 2.
Допускается включать в документ П3 или ПВ
Допускается включать в документ П9
При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1
При разработке на стадии ТП допускается включать в документ П2
В состав проекта не входят
В состав проекта не входят
Допускается включать в документ П2
Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
Допускается включать в документы П2 или П3
Для задачи допускается включать в документ 46 по ГОСТ 19.10
Допускается включать в документы П2, П3 или П4
Допускается включать в документ П9
На стадии ТП допускается включать в документы П4 или П5
Допускается выполнять в виде таблиц
*Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД
- В таблице приняты следующие обозначения:
- ЭП — эскизный проект;
- ТП — технический проект;
- РД — рабочая документация;
- ОР — общесистемные решения;
- ОО — решения по организационному обеспечению;
- ТО — решения по техническому обеспечению;
- ИО — решения по информационному обеспечению;
- ПО — решения по программному обеспечению;
- МО — решения по математическому обеспечению.
- Знак Х — обозначает принадлежность к проектно-сметной или эксплуатационной документации.
- Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.
[из 1.3.1 ГОСТ 34.201-89]
Состав комплекта документов при инициативной разработке
Состав комплекта документов при инициативной разработке (см. «Определение целей и задач документирования») может быть существенно сокращен по сравнению с изложенным в табл. 2 п. 1.3.1 ГОСТ 34.201-89. Потребуется минимальный комплект, необходимый и достаточный для автоматизированной системы:
- техническое задание по ГОСТ 34.602;
- пояснительная записка (П2 по ГОСТ 34.201);
- описание комплекса технических средств (П9 по ГОСТ 34.201);
- описание программного обеспечения (ПА по ГОСТ 34.201);
- описание информационного обеспечения (П5 по ГОСТ 34.201);
- описание организационной структуры (ПВ по ГОСТ 34.201).
Техническое задание потребуется руководству ради того, чтобы знать, чем занята проектная команда. Или она просто так что-то делает, радиолюбительством занимается. Пояснительная записка — для выяснения, насколько точно и обоснованно выполняются требования ТЗ. Описание комплекса технических средств (желательно с чертежом общего вида в виде панорамных фотографий и детальных снимков) — из тех соображений, что при очередной инвентаризации придется отчитываться, где, что, кому и сколько. А на детальных снимках видны шильдики с серийными номерами, позволяющие оперативно найти, в какой стойке расположено искомое и быстро отчитаться при инвентаризации, см. рисунки.
Описание программного и информационного обеспечения вряд ли представляет интерес для руководителя, а вот описание оргструктуры — весьма и весьма. Из него можно выяснить, кто из проектной команды чем занят, насколько он загружен, с кем «коммуникирует» и т.д., а не задавать вопросы из серии «А что ты сделал из того, что должен был сделать?». При разрастании штата подразделения держать в голове функции всех и каждого, лично ставить задачи, отслеживать исполнение и т.д. становится затруднительно, несмотря на обилие программных средств руководства проектом.
При разработке изделия для собственных нужд достаточно инструкции по эксплуатации по ГОСТ 2.102-68. Если «собственные нужды» выходят за рамки одного подразделения предприятия — изделие разрабатывается, допустим, для соседнего отдела, — то следует подстраховаться и разработать минимальный комплект документов:
- технические условия (ТУ по ГОСТ 2.102) — обязательно стребовать подпись с «заказчика»;
- пояснительную записку (ПЗ по ГОСТ 2.102);
- программу и методику испытаний (ПМ по ГОСТ 2.102) или, хотя бы, получить согласованный и утвержденный протокол испытаний;
- какой-либо эксплуатационный документ по ГОСТ 2.601.
В ряде случаев могут дополнительно потребоваться чертежи, спецификации и т.д. Многое зависит, в конечном счете, от личных взаимоотношений руководителей подразделений. Чем лучше взаимоотношения, тем меньше бумаги придется плодить
Состав комплекта документов при инициативной разработке для программы выбирается из идеологических соображений, приведенных выше, только согласно ГОСТ 19.ххх.
Состав комплекта документов при иных видах разработки
При разработках в интересах заказчика состав комплекта документов может приближаться к реграментируемым соответствующими стандартами 2, 19, 24-й систем и 34-го комплекса, как показано в таблицах выше. При разработке в интересах «народно-хозяйственного» пользователя чаще всего достаточно единственного документа — руководства пользователя, см. «Как писать руководство пользователя? Часть I».
Источник: tdocs.su
Разбор тестирования 1С:Профессионал и PMP
Если ведется разработка тиражного решения, то для него можно создавать файлы поставки и обновлений для клиентов. Для этого, в сохраненной и обновленной конфигурации, необходимо выбрать меню Конфигурация -> Поставка:
Утилита позволит сделать как полную поставку, так и файл обновления:
Также поддерживается возможность настройки поставки, то есть выбора, какие объекты клиент сможет редактировать, а также настройка видимости текстов модулей:
Вопрос 05.20 экзамена 1С:Профессионал по платформе. Что необходимо для создания файлов поставки в текущей ситуации?
- Сохранить конфигурацию и обновить конфигурацию базы данных, перейти к процессу создания поставки
- Сохранить конфигурацию, перейти к процессу создания поставки
- Закрыть конфигурацию, перейти к процессу создания поставки
- Можно сразу создать файлы
Правильный ответ первый — конфигурация не сохранена, об этом говорит значок *.
Вопрос 05.21 экзамена 1С:Профессионал по платформе. Окно создания файлов поставки и обновления…
- позволяет создать либо файл поставки, либо файл обновления
- позволяет создать сразу и файл поставки и файл обновления
- создает единый файл, который можно использовать как для обновления, так и для создания новой базы данных
Правильный ответ второй, см. скриншот выше.
- Добавить файлы поставки предыдущих версий
- Указать место создания файла. Добавить файлы обновлений предыдущих версий
- Указать место создания файла
- Верны все указанные ответы
- Верны ответы 1 и 3
- Верны ответы 2 и 3
Правильный ответ пятый. Нужно указать платформе на прошлую версию конфигурации, и решить куда положить обновления.
7 комментариев:
Вопрос 05.23
«при создании файла обновления».
Помогите, пожалуйста, разобраться, почему правильный ответ 5, а не 2? Ответить Удалить
потому что 1С так решила. Но думаю, у кого-нибудь найдется более логичный ответ, хотя и это не точно. Удалить
По-моему, все дело в очередности действий. Сначала выбираешь предыдущую версию, а потом уже выбираешь место сохранения файла обновления. Удалить
Правильный ответ 5ый потому, что указываются файлы ПОСТАВКИ (cf), а не файлы ОБНОВЛЕНИЙ (cfu) Удалить
Этот комментарий был удален автором. Ответить Удалить
На 04.07.22 Второй пункт вопроса звучит: «2.Добавить файлы обновлений предыдущих версий» и в тренажере он показывается как Правильный Ответить Удалить
вопрос 5.23 чуть-чуть изменился и теперь вариант 2 правильный, проверено в официальном тренажере 1с.
5.23 Какие действия необходимо выполнить при создании файла обновления
конфигурации?
1. Добавить файлы поставки предыдущих версий
2. Добавить файлы обновлений предыдущих версий
3. Указать место создания файла
4. Верны все указанные ответы
5. Верны ответы 1 и 3
6. Верны ответы 2 и 3
Ответить Удалить
Источник: about1cerp.blogspot.com