А в это время

• программист пишет код на стадии кодирование v. 2.0;

• продюсер разрабатывает дизайн продукта на стадии ди­зайн и документация v. 3.0;

• маркетолог, идущий, как всегда, в авангарде, обдумывает идеи на стадии идея v. 4.O.

Таким образом, мы рассмотрели полностью цикл разработки версии 1.0 проекта www.testshop.rs. Дальше все идет по ана­логии.

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

Итак, большая картина цикла разработки ПО.

Большая картина — это всего лишь модель, и в реальной жизни все так гладко, красиво и гармонично не бывает. На­пример, во время стадии идея v. 2.0 маркетолог может генери­ровать как краткосрочные идеи цикла v. 2.0, так и долгосрочные цикла v. 4.0 и v. 5.0.

В завершение беседы о цикле разработки ПО давайте • поставим акцент на паре важных моментов,

Цикл разработки ПО

• сделаем одну оговорку,

• остановимся на одной ценной мысли и

• ответим на практические вопросы.

Пара важных моментов:

1. Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже в электронном виде) и доступны на интранете.

2. Такие вещи, как утверждение спека, рассмотрение тест-кейсов или инспекция кода, — это не какие-то полицей­ские мероприятия, призванные подрезать крылышки твор­ческим и свободным личностям. Совершенно наоборот — это средства, позволяющие

• улучшить качество,

• прикрыть спину,

• стать хорошим людям еще лучше.

Оговорка:

В аквариумах интернет-компаний кроме продюсеров, програм­мистов, тестировщиков и начальников обитает еще много других разновидностей не менее полезных особей, таких, как

• веб-дизайнеры;

• системные администраторы и администраторы баз данных;

• народ из службы поддержки и маркетинга;

• бухгалтеры (хлещущие чай);

• спецы по железу (хлещущие пиво) и др.

Мы их всех любим, ценим и, как видите, не забываем. Просто нужно было сделать допустимое упрощение для удобства вос­приятия нового материала и, например, свести написание кода только к программистам, в то время как JavaScript-колд обычно пишется веб-дизайнерами.

Ценная мысль:

Акт планирования, будь то спек, дизайн кода, тест-кейс или до­кумент о неотложном ремонте бага, — это возможность посмот­реть в будущее, предугадать и предотвратить возможные про­блемы и/или баги.

Эффективное планирование — это одна из важнейших со­ставляющих процесса разработки ПО.

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

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

1. Перечислите стадии цикла разработки ПО.

2. Какой баг дороже: пойманный не во время написания спека или во время тестирования?

3. Перечислите болезни спеков.

4. Почему продюсер не должен давать в спеке технических инст­рукций?

5. Для чего нужно утверждение спека?

6. Для чего нужно замораживание спека?

7. Почему спеки нужно хранить в CVS?

8. Перечислите и прокомментируйте причины появления багов кода.

9. Что такое юнит-тест?

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

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. Осуществили проверку согласно плану.

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

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

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

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