в тех комбинациях (ситуациях или окружении), которые мы использовали. Но это не дает 100 % уверенности в том, что при использовании других комбинаций (ситуаций или окружений) тоже не будет дефектов.

— Раннее тестирование. Чем раньше начнется тестирование, тем быстрее получится выявить дефекты, а значит, снизятся затраты на разработку в целом. Раннее тестирование на первый взгляд требует больше ресурсов: обычно проверки проводят на последних этапах разработки, а тут к ним добавляются более ранние этапы. Однако следование этому принципу приводит к меньшему расходованию ресурсов в рамках всего проекта или команды.

— Тестирование зависит от контекста. Проверка функциональности сильно зависит от вашего программного обеспечения. Web и Mobile приложения имеют свои особенности в тестировании, блокчейн и ритейл как области бизнеса — свои. Эти особенности обязательно должны учитываться на всех этапах разработки для более высокого качества тестирования.

— Скопление дефектов. Когда дефекты находятся близко по функционалу или в одном месте, это может свидетельствовать о более сложной проблеме в глубине программного обеспечения. А значит, надо уделить больше внимания проблемной части приложения. Также это может свидетельствовать о проблемах в процессах или коммуникациях между участниками разработки.

— Децентрализация ответственности. QA инженеры несут основную часть ответственности за качество, но на него также влияет работа аналитиков, разработчиков, менеджеров и всех остальных участников процесса. А значит, для эффективной работы надо учитывать реальное распределение ответственности.

В этом списке нет «Парадокса пестицида», который ввели очень много лет назад, и звучит он примерно так: «Если повторять одни и те же тестовые сценарии снова и снова, то со временем они перестанут выявлять новые ошибки».

Описанные принципы основаны на статистике и истинах, которые мы не можем поменять. В то же время «Парадокс пестицида» на практике очень избирателен. Какие — то старые тестовые сценарии слабо подвержены этой проблеме, какие — то явно больше. В одних старых проектах с этим часто сталкиваются, в других это большая редкость. Причина такой нестабильности в подмене причинно — следственных связей.

Не редко на проектах возникает нехватка ресурсов: их недостаточно, чтобы нанять опытного инженера или выделить существенное количество времени для полноценного и качественного анализа функционала с последующим написанием тестовых сценариев. Это приводит к тому, что часть проверок забывают написать, либо тестовые сценарии становятся слишком абстрактными.

Набор тестовых сценариев, соответствующий первой цели тестирования, учитывающий его первый принцип, идеально и полностью (но не избыточно) выполняющий проверки некоего алгоритма, никогда или почти никогда не столкнется с проблемой, называемой «Парадокс пестицида». Первопричинная проблема заключается не в том, что тестовые сценарии устаревают, а в том, что их качество изначально находится на недостаточном уровне и часть функционала всегда остаётся без тестирования.

«Парадокса пестицида» изначально можно избежать, а его появление означает неполное соблюдение третьей цели тестирования. При написании недостаточных или абстрактных проверок не учитывают вполне вероятный риск того, что рано или поздно в части функционала, которая не тестируется или слабо тестируется, начнутся пропуски ошибок.

4.4. Качество программного обеспечения

Качество программного обеспечения — это совокупный набор параметров, показывающий насколько все наше программное обеспечение соответствует определенным критериям.

Важно понимать, что перечень критериев может сильно отличаться для разных проектов. К примеру, не всем необходимо заботиться о соблюдении законов в области игорного бизнеса, а только тем, кто непосредственно с этим работает. Банкам нужно максимально заботиться о безопасности данных, в то время как сайту — визитке это необходимо на минимальном уровне.

Основные критерии качества:

— Функциональность — программное обеспечение должно выполнять функции, для которых оно было создано.

— Безопасность — программное обеспечение должно предоставлять необходимый уровень безопасности.

— Соответствие стандартам и законодательству — программное обеспечение должно соответствовать законодательным нормам, стандартам и выполнять их требования.

— Надежность — программное обеспечение должно стабильно работать при различных сбоях и отказах.

— Производительность — программное обеспечение должно иметь хорошую производительность при разной нагрузке.

— Удобство использования — программное обеспечение должно быть максимально удобным и эффективным для пользователя.

— Поддерживаемость — программное обеспечение должно быть легким в поддержке и усовершенствованиях.

На каждом проекте у каждого критерия будет своя метрика того, как эти показатели высчитываются и какие считаются приемлемыми, а какие нет. Основные критерии направлены на всестороннюю заботу о программном обеспечении. Однако можно выделить дополнительные критерии качества, которые не относятся к программному продукту напрямую, но также сильно влияют на него:

— Эффективная документация и обучение — документация проекта и его процессов, а также процесс обучения должны быть актуальными и эффективными. Качество документации и обучения сильно влияет на создаваемое программное обеспечение, а также на скорость разработки и правильность понимания работы программного продукта.

— Эффективное управление качеством — недостаточно просто установить критерии качества где бы то ни было и им следовать, необходимо регулярно проводить их аудит, планирование пересмотра, эффективное вовлечение необходимых сотрудников и т. д.

4.5. Требования

Требование — это конкретное описание того, что должно выполнять программное обеспечение.

Например:

— Площадь квадрата вычислять по формуле S=a2, где S — площадь, а — длина стороны.

— При открытии Door_127 запускается NPC типа Guard_5, находящийся в Room_34 и запускается скрипт NPC Atack_360.

— Данные хранить в SQL таблице Users с полями: ID (int, unique, not null), login (varchar, unique, not null), password (varchar, not null).

Требования являются первым этапом на пути разработки программного обеспечения. Они — главный источник информации о том, как должен работать конечный продукт. Поэтому очень важно, чтобы требования были хорошими, то есть качественными. Сами по себе требования являются результатом работы аналитиков, которые, как и все люди, могут совершать ошибки. Поэтому один из этапов тестирования — это тестирование требований. На практике его могут проводить как QA инженеры, так и сами аналитики. Хотя хорошей практикой будет, если в тестировании требований участвуют все заинтересованные члены команды, кем бы они ни были. Также замечу, что какая-либо проверка требований любого уровня не обязательно проводится формально, то есть, когда вы оставляете комментарии и замечания в документе. В Agile подходах разработки она нередко проходит в виде общения полного или частичного состава участников команды.

У требований может быть разная глубина деталей и направленности, поэтому их делят на несколько типов. В реальной жизни они не всегда будут разделены и могут представлять сплошной документ, где эти типы не обозначены или вовсе перемешаны.

Типы требований:

— Business Requirements — описывают высокоуровневые цели и задачи бизнеса, которые должен решить проект или отдельная задача. В таких требованиях обычно нет совсем никаких подробностей о реализации, а только цели и потребности бизнеса с их абстрактными решениями. Тестирование таких