что такое превентирование багов

BYTEX BLOG

Андерклокинг — снижение частоты работы оборудования.

Баг (дефект) — недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов — важность той или иной ошибки в ПО:

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

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

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

Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

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

Обеспечение качества (Quality Assurance, QA) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

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

Ошибка (англ.Error) – действие, которое порождает неправильный результат.

Сбой (англ.Failure) – несоответствие фактического результата работы компонента или системы ожидаемому результату.

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing) — тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing) — тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

Классификация по целям и задачам:
Функциональное тестирование — проверка корректности работы функциональности приложения.
Нефункциональное тестирование — проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование — проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование — проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование — тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса — тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости — тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных — тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов — совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование — тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование — формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование — тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности — тестирование способности приложения выполнять свои функции в заданных условиях.
Тестирование восстанавливаемости — тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности — исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование — исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов/
Тестирование масштабируемости — исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование — исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование — исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование — исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ граничных значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Дымовое тестирование (англ. Smoke test) — короткий цикл тестов для подтверждения, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.

Исследовательское (ad-hoc) тестирование — это разработка и выполнения тестов в одно и то же время, что является противоположностью сценарного подхода.

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

Матрица соответствия требований (англ. Traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Операционное тестирование (англ. Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы.

Предугадывание ошибки (англ. Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

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

Серьезность (англ. Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.

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

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

Альфа-тестирование (англ. Alpha testing) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

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

Релиз-кандидат или RC (англ. Release candidate), Пре-релиз, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. Post-release to manufacturing) — издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

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

Тест-дизайн (англ. Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

Тест-план (англ. Test Plan) — это документ, описывающий весь объем работ по тестированию, а также оценки рисков с вариантами их разрешения.

Тестирование взаимодействия (англ. Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

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

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

Чек-лист (англ. Check list) — это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Z-конфликт (англ. Z-fighting) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

Источник

Выдержки из книги Романа Савина Тестирование DOT COM

Хочу поделиться основными выдержками и тем, что я отметил для себя основного из книги Савина Тестирование DOT COM.

Вот книга кому интересно

Определение бага Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result). Мы имеем баг при наличии любого фактического результата, отличного от ожидаемого. Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:

1. Мы узнаем (или уже знаем) ожидаемый результат;

2. Мы узнаем (или уже знаем) фактический результат;

3. Мы сравниваем пункт 1 и пункт 2
Основными источниками ожидаемого результата являются:1. Спецификация.

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

Цель тестирования — это нахождение багов до того, как их найдут пользователи. Другими словами, вклад тестировщика в счастье пользователя — это приоритет в нахождении багов.

QA — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи.

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

• QA призвано улучшить ПО через улучшение процесса разработки ПО;

• тестирование — через обнаружение багов.

Тест кейс шаги — это инструкция по вводу,

исполнение шагов — это ввод;

ожидаемый результат — это ожидаемый вывод;

фактический результат — это фактический вывод.

Исполнение тест-кейса завершается сравнением вывода факти-ческого и вывода ожидаемого.

Исход исполнения тест-кейса (test case result) Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух:
1. Положительный исход (PASS), если ФР равен ОР, либо
2. Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!

Иногда возникает ситуация, когда мы заблокированы (test case execution is blocked), так как не можем пройти ВСЕ шаги тесткейса. Например, мы не можем продвинуться дальше, если кнопки “Завершить заказ” из шага не существует на соответствующей веб-странице. В таком случае мы рапортуем баг (в данном случае баг об отсутствии кнопки “Завершить заказ”).

Атрибуты тест-кейса
1 УНИКАЛЬНЫЙ ID (Unique ID)ID должен быть уникальным в пределах не только документа, содержащеготест-кейс (об этом документе позже), но и всего департамента

2 ПРИОРИТЕТ ТЕСТ-КЕЙСА (Test Case Priority)Это важность тест-кейса. Важность отражается по шкале от 1 до п,где 1 — это высший приоритет, а п — это низший приоритет.Думаю, что рационально делать п = 4.

3 ИДЕЯ (IDEA)Это описание конкретной вещи, проверяемой тест-кейсом (в даль-нейшем эту конкретную вещь мы также будем называть “идеятест-кейса”).

4 ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ (SETUP and ADDITIONAL INFO)В подготовительную часть тест-кейса могут включаться:• данные о существующем эккаунте пользователя (legacy useraccount) или инструкции по созданию нового эккаунта (newuser account);• другие данные, используемые в тест-кейсе, например атри-буты используемой кредитной карты;

• запросы к базе данных (SQL queries), используемые в тест-кейсе;

• комментарии в помощь тестировщику, например о нюансах, которые могут встретиться при исполнении тест-кейса;

• другие вещи, облегчающие исполнение и поддержку тест-кейса (о поддержке мы еще поговорим).

5 ИСТОРИЯ РЕДАКТИРОВАНИЯ (Revision History)

Тест-комплекты

Совокупность тест-кейсов (находящихся, как правило, в одном
документе), которые проверяют
• какую-то определенную часть нашего интернет-проекта
и/или
• определенный спек

Атрибуты

Author:
Spec ID:
Priority:
Producer:
Developer:
OVERVIEW:
GLOBAL SETUP and ADDITIONAL INFO:
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека. Сам ID дол-
жен быть линком к спеку в локальной сети (об этом мы еще
поговорим).
Priority — приоритет тест-комплекта (например, от 1 до 4), обыч-
но соответствующий приоритету спека.
Producer — продюсер, написавший спек.
Developer — программист, пишущий код в соответствии со спеком. Искусство создания тест-кейсов

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

Хороший спек, как и хороший закон, отличают следующие вещи:
1. Акцент на деталях и их четкое определение.
2. Забота о недопущении неверного толкования.
3. Непротиворечивость внутри спека и с другими спеками.
4. Логическая взаимосвязь компонентов.
5. Полнота охвата предмета.
6. Соответствие нормативным актам.
7. Соответствие деловой практике.

Спеки имеют следующую очередность статусов:
1. Во время написания они имеют статус Черновик (Draft).
Продюсер пишет спек.
2. После написания и до утверждения — Ожидание утвер-
ждения (Approval Pending).
Спек написан, и назначается совещание (meeting) с про-
граммистами и тестировщиками по его обсуждению или
же просто им посылается е-мейл с приложением.

3. После утверждения — Утверждено (Approved или Final).
Если на митинге все закричали “Ура!” или получены по-
ложительные отзывы от всех реципиентов, утвержденный
спек немедленно выкладывается на один из серверов в ло-
кальной сети, чтобы быть доступным любому лицу внутри
компании, которому положено его видеть. Если же спек не
принят, то все начинается с пункта 1

Юнит-тестирование (unit testing) — это тестирование, произ-
водимое самим программистом. Здесь нужно подчеркнуть, что
неправильный подход к введению юнит-тестирования вызо-
вет справедливое раздражение программистов, так как за тес-
тирование платят тестировщикам, а отсутствие требований к
юнит-тестированию вообще увеличит стоимость багов.

Давайте рассмотрим большую картину цикла разработки ПО в
динамике.
Сначала обобщим знания об игроках, их ролях и стадиях цикла с
их участием.
Игрок
Роль
Стадия
Маркетолог Генерирует идеи и составляет MRD Идея
Продюсер Разрабатывает и документирует
дизайн продукта Дизайн
и документация
Программист Переводит дизайн продукта на язык
программирования Кодирование
Ремонтирует баги Тест и ремонт
Готовится к исполнению
тестирования Кодирование
Исполняет тестирование Тест и ремонт

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

Свяжем цикл тестирования с циклом разработки:
1. Изучение и анализ предмета тестирования
начинаются перед утверждением спека (в завершение стадии
Разработка дизайна продукта и создание документации) и про-
должаются на стадии “Кодирование”.
2. Планирование тестирования
происходит на стадии “Кодирование”.
3. Исполнение тестирования
происходит на стадии “Исполнение тестирования и ремонт багов”.

Классификация видов тестирования по признаку
состоит из следующих элементов.
Перечисляем:

1. По знанию внутренностей системы:
• черный ящик (black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).

2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/perfor-
mance testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).

3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).

4. По времени проведения тестирования:
• до передачи пользователю — альфа-тестирование (alpha-
testing);
– тест приемки (smoke test, sanity test или confidence test);
– тестирование новых функциональностей (new feature
testing);

– регрессивное тестирование (regression testing);
– тест сдачи (acceptance or certification test);
• после передачи пользователю — бета-тестирование (beta
testing).

5. По критерию “позитивности” сценариев:
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).

6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or end-
to-end testing).

