Виды тестовой документации
Создание тестовой документации является вторым этапом жизненного цикла ПО.
Тестовая документация включает в себя:
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен описывать следующее:
Критерии начала тестирования:
Критерии окончания тестирования — результаты тестирования удовлетворяют критериям качества продукта:
Преимущества тест плана:
Составляющей частью планирования тестирования (как отдельного документа или же процесса планирования в целом) является стратегия тестирования. Стратегия может быть:
Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования.
В стратегии тестирования описывают:
Стратегия может быть представлена как в виде традиционно расписанного документа, так и в более наглядном формате, например, используя таблицу:
В общем, план тестирования устанавливает цели процесса тестирования, он определяет, что будет проверяться, а стратегия тестирования описывает, как достичь целей, поставленных в плане тестирования.
Пользовательские истории
Пользовательские истории (User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.
Примеры:
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Структура юзер стори
Текст самой юзер стори должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится.
Правила на написание User Story
Actor
Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла — значит эта часть бесполезна.
Джеф Паттон предлагает следующее:
Действие
Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать» авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне «ЧТО?» делает, а не «КАК?». Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное «КАК» — решение.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите «чтобы …».
Уберите эту часть из истории. Если ничего не потеряли — значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки «чтобы». Для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Представим что вы создали историю — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение».
У меня Аcceptance Сriteria — это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ». То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Практические советы по написанию пользовательских историй
Пример юзер стори:
продолжение:
Тестирование документации
Документация– это еще одна составляющая программного продукта любой уважающей себя организации, занимающейся разработкой программного обеспечения. Но не все организации уделяют достаточное количество времени разработке стоящей документации. Очень часто нам приходится иметь дело с толковым программным продуктом и невзрачным, непонятным и беспомощным документным сопровождением.
Попробуем собрать воедино критерии тестирования, образующие квинтэссенцию качественной документации. Думаю, будет справедливым, если мы опустим такое всем понятное правило, как грамматика, так как не в ней одной таится успешный релиз.
В целом, документация создается для возможности грамотно и без паники найти выход или решение из любой возникшей проблемной ситуации человеку из самым низким знанием принципов разработки программного обеспечения. От этого принципа необходимо отталкиваться, продумывая содержание и структуру наших мануалов.
• Полнота и соответствие действительности. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении. И данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой.
• Навигация. И не просто навигация, а удобная навигация. У пользователя никогда не должно возникать проблем с поиском необходимой ему информации. Древовидная структура файлов, закладки и прочее должны быть на видном месте сразу, как пользователь открывает документ. Алфавитный указатель, поиск – должно присутствовать все, что поможет найти решение или описание проблемы.
• Из пункта выше вытекает структурированность документации. Все документы должны находится в полном порядке, по разделам. Также, текст должен быть с четкой структурой, чтобы можно было в любой момент вспомнить, где остановился или понять, в каком абзаце содержится именно та информация, которая нам необходима.
• Инструкции должны присутствовать везде. Даже при выполнении абсолютно одинаковых манипуляций с программой необходимо пошаговое описание действий во всех случаях. Это может быть как прямое повторение инструкций, так и ссылка на уже существующие.
• Термины и их значение. В любой документации может использоваться масса терминов, аббревиатур и сокращений. Каждый из них должен иметь свое значение и расшифровку.
• Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории.
• Если документация создана и для иностранных пользователей,то необходимо привлечение специалистов данного лингвистического сектора, вплоть до носителей языка.
Основные принципы тестирования требований
Существует еще много требований к составлению и тестированию документации. Сегодня мы рассмотрели основные положения. Но главное правило, которое поможет нам – это умение ставить себя на место пользователя, попавшего в определенную проблемную ситуацию.
Свойства качественных требований
В процессе тестирования требований проверяется их соответствие определённому набору свойств:
Техники тестирования требований
Тестирование документации и требований относится к разряду нефункционального тестирования (non-functional testing). Основные техники такого тестирования в контексте требований таковы:
Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки.
Для запоминания: аналог технического просмотра — это ситуация, когда некий договор визирует юридический отдел, бухгалтерия и т.д.
Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.).
Что такое тестовая документация и зачем она нужна?
Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.
Что такое тестовая документация?
Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д.
В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).
В чем важность тестовой документации?
Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.
Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.
И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA.
Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.
Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.
Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.
Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.
Какую тестовую документацию используют QA-команды?
Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.
План тестирования (test plan)
План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта.
В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.
Чеклист (checklist)
Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.
Выглядит чеклист как список функций с указанием статуса — результата проверки.
Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.
Тест-кейс (test case)
В тест-кейсе содержатся:
Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.
Сценарий использования (use case)
Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением.
Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя.
При создании юзкейсов тестировщики учитывают требования и бизнес-цели.
Баг-репорт
Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага.
Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.
Требования (requirements specification)
Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения.
В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.
Как все это работает?
Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей.
А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.
Чем крупнее проект, тем больше документации нужно.
Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.
Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет.
Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.
Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.
В заключение
Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.
Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Тестирование документации к программным продуктам
Перечень качеств, на которые можно ориентироваться при тестировании документации:
1. Работоспособность сценариев
Самое главное качество, которым должна обладать документация. Сценарии должны быть описаны точно, их выполнение должно приводить к достижению целей, для выполнения которых создан продукт. Если есть альтернативные сценарии, то они должны быть упомянуты.
2. Полнота описания
Очевидный пункт, подразумевающий, что каждый элемент функционала, будь то элемент интерфейса, такой, как кнопка, флажок, всплывающая подсказка и т.д. или же вводимая команда, или реакция на действия должны быть описаны. В том числе стоит учитывать, что пользователю может потребоваться отыскать в документации алгоритм действий при появлении определенного сообщения.
3. Уделение внимания обязательным пунктам
Не должно быть такого, что какие-либо обязательные и важные действия пользователя упоминаются вскользь, нужно уделить внимание описанию всех необходимых действий. Документация не должна напоминать кредитный договор, в котором все дополнительные условия описаны мелким шрифтом. Например, стоит явно прописать информацию о том, что если в конфигурационном файле будет запятая вместо точки то приложение не будет запускаться. Подобно тому, как в кредитном договоре стоит на видном месте прописать то, что процентная ставка станет 300% годовых вместо 20% в случае неуплаты платежа в срок.
4. Актуальность описания
Если тестируется документация к программному продукту, у которого много версий, то следует обратить внимание на актуальность описания. Может оказаться так, что в текущей версии функционал был изменен, но в документацию это не попало. Или же в последий момент было принято решение не включать фичу в текущий релиз, а она уже описана в документации. Также стоит обратить внимание на актуальность годов, контактных данных, системных требований, лицензионного соглашения, скриншотов.
5. Адаптированность к тому, что пользователь будет в спешке
Важное качество. Редко когда бывает так, что документацию читают неспешно на досуге. Чаще всего люди обращаются к документации, когда у них что-то не работает, велика вероятность того, что пользователь читает документацию в нерабочее время. Здесь можно порекомендовать минимизировать количество цепочек действий с зависимостями. Выполнение сценария не должно напоминать прохождение квеста. Было бы хорошо, чтобы все необходимые условия для выполнения сценария были описаны до сценария. Можно привести такую аналогию: Если требуется прибить полку к кирпичной стене, то помимо полки в обязательном порядке потребуется перфоратор, бур, дюбель-гвозди.
6. Адаптированность к тому, что пользователь будет раздражен
Эмоциональная реакция при взаимодействии с программными продуктами имеет очень большое сходство с реакцией при взаимодействии с другими людьми. В случае, если пользователь читает документацию из-за того, что у него возникли какие-либо неполадки, скорее всего он будет в раздраженном состоянии. Здесь можно рекомендовать делать атомарность предложений и абзацев. Например, вместо > лучше прописать >
7. Структурированность, адаптированность к быстрому поиску
Документация должна иметь четкую структуру и пользователь должен иметь возможность быстро найти в ней информацию по оглавлеию. Можно провести параллель с качеством фотоаппарата: простой фотоаппарат должен иметь такие конструктивные характеристики, чтоб можно было быстро задействовать его, не упустив момента. Если фотоаппарат будет долго доставаться из чехла и долго включаться, то в нужный момент может он может оказаться бесполезен. Применительно к документации и справке, если для поиска какой-то информации нужно много времени, то пользователь может бросить поиск т.к. у него не хватит терпения выполнять действия.
8. Наличие указания на необратимость действий
Если какие-либо действия пользователя необратимы, то стоит явно об этом указать. Например, при удалении чего-либо в программе, потом далеко не всегда можно это восстановить. Также стоит добавить информацию о том, как можно обратить те или иные действия. Например, мы хотим внести в программу множество данных, но не уверены в том, что они верные, стоит явно указать способ, каким образом можно будет потом обратить наши действия, например, восстановление настроек).
9. Подтверждение ожидаемого
После описания последовательности некоторых действий стоит указать ожидаемый результат. Подобно тому, как стоит попробовать суп после того, как туда добавили соль и специи.
10. Описание последствий отсутствия действий пользователя
Стоит добавить в документацию информацию о том, что будет, если пользователь не выполнит требуемые от него действия. Например, если пользователь не задаст ip-адрес сетевого интерфейса, то через этот интерфейс не получится отправлять пакеты.
11. Ясность изложения информации
Должна использоваться наиболее подходящая к тестируемым объектам терминология. Если используется специфический термин, то стоит его отдельно описать. Если возможно двоякое толкование термина, то следует уточнить какое именно используется.
12. Логика и согласованность
В сценариях должно указываться какие действия с какой целью делаются. Должен быть понятен смысл выполняемых действий.
13. Последовательность изложения
В некоторых сценариях важна последовательность выполнения действий. Например, при варке супа мы сначала наливаем воду, а затем добавляем другие ингредиенты, такие, как картофель. Если же сначала положить картофель, а воду залить намного позже, то вместо супа получится что-то несъедобное.
14. Орфография, синтаксис, пунктуация
Разумеется, текст должен быть описан грамотно. Орфографию можно проверить в MS Word или другими средствами. Для проверки синтаксиса и пунктуации необходимо вчитываться в текст, понимать его смысл, понимать значения каждого из используемых терминов.
15. Наличие описания настроек по умолчанию
Если есть какие-либо настройки, и в них есть значения по умолчанию, то было бы хорошо, чтоб это было описано. Пользователь захочет найти информацию о настройках по умолчанию, если он менял настройки, но не запоминал изменений, и после этого программа перестала корректно работать.
16. Адаптированность к аудитории
Если продукт рассчитан на простых пользователей, то в документации к нему действия пользователя должны описываться простыми понятными терминами. Если же продукт рассчитан на пользователей Apple либо на администраторов Linux, то стоит учитывать особенности этих пользователей. Руководства к серверному и управляющему ПО часто ориентированы на системных администраторов.
17. Атомарность сценариев
Больше применимо к справке, но зачастую пользователям нужна информация лишь об одном элементе функционала. И нет желания и возможностей изучать полностью документацию. Не стоит заставлять пользователя изучать весть продукт, если есть возможность этого не делать. Например, если нужно поменять шрифт в текстовом редакторе, не следует указывать в документации о том, что прежде чем это делать необходимо изучить историю текстовых редакторов, изучить перечень функций текстового редактора, изучить что такое шрифты и т.д.
18. Адаптированность к наименее возможной квалификации пользователей
Не всегда люди задаются вопросом о том, как функционирует программа, им важен результат. И стоит учитывать, что продукт могут использовать разные пользователи. Например, системному администратору, имеющую высокую квалификацию, может потребоваться показать на пальцах результаты работы с использованием продукта директору. А директор может заглянуть в документацию, если показанные результаты очень важны в рамках его деятельности. Тут стоит как можно меньше использовать сложные технические термины, для понимания которых придется открывать интернет. Домохозяйке не обязательно знать как функционирует микроволновая печь, но ей важно знать, что в ней можно варить и не следует помещать внутрь металлические предметы. Также домохозяйке, в отличие от ученого, следует знать, что не стоит помещать яйца в микроволновку.
Кому нужна качественная документация
Часто замечаю, что мало кто обращает на качество документации. Действительно, кому она приносит выгоду и какую? Подозреваю, что многие команды при разработке программных продуктов создают документацию лишь потому, что задачу по созданию документации поставили вышестоящие лица. И понижение приоритета обеспечения качества документации обусловлено тем, что нет возможности подсчитать в цифрах выгоду, которую это дает. К сожалению, я не могу представить такую статистику в цифрах.
Выгоду от наличия документации можно сравнить с выгодой создания дополнительной инфраструктуры при постройке жилья. С одной стороны, при продаже главную роль играет площадь жилья: цена назначается за квадрат. Но если присмотреться — цена в некоторых домах значительно превосходит цену в других. И обусловлено это в первую очередь окружающей инфраструктурой (стоянки, лифты, газоны, и т.д.).
Наличие качественной документации дает плюсы: пользователи не стремятся отказаться от продукта, снижается нагрузка на техподдержку, внутри команды разработки возникает меньше вопросов о том, как должен функционировать продукт, легче его продавать.
