подлецов, которые считают, что чем запутаннее код, тем лучше?

11. Для чего нужно замораживание кода?

12. Каковы преимущества постоянной интеграции кода?

13. Какие баги ловятся компайлером (интерпретатором)?

14. Какие баги НЕ ловятся компайлером (интерпретатором)?

15. Почему файлы с тест-комплектами нужно хранить в CVS?

16. Почему рассмотрение тест-кейсов выгодно не только компании,

но и самому тестировщику?

17. Что такое тест приемки?

18. Что случается, если тест приемки не пройден?

19. В чем отличия тестирования новых функциональностей от рег-

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

20. У нас после каждого релиза появляются тест-кейсы, которые мы

должны исполнять в последующих релизах для регрессивного

тестирования. Соответственно наступает момент, когда столько

тест-кейсов для регрессивного тестирования, что нет никакой воз-

можности их исполнить в пределах временных рамок без ущерба

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

делать? (Ответ будет в одном из следующих разговоров.)

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

слово "релиз".

22. Перечислите виды релизов.

23. Может ли быть в основном релизе код с зафиксированными

багами предыдущего релиза?

24. Если ответ на предыдущий вопрос положительный, то почему

мы не выпустили патч-релиз, а ждали следующего релиза?

25. Что означает номер релиза 11.44?

26. Обоснуйте необходимость CVS для процесса разработки ПО и

релиза.

27. Что такое бранч CVS и для чего он нужен?

28. Назовите состояния бранча и условия для этих состояний.

29. Что такое процедура о неотложном ремонте багов и зачем она нужна?

30. Почему для бета-тестирования набирают народ из типичных

пользователей?

ЧАСТЬ 2

• ЦИКЛ ТЕСТИРОВАНИЯ ПО

• КЛАССИФИКАЦИЯ ВИДОВ

ТЕСТИРОВАНИЯ

цикл

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

• ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ

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

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

ока мы еще не остыли от цикла разработки, предлагаю не-

медленно рассмотреть цикл тестирования.

П

Поехали.

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

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

жимный пылесос. После того как агрегат вытащен из коробки,

берем "Инструкцию по использованию" и мытарим чудо техники,

пока все десять режимов не докажут свою лояльность и пре-

данность.

Если посмотреть на процесс более абстрактно, можно увидеть

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

1. Прочитали, например, пункт 2п инструкции, чтобы понять,

как работает режим влажной уборки.

2. Мгновенно в уме составили план проверки влажной уборки:

а. Налить горячую воду в верхний бачок пылесоса.

б. Нажать на кнопку Power.

в. Нажать на кнопку Pressure.

г. И т.д. и т.п.

3. Осуществили проверку согласно плану.

131

132

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

Перейдем от тестирования пылесосов к тестированию ПО.

Цикл тестирования ПО состоит из трех этапов:

1. Изучение и анализ предмета тестирования.

2. Планирование тестирования.

3. Исполнение тестирования.

На любом из этапов может быть найден баг (как в ПО, так и в

документации), баг должен быть отремонтирован ответственным

товарищем (например, программистом или продюсером), и

качество ремонта должно быть сертифицировано тестиров-

щиком.

Свяжем цикл тестирования с циклом разработки:

1. Изучение и анализ предмета тестирования

начинаются перед утверждением спека (в завершение стадии