7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi
automated testing).

8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).

По знанию внутренностей системы

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

БЕЛЫЙ ЯЩИК (white box)
также известен под именами Стеклянный ящик (glass/clear box),
Открытый ящик (open box) и даже Никакой ящик (по box).
В отличие от “Черного ящика” при подходе “Белый ящик” тес-
тировщик основывает идеи для тестирования на знании об
устройстве и логике тестируемой части бэк-энда.
Таким образом, при белоящичном тестировании сценарии созда-
ются с мыслью о том, чтобы протестировать определенную часть
бэк-энда, а не определенный паттерн поведения пользователя.

Тестировочное покрытие (test coverage) состоит из двух вещей:
а. Покрытие возможных сценариев.
б. Покрытие исполнения тест-кейсов.

СЕРЫЙ ЯЩИК (gray/grey box)
Это подход, сочетающий элементы двух предыдущих подходов, это
• с одной стороны, тестирование, ориентированное на поль-
зователя, а значит, мы используем паттерны поведения поль-
зователя, т.е. применяем методику “Черного ящика”;
• с другой — информированное тестирование, т.е. мы знаем,
как устроена хотя бы часть тестируемого бэк-энда, и активно
используем это знание.

По объекту тестирования
Функциональное тестирование (functional testing);
Тестирование интерфейса пользователя (UI testing);
Тестирование локализации (localization testing);
Тестирование скорости и надежности (load/stress/ per-
formance testing);
• Тестирование безопасности (security testing);
• Тестирование опыта пользователя (usability testing);
• Тестирование совместимости (compatibility testing).

ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ (functional testing)

ТЕСТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ
(UI (читается как “ю-ай”) testing)
Это тестирование, при котором проверяются элементы интерфей-
са пользователя. Мы рассмотрим все основные элементы

ТЕСТИРОВАНИЕ СКОРОСТИ И НАДЕЖНОСТИ
(load/stress/performance testing)
Это проверка поведения веб-сайта (или его отдельных частей)
при одновременном наплыве множества пользователей.

ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ (security testing)
Тестирование безопасности — это множество вещей, суть кото-
рых заключается в том, чтобы усложнить условия для кражи —
кражи данных, денег и информации.

ТЕСТИРОВАНИЕ ОПЫТА ПОЛЬЗОВАТЕЛЯ
(usability testing)
Юзабилити-тестирование часто проводится путем привлечения
группы потенциальных пользователей с целью собрать впечатле-
ния от работы с системой.
Зачастую опыт пользователя тестируется самими продюсерами
во время написания спека и создания макетов. Есть также про-
фессиональные юзабилити-инженеры.

ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ
(compatibility testing)
Это проверка того, как наш веб-сайт взаимодействует с
• “железом” (например, модемами) и
• ПО (браузерами/операционными системами) наших поль-
зователей.

По субъекту тестирования
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).

АЛЬФА-ТЕСТИРОВЩИК (alpha tester)
Это сотрудники компании, которые профессионально или непро-
фессионально проводят тестирование: тестировщики, програм-
мисты, продюсеры, бухгалтеры, сисадмины, секретарши. В стар-
тапах накануне релиза нередко все работники, включая Харито-
ныча, сидят по 16 часов кряду, пытаясь найти непойманные баги.
БЕТА-ТЕСТИРОВЩИК (beta tester)
Это нередко баловень судьбы, который не является сотрудником
компании и которому посчастливилось пользоваться новой сис-
темой до того, как она станет доступна всем остальным. За бета-
тестирование иногда даже платят деньги (вспомните пример с 50
долл. в час за юзабилити-тестирование).

