3. По признаку позитивности сценариев:

• Позитивное тестирование (positive testing)

• Негативное тестирование (negative testing)

3. По степени подготовленности к тестированию:

• Тестирование по документации (formal testing)

• Интуитивное тестирование (ad hoc testing)

3. По уровню тестирования:

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

• Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

• Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей. Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

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

3. По стратегии тестирования:

• Тестирование частей против тестирования целого. Существует восходящая и нисходящая стратегии тестирования.

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

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

• Псевдоотладка и мутационное тестирование. Эти стратегии связаны с преднамеренным вводом ошибок в код программы.

• псевдоотладка используется для оценки проводимых тестов;

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

Статическое и динамическое тестирование

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

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

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

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

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

Регрессионное тестирование

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

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

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

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

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

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

Цитата: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу "два шага вперед, шаг назад".

Почему не удается устранять ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной или документация очень хорошей, отдаленные последствия этого исправления останутся незамеченными. Во-вторых, ошибки обычно исправляет не автор программы, а зачастую младший программист или стажер. Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически, после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое возвратное (регрессионное) тестирование действительно должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит.» — Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — Пер. с англ. — СПб.: Символ-Плюс, 2001. — 304 стр.: ил. (стр.113–114).

Покрытие кода

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

Существует несколько различных способов измерения покрытия, основные из них:

• покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована;

• покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована;

• покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы;

• покрытие функций — каждая ли функция программы была выполнена;

• покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены.

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

Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например, 67 % покрытия путей — это лучший результат, чем 67 % покрытия операторов. Надо сказать, что вопрос о связи значения покрытия кода и качества тестового набора ещё до конца не решён.

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

Примеры тестов, проводимых при функциональном и системном тестировании

1. Сверка со спецификацией.

Пример:

Пункт требований из спецификации (документа требований)

Разработать блок регистрации пользователя, включающий в себя следующие поля:

Имя пользователя – символьное (30);

Фамилия – символьное (20);

Ник – символьное (15) допускаются цифры и спецсимволы;

Пароль – символьное (от 8 до 12);

E-mail;

Телефон (только цифры) – не более 15;

Дизайн формы имеет вид: …..

Обязательные поля для ввода пометить *

Тестовый сценарий для проверки блока регистрации пользователей

№	Name (название)	Inputs and technics (шаги для воспроизведения)	Expected results (ожидаемый результат)	Note (Заметка)	Result (Результат)
1	Проверка верстки блока регистрации
2	Проверка валидации
2.1	Поле Имя	В поле «имя» ввести 40 букв и цифр	После ввода 30-40 символов у пользователя ограничивается возможность ввода. Появляется сообщение, что имя не должно содержать цифры и специальные символы
2.2	Проверка поля Фамилии	В поле «фамилия» ввести 40 букв и цифр	После ввода 30-40 символов у пользователя ограничивается возможность ввода. Появляется сообщение, что фамилия не должна содержать цифры и специальные символы
2.3	Проверка Ника	Проверить на ограничение по количеству символов, ввести 15 символов	(максимальное количество). Ввелись первые 15 символов
2.4	Проверка Пароля	Ввести 5 символов Ввести 15 символов	Появляется сообщение, что пароль должен содержать от 8 до 12 символов. Вводимые в поле символы отображаются *
2.5	Проверка Email	Скопировать кусок текста их Word длиной 2000-4000 символов. Вставить в поле Email	Формат E-mail указан не верно
3	Проверка ввода обязательных полей	Ввести в поле логин, пароль, нажать «Сохранить»	Должно появиться сообщение: «Все поля, отмеченные * должны быть введены»
4	Проверка ввода корректной информации		Пользователь зарегистрировался и получил сообщение, что он зарегистрирован; ему доступна функция выхода из системы (logout)
5	Проверка авторизации	Зайти в систему по только что созданному пользователю	Авторизация прошла успешно. Пользователю доступны все функции зарегистрированного пользователя

2. Метод эквивалентных разбиений входных данных. В этом случае входную область программы разбивают на конечное число классов эквивалентности – наборов данных с общими свойствами.

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

