Главная цель этой проблемно-постановочной статьи – обращение к теоретическим основам Тестирования ПО, т.е. чёткое построение оригинальных базовых понятий или определений и поиск смыслов. Основная проблема, с которой приходилось бороться при написании,- соскальзывание из изложения теоретических аспектов в плоскость практической методологии.
Определение 1. Программное обеспечение (ПО) – это комплекс аппаратных средств, системных служб и вспомогательных сервисов, составляющих сконфигурированную среду (инфраструктуру), с которой интегрируются прикладные программы, в совокупности реализующие целевые процессы, наделенные заданными характеристиками, правилами поведения, настроенными для решения конкретных задач в соответствующих режимах работы, включая взаимодействие с Пользователем.
Примечание_1. С конкретным ПО (созданным Разработчиком для Заказчика) неразрывно связаны: пакет рабочей документации и, возможно, ресурс, поддерживающий это ПО в работоспособном состоянии. В общей инфраструктуре можно выделить ландшафт, в котором это ПО разворачивается и функционирует.
Определение_2. Тестирование – это способ сбора измеряемых характеристик Объекта, включая информацию о его способностях изменять своё состояние в зависимости от начальных условий и воздействия.
Определение_3. Объект тестирования – это целое или некое подмножество его составляющих, вплоть до логически или физически изолированных примитивов (элементов декомпозиции, см. Примечание_2), которому сопоставлено заданное подмножество требований.
Определение_4. Требование – это часть или совокупность статических и динамических атрибутов и свойств, которые обобщены в критерии оценки способности Объекта выполнять определённое предназначение в соответствующих условиях эксплуатации.
Примечание_2. Архитектурно, ПО разделяется на функциональные модули, из которых складываются отдельные подсистемы, которые объединяются в системы и программные комплексы, физически (или виртуально) работающие на распределённом оборудовании. Обычно здесь имеет место декомпозиция, когда для достижения конкретной(ых) цели(ей) решается совокупность задач, результат каждой получается на основе конкретного алгоритма, в котором можно выделить ветви, для прохода по которым требуется выполнять команды, управляя потоком исполнения и инициируя исполнение операций, которые, соответственно доступу, способны обрабатывать/изменять сущности. К упомянутым целям добавим обеспечение гибкого, отказоустойчивого, тестопригодного построения с минимизацией изменений при смене/добавлении требований.
Определение_5. Тестопригодность — это наличие у Объекта (см. Примечание_3) таких важных свойств, как управляемость, наблюдаемость и покрываемость.
Определение_6. Управляемость – это свойство объекта, когда он, посредством воздействия через интерфейс входа, может быть переведен из заданного начального состояния в требуемое конечное состояние, определяемое посредством интерфейса выхода.
Определение_7. Наблюдаемость — это свойство Объекта, когда по полученному конечному состоянию на его выходе и известных поданных ранее на вход воздействий, можно определить его предшествующее состояние, т.е. можно судить о причинно-следственных связях происходящих событий между этими состояниями.
Определение_8. Покрываемость — это свойство Объекта быть проверенным конечным множеством Эквивалентных тестов.
Определение_9. Эквивалентный тест – это способ проверки Объекта, когда из множества всех входных воздействий для конкретного начального состояния Объекта можно выделить подмножество, при каждом входном воздействии из которого будет получено одно и то же конечное состояние. В этом подмножестве фиксируется единственный вариант определяющий одну показательную проверку.
Примечание_3. Объектом тестирования ПО, например, может быть документация с требованиями, текст с выводом конечных формул или алгоритмов прикладного решения, текст программного кода. Если Объектом тестирования ПО является рабочий процесс с контекстом его исполнения, тогда данный Объект должен быть тестопригодным.
Определение_10. Дефект (defect) — это факт отклонения конкретной характеристики/поведения разработанного ПО от предъявляемых требований, их описания в рабочей документации; объективная несовместимость решения с предметной областью; отклонение от действующих локальных Стандартов и Законов; несоответствие корпоративным требованиям разработки ПО; субъективные замечания, относящиеся к негативным прецедентам (см. Примечание_4).
Примечание_4. Практически невозможно подробно описать в рабочей документации всё, что должно и не должно делать ПО. Поэтому на разных стадиях жизненного цикла имеют место наблюдения/ситуации, которые непонятно как трактовать. Когда такое выявляется впервые – это Инцидент (incident), а после того, когда согласованно принимается решение, дефект это или нет, тогда это «нечто» становится Прецедентом (рrecedent) для идентификации повторных подобных случаев. Т.о. формируется практика прецедентов, закрывающая “дыры” документации.
Примечание_5. Фича (feature) — это выявленное недокументированное проявление в работе ПО, которое, в силу практики прецедентов, не является Дефектом. По своему характеру чаще является бесполезным, не раздражающим Пользователя артефактом, который не имеет смысла предлагать для использования.
Определение_11. Задача на тестирование ПО – это артефакт (элемент регламента), содержащий: цели тестирования; необходимые стадии решения и выделенные на них сроки и ресурсы; краткое описание тестового ландшафта и данных доступа к его компонентам (со ссылкой на Задачу по его подготовке для Администратора); описание Объекта тестирования с подлежащими проверке требованиями (со ссылками на соответствующие разделы рабочей документации и Задачи Разработчикам, выполнение которых будет проверяться); условий неудовлетворительного состояния Объекта тестирования, при которых решение задачи прерывается; требуемого формата для отчета о результатах проведённых работ, включая необходимые метрики и статистику, которые необходимо собрать/предоставить.
Определение_12. Тестирование ПО – это процесс решения поставленной Задачи на тестирование ПО. Его начало – это момент получения в работу задачи на тестирование. Окончание тестирования определено сроками из поставленной задачи (или по условиям). Этот процесс состоит из стадий: обследования (см. Примечание_6); планирования (см. Примечание_7); испытаний (включая регистрацию Дефектов, Проблем, предложений Усовершенствования, см. Определение_21..23); оформления результатов (составление отчета и выделение подпокрытия для регрессии, и для приёмо-сдаточных испытаний в будущем).
Примечание_6. Обследование в тестировании – это стадия экспертизы задания и углубленного погружения в его контекст, в результате чего формируются ранжированный по важности, рискам и взаимозависимости полный спектр того, что надо проверить, понимание о методике (что/где/когда/каким образом делать и наблюдать), представление о подходящем инструментарии, с помощью которого можно испытывать или измерять конкретные характеристики или собирать статистику. Замечание: Важность и Риски (см. Определение_19, 20) — это атрибуты, оценки которых должны быть близки к объективным, они согласовываются с компетентными специалистами (или ими предоставляются).
Примечание_7. Планирование в тестировании – это стадия выработки стратегии и тактики проведения испытаний. В результате формируются методики и технологии проверок, а на их основе – согласованная программа с указанием ролей и действий участников испытаний (или подключаемых средств автоматизации) на соответствующих событийно-временных отрезках подготовки/проведения теста и фиксации его результатов. Обеспечивается оптимальное покрытие проверками Объекта тестирования, которое необходимо осуществить имеющимися ресурсами в заданные сроки, с минимизацией неконтролируемых факторов.
Примечание_8. Параллельно стадиям обследования, планирования, а также с целью их замены, может иметь место исследовательское тестирование, выполняемое специалистом с высоким уровнем компетенции исследователя, со способностью в короткие сроки построить аналитическую базу, не ограничиваясь рабочей документацией; углубить знания о связанных с ПО технологиях и домене; создающим или владеющим вспомогательным инструментарием; на одном языке взаимодействующим с Бизнесом, Разработчиком, Системным Администратором.
Определение_13. Исследовательское тестирование — это творческий процесс, заключающийся в генерации креативных или наиболее существенных, с точки зрения решаемой задачи, вопросов о причинно-следственных связях в работе ПО и в воплощении поиска ответов на них в экспериментах, направленных, с одной стороны, на выявление неочевидных логических тупиков и условий, при которых возникают проблемы функционирования ПО или нарушается безопасность, с другой стороны, для накопления и синтеза знаний об Объекте тестирования и совершенствования применяемых технологий, позволяющих перейти к его более глубокому исследованию.
Примечание_9. Дефекты являются важной характеристикой для анализа как состояния ПО, так и уровня развития, на котором производились работы по его созданию. Явный дефект тот, который зарегистрирован, но не устранен (иначе Исправленный). Заметим, он может оставаться никогда не устранённым или быть в принципе не устраняемым. Скрытый дефект – это тот, который не выявлен при испытаниях, (возможно, из-за ограничений на сроки и ресурсы или недостаточного уровня развития, на котором производилось тестирование) и может проявиться в процессе непосредственной эксплуатации.
Определение_14. Ошибка (error) – неправильность мыслей, действий, распоряжений конкретного специалиста в рамках постановки/выполнения задачи, результат работы которого не позволит корректно решить эту задачу (достигнуть цели).
Примечание_10. Ошибка может быть свойственна не только Исполнителю ПО, но и Заказчику или Пользователю.
Определение_15. Баг (bug) – это факт непреднамеренного некорректно выполненного кодирования программы, заключенный в её тексте, вызывающий (после сборки и развертывания программы в рабочем ландшафте) отклонение от требований к работе ПО.
Примечание_11. Парадоксальная и очень нежелательная ситуация, когда два Бага в программе могут друг друга компенсировать, не выявляясь.
Примечание_12. Тестировщик по методике «Белый ящик» находит Баги, а тестируя «Чёрным ящиком», обнаруживает Дефекты.
Определение_16. Проблема (problem) — ситуация, когда на текущем этапе у специалиста нет возможности эффективно или в принципе выполнить свою часть работы из-за того, что предыдущий (или ранее в жизненном цикле ПО по технологической цепочке) исполнитель допустил Ошибку.
Примечание_13. Баг может быть заимствован из сторонних вспомогательных фреймворков или являться следствием Ошибки, допущенной непосредственно Разработчиком, или следствием Проблем, созданных ранее другими специалистами.
Определение_17. Авария (accident) — это факт выхода из строя аппаратных средств или серьёзных нарушений в работе системного или прикладного ПО (например, завершился срок действия лицензии или сертификата) на Серверной стороне или сети/связи или на стороне Пользователя, т.е. ситуация при которой ПО объективно не работоспособно.
Определение_18. Сбой — это факт глобальной (failure – на Серверной стороне) или локальной (fault – у отдельного Пользователя) временной нехватки мощностей/ресурсов, т.е. ситуация при которой штатный режим работы ПО прерывается, затем происходит его самовосстановление, вероятно, с привлечением ресурса поддержки.
Примечание_14. В случае Аварии или глобального Сбоя, действительно, ПО может быть объективно не работоспособно. Но! Принцип суперпозиции позволяет выделять модули, которые можно резервировать или применять специальные технологии отказоустойчивости.
Примечание_15. Различные предпосылки порождают Ошибки, из-за них возникают Проблемы и Баги, которые вместе с дополнительными (не)предсказуемыми факторами являются причинами Дефектов (явных и неявных), определяющих состояние ПО, анализ которых позволяет спрогнозировать, где и насколько ПО ещё недостаточно проработано и оттестировано. Исходя из утверждения, что идеального ПО не существует, очевидна опасность — предоставить его в эксплуатацию в таком состоянии, что вместо достижения заданных Заказчиком целей оно нанесёт ему (Пользователям) ущерб. Оценку состояния ПО можно сформировать на основе анализа отчетов соответствующих задач на тестирование. Это выявляет важность того, насколько полно и четко требуется ставить/формулировать эти задачи и обеспечивать их корректное исполнение, готовя необходимую информационную базу для выбранной методики Теории принятия решений в условиях риска и неопределенности.
Определение_19. Риск (risk) – это количественная оценка последствий выбора альтернативы решения в условиях неопределённости.
Определение_20. Важность (importance) сущности – это количественная оценка её значимости или степени зависимости от неё других сущностей в контексте специфики её реализации или обстоятельств эксплуатации.
Определение_21. Описание Дефекта (bug-report) — это зарегистрированное сообщение, основным содержанием которого является информация о сути наблюдаемого у Объекта тестирования отклонения от эталона (ожидаемой реализации) и чёткое описание условий и действий для его повторного наблюдения, по возможности, дополненное локализацией Бага в программе.
Определение_22. Описание Проблемы (issue) – это зарегистрированное сообщение для эскалации выявленных Инцидентов и Ошибок, препятствующих проведению эффективных работ, связанных с разработкой и тестированием ПО, а также предложений по их решению.
Определение_23. Описание Усовершенствования (enhancement) — это зарегистрированное сообщение, содержащее предложение о необходимости изменения/дополнения ПО (и соответственно требования в рабочей документации) для его удобной и эффективной эксплуатации/администрирования.
Примечание_16. Детали формата и содержания для сущностей из Определений_21..23 регламентируется отдельно.
Признаюсь, я не люблю спорить, но, если по существу, то готов. Очевидно, здесь я заострил внимание только на тех понятиях, на которые имею особый взгляд или часто замечаю их некорректное употребление. Буду особенно благодарен читателям, которым статья не понравится, за их мнение и аргументацию. Повторюсь, в этой статье я попытался найти точки роста научности в области Тестирования ПО, его философию и эстетику.
Автор: testopatolog