По времени проведения тестирования
ДО передачи пользователю — альфа-тестирование (alpha
testing):
• тест приемки (smoke test, sanity test или confidence test);
• тестирования новых функциональностей (new feature
testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance или certification test),
ПОСЛЕ передачи пользователю — бета-тестирование (beta
testing)

По критерию
позитивности сценариев
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).

По степени изолированности
тестируемых компонентов
компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or
end-to-end testing).

Компонентное тестирование (component testing) — это тестиро-
вание на уровне логического компонента. И это тестирование
самого логического компонента.
Интеграционное тестирование (integration testing) — это тести-
рование на уровне двух или больше компонентов. И это тестиро-
вание взаимодействия этих двух или больше компонентов.
Системное (или энд-ту-энд) тестирование (system or end-to-end
testing) — это проверка всей системы от начала до конца.

По степени автоматизированности
тестирования
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное / полуавтоматизированное тестирование
(semi automated testing).

8. По степени подготовки к тестированию
• тестирование по тест-кейсам (documented testing);
• интуитивное тестирование (ad hoc testing).

Подготовка к тестированию с точки зрения тестировщика
включает:
1. Написание новых тест-кейсов и/или
2. Изменение существующих тест-кейсов и/или
3. Удаление существующих тест-кейсов.
Иногда требуется создание/модификация тест-тулов, но об этом
мы здесь говорить не будем, так как фактически тест-тулы — это
чистой воды программирование, облегчающее исполнение тест-кейсов.

Постулат “Software has bugs” (“ПО содержит баги”)

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

Методы генерирования тестов:
1. Черновик-чистовик (dirty list-white list);
2. Матричная раскладка (matrices);
3. Блок-схемы (flowchart).178
Тестирование Дот Ком. Часть 3
Методы отбора тестов:
1. Оценка риска (risk estimate);
2. Эквивалентные классы (equivalent classes);
3. Пограничные значения (boundary values).

1. Черновик-чистовик (dirty list-white list);
В процессе (и/или после) прочтения спека, эксплоринга ПО и/или
получения информации о ПО другим способом, не анализируя и
отдавшись вдохновению и фантазии, мы просто набрасываем на
лист бумаги

2 МАТРИЧНАЯ РАСКЛАДКА
Одна из прелестей матричного подхода заключается в наглядно-
сти — мы видим перед собой таблицу со структурированными
вариантами сценариев, и нам удобно комбинировать их в более
сложные сценарии или непосредственно переносить их в тест-
кейсы.

3. БЛОК-СХЕМЫ
Блок-схема — это
графическая презентация некого процесса.

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

Методы отбора тестов
1. Оценка риска (risk estimate).
2. Эквивалентные классы (equivalent classes).
3. Пограничные значения (boundary values).

1 Оценка рентабельности использования ресурсов и перенапровление ресурсов в нужное русло

2. Эквивалентные классы (equivalent classes).
эквивалентный класс — это одно или больше значений ввода,
к которым ПО применяет одинаковую логику.

3. Пограничные значения (boundary values).
Пограничные значения — это конкретные предельные значения, образующие водораздел между эквивалентными классами. Для каждого эквивалентного класса может быть лишь один из трех вариантов: а. Есть только нижний предел (класс 5). б. Есть нижний и верхний пределы (класс 2, класс 3, класс 4). в. Есть только верхний предел (не рассматриваемый в данном примере класс, который ограничен только сверху гипотети ческим отрицательным значением, непосредственно пред шествующим классу 1). Пограничным тестированием (boundary testing) называется применение метода тестирования пограничных значений.

Итак, концептуально СТБ (система трекинга багов) — это инфраструктура, позволяющая

• модифицировать информацию о багах.

Существует множество профессиональных СТБ — от бесплатной Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test Director by Segue), и естественно, что интернет-компании используют для трэкинга багов не тетрадки или текстовые файлы, а именно специальное ПО, непосредственно созданное для трэкинга багов. О таком ПО и процессе трэкинга багов мы и поговорим сегодня.

