Пока нет оценок.
Пожалуйста, подождите...

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

Динамика тестируемости программного обеспечения

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

1. Снижение эпистемологической тестируемости из-за роста стандарта качества или изменения продукта

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

2. Улучшение аспектов тестирования всегда повышает скорость совершенствования эпистемологической тестируемости

Все усилия, прилагаемые QA-инженером с целью улучшить аспекты тестируемости, по факту увеличивают скорость, с которой продукт проверяется. Тестировщик всегда знает, что и как проверять.

3. Развитие тест-стратегии иногда снижает субъективную тестируемость

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

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

4. Улучшение внутренней тестируемости создает риск снижения проектной тестируемости

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

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

5. Проектная тестируемость также снижается из-за улучшения ценностной тестируемости

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

6. Развитие практической тестируемости способствует улучшению разработки и поддержки

Если продукт просто тестировать, значит, его он прост и в поддержке, дальнейшем развитии и постепенном улучшении.

7. QA-специалист борется за тестируемость

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

Виды тестируемости

Виды тестируемости

Базовые составляющие анализа тестируемости

Эпистемологическая тестируемость

  • Все знания о качестве – если раньше мы работали с подобным продуктом, нам понадобится меньшее количество времени на проведение тестирования.
  • Толерантность к отказу – чем ниже уровень требований для тестов, тем больше рисков может себе позволить проверяющий.

Проектная тестируемость

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

Ценностная тестируемость

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

Субъективная тестируемость

  •  Знания о продукте – чем больше тестировщик знает о ПО (включая все его характеристики и особенности), тем лучше он сможет проверить продукт. Если никаких данных у него нет, он сможет быстро и эффективно научиться, проводя тестирование исследовательским способом.
  • Технические познания – возможность программировать, знание терминологии и используемого инструментария, общее понимание динамики изменчивости продукта упрощает процесс его тестирования.
  • Доменные познания – чем больше тестировщик знает о пользователе, тем лучше он проверяет продукт.
  • Способности к тестированию – развитие подобных навыков очень упрощает процесс тестирования ПО. Если с определенной последовательностью использовать экспериментальный дизайн, процесс моделирования, учет потенциальных элементов продукта, применять критическое мышление и тест-фрейминг, процесс проверки можно вывести на весьма новый и продуктивный уровень.
  • Вовлеченность в тестирование – проверять проще, когда тестировщик находится очень близко к процессу разработки, постоянно контактируя с командой разработчиков. Если же он очень далек от этого, эффективность его проверок будет на весьма низком уровне.
  • Тест-тактика – качественно спроектированная тест-тактика позволяет существенно снизить время и силы на проверки.

Внутренняя тестируемость

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

Итог

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

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

Оставить комментарий