4.2. QA, QC и Testing
В последние годы на рынке все меньше вакансий, звучащих как «QC Engineer» или «Tester», а половину предложений с таким названием на самом деле стоит именовать «QA Engineer». Причина в том, что сейчас все инженеры в той или иной степени выполняют работу в области QA. То есть, специалисты тестирования чаще обеспечивают качество, а не только контролируют его или тестируют. Далее подробнее о том, что это такое и в чем разница.
4.2.1. Testing
Целью Testing (Тестирования) является вся деятельность для выполнения проверок и обнаружения несоответствий между ожидаемыми и фактическими результатами работы тестируемого продукта.
Тестирование включает в себя создание баг репортов, чек–листов, тестовых сценариев, их выполнение. Оно является частью Quality Control и полностью входит в него.
4.2.2. QC (Quality Control)
Цель QC (Контроль качества) – удостовериться, что программное обеспечение соответствует требованиям, то есть получение глобального представления о программном обеспечении.
Контроль качества включает в себя результаты проведенного тестирования (Testing), их анализ и оценку для получения картины о том, каким качеством обладает программное обеспечение. Контроль качества является частью Quality Assurance и полностью входит в него.
4.2.3. QA (Quality Assurance)
Целью QA (Обеспечение качества) является всестороннее предотвращение дефектов с помощью процессов и регламентов. Оно включает в себя создание процессов и регламентов на всех уровнях (от компании до конкретной функции приложения), а также их исполнение и обновление. Quality Assurance влияет на качество как внутри команды тестирования, так и во всех других командах (аналитики, разработчики и т.д.).
Визуально QA–QC–Testing можно представить так:
Таким образом, QA–QC–Testing являются более подробным описанием трех целей тестирования и того, какие действия проводят для их достижения, без привязки к конкретному программному обеспечению/проекту/компании.
Если более коротко, то:
– Testing – это исследование качества.
– QC – это оценка и контроль уровня качества.
– QA – это создание, улучшение, выполнение регламентов по предотвращению появления дефектов.
4.3. Принципы тестирования
Принципы тестирования – это основные положения, которые помогают определить эффективные методы и подходы к процессу тестирования.
Всего есть шесть основных принципов тестирования:
– Исчерпывающее тестирование невозможно. Это означает, что проверить абсолютно все комбинации невозможно или крайне дорого. Отсюда вывод: надо тестировать только те комбинации, которые лучше выявляют дефекты. Следование этому принципу позволяет многократно сократить время на тестирование, при этом оставляя качество проверок на высоком уровне.
– Тестирование демонстрирует наличие дефектов, а не их отсутствие. Это значит, что, когда мы не находим дефекты, мы даем гарантию, что их нет именно в тех комбинациях (ситуациях или окружении), которые мы использовали. Но это не дает 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 – описывают высокоуровневые цели и задачи бизнеса, которые должен решить проект или отдельная задача. В таких требованиях обычно нет совсем никаких подробностей о реализации, а только цели и потребности бизнеса с их абстрактными решениями. Тестирование таких требований со стороны QA инженеров маловероятно.
– User Requirements – изложение ожиданий конечных пользователей. Чаще всего оформляются в виде пользовательских историй или сценариев. Этот уровень тоже обычно не тестируют QA инженеры, хотя такое случается. Используя эти требования, QA инженер может представить абстракции того, как будут выглядеть его проверки.
– Functional Requirements – описание поведения системы или конкретных ее функций, с которыми работают конечные пользователи. На этом уровне мнение QA инженера особенно важно, так как он постоянно работает с функционалом и может не только исправить ошибку, допущенную аналитиком, но и предложить лучшее решение.
– Non–functional Requirements – описывают нефункциональные атрибуты системы, такие как: производительность, надежность, безопасность, удобство использования, совместимость и т.д. В тестировании таких требований участвуют QA инженеры. Они могут иметь ограниченные технические знания, однако это не мешает им проверить само качество требований.
– Regulatory Requirements – описывают соответствие регуляторов законодательным, нормативным и другим юридическим требованиям. QA инженеры, как и в случае с нефункциональными требованиями, могут протестировать лишь качество того, как описаны требования, но, если не имеют навыков в этой области, то относительно поверхностно.
Каждый из этих типов требований играет важную роль в процессе разработки и гарантирует, что все аспекты системы будут должным образом рассмотрены и реализованы для достижения целей проекта.
Требования могут быть качественными или нет.
Критерии качества требований:
– Конкретность – требования должны быть четко сформулированы, без неоднозначностей. Каждое требование должно быть понятно всем участникам проекта.
– Измеримость – должен существовать способ проверить, выполнено требование или нет.
– Достижимость – требование должно быть достижимым в рамках ресурсов проекта, его ограничений и доступных технологий.
– Атомарность – требование должно быть настолько неделимым, насколько это возможно.
– Релевантность – требование должно быть важным для бизнес–целей проекта.
– Полнота – требование должно полностью описывать поведение системы, не оставляя пробелов в спецификации. Все возможные сценарии использования должны быть учтены.
– Непротиворечивость – требования не могут противоречить друг другу, они должны быть согласованы.
– Модифицируемость – требования должны быть оформлены в таком виде и структуре, при которых их изменения проходят легко и не приводят к значительному влиянию на другие требования.
– Проверяемость – должна быть возможность протестировать требование, чтобы определить, что система его выполняет.
– Отслеживаемость – должна быть возможность проследить, как требование реализуется на разных этапах разработки. Каждое требование в ходе реализации функционала должно иметь нумерацию или маркер с привязками к задачам. Это значит, что не должно возникать трудностей в том, чтобы отследить любое требование от момента его возникновения до конечной реализации.
– Проранжированность – требования должны быть отсортированы в соответствии с важностью целей.
Далее рассмотрим примеры критериев качества требований. Учтите, что каждый пример описывает конкретный критерий, но для простоты может намеренно нарушать другие.
Пример конкретности требования
В хорошем примере корректно описано, что должна делать система, когда она должна совершать действия, каким способом и в рамках какого времени. Это требование очень важно, так как для каждого участника команды «быстро» – субъективное понятие, а значит работу системы каждый оценит по-своему.
Пример измеримости требования
В хорошем примере указана точная цифра, по которой можно будет судить, выполняет ли система указанное требование.
Пример достижимости требования
В плохом примере отчеты любого размера должны экспортироваться за 2 секунды, что невозможно выполнить при генерации 200 страниц. В хорошем примере цифры реалистичные и разграничены по объему экспортируемой информации.
Пример атомарности требования
В хорошем примере описано только одно требование, в плохом сразу несколько в одном предложении. В целом, такое может быть допустимо для требований бизнес-уровня. Но если вам необходимо задать несколько бизнес-требований, их лучше разделять. Польза этого особо заметна на больших и старых проектах, когда есть необходимость четко отследить, откуда появились конкретные требования и какие из них были реализованы в полном объеме или нет.
Пример релевантности требования
В хорошем примере требование описывает полезные и актуальные функции для большинства пользователей веб-сайтов электронной коммерции. Плохой пример довольно утрированный, но суть в том, что требование может быть абсолютно бесполезным или несвоевременным для выполнения бизнес-целей проекта, а значит трата ресурсов на его выполнение – избыточное или вовсе бессмысленное действие. Некоторым проектам крайне важно быть в числе первых кто реализует ту или иную функциональность. При этом гонка с конкурентами может быть достаточно обостренной чтобы действительно заботиться о релевантности буквально каждые пару недель.
Пример полноты требования
В хорошем примере есть полное понимание того, какие данные требуются от пользователя. В плохом примере не понятно, какие именно данные необходимо собирать, а это очень важно, так как разные данные требуют разного уровня обеспечения безопасности со стороны тех, кто их хранит, не говоря о соответствующих лицензиях от государственных органов и соглашений с пользователем.
Пример непротиворечивости требования
В хорошем примере нет противоречивого утверждения – учетная запись полностью заблокирована. В плохом примере либо требуется уточнение, что учетная запись блокируется не полностью, а выборочно для определенного метода входа в систему, либо возможность входа указывает на то, что сама попытка проникнуть в систему другим способом не заблокирована, но сделать это не получится.
Пример модифицируемости требования
В хорошем примере при изменении алгоритма достаточно будет обновить его только один раз, в месте куда введет ссылка, которая всегда укажет на него. Плохой пример потребует больше внимательности при обновлении и больше затрат времени.
Пример проверяемости требования
В хорошем примере существует однозначный способ проверить во время тестирования, выполнено ли требование. В то же время, «приятный» пользовательский интерфейс является очень субъективным понятием.
Пример отслеживаемости требования
В хорошем примере сразу понятно, что это требование имеет отношение к какой–то конкретной фиче и пользовательской истории с уникальными номерами. На практике это может быть не частью названия, а связью между сущностями в системе, где создаются они или такие документы.
Пример проранжированности требования
В хорошем примере сразу понятно, какие требования абсолютно необходимы для успешного выполнения целей проекта или задачи, а какие являются второстепенными и не критичны для выпуска проекта. Четкая приоритезация позволяет акцентировать работу команды на главных задачах, а также дает понять, какой частью функционала можно в теории пожертвовать в случае запаздывания по срокам реализации проекта.
Соблюдение этих критериев качества требований позволяет создать четкую и понятную спецификацию из различных типов требований. Качественные требования являются фундаментом для эффективной разработки программного обеспечения.
4.6. Верификация и валидация
Верификация – это проверка того, что программное обеспечение соответствует требованиям и спецификациям.
Пример
Подтверждение того, что написанный программный код полностью и корректно выполняет все алгоритмы, которые мы от него требуем, является верификацией.
Валидация – это проверка того, что программное обеспечение соответствует ожиданиям пользователей.
Пример
Подтверждение того, что написанное приложение по созданию финансовой отчетности полностью выполняет потребности и желания пользователей, является валидацией.
Эти термины похожи, но ключевая разница заключается в том, что мы можем создать прекрасное программное обеспечение с высокой производительностью и красивым функционалом, то есть пройти верификацию требований, но при этом можем, к примеру, генерировать отчеты в формате, который поддерживают не все компьютеры пользователей. Таким образом, верификация это о том, правильно ли мы реализовали задуманное, а валидация о том, правильно ли мы поняли и уточнили потребности пользователей.