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

1. СТБ —это

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

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

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

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

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

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

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

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

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

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

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

9. Приложение (attachment) — это суперполезная вещь, так как служит графической (как правило) иллюстрацией бага.

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

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

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

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

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

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

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

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

1. Могут ли простые бумажные карточки или текстовый файл слу­жить в качестве СТБ?

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

Тестирование Дот Ком. Часть 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.

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

Кстати, тест приемки — это, как правило, эд хок-тестирование, при ко­тором мы проверяем, работают ли самые базовые вещи, как, напри­мер, создание нового эккаунта. Я рекомендую составить список с та­кими базовыми вещами, например:

Создай новый эккаунт

Войди в систему

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

Исполнение тестирования. Стадия 1: тестирование новых фича

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

Вопрос: Как мы тестируем новые фича?

Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем их. Попутно заносим баги. Спорим с программистами о приори­тетах этих багов. Закрываем эти баги. Одним словом, обычная суета сует.

Это в общем-то все насчет стадии 1 исполнения тестирования, но, поскольку нужно чем-то занять время, давайте поговорим о не­скольких нужных вещах:

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

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

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

Дата добавления: 2015-12-07