Пример Процесса После того как баг заносится в СТБ, его статус автоматически становится “Open”; после того как баг зафиксирован и регрессивное тестирование подтвердило успех починки, мы меняем статус на “Closed”; если же тот же баг, после того как мы его закрыли, был найден снова, то мы меняем “Closed” на “Re-Open”.

Атрибуты бага

BUG NUMBER (НОМЕР БАГА) Каждому новому багу СТБ автоматически присваивает уникальный, следующий по порядку номер. Например, подходите вы к программисту и спрашиваете: “Слушай, браза, как там 1232 поживает?”

SUMMARY (КРАТКОЕ ОПИСАНИЕ) Краткое описание — это максимально информативное и сжатое описание проблемы. Как правило, текстовое поле для краткого описания не превышает 100 символов и в эти 100 символов (включая пробелы) нужно уместить информацию, достаточную для понимания сути проблемы. Кстати, то, как тестировщик формулирует краткое описание, наглядно говорит о его профессионализме.

Пример самого плохого Summary “Ничего не работает”. За такое Summary раньше били по голове канделябром, и хотя сейчас времена другие, но все равно, пожалуйста, никогда, никогда не пишите в кратком описании ничего подобного. Почему поле для краткого описания такое короткое? Потому что баги, занесенные в СТБ, выглядят примерно так, списком, на значения которого можно кликнуть мышкой и получить полную информацию по конкретным багам:

Итак, в кратком описании сжато и информативно излагаем суть проблемы.

DESCRIPTION AND STEPS TO REPRODUCE (ОПИСАНИЕ И ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ) Это многострочное текстовое поле. Я пользуюсь следующим форматом для заполнения этого атрибута: Description: Полезная информация о баге: описание, комментарии, нюансы и т.д.

Steps to reproduce: Конкретные шаги для воспроизведения проблемы.

Bug: Фактический результат.

Expected: Ожидаемый результат.

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

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

SUBMITTED BY (АВТОР БАГА) СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение “Submitted by ” — это нередактируемый текст с именем товарища, занесшего баг в СТБ (товарищ далее именуется автором бага). Как правило, автором бага является тестировщик.

DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА) Как и в случае с Submitted by, СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение “Date submitted” — это нередактируемый текст с датой и временем, когда баг был занесен в СТБ своим отцом — автором.

ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА) Каждый открытый баг в каждый конкретный момент имеет своего конкретного держателя (Owner). Держатель бага — это участник процесса разработки ПО, на котором лежит ответственность сделать следующий шаг на пути к закрытию бага. Варианты следующего шага определяются процессом.

Когда баг заносится в СТБ, то автор бага обязательно должен выбрать имя из списка ниспадающего меню “Assigned to ” (СТБ выдаст ошибку, если имя не выбрано). Список “Assigned to ” состоит из имен всех пользователей, кто имеет эккаунты в СТБ. Например, мое имя пользователя в СТБ может выглядеть как г savin.

VERSION FOUND (ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ) Это ниспадающее меню с версиями веб-сайта, автор бага обязан выбрать значение, соответствующее номеру версии продукта, в которой был найден баг.

BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ) Это небольшое (примерно 10 символов) текстовое поле, куда автор бага обязан вбить номер билда, в котором был найден баг.

VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ) Это ниспадающее меню с версиями веб-сайта. После того как программист починил баг, он должен передать этот баг далее (релиз-инженеру), для того чтобы в итоге Verifier произвел регрессивное тестирование (у нас будет подробное объяснения процесса через 5 минут). Программист обязан выбрать номер версии, соответствующий бранчу в CVS, куда он направил отремонтированный код. Version Fixed может иметь, как одно из значений, “N/A ” (Not applicable — “к данной ситуации неприменимо”), которое продюсер обязан выбрать, зафиксировав баг, найденный в спеке.

BUILD FIXED (БИДД С ПОЧИНЕННЫМ КОДОМ) Это небольшое (например, 10 символов) текстовое поле, которое заполняется в то же время, что и Version Fixed, т.е. после починки бага и помещения починенного кода в CVS. В Build Fixed программист обязан указать номер следующего билда, который подхватит исправленный код из CVS.

• номер последнего билда на www.main.testshop.rs равен 114,

• билд-скрипт для нового билда стартует в 16:00 и

