Тестирование. Часть 1.

ЧТО ТАКОЕ БАГ

Баг (bug) - это отклонени фактического результата (actual result) от ожидаемого результата (expected result).

Три условия жизни и процветания бага:

1. Известен фактический результат;

2. Известен ожидаемый результат;

3. Известно, что резульата из пункта 1 не равен результату из пункта 2.

Любое тестирование - это поиск багов.

Основные источники ожидаемого результата:

1. Спецификация.

2. Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение.

Спецификация ( или spec) - это детальное описание того, как должно работать ПО. В большинстве случаем баг- это отклонение от спецификации.

Функциональный баг (functional bug или баг обыкновенный) - баг, вскормелнный на несоответствии фактической работы кода и функционального спека.

Feature Request - запрос на улучшение.

ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED

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

Концепции:

1) 100% проверка ПО в реальных программах невозможна, поэтомуцель тестирования это свести к минимуму просочившиеся баги.

2) Критерий эффективности тестирования это не количество багов, найденных до релиза, а качественная работа программного продукта, и количество багов найденых после релиза.

Баги делятся на 4 приоритета. К 4 приоритету относятся самые незначительные баги. Допустим у нас есть два тест-кейса: один 1-го приоритета и другой 3-го приоритета, оба тестируют некую функциональность А, и есть время для исполнения только одного из них. Естественно, что мы выберем тест-кейс 1-го приоритета. Приоритезация тестирования полезна при регрессивном тестировании.

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

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

Pattern - шаблон, тенденция.

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

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

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

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

ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ

Тест-кейс (test-case) - это профессиональная документсация, руководствуясь которой выполняется тестирование.2. Это инструмент тестировщика, преднозначенный для документирования и проверки одного или более ожидаемых результатов.

Тест-комплект (test-suite) - объединение тест-кейсов.

Test-case generation - процесс создания тест-кейса.

Test-case executive исполнение тест-кейса.

Главная и неотъемлимая часть тест-кейса - это ожидаемый результат.

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

Шаги тестирования - инструкция по вводу.2. Это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату.

Каждый тест-кейс исполнение которого завершено дает нам одно из двух:

1. Положительный исход (PASS), если ФР равен ОР.

2. Отрицательный исход (FAIL), если ФР не равен ОР, найден баг.

Уникальный ID (Unique ID) - ID должен быть уникальным не только в перделах документа, содержащего тест-кейс, но и всего депортамента качества.

Идея (IDEA) - это описание конкретной вещи, проверяемой тест-кейсом (эту вещь будем называть "идея тест-кейса"). (Например ожидаемый результат является "10" - тут первая цифра (1- Visa, 2- MasterCard, 3- Switch), вторая цифра - флаг успеха (0- успех, 1 ошибка). 10 - транзакция картой Visa была успешной.). В начале тест-кейса следуен написать "оплата может быть произведена любой картой Visa."

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

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

В подготовительную часть тест-кейса могут включаться:

- данные о существующем аккаунте пользователя (legacy user account) или инструкции по созданию нового аккаунта (new user account);

-другие данные, используемые в тест-кейса, например атрибуты используемой кредитной карты;

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

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

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

История редактирования (Revision History) для того, чтобы иметь сведения о рождении истории развития каждого тест-кейса, мы ведем лаконичный журнал изменений, где отражаем: кто? что? зачем? когда? почему?

Атибуты истории редактирования:

-Created on <date> by <name> - тест-кейс создан -дата, кем.

-Modified on <date> by <name> - тест-кейс изменен дата, кем.

-Change - Что, зачем и почему было изменено. В наших примерах мы не печатаем слово change, а просто заполняем значение этого атрибута в поле справа от "Created on" или "Modified on".

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

Maintainability(поддерживаемость) - означает, насколлько легко и просто можно изменить тест-кейс при изменениях в ПО.

Для улучшения поддерживаемости тест-кейса нужно:

1. Сделать тест-кейс data-driven.

2. Не описывать шаги по явно очевидным сценариям ( например логин).

3. Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса (например, имя товара).

4. Вынести во внешний документ повторяющиеся сценарии ( например, семь шагов оплаты).

2 или больше ожибаемых результатов в одном тест-кейсе - это нормальная практика. Во многих случаях, когда несколько ожидаемых результатов просятся в один тест-кейс, нужно проверить снаружи и изнутри или на front end и back end.

Недостатки, которые нужно выжигать из тест-кейсов:

1. Зависимость тест-кейсов друг от друга.

2. Нечеткая формулировка шагов.

3. Нечеткая формулировка идеи и/или ожидаемого результата.

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

2. Перечисляющиеся в тест-кейсе шаги должны быть объективно четкими и ясными. Нужно помнить, что:

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

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

3. а) не рекомендуется отсылка к внешнему документу.

б) нужно помнить, что суть секции IDEA - это объяснение идеи тест-кейса.

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

Совокупность тест-кейсов, которые проверяют

-какую-то определенную часть нашего интернет-проекта (например оплату) и/или

-определенный спек (например, спек Рассфлка пользователям е-мейлов на основании историй заказов) называют тест-комплектом (test case suite).

Что происходит в жизни?

-получаем новый спек;

-создаем новый файл, в котором создаем новые тест-кейсы для этого нового спека;

-исполняем новые тест-кейсы с их одновременной модификацией.

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

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

Рекомендуется не удалять тест-кейсы насовсем.

#тестирование