[Перевод] Лидерство в тестировании — документация
Добро пожаловать в серию статей «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы — особенно в гибких командах — преуспеть в своих ролях руководителя тестирования и менеджера по управлению.
Независимо от того, какой это проект, организация или подход, всегда найдется место для документации. Хорошая документация — это находка, предоставляющая полезную информацию о подходах, масштабах, планах, конструкциях и результатах анализа, разработки и тестирования.
В этой статье я расскажу о:
Ценности документации
Опасности шаблонов и вырезания/вставки готовых шаблонов
Типы тестовой документации
Консультации по проектной документации
Ценность документации
В структурированных проектах документы обычно считаются самостоятельными результатами. В Agile или непрерывных методологиях документация может создаваться как побочный продукт, имеющий большую или меньшую ценность.
Написание документов может быть основным занятием профессиональных технических писателей, но для большинства практиков это рутинная работа, какой бы полезной она ни была. В то время как написание документов может быть скучным для некоторых людей, реальная проблема с документацией заключается в том, что во многих случаях большая часть документации — это просто пустая трата времени. Она малоценна, устарела, неточна — или все вместе взятое.
У каждого менеджера по тестированию есть написанные стратегии тестирования, которые люди не читали и на которые не купились. Тестировщики пишут множество планов тестирования, сценариев и отчетов, и единственный контент, представляющий ценность для стейкхолдеров, — это одностраничные самари в начале или в конце.
У нас есть все письменные документы, которые, как мы знаем, не имеют большой ценности и которые никто не будет читать.
Это связано с распространенными проблемами с документацией, с которыми мы сталкиваемся как в больших, так и в малых проектах. Для каждого документа, который мы пишем, есть несколько вопросов, на которые нам необходимо ответить:
Какой тип документа? Политика или стратегия, подход или план, замысел или реализация, или результат и интерпретация?
Какова цель этого документа?
Какой контент требуется для достижения этой цели?
Какие источники знаний требуются для создания контента?
Если документ должен меняться с течением времени, как он будет поддерживаться?
Какой уровень детализации требуется?
Как руководителю тестирования или команде, вам нужно будет выяснить, какие типы и форматы документации являются подходящими и, если они должны быть физическими, или так называемыми живыми документами, как они поддерживаются.
Опасности шаблонов и вырезания/вставки
Если в вашем проекте определено, что требуется определенный документ, скажем, план тестирования системы или реестр рисков, возникает соблазн найти готовый шаблон для этих (и многих других типов документов) в Интернете.
Некоторые шаблоны могут претендовать на соответствие какому-либо стандарту или соглашению и на то, что они были загружены и использованы тысячи раз. Иногда может показаться, что шаблон в точности соответствует вашей цели. Но, как мы увидим, даже если оглавление выглядит исчерпывающим, это может привести к неприятностям.
Также может быть так, что вы или другие сотрудники вашей компании подготовили аналогичный документ для предыдущих проектов. У вас может возникнуть соблазн скопировать и переименовать этот документ, изменить ссылки на старый проект и отредактировать содержимое в соответствии с требованиями.
Предупреждение: По моему опыту независимого рецензента, это очень распространенное явление и часто является реальной проблемой.
Во-первых, обычно совершенно очевидно, что было сделано копирование / редактирование. Язык, используемый в тексте, часто кажется оторванным от проекта, и повсюду есть пробелы и лишний текст. Почему это происходит?
Использование предварительно сформированного шаблона или существующего документа в качестве источника сопряжено с рядом рисков:
Он выглядит всеобъемлющим, но может включать в себя темы, которые являются неуместными, и исключать другие, которые являются существенными.
В нем приведены заголовки для документа, но абсолютно нет указаний относительно того, какое содержание подходит для каждого заголовка.
Он может содержать текст, который выглядит пригодным для повторного использования и скопирован без изменений из предыдущего несвязанного проекта, но этот текст может создать неверное впечатление, быть неточным или неполным.
Использование шаблонов для получения заголовков и базового форматирования макета может быть полезным, но основная проблема с шаблонами заключается в следующем:
Использование шаблона может сэкономить некоторое время; риск в том, что вы недостаточно продумаете содержание.
Соблазн использовать шаблоны состоит в том, чтобы чрезмерно доверять им, а затем писать образец для различных разделов. В конце концов, вы можете подумать, что документ заполняется «галочкой» и его все равно никто не прочтет. Риск использования шаблонов заключается в том, что вы перестаете думать и пишете документ, который не имеет большой ценности.
Типы тестовой документации
В этом разделе мы рассмотрим различные формы тестовой документации и обсудим некоторые соображения в структурированных или гибких / непрерывных проектах по сравнению с традиционным waterfall.
Основной набор тестовых документов, как правило, делится на следующие категории:
Политика и стратегия (иногда известные как Мастер тест план тестирования)
Определение теста (оно же спецификация или планы тестирования, что приводит к путанице)
Тест дизайны
Тест кейсы
Процедуры тестирования или сценарии
Выполнение теста
Расписание
Лог
Отчёт об тестировании
Приведенный выше диапазон типов документов охватывает определение процесса тестирования, ключевые действия по определению и выполнению, а также отчетность.
Существует несколько других документов, связанных с тестированием, которые в более бюрократической среде включали бы определения тестовой среды и процессы управления, процедуры приемки, процессы управления инцидентами и так далее (мы рассмотрим управление инцидентами в следующей статье).
Другим очевидным упущением из вышеприведенного был бы общий план или расписание тестовых мероприятий. Расписание на самом деле не является тестовым документом, это часть общего плана структурированного проекта (мы также рассмотрим планирование расписания в следующей статье, так что следите за обновлениями!).
Политика, стратегия, Мастер тест план
Цель | Политика обычно распространяется на организацию и включает в себя подмножество тем, охватывающих все проекты. Стратегия обычно охватывает один проект (или приложение) В целом, стратегия предусматривает принятие решений по логистическим вопросам подхода, передачи полномочий, ответственности, окружающей среды и т. д. Некоторые из этих решений могут быть приняты заранее и задокументированы в стратегии Некоторые решения не могут быть приняты сейчас, но стратегия может документировать процесс, метод или информацию, которые позволят принимать решения (в рамках проекта). Для неопределенных ситуаций или незапланированных событий, когда необходимо принимать решения, в стратегии будут задокументированы общие принципы (или процесс), которым следует следовать. |
Содержание | Стейкхолдеры, цели, ключевые риски, вызывающие озабоченность Принципы тестирования/подход, которые должны быть приняты, например, подход к тестированию, основанный на оценке риска Процесс тестирования (этапы тестирования): цели и сфера охвата критерии приемлемости методы, техники конечные результаты (документы) ответственность нефункциональные/технические тестовые мероприятия политика управления поставщиками (тестирование) процесс управления инцидентами источники тестовых данных тестовые среды инструменты/стратегия автоматизации форматы/шаблоны документации |
Источники | Стейкхолдеры, пользователи, бизнес-аналитики, разработчики, операции |
Поддержка | Обычно это одноразовый документ, определенный для проекта или программы |
Agile/непрерывные методологии Например, стратегия тестирования для agile роектов с использованием Scrum, скорее всего, будет довольно краткой и займет всего несколько страниц (если они вообще документированы). Процесс тестирования может не состоять из этапов, но, вероятно, существует определение тестирования на разных уровнях. Например: Тестирование в спринте или итерации Тестирование для релиза Тестирование системной интеграции (с другими системами или интерфейсами) Пользовательское тестирование (в рамках спринта и/или acceptance тестирование на уровне релиза). То, как инструменты используются при тестировании разработчиками (и, например, с использованием BDD или TDD), скорее всего, останется недокументированным, но ожидается, что команды разработчиков разработают подход и будут взаимодействовать с другими членами команды по мере фиксации нового кода. Роль тестировщика может заключаться в интерактивном тестировании фич по мере их выпуска разработчиками или в том, чтобы выступать в качестве тренера по тестированию для остальной команды. Подобно использованию инструментов и/или TDD, способ работы будет эволюционировать с течением времени и, возможно, никогда не будет официально задокументирован. |
Определение теста (дизайн, случаи, процедуры)
Цель | Продемонстрировать поток или прослеживаемость между источниками знаний и тестами, которые необходимо выполнить Для документирования охвата (по нескольким моделям) аспектов требований, системных функций или поведения пользователя Чтобы дать заинтересованным сторонам возможность проанализировать область применения, подход, покрытие и выбор, сделанные при создании тестов для применения Предоставлять инструкции по проведению тестов с некоторым согласованным уровнем детализации. |
Содержание | Объем тестирования — как на высоком уровне, например фичи, так и на более низком уровне, например, модели поведения Покрытие тестов в сравнении с элементами в области применения (например, матрица охвата требований или другая тестовая модель) Тест-кейсы, определяющие фичи, предварительные условия, входные данные и последующие условия (включая ожидаемые результаты) Тестовые процедуры, повторно используемые для выполнения выбранных тестовых примеров. |
Источники | Стейкхолдеры, пользователи, требования, проекты и спецификации |
Поддержка | В принципе, при фиксированных требованиях должна существовать одна согласованная версия этих документов Там, где происходят изменения требований или области применения, тестировщикам необходимо будет скорректировать документы, поддерживать отслеживаемые аспекты документации и предоставлять журнал управления конфигурацией или изменений. |
Agile/непрерывные рассуждения Область определения тестов — это то, где подход к agile наиболее заметно отличается от структурированных проектов. Потенциально тестировщики, которые фокусируются на фичах по мере их доставки, могут вообще не создавать никакой документации. Это уместно, например, если существует общесистемная политика или подход для тестирования функций. Более вероятно, что будет краткий регламент тестирования каждой фичи в ходе ознакомительной тестовой сессии. Раздел — это как план на короткий период исследования. Подход, как правило, определяет: Область тестового сеанса — фича (и), которую (которые) необходимо охватить, и/или некоторые заданные функциональные возможности или поведение системы Цель занятия — изучить определенные аспекты поведения, сосредоточиться на некотором риске или способе сбоя, применить некоторые выбранные сценарии Продолжительность сеанса обычно составляет 45–120 минут. Сессия обязательно ограничена по объему, но тестировщики могут свободно исследовать ее вне рамок тестирования, если они считают это ценным Подход может быть направлен на то, чтобы сосредоточиться на исследовании — узнать, что делает фича, определить конкретные модели поведения, которые стоит протестировать, оценить, какой объем тестирования / сколько сеансов требуется для тестирования большой или сложной фичи, понять, какие тестовые данные могут потребоваться для ее тестирования и так далее Подход может быть конкретно посвящен тестированию какой-либо фичи, но может выделять некоторые области, которые требуют большего внимания, чем другие. Инструменты BDD и стори в выбранном формате, например стори и сценарии в формате Cucumber или Gherkin, могут обеспечить трассируемость и содержание, которые обеспечивают тестовые проекты и процедуры. Каждый сценарий с предложениями «дано/когда/затем» определяет предварительные условия, входные данные и последующие условия. Они ссылаются на одну функцию, поэтому они предоставляют минимальный тест-кейс / процедуру и, по крайней мере, трассируются до функций. Тесты, которые были написаны по сценарию для запуска с помощью инструментов, могут содержать промежуточную документацию, а могут и не содержать ее. Команды больше полагаются на наблюдение за автоматизированными тестами и таблицами тестовых данных, используемых автоматизированными сценариями, чем на документированные проекты тестов. |
Выполнение теста (расписание, логирование)
Цель | Уточнить порядок выполнения тестов Записать статус тестов — запущен/не запущен и статус Предоставить результаты выполнения теста для отчетности |
Содержание | Идентификатор теста, тестировщик, дата/время запуска, статус Для тестов, которые, по-видимому, демонстрируют аномальное поведение (необязательно): Подробные сведения о тесте по мере выполнения, где детали отличаются от сценария Фактические \ ожидаемые результаты Другие наблюдения, интерпретация Статус тестирования (дефект, ошибка настройки или окружающей среды и т.д.т. д.) Идентификатор наблюдения или отчета о дефекте (при необходимости) |
Источники | Перечень тестовых примеров/процедур, тестировщики |
Поддержка | График будет изменяться в соответствии с объемом тестирования, а процедуры будут изменены, удалены или добавлены в план. Тесты, скорее всего, будут выполняться несколько раз либо в качестве повторных тестов, либо в качестве регрессионных тестов. Журнал должен содержать полную историю всех тестов в области видимости. |
Agile/непрерывные рассуждения Если agile/непрерывные проекты не привязываются к документам с определениями тестирования, они в некоторой степени компенсируют это, поощряя тестировщиков лучше вести журналы выполнения тестов. Там, где тестирование проводится в сеансах в соответствии с подходом по тестированию, ожидается, что тестировщик будет тщательно записывать выполняемые им тесты. Существует несколько специализированных инструментов для ведения журнала тестов, которые представляют собой нечто большее, чем записные книжки, поэтому многие тестировщики используют простые текстовые редакторы, блокноты для заметок или записные книжки на бумажном носителе. Журналы, как правило, используются для записи всех значимых действий и наблюдений в сеансах во время их выполнения. Типичный журнал ознакомительного тестирования должен содержать такие аспекты, как: Структура исследованных объектов (карта территории) Замечания, вопросы, касающиеся особенностей, рассмотренных на сессии Модели, списки, таблицы тестовых заданий и идей для тестирования Выполняются тесты, снятые достаточно подробно, чтобы их можно было воспроизвести Обнаружены аномалии — сбои, сомнительное поведение, медленные ответы, плохой пользовательский интерфейс и так далее Время, затраченное на исследование, настройку теста, тестирование, расследование, регистрацию ошибок, повторное тестирование, регрессионное тестирование, непроизводительное время Дата/время начала Там, где тестировщики регистрируют свою сессионную активность с помощью заметок или других инструментов, они используют некоторую разметку или другой язык, специфичный для предметной области, для структурирования своих заметок. Они могут быть проанализированы с помощью простых внутренних инструментов для получения кратких сведений о действиях для использования в отчете об испытаниях. Тесты, выполняемые инструментами (как проприетарными, так и с открытым исходным кодом), автоматически ведут журналы. Обычно эти журналы доступны для запроса с помощью инструмента или пользовательских процедур. |
Отчет о тестировании
Цель | Для сообщения результатов этапа тестирования, выбранных тестов или тестовой сессии Может также применяться к техническим требованиям или нефункциональным тестовым мероприятиям, и в этом случае содержание будет отличаться в соответствии с целью тестирования Частично информировать стейкхолдеров, позволяя им принять решение о принятии или выпуске системы или подсистемы. |
Содержание | Время начала/окончания тестирования и его продолжительность Тестовая среда Тестируемая версия (и) программного обеспечения и системы Цели и объем тестирования (из стратегии тестирования, определения теста) Краткое изложение результатов Фичи, которые считаются работающими в соответствии с требованиями Риски, которые считаются устраненными Невыполненные тесты значимости (провалены или заблокированы) Фичи частично и не протестированы Риски устранены частично или не устранены вовсе. Подробная информация о результатах тестирования с выводом из журналов тестирования и т. д. Статус обходного пути для нерешенных аномалий Тестовые анализы Ход тестирования и его статус с течением времени Статистика инцидентов |
Источники | Стратегия тестирования, определения тестов, журнал тестирования, отчеты об инцидентах Большая часть содержимого отчета о тестировании будет состоять из инструментов, используемых для записи определений теста, журнала тестирования и журнала инцидентов или дефектов. |
Поддержка | Это моментальный снимок, сделанный во время фазы выполнения теста, и он не поддерживается. |
Agile/непрерывные рассуждения Цель отчета о тестировании в гибком проекте может охватывать одну итерацию или спринт, тестирование для выпуска или этап тестирования более высокого уровня, такой как интеграция или общая приемка системы. Как бы то ни было, цель остается неизменной. Большая часть содержимого отчета о тестировании будет взята из инструментов или заметок тестировщиков. Краткое изложение результатов составляется руководителем тестирования или тестировщиком для этапа тестирования меньшего масштаба. Как обычно, отчет, вероятно, будет менее формальным, и в нем, вероятно, будет меньше необработанных данных, которые могли бы лечь в основу сложного анализа. Конечно, во время итерации (ий) прогресс в итерации с точки зрения предоставленных функций или историй, протестированных и одобренных пользователями, может быть зафиксирован в инструменте или на общедоступной доске Kanban. Таким образом, стейкхолдеры постоянно информируются о ходе выполнения на протяжении всей итерации, и отпадает необходимость в официальном отчете по окончании периода тестирования. Видимость прогресса — ключевая проблема для гибких команд. Например, при регулярных, возможно, ежедневных встречах за Scrum-доской члены команды делятся своим пониманием прогресса, задают вопросы друг другу и постоянно согласовывают позицию (и следующие шаги). Таким образом, формальный отчет об испытаниях может никогда не потребоваться, поскольку команда всегда информирована и находится в курсе последних событий. Если тестировщики ведут письменные записи о своих действиях в сеансе, то нет доступных для анализа данных для представления автоматических отчетов, поэтому отчеты о сеансе и ходе выполнения могут быть представлены общедоступным визуальным способом. Это требует высокой степени дисциплины и хороших коммуникативных навыков со стороны тестировщиков. Ведущий тестирование или менеджер должен будет предоставить заинтересованным сторонам соответствующий информативный отчет, основанный на устных сообщениях. |
Несколько советов
Тема документации в проектах является деликатной как для тестировщиков, так и для других членов проектной команды.
Большинство людей рассматривают написание документации как рутинную работу.
Вот некоторые вещи, которые следует иметь в виду при разработке вашей документации:
Документация должна иметь четко определенную цель и аудиторию. Если вашей аудитории не нужна документация, они не будут ее читать. Если это не соответствует их собственным целям, они не купятся на это.
Как правило, лучше записывать какое-либо действие до или по мере его выполнения. Например, TDD фиксирует тесты перед написанием кода. Журналы тестового сеанса должны записываться во время сеанса, а не записываться после него.
Необходимые данные для регистрации того или иного аспекта тестирования могут быть минимальными. Например, тест, записанный в записную книжку, может быть достаточным для тестировщика, но его нелегко проанализировать. Возможно, простой текстовый журнал (лог) с некоторой разметкой будет проще использовать, но его также можно было бы проанализировать с помощью кастомных тулов.
Процедуры тестирования могут вообще не понадобиться, если тестировщики хорошо знают тестируемую систему. Возможно, необходима только тестовая цель или подход. Подготовленные тестовые примеры могут быть минимально задокументированы в электронной таблице.
Заключение
Необходимость — мать документации
Если вы готовите исчерпывающую документацию для своих заинтересованных сторон, а они ее не читают, значит они не видят в ней ценности.
Лучше предоставить заинтересованной стороне чистый лист бумаги и совместно добавить темы, которые они должны увидеть в документе, и работать исходя из этого. Возможно, они просят много контента, но то, что им на самом деле нужно, довольно просто. Продолжайте спрашивать: «Зачем им это нужно?».
Создавайте свою документацию целенаправленно; не просто предоставляйте контент, который, по вашему мнению, может быть полезен другим, потому что у вас могут быть данные.
Спасибо за чтение, присоединяйтесь к нам в следующий раз, когда мы засучим рукава и начнем планировать тестирование.
