QA Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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