Качество программного продукта и тестирование
Качество программного продукта можно оценить некоторым набором характеристик, определяющих, насколько продукт "хорош" с точки зрения всех потенциально заинтересованных в нем сторон. Такими сторонами являются:
- заказчик продукта
- спонсор
- конечный пользователь
- разработчики продукта
- тестировщики продукта
- инженеры поддержки
- отдел обучения
- отдел продаж и т.п.
Каждый из участников может иметь различное представление о продукте и по-разному судить о том, насколько он хорош или плох, то есть насколько высоко качество продукта. С точки зрения разработчика, продукт может быть настолько хорош, насколько хороши заложенные в нем алгоритмы и технологии. Пользователю продукта, скорее всего, безразличны детали внутренней реализации, его в первую очередь волнуют вопросы функциональности и надежности. Спонсора интересует цена и совместимость с будущими технологиями. Таким образом, задача обеспечения качества продукта выливается в задачу определения заинтересованных лиц, согласования их критериев качества и нахождения оптимального решения, удовлетворяющего этим критериям.
В рамках подобной задачи группа тестирования рассматривается не просто как еще одна заинтересованная сторона, но и как сторона, способная оценить удовлетворение выбранных критериев и сделать вывод о качестве продукта с точки зрения других участников. К сожалению, далеко не все критерии могут быть оценены группой тестирования. Поэтому ее внимание в основном сосредоточено на критериях, определяющих качество программного продукта с точки зрения конечного пользователя.
Тестирование как способ обеспечения качества. Тестирование, с технической точки зрения, есть процесс выполнения приложения на некоторых входных данных и проверка получаемых результатов с целью подтвердить их корректность по отношению к результату.
Тестирование не позиционируется в качестве единственного способа обеспечения качества. Оно является частью общей системы обеспечения качества продукта, элементы которой выбираются по критерию наибольшей эффективности применения в конкретном проекте.
Рассмотрим пример. В качестве приложения возьмем программу для работы с сетью (browser), критерии качества которой приведены в Табл.9.1.
Таблица 9.1.
Критерии качества программы browser | Пользователь | Заказчик | Инженер поддержки |
|---|
| Функциональная полнота | + | - | - |
|---|
| Цена разработки | - | + | - |
|---|
| Отсутствие дефектов | + | Косвенно | + |
|---|
| Удобство использования | + | - | - |
|---|
| Возможность внесения изменений в будущем | - | Косвенно | + |
|---|
| Легкость исправления дефектов | - | - | + |
|---|
| Документация на реализацию, в том числе комментарии | - | - | + |
|---|
| Своевременность исполнения проекта | - | + | - |
|---|
Матрица критериев качества заинтересованных в них участников для рассматриваемого проекта приведена в таблице 9.2 . Допустим, что вид матрицы критериев качества и проверяющих элементов системы обеспечения качества для данного проекта будет следующим:
Таблица 9.2.
Матрица критериев качества и элементов системы обеспечения качества | Тестирование | Анализ рынка и специальные лаборатории1) | Обзоры кода | Анализ дизайна | Аудиты процесса разработки |
|---|
| Полнота функциональности | +, не всегда эффективно | + | - | - | - |
|---|
| Стоимость разработки | - | - | - | - | + |
|---|
| Отсутствие дефектов | + | - | + | - | - |
|---|
| Удобство использования | +, не всегда эффективно | + | - | - | - |
|---|
| Возможность внесения изменений в будущем | - | - | +- | + | - |
|---|
| Легкость исправления дефектов | - | - | + | + | - |
|---|
| Документация на реализацию, в том числе комментарии | - | - | + | - | + |
|---|
| Своевременность исполнения проекта | - | - | - | - | + |
|---|
Данные (Табл. 9.1, Табл. 9.2) показывают, что из восьми элементов общего качества продукта тестирование способно оценить и контролировать только три (1, 3, 4), причем наиболее эффективно тестирование контролирует отсутствие дефектов (3).
В каждом конкретном проекте элементы системы должны быть выбраны так, чтобы обеспечить приемлемое качество, исходя из приоритетов и имеющихся ресурсов. Выбирая элементы для системы обеспечения качества конкретного продукта, можно применить комбинированное тестирование, обзоры кода, аудит. При подобном выборе некоторые качества, например легкость модификации и исправления дефектов, не будут оценены и, возможно, выполнены. Задачей тестирования в рассматриваемом случае будет обнаружение дефектов и оценка удобства использования продукта, включая полноту функциональности. Исходя из задач, поставленных перед группой тестирования в конкретном проекте, выбирается соответствующая стратегия тестирования. Так, в данном примере, ввиду необходимости оценить удобство использования и полноту функциональности, преимущественный подход к разработке тестов следует планировать на основе использования сценариев.
Итак, основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
- Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
- Определение критериев, формирующих представление о качестве для каждого из участников.
- Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
- Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
- Определение способов и механизмов достижения каждого критерия.
- Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей
поддержка курса
Основы тестирования программного обеспечения
RSS