tестирование dot com

Краткое подведение итогов

1. Цель тестирования — это нахождение багов до того, как их най

дут пользователи.

2. Нехватка ресурсов не позволит стопроцентно протестировать

сколько-нибудь сложное ПО.

3. Не имеет никакого значения, сколько багов было найдено до

релиза.

4. Статистика багов, найденных после релиза, и ее последующий

анализ могут помочь идентифицировать проблемные участки

процесса разработки ПО. Сопоставление статистики от релиза к

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

таковая существует.

5. QA направлено на превентирование багов, тестирование — на

поиск багов.

6. Тестировщики одни не могут обеспечить качество ПО. Обеспе-

чение качества — это задача всех участников процесса раз-

работки ПО. Важными факторами, влияющими на качество,

являются отлаженность и настройки самого процесса разработки

ПО.

Вопросы и задания для самопроверки

1. У вас есть 5 функциональностей, и отведенного времени не хва-

тит, чтобы тщательно протестировать их все. На основании чего

вы расставите приоритеты в тестировании? Подсказка: помните

о счастье пользователя.

2. Петров нашел 50 багов до релиза, но пропустил 5 багов, которые

были найдены пользователем. Сидоров нашел 12 багов до

релиза, не пропустив ни одного. Кому дать премию?

3. Как должен поступить менеджер, чтобы решить вопрос с про-

блемой оплаты?

4. Придумайте аналогию, демонстрирующую разницу между ОА и

тестированием.

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

ТЕСТ-КЕЙСОВ

• ЧТО ТАКОЕ ТЕСТ-КЕЙС

• СТРУКТУРА ТЕСТ- КЕЙСА

• ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА •

ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА

• ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ •

ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА

• СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ

В ОДНОМ ТЕСТ-КЕЙСЕ?

• ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ

• ТЕСТ-КОМПЛЕКТЫ

• СОСТОЯНИЯ ТЕСТ-КЕЙСА

• А НАПОСЛЕДОК Я СКАЖУ

ы исполняем тестирование, т.е. непосредственно "рвем на

Мкуски" ПО, руководствуясь нашей профессиональной до-

кументацией — тест-кейсами (test case). Поговорим о формаль-

ной стороне эффективного тест-кейса и коснемся объединений

тест-кейсов — тест-комплектов (test suite).

Что такое тест-кейс

Допустим, что перед сборами на рыбалку мы составили следую-

щий список:

1. Удочка.

2. Коробка с запасными поплавками и леской.

3. Банка с червями.

35

Искусство создания тест-кейсов

37

4. Стакан граненый.

5. Бутылка "Абсолюта".

6. Огурец соленый.

Затем при деятельном участии жен, детей и котов мы наконец

собрались в дорогу и перед выходом взяли список и проверили

рюкзак на наличие каждого из 6 предметов.

Так вот.

Каждая из 6 строк списка — это и есть тест-кейс (test case).

Сам список является тест-комплектом (test suite).

Процесс придумывания и написания каждой строки списка

называется созданием тест-кейса (test case generation).

Процесс проверки рюкзака на наличие определенного пред-

мета — исполнением тест-кейса (test case execution).

Test case можно перевести как "тестируемая ситуация" и как

"оболочка для теста", оба перевода легитимны и представляют

собой идеальный союз для понимания места и значения тест-кей-

сов в этом жестоком мире.

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

результат, например "огурец соленый", т.е. тест-кейс может

полностью состоять только из ожидаемого результата.

Структура тест-кейса

Проблема в том, что для нахождения бага (что является смыслом

любого тестирования) кроме ожидаемого нам нужен и фактиче-

ский результат. В случае с огурцом мы просто заглядываем в

рюкзак и смотрим, на месте ли этот "фрукт". В случае же тести-

рования ПО, как правило, необходима инструкция, как прийти к

фактическому результату.

Пример

Допустим, тестировщику А. Боброву, который только что начал рабо-

тать в нашем стартапе www.testshop.rs, дали для исполнения следую-

щий тест-кейс:

"Оплата может быть произведена картой VISA". Сразу же

возникает по крайней мере две проблемы:

38

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

• для исполнения тест-кейса нужна тестировочная карта VISA,

которой у него нет;

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