• программист направил код в CVS в 15:30, то билд 115 должен содержать исправленный код из CVS и, следовательно, программист должен вбить в Build Fixed значение “115”.

Очень очевидный и очень важный момент, о которым мы уже говорили: перед началом регрессивного тестирования Verifier должен удостовериться, что версия и билд на тест-машине соответствуют значениям атрибутов Version Fixed и Build Fixed для данного бага.

COMMENTS (КОММЕНТАРИИ) Это многострочное текстовое поле, куда любой имеющий счет в СТБ и соответствующую привилегию может занести свои комментарии, пояснения, уточнения и т.д. • о баге и/или • своих действиях в отношении бага. В некоторых случаях комментарий должен быть обязательным для заполнения, например когда программист возвращает баг тестировщику, так как считает, что это вовсе не баг.

SEVERITY (СЕРЬЕЗНОСТЬ БАГА) Форма: ниспадающее меню со значениями от О до С4 (51—4) включительно. Содержание: серьезность бага — это степень воздействия бага (magnitude of impact) на ПО, исходя из принадлежности бага к определенной технической категории.

С1— КРИТИЧЕСКИЙ Критический системный сбой — ситуация, когда какая-то часть ПО на машине для пользователей “рушится” — например, нажимаете на кнопку “Поиск” и получаете ошибку “HTTP Error 500 Internal server error”. Потеря данных (data loss) — чаще всего это происходит, когда данные: а) не достигают базы данных либо б) незапланированно удаляются из нее.

Например: а) при регистрации е-мейл пользователя не вставляется в опреде ленную колонку определенной таблицы базы данных; б) при обновлении пользователем адреса на фронтенде старый адрес удаляется из базы данных. Проблема с безопасностью — например, когда после логина пароль виден как часть URL, так что кто-то может подсмотреть пароль и использовать его в своих корыстных целях. При современном состоянии дел в Интернете, когда 4% монетарных транзакций осуществляется мошенниками, безопасность — вещь первостепенная.

С2 — ЗНАЧИТЕЛЬНЫЙ Веб-сайт “зависает” — одна из основных бед интернет-проектов, например, нажимаешь на кнопку “Купить”, и следующая страница грузится, и грузится, и грузится… Как правило, после таких “загрузов” очень хочется попробовать веб-сайт конкурента. Баг блокирует кодирование, тестирование или использование вебсайта — ситуация, когда работа тестировщика (и/или программиста) и/или использование веб-сайта не могут быть продолжены, так как на одном из этапов появляется проблема, превентирующая дальнейшее продвижение.

Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте. Термин “блокирование” также связан с понятием “обходной путь” (workaround), а вернее, с отсутствием этого пути. Например, согласно тесткейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную.

СЗ — УМЕРЕННЫЙ Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены. СА — КОСМЕТИЧЕСКИЙ Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).

PRIORITY (ПРИОРИТЕТ БАГА) Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно. Содержание: приоритет бага — это показатель важности бага для бизнеса компании. Кстати, многие товарищи путают приоритет и серьезность. Коренное различие между ними кроется в том, что серьезность отражает технический аспект бага, а приоритет — коммерческий. Серьезность — это категория абсолютная. Приоритет — это категория относительная. Так, если сайт рушится (crash), то это С1, и мы не можем,

Примеры П1 —П2 —всепонятно. ПЗ — каждая стадия цикла разработки ПО имеет свои запланированные временные рамки. Таким образом, если релиз должен состояться 16 марта, тодо 16 марта все ПЗ должны быть зафиксированы из акрыты. П4 — такие баги фиксируются, если у программиста есть время.

Например, в какой-нибудь старой версии браузера интернет/эксплорер (Internet Explorer — IE) не работает какое-нибудь суперзамысловатое флоу, которое вряд ли может прийти кому-либо в голову. У каждой компании есть свои заморочки, но, как правило, все баги П1, П2 и ПЗ должны быть зафиксированы и закрыты до релиза. В случае с ПЗ, если не хватает времени, может приниматься решение о релизе, содержащем баг, с условием, что в течение такого-то периода времени (дни) этот баг будет зафиксирован, протестирован и патчрелиз выпущен на машину для пользователей.

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

CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ) Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любое изменение бага отражается в нередактируемом многострочном текстовом поле в следующем формате: • дата и время изменения (date and time of change); • имя лица, изменившего баг (who changed); • название измененного атрибута (what was changed); • предыдущее значение атрибута (previous value); • новое значение атрибута (new value).

STATUS (СТАТУС) Это ниспадающее меню со значениями: • Open (Открыт), • Closed (Закрыт), • Re-Open (Повторно открыт). Значение Open присваивается багу автоматически при занесении бага. Закрыть баг можно только при соответствующей резолюции (об этом через минуту). Значение Re-Open выбирается тестировщиком, когда он возрождает к жизни закрытый баг. Почему возникают ситуаци

RESOLUTION (РЕЗОЛЮЦИЯ) Это ниспадающее меню со значениями: Not Assigned (не приписан) Assigned (приписан) Fix in Progress (баг ремонтируется) Fixed (баг отремонтирован) Build in Progress (билд на тест-машину в процессе) Verify (проведи регрессивное тестирование) Fix is Verified (ремонт был успешен) Verification Failed (ремонт был неуспешен) Can’t Reproduce (не могу воспроизвести) Duplicate (дубликат) Not a bug (не баг) 3rd party bug (не наш баг) No longer applicable (поезд ушел)

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

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

Исполнение тестирования состоит из двух стадий, идущих в следующей очередности:

1. Тестирование новых фича (new feature testing);

2. Регрессивное тестирование (regression testing).

• Test Estimation (тест-смета).

• Entry/Exit Criteria (критерий начала/завершения).

• Test Plan (тест-план).

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

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

Другие же бросают куски кода в проект, как грязь на стену, считают юнит тестирование вещью, не подобающей для компьютерного гения, и не склонны кооперироваться ни с кем, кроме виртуальных солдат игры Halo. Следовательно, во втором случае мы должны заложить больше времени на наше тестирование; • будет ли интеграция нашего ПО с ПО наших бизнес-парт неров — вендоров (vendor), например интеграция с ПО платежной системы. Тест-конфигурация выглядит так: наша тест-машина “разговаривает” с их тест-машиной. Соответственно если что-то не в порядке с их тест-машиной, то проблема решается сложнее, чем при локальном тестировании, когда вы заносите баг и наш программист его ремонтирует. В случае с их тест-машиной

TestPlan (тест-план)

1. Название тест-плана, имя автора и номер версии. Например «Тест-план проекта “Новые алгоритмы для поиска”». Автор Т. Черемушкин. Версия 2. 2. Оглавление с разделами тест-плана: Например Введение стр.

2 Документация с требованиями к ПО стр. 3 и т. д.

3. Введение, в котором мы приводим информацию о сути и истории тестируемого проекта.

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

5. Фича, которые будут тестироваться, перечисляем и, если нужно, комментируем. Каждой фича назначается приоритет.

6. Фича, которые НЕ будут тестироваться, перечисляем и объясняем, почему НЕ будут тестироваться. Например, частью спека #9172 “Улучшение безопасности платежных транзакций” являются требования к скорости работы веб-сайта (performance). Допустим, у нас нет ни специалиста, ни ПО для тестирования скорости работы, и если мы не собираемся их нанять и приобрести, то указываем, чтоперформанс тестироваться не будет, так как нет ресурсов.

7. Объем тестирования — виды тестирования, которые мы будем проводить, и разъяснения к ним. Например “Системное тестирование будет исполняться для проверки всего флоу оплаты, начиная от добавления книги в корзину и заканчивая проверкой значений базы данных и подтверждением от тест-машины вендора”.

8. Тест-документация — перечисление тест-документации, которая должна быть создана для данного проекта Например “Тест-комплектпо тестированию опека #1288. Тест-комплект по тестированию спека #3411”.

9. Тест-тулы — функциональности тест-тулов, которые должны быть созданы для тестирования проекта.

10. Критерий начала/завершения — те самые критерии, о кото рых мы говорили минуту назад: • критерий начала подготовки к тестированию; • критерий завершения подготовки к тестированию; • критерий начала исполнения тестирования; • критерий завершения исполнения тестирования.

11. Допущения — список допущений, которые мы сделали при составлении данного тест-плана и которые сделаем при тестиро вании. Например, мы допускаем (предполагаем), что код будет заморожен в срок, без задержки.

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

13. “Железо” и ПО — список и конфигурации “железа” и ПО, которые будут использоваться при тестировании.

14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/ продолжено. Например, к условию приостановки можно отнести количество П1 багов, при котором (и/или после которого), по мнению автора (-ров) тест-плана, дальнейшее продолжение тестирования не имеет смысла (например, 7 П1). Соответственно условием возобновления должно быть количество оставшихся П1 багов (после ремонта и регрессивного тестирования), которое позволяет возобновить тестирование (например, 2 П1).

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

16. Тренинг — тренинг, необходимый для данного проекта. Например, при соответствующей ситуации нужно указать, что для создания тесткейсов тестировщику необходимо прослушать семинар “Банковская система США”.

17. Расписание — сроки, имеющие отношение к тестированию данного проекта:

• дата замораживания спеков;

• дата начала подготовки к тестированию;

• дата завершения подготовки к тестированию;

• дата интеграции и замораживания кода;

• дата начала тестирования новых фича;

• дата завершения тестирования новых фича;

• дата начала регрессивного тестирования;

• дата завершения регрессивного тестирования.

18. Оценка риска — предположение о том, как и что может пой ти по неправильному пути и что мы в этом случае предпримем. Например, если мы не успеваем закончить тестирование (не выполняем требование “Условия завершения”, например, “все тест-кейсы исполнены”) в срок, то придется задерживаться на работе и приходить в офис в выходные и праздники. Кстати, если народ приходит в выходные и праздники, то компания должна, по крайней мере, кормить его обедом.

19. Прочие положения — вещи, не вошедшие в тест-план, о которых неплохо было бы упомянуть.

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

21. Приложения — например, расшифровка терминов и аббревиатур, используемых в тест-плане. Это все о тест-планах и о первой стадии исполнения тестирова

Регрессивное тестирование как второй этап исполнения тестирования — это проверка того, что изменения, сделанные в ПО (для того, чтобы мир увидел новые фича), не поломали старые фича.

1. Выбор тест-комплектов для регрессивного тестирования.

2. Решение проблемы противоречия между ограниченными ресурсами (например, время на регрессивное тестирование) и перманентно у

Первый вопрос: “Как узнать, какие части ПО могут быть поломаны?” С одной стороны, как мы уже не раз говорили, в сложной системе, которой является более или менее серьезный веб-сайт, во многих случаях сверхсложно определить, где и как откликнется изменение кода, с другой — мы все-таки можем предполагать: • к какой части ПО принадлежат новые фича

(например, фича из спека #5419 “Новые функциональности для Корзины” принадлежат к “Корзине”) и • какие старые фича напрямую зависят от части ПО с новыми фича (например, компонент “Оплата” использует данные (по ценам книг), которые передаются ей компонентом “Корзины”). Решение следующее: Первой группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие часть ПО, к которой принадлежат новые фича. Например, при новых фича для “Корзины” в первую группу идут все тест-комплекты, непосредственно тестирующие “Корзину”.

Второй группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие старые фича, которые зависят от части ПО с новыми фича. Например, при новых фича для “Корзины” во вторую группу мы можем отнести тест-комплекты, проверяющие “Оплату”. Рациональное объяснение: если даже программист НЕ сломал ничего, есть большая вероятность того, что код фича, напрямую зависящей от измененной части ПО, также нуждается в модификации (о необходимости которой и продюсер, и программист могли просто… забыть).

Выводы

1 Тест-смета необходима для приведения к одному знаменателю потребностей компании и возможностей тестировщиков.

2. Каждый этап тестирования начинается/заканчивается при наступлении условия начала/завершения.

3. Тест-план — это документ, обобщающий и координирующий тестирование.

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

5. Из всех способов решения проблемы асинхронизации ресурсов и объема регрессивного тестирования наем новых людей самый простой и недалекий.

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

Источник