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

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

те немедленно разобрались, в чем дело. Если проблема сломан-

ного билда (broken build) не решается в течение, скажем, 60 ми-

нут, то, согласно правилам нашей компании, С. Щетинин воз-

вращает на www.main.testshop.rs предыдущий билд, т.е. 58.

Тестировщик Антон Никонов получает радостное известие, что

баг #3221 был зафиксирован и отремонтированный код ждет его

на www.main.testshop.rs. Удостоверившись, что www.main.testshop.rs

имеет версию и билд 7.0-59, он исполняет шаги, указанные в

"Описании и шагах..." бага, и, удостоверившись, что значение

result стало равным 10, закрывает баг:

Атрибут: Resolution.

Значение:

"Fix is Verified".

Атрибут: Status.

Значение: "Closed".

Жизнь замечательных багов

255

А затем в качестве второй части регрессивного тестирования ис-

полняет, например, тест-кейс с картой MasterCard. Флоу с

MasterCard — это приоритетное флоу функциональности Оплата,

и неплохая идея проверить, что ремонт ситуации с VISA не сломал

флоу с MasterCard.

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

1. СТБ —это

• с одной стороны, хранилище багов, а

• с другой — средство коммуникации.

2. Баг — это в зависимости от контекста

• расхождение между фактическим и ожидаемым результатами

и/или

• запись (виртуальная карточка) в СТБ.

3. Настройки СТБ определяются процессом, а не наоборот.

4. Настройками СТБ и созданием эккаунтов ведает администратор

СТБ.

5. Занести баг может любой, у кого есть счет в СТБ и соответст-

вующая привилегия.

6. У бага в СТБ есть атрибуты, значения которых позволяют судить

о состоянии и истории бага.

7. Значения некоторых атрибутов присваиваются автоматически

(номер бага).

8. Мы никогда не заносим баг с кратким описанием "Ничего не

работает".

9. Приложение (attachment) — это суперполезная вещь, так как

служит графической (как правило) иллюстрацией бага.

10. У каждого открытого бага всегда есть держатель.

11. На интранете обязательно должна быть страничка "Кто ответ-

ственен за что".

12. Серьезность бага —это техническая категория.

13. Приоритет бага — категория, связанная с бизнесом.

14. Нет ни одного изменения бага, которое бы не стало достоянием

гласности.

15. Функциональность — это только одно из значений емкого тер-

мина фича.

16. Значения резолюции — это этапы жизни бага.

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

1. Могут ли простые бумажные карточки или текстовый файл слу-

жить в качестве СТБ?

2. Приведите пример формата значения атрибута "Шаги и ожи-

даемый результат".

256

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

3. Чем били по голове тех, кто заносил баг с кратким описанием

"Ничего не работает"?

4. Перечислите элементы веб-страницы и проблемы, с ними свя-

занные.

5. Как сделать графический файл с тем, что мы видим на экране

монитора?

6. Основная обязанность держателя бага.

7. Что должен проверить Verifier перед началом регрессивного

тестирования?

8. Приведите две части регрессивного тестирования. Нужно ли

проводить вторую часть, если первая не работает? Можно ли

закрыть баг уже после первой части, если ремонт был успешен?

9. В чем концептуальное различие серьезности и приоритета?

10. Кого мы обычно включаем в Notify list?

11. Дайте определение фича.

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

заново?

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

вам баги как "Not Reproducible'"?

14. Почему возникают ситуации, когда баг возвращается с резо-

люцией "Not a bug"?

15. Нарисуйте блок-схему процесса трэкинга багов.

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.

СТАДИЯ 1:

ТЕСТИРОВАНИЕ НОВЫХ ФИЧА

• TEST ESTIMATION (ТЕСТ-СМЕТА)

• ENTRY/EXIT CRITERIA (КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ)

• TEST PLAN (ТЕСТ-ПЛАН)

отя при разговоре о процессе разработки ПО мы перевели

Х "New Feature Testing" как "Тестирование новых компонен-

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

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

дующей очередности:

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

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

Сначала о стадии 1.

После того как код проинтегрирован, тест приемки пройден и код

заморожен, мы начинаем тестирование новых фича.