tестирование dot com
Шрифт:
для исполнения тест-кейсов для новых функциональностей. Что
делать? (Ответ будет в одном из следующих разговоров.)
21. Придумайте аналогию из жизни, чтобы проиллюстрировать
слово "релиз".
22. Перечислите виды релизов.
23. Может ли быть в основном релизе код с зафиксированными
багами предыдущего релиза?
24. Если ответ на предыдущий вопрос положительный, то почему
мы не выпустили патч-релиз, а ждали следующего релиза?
25. Что означает номер релиза 11.44?
26.
релиза.
27. Что такое бранч CVS и для чего он нужен?
28. Назовите состояния бранча и условия для этих состояний.
29. Что такое процедура о неотложном ремонте багов и зачем она нужна?
30. Почему для бета-тестирования набирают народ из типичных
пользователей?
ЧАСТЬ 2
• ЦИКЛ ТЕСТИРОВАНИЯ ПО
• КЛАССИФИКАЦИЯ ВИДОВ
ТЕСТИРОВАНИЯ
цикл
ТЕСТИРОВАНИЯ ПО
• ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ
• ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ
• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
ока мы еще не остыли от цикла разработки, предлагаю не-
медленно рассмотреть цикл тестирования.
П
Поехали.
Отвлечемся от компьютеров и представим ситуацию, когда
нужно проверить, ну, например, свежекупленный десятире-
жимный пылесос. После того как агрегат вытащен из коробки,
берем "Инструкцию по использованию" и мытарим чудо техники,
пока все десять режимов не докажут свою лояльность и пре-
данность.
Если посмотреть на процесс более абстрактно, можно увидеть
три вещи, которые явились моделью пылесосного тестирования:
1. Прочитали, например, пункт 2п инструкции, чтобы понять,
как работает режим влажной уборки.
2. Мгновенно в уме составили план проверки влажной уборки:
а. Налить горячую воду в верхний бачок пылесоса.
б. Нажать на кнопку Power.
в. Нажать на кнопку Pressure.
г. И т.д. и т.п.
3. Осуществили проверку согласно плану.
131
132
Тестирование Дот Ком. Часть 2
Перейдем от тестирования пылесосов к тестированию ПО.
Цикл тестирования ПО состоит из трех этапов:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.
На любом из этапов может быть найден баг (как
документации), баг должен быть отремонтирован ответственным
товарищем (например, программистом или продюсером), и
качество ремонта должно быть сертифицировано тестиров-
щиком.
Свяжем цикл тестирования с циклом разработки:
1. Изучение и анализ предмета тестирования
начинаются перед утверждением спека (в завершение стадии
"Разработка дизайна продукта и создание документации") и про-
должаются на стадии "Кодирование".
2. Планирование тестирования
происходит на стадии "Кодирование".
3. Исполнение тестирования
происходит на стадии "Исполнение тестирования и ремонт багов".
Важный момент:
показанная связь между циклом разработки ПО и циклом тести-
рования — это всего лишь типичная модель взаимодействия
процессов, в то время как на практике, и особенно в стартапах,
встречается множество ситуаций, когда, например, нет спеков,
код уже написан и его срочно нужно протестировать навскидку,
нет времени на создание тест-документации и пр. Поэтому пред-
лагаю, чтобы мы, изучая цикл тестирования, абстрагирова-
лись от цикла разработки.
Что нам это даст? Гибкость, так как,
зная цикл тестирования как независимый процесс, мы сможем
легко связать его с любым циклом разработки ПО в любой ин-
тернет-компании.
Цикл тестирования ПО
133
Итак, независимый процесс, называемый циклом тестирования
ПО, состоит из трех стадий:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.
1. Изучение и анализ предмета тестирования
Вопрос: что можно протестировать в интернет-проекте?
Легитимные варианты ответа:
• интерфейс пользователя (например, что определенная кноп-
ка называется "Купить", а не "Кипуть");
• скорость работы веб-сайта (например, то, что при одно-
временной работе с сайтом 200 пользователей скорость за-