Каждый тест являющийся представителем некоего класса эквивалентности разбиения выполняют в 2 этапа:

• выделение классов эквивалентности;

• построение тестов.

Различают 2 вида классов эквивалентности:

• правильные (корректные) – представляющие собой правильные входные данные программы;

• неправильные входные данные, в которых заведомо вводятся ошибочные значения.

Правила проектирования классов эквивалентности:

• Если входное условие описывает область значений, то определяется один правильный класс эквивалентности и два не правильных;

• Если входной параметр описывает число значений, также определяется один правильный и два не правильных;

• Если входное условие задает множество входных значений и есть основание полагать, что каждое значение программа трактует особо, то тогда для каждого такого значения стоится правильный класс эквивалентности и один не правильный для всех;

• Если входное условие описывает ситуацию, когда, например, первым символом идентификатора должна быть буква, то приходиться строить два класса эквивалентности, первый символ правильный – буква, второй - неправильный – символ;

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

3. Метод анализа граничных значений входных данных.

Граничные условия – ситуации, возникающие непосредственно на границе входных или выходных классов эквивалентности выше или ниже ее границы.

Метод тестирования граничных значений дополняет метод классов эквивалентности.

Основные отличия этих двух методов:

• Для метода граничных значений тестовые варианты создают для проверки только границ классов эквивалентности;

• При создании тестовых вариантов учитывают не только условия ввода, но и область вывода.

Общие правила при проведении тестов рассмотренными методами (граничных значений и эквивалентных разбиений)

• Если условие ввода позволяет задать диапазон значений от n до m, то создают тесты:

• для получения значений n и m;

• для определения значений n и m.

• Если условие ввода удовлетворяет дискретному ряду значений, то создают тесты для определения:

• минимального и максимального значения;

• значений чуть меньше минимального и чуть больше максимального.

• Если входной файл может содержать, например, от 1 до 255 записей, то создают тесты для получения 0, 1, 255, 256.

• Правило 1 используется для каждого условия вывода.

• Если внутренние структуры данных программы имеют предписанные границы, то пишутся тестовые процедуры (сценарии), которые позволяют проверить (тестировать) эти структуры на их границы.

• Если входные и выходные данные являются упорядоченными множествами, то необходимо тестировать обработку первого и последнего элемента этих множеств.

4. Тестирование объектно-ориентированного программного обеспечения (ООП).

При тестировании приложений созданных с использованием ООП, кроме методов, описанных ранее, используется следующее:

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

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

• Проектирование поэлементных тестов для совокупности класса.

• Проектирование поэлементных тестов для иерархии класса.

5. Производительность. Performance Testing – тестирование производительности. На этом этапе проверяется скорость выполнения операций в единственном времени с использованием специальных программ тестирования, а иногда и с секундомером.

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

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

• Зайти

• Зарегистрироваться

• Пройтись по категориям

• Осуществить поиск продукта

• Добавить продукты в фавориты

• Добавить продукты в корзину

• Частично очистить корзину

• Пойти за покупками (перейти на «Купить»)

8. Нагрузочные испытания.

9. Совместимость и преобразование форматов данных.

10. Аппаратные конфигурации. При тестировании аппаратных конфигураций необходимо проверить на совместимость работы с различными периферийными устройствами.

11. Тестирование и сопровождение программы на этапе гарантийного обслуживания.

Категории программных ошибок

1. Ошибки пользовательского интерфейса.

• Функциональность. Функциональные недостатки встречаются абсолютно у всех программ, поскольку ожидание пользователей вещь субъективная. Исправить абсолютно все недостатки (не приводящие к серьезным проблемам) не возможно, попытка это сделать может привести к потерям концептуальной целостности продукта, его усложнению или новым более серьезным ошибкам. Если функциональный недостаток очевиден, задачу трудно выполнить (решается неуклюже), такую проблему надо устранять.

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

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

• Пропущенные команды. Не заставляет ли программа выполнять некоторые действия не естественным или не эффективным способом.

• Производительность. Если пользователь ощущает задержки, а программы – конкуренты работают быстрее, значит это ошибка производительности.

• Выходные данные. В нужном ли виде формируются выходные данные; отчетливо ли видно распечатанные в программе; сохраняются ли они в формате, доступном для других программ; помещаются ли отчеты по ширине на один экран.

2. Обработка ошибок.

3. Ошибки, связанные с обработкой граничных условий.

4. Ошибки вычислений. К этой категории относятся:

   • Ошибки, связанные с ошибками округлений.

   • Вычислением сложных формул.

   • Ошибки, вызванные не правильным выбором алгоритма: применяются не правильные формулы, неверные способы разбиения сложных выражений на более простые, логические ошибки, применяемые к формулам.

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

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

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

8. Ситуация гонок. Типичные для систем, где параллельно выполняются взаимодействующие процессы и потоки и, прежде всего, для многопользовательских систем реального времени. Классификация ситуации гонок: если в системе ожидаются 2 события и первым может наступить любое из них, но при наступлении событии А – выполнение программы продолжиться, а при наступлении В – произойдет сбой. Это одна из наиболее распространенных ошибок.

9. Перегрузки. Не всякая программа адекватно справляется с перегрузками. Вместо сбоев в программе, вызванных нехваткой памяти, перегрузкой трафика, отсутствием необходимых ресурсов, - должны выдаваться адекватные сообщения. У каждой программы есть свои пределы, но эти пределы должны обязательно удовлетворять требования. Пример: Если программа выдает сообщение, что в ней много пользователей при 5 пользователях, а рассчитана на 100, такое сообщение не является решением проблемы

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

    • Программа посылает устройствам неверные данные

    • Игнорируют сообщения об ошибках устройств

    • Пытаются использовать устройства, которые заняты или вообще отсутствуют.

11. Контроль версий. Ошибки могут возникать, когда в новую версию попадают старые модули.

12. Ошибки документации. Ошибок в документации не должно быть (должны бать инструкции, Help).

13. Ошибки тестирования. Связаны с ошибками, которые тестировщики не находят (допускают).

План тестирования

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

Согласно стандарту IEEE 829, план тестирования состоит из следующих разделов:

1. Идентификатор плана проведения испытаний.

2. Введение.

3. Компоненты, которые должны тестироваться. В компонентах нужно привести краткое описание объекта тестирования:

• Системы.

• Приложения.

• Оборудования.

• В том числе, отдельные компоненты системы.

4. Характеристики и свойства, которые должны тестироваться. Те характеристики и свойства, которые будут тестироваться (по договоренности с заказчиком, если это аутсорсингвый (договорной) проект и все характеристики и свойства, если это собственный проект).

5. Характеристики и свойства, которые не должны тестироваться.

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

• Статическое тестирование требований, проектная документация;

• Статическое и динамическое тестирование, которое должно проводиться на стадиях тестирования программных кодов, модулей и проверки взаимодействии и функционирования компонентов системы;

• Тестирование свойств;

• Испытания при перегрузках под нагрузкой, тестирование производительности;

• Проверка средств защиты;

• Тестирование установки обновления программного продукта;

• Тестирование средств дублирования восстановления;

• Тестирование графического интерфейса;

• Регрессионное тестирование;

• Приемочные испытания:

• при α – альфа испытания;

• при β – бета испытания.

• Проверка результатов устранения дефектов;

• Прерывание испытаний проводимых в автоматизированном и неавтоматизированном режимах;

• Виды тестирования, проведение которых поручается сторонним организациям;

• Использование системы отслеживания дефектов для ввода сообщения о неисправности;

7. Критерии успешных и не удачных испытаний;

8. Критерии по остановке испытаний и требования возобновлений испытаний:

• Готовность тестовой платформы;

• Законченность разработки требуемого функционала;

• Наличие всей необходимой документации.

9. Выходные результаты тестов может состоять из следующих пунктов:

• План проведения испытаний;

• Документы, регламентирующие проектирование тестов;

• Документ, содержащий спецификации тестов;

• Сообщение о результатах прогонов теста

• Сообщение об обнаруженных дефектах

• Примечание по выпуску программного продукта.

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

11. Требования к окружающей среде. Определяются в требованиях к проекту.

12. Распределение ответственности при проведении тестирования. В этом пункте указываются компетенции:

• Модульное тестирование проводится разработчиком;

• Распределение ошибок зафиксированных в системах бактренинга (отслеживание дефекта) проводится менеджером проекта;

• Написание тестовых процедур проводится старшим менеджером отдела качества;

• Нагрузочное тестирование проводят инженеры по контролю качеством и системный администратор.

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

14. График работ. График работ должен быть спланирован менеджером совместно с начальником отдела контроля качества. При составлении графика работ нужно учесть: Если в графике выпуска продукта β – версия запланирована на определенное число, в плане проведения испытаний тестирование этой версии должно быть позначено на более ранний срок, чтобы к моменту выпуска этой версии она была полностью протестирована, а дефекты устранены. После составления план тестирования, как и любой другой документ, подвергается статическому тестированию, так, как является важным продуктом жизненный цикл (ЖЦ) разработки. В проверках должны участвовать не только члены группы тестирования, но и представители разработчиков, руководства, а иногда и заказчика. Проверки плана тестирования преследуют следующие цели:

• Все исполнители, принимающие участие в процессе разработки продукта, должны понимать и одобрять цели, покрытие, ограничения и риски, связанные с проведением тестирования;

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

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

15. Риски и предвиденные обстоятельства.

16. Утверждение плана проведения испытаний.

Документирование и анализ ошибок

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

• Тщательно проанализировать ошибку, чтобы описать её предельно кратко и корректно;

• Объяснить, как воспроизвести ошибку или проблемную ситуацию;

• Составить полный, понятный и непротиворечивый отчет.

Структура отчета о проблеме

Независимо от программных средств, использующихся для учета ошибок, а эти программные средства: (Mantis, Bugzilla, MsProject, Track Studio), отчет об ошибке включает следующие пункты:

• Имя проекта (обязательно);

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

• Тип отчета (категория). Как правило, категории заполняются менеджером вначале проекта. Могут быть следующими:

1. Категории по типам ошибок;

(Типы программных ошибок)

• Ошибка кодирования;

• Ошибка проектирования;

• Ошибка useability;

• Ошибка графического интерфейса;

• Расхождение с документацией (спецификацией);

• Предложение;

• Взаимодействие с аппаратурой;

• Вопрос.

2. Категории по видам составляющих проекта

Например:

• Модуль администратора (сайт);

• Модуль совершения покупки;

• Модуль саморегистрации пользователей;

• Модуль отображения баннеров.

Иногда названия категорий могут совпадать с названиями пунктов требований.

• Степень важности. Этот пункт заполняется тестировщиком, в нем указывается, сколь серьезна выявленная проблема. Четких критериев для определения важности не существует, но, как правило, в системах предусмотрено 4-6 степеней важности:

• Не серьезная (связана с исправлением в тексте, если этот текст не находится на главной странице);

• Нормальная (средняя, normal, как правило, этот критерий стоит по умолчанию, и если тестировщик не может разобраться к какой степени важности отнести, то нужно оставлять это пункт);

• Серьезная ошибка (расхождение со спецификацией, ошибки на главной странице, не приводящие к блокированию системы);

• Аварийные ошибки (crash, ошибки, связанные с появлением не обработанных исключений, не приводящих к блокированию системы);

• Блокирующие ошибки (block, когда система блокируется, падает).

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

• Исправить немедленно (immediately, в том случае, если ошибка задерживает работу других сотрудников);

• Исправить как можно быстрее;

• Исправить в текущей версии;

• Исправить до выхода окончательной версии;

• Исправить, если возможно;

• Не обязательно.

• Суть проблемы (Summary). Формируется суть ошибки, при этом описание должно быть информативным. Например: в Internet Explorer разъехалась домашняя страница пользователя. Поле Summary всегда отображается в сводном перечне ошибок, поэтому если даже две ошибки похожи друг на друга, в разделе Summary предложение должно быть уникальным.

• Воспроизводимость проблемной ситуации. Есть несколько возможностей воспроизведения степеней ошибки:

• Всегда;

• Иногда;

• Случайным образом;

• Невозможно воспроизвести.

• Подробное описание проблемы (description). Более детальное описание проблемы, ссылки на дополнительную информацию и приложения. Именно в этом пункте можно указать версию продукта, если она не указана ранее и для нее не указан отдельный пункт.

• Шаги для воспроизведения. Описать по пунктам все действия, приводящие к возникновению ошибки (например, обратить внимание – таблица «разъехалась»).

• Дополнительная информация. Не обязательный пункт. Можно привести какую-то аргументацию, указать ссылки на источники, указать, как можно исправить какую-либо ошибку.

• Автор отчета.

• Дата обнаружения проблемы.

• Поручено (направлено). Как правило, заполняется менеджером или руководителем группы разработки. Здесь указывается, кто из сотрудников отвечает за решение проблемы.

• Комментарии (Notes). В комментариях, как правило, указывается замечание при изменении статуса ошибки. Например:

Исправлено в версии…

Не могу воспроизвести ошибку

Не считаю нужным эту ошибку исправлять

Будет исправлено в версии…

• Состояние ошибки (статус). В поле состояние только что написанного отчета записывается «Открыто» (New). После исправления ошибки статус изменяется на «Решено». А после проверки того, что ошибка исправлена или принято решение о том, что ошибка не будет исправляться, значение этого поля исправляется на «Закрыто» (Closed). Если ошибка направлена на сотрудника, который будет ее исправлять «Направлена» (Assigned). Можно поставить статус «Отложено», в том случае, если ошибка не воспроизводится, исправление откладывается на неопределенный срок. Можно поставить статус «Рассматривается», если менеджер с ошибкой ознакомился, но она пока ни на кого не распределена (разработчик – пока не занимался исправлением).

• Поле для проверки связи между ошибками. Если, допустим, две ошибки дублируют друг друга, возможна связь ошибок (отчетов) об ошибках дубликатах. Возможность установления связей между родительскими и дочерними ошибками.

Тестирование требований

Тестирование требований - это завершающий этап процесса формирования требований.

Основные факторы, которые требуют участия группы тестирования на стадии формирования требований:

• необходимость получения спецификаций, служащих основой для составления плана тестирования и Test Case;

• необходимость статического тестирования с целью предотвращения перетекания дефектов на более поздние стадии разработки.

Статические методы тестирования:

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

2. Сквозной контроль – один человек, тот, что готовил требования, их презентует, все остальные исполнители делают замечания, высказывают пожелания; в связи с тем, что мероприятие менее формализовано, считается что остается больше времени на обнаружение дефектов.

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

Критерии, используемые при тестировании требований

1. Полнота;

2. Однозначность;

3. Непротиворечивость;

4. Прослеживаемость;

5. Осуществимость;

6. Контролепригодность.

Полнота.

• требования не должны содержать выражений типа: и так далее, и прочее, подлежит определению, и им подобные.

• требования не должны ссылаться на несуществующую информацию (не существующую спецификацию).

• требования не должны ссылаться на неопределенные функциональные требования.

Однозначность. Если словесное толкование сложное, в помощь можно представить диаграмму, прототипы, формулы, формы.

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

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

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

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

Типы требований

• Функциональные средства

• Интерфейсы – описываются входы, получаемые из внешних систем и выходы, направляемые во внешние системы.

• Данные – входные и выходные данные системы, используемый формат, какие данные нужно сохранять, какой объем данных должен поступать в систему и из системы, с какой скоростью передачи, с какой точностью должны производится вычисления.

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

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

• Физическая среда – где будет функционировать оборудование, ограничения на окружающую среду.

• Безопасность – как осуществляется доступ к системе и управление её данными. Как производится дублирование данных.

• Документация – в каком виде будет представлена документация.

• Устранение неисправностей – как система реагирует на неисправность.

• Сопровождение

• План поставки версий – если требованиям назначены приоритеты, то временной график поставки версий тоже должен быть представлен.

Литература

• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с.

• Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001. — 544 с.

• Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с.

• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2008. — 368 с.

• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб.: Питер, 2004. — 320 с.

• Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — Пер. с англ. — СПб.: Символ-Плюс, 2001. — 304 стр.