Основы тестирования ПО

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

Зачем нужно тестирование ПО?

Разработчики могут случайно допустить ошибки, дефекты или баги. Современное ПО сложно, и недопонимание может привести к ошибкам в логике и коде.

Тестирование выявляет дефекты, чтобы их можно было исправить и повысить качество ПО. Цель состоит в том, чтобы разработать и поставить приложения без дефектов. Когда компания берётся создать ПО для клиента, её работу определяют правовые, договорные и отраслевые требования. Компания, которая заботится о качестве, включает тестирование в число своих передовых практик.

Трудно определить, какого объёма тестирования достаточно. Тщательное планирование и продуманные тестовые сценарии помогают обеспечить качественную поставку.

Кто тестирует ПО?

Кто должен проверять ПО? Разработчики часто проверяют свой код несколько раз перед передачей. Тем не менее дефекты могут остаться, ведь собственные ошибки трудно заметить.

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

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

Иногда разработчики проверяют работу друг друга. Такой подход называется взаимным тестированием, или buddy testing. В каждой команде разработки должны быть специалисты, выделенные для тестирования, а на проекте обычно есть хотя бы одна отдельная команда тестирования. Одни компании создают отдельные команды для проверки удобства использования, производительности, безопасности и других видов тестирования. Другие поручают эту работу специализированным компаниям, независимым тестировщикам или консультантам.

Что именно нужно тестировать?

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

Открыть схему в полном размере ↗

Что именно нужно тестировать?

Когда тестируют ПО?

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

Как часто нужно тестировать?

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

Открыть схему в полном размере ↗

Как часто нужно тестировать?

Что такое стандарты тестирования ПО?

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

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

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

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

Что такое тестируемость ПО?

Тестируемость показывает, насколько легко протестировать программную систему. Оцените её заранее, чтобы определить необходимые ресурсы. Тестирование выявляет дефекты. Тестируемость помогает понять, в каких областях дефекты могут остаться незамеченными. Высокая тестируемость облегчает проверку, а низкая требует больших усилий. Учитывайте следующие факторы.

1. Управляемость позволяет контролировать процесс тестирования и оптимизировать его.
2. Наблюдаемость означает, что поведение системы и факторы, влияющие на результат, видны и доступны для проверки.
3. Доступность означает, что вы можете получить доступ к системе для её тестирования.
4. Простота достигается благодаря последовательному проектированию, понятным функциям и простым приёмам программирования. Всё это снижает сложность тестирования. Более сложное ПО проверять труднее.
5. Стабильность облегчает тестирование. Частые изменения проекта могут ему мешать.
6. Доступная информация о ПО сильно влияет на эффективность тестирования.

Учитывайте следующие связи между тестируемостью и дефектами.

1. Более высокая тестируемость способствует улучшению тестов и сокращению числа дефектов.
2. Более низкая тестируемость может ухудшить качество тестов и оставить в системе больше дефектов.

Верификация и валидация ПО

Верификация и валидация представляют собой разные виды анализа. Валидация проверяет, ту ли систему вы создаёте. Соответствует ли она требованиям клиента?

Верификация проверяет, правильно ли вы создаёте систему. В центре внимания техническое качество и соблюдение необходимых стандартов.

Валидация проверяет, отвечают ли спецификации потребностям клиента. Верификация проверяет, следует ли разработка стандартам качества ПО и инженерным практикам организации.

Открыть схему в полном размере ↗

Верификация и валидация ПО

В некоторых подходах верификацию проводят на каждом этапе разработки, а валидацию сосредотачивают в начале и конце, во время анализа требований и приёмочных испытаний. На практике такой порядок соблюдать трудно. В начале сложно учесть все требования клиента, и после запуска разработки требования часто меняются. Сами команды разработки тоже могут предложить изменения. Поэтому проводите и верификацию, и валидацию на протяжении всей разработки.

Тестировщики используют верификацию и валидацию, или V&V, для проверки разных аспектов качества ПО.

Тестирование и отладка ПО

У тестирования и отладки разные цели. Тестирование обнаруживает дефекты. Отладка начинается после обнаружения дефекта и устраняет его причину.

Когда тестировщики сообщают о дефекте, разработчики ищут первопричину. Они изучают связанные модули, находят проблему в коде и исправляют её. Во время отладки причину выявляют и устраняют шаг за шагом.

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

1. Тестирование обнаруживает дефекты. Отладка находит и устраняет их причины.
2. Тестирование важно для разработки. Отладка помогает устранять дефекты, выявленные тестами.
3. Тестирование начинается на ранних этапах разработки. Отладка начинается, когда поступают сообщения о дефектах.
4. Тестирование включает верификацию и валидацию (V&V). Отладка исследует и устраняет причину дефекта.

Что такое дефект?

Дефект представляет собой отклонение от спецификации требований к ПО. Дефекты могут возникнуть в коде или при проектировании и приводить к неверным результатам при выполнении программы.

1. Код с большим количеством дефектов часто называют кодом с багами.
2. Отчёт о дефекте описывает характер проблемы.
3. Системы учёта дефектов позволяют отслеживать дефекты в программной системе.
4. Один из методов тестирования предусматривает намеренное внесение дефектов в код. Затем наблюдают за результатом, чтобы проверить, реагирует ли система на эти проблемы ожидаемым образом.

Открыть схему в полном размере ↗

Что такое дефект?

Что такое серьёзность и приоритет?

Серьёзность показывает, как дефект влияет на систему. По степени влияния выделяют следующие категории.

1. Критический дефект не позволяет приложению нормально работать из-за сбоя системы или повреждения данных. Пользователь не может продолжить работу.
2. При серьёзном дефекте возможен сбой, но пользователь может получить результат другим способом без дополнительного обучения. Такие дефекты менее серьёзны, чем критические.
3. При дефекте средней серьёзности система продолжает работать, но выдаёт неверные или противоречивые результаты.
4. Незначительный дефект не приводит к сбою системы и не ухудшает удобство использования. Его легко исправить.
5. Косметический дефект влияет на внешний вид системы.

В отчёте о дефекте указывают не только его серьёзность, но и приоритет. Приоритет подсказывает разработчикам, в каком порядке устранять дефекты.

1. Дефект с низким приоритетом устраняют после более приоритетных дефектов. Он не требует немедленного вмешательства.
2. Дефект со средним приоритетом устраняют вскоре после более приоритетных дефектов.
3. Дефекту с высоким приоритетом уделяют внимание сразу и устраняют его как можно быстрее.

Чтобы определить срочность действий, учитывайте указанные в отчёте серьёзность и приоритет вместе.

Открыть схему в полном размере ↗

Что такое серьёзность и приоритет?

1. При высокой серьёзности и высоком приоритете проблема в базовой функции не позволяет пользователю работать с системой. Устраните её немедленно.
2. При высоком приоритете и низкой серьёзности опечатка в названии компании или проблема с логотипом почти не влияет на функции, но требует немедленного исправления.
3. При высокой серьёзности и низком приоритете крупный дефект затрагивает модуль, который пользователю пока не нужен. Исправление может подождать.
4. При низком приоритете и низкой серьёзности косметические дефекты, не влияющие на функции, обычно исправляют в последнюю очередь.