Ответы на вопросы из главы "Цикл разработки ПО"

Вопрос номер 1

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

1. Идея.

2. Разработка дизайна продукта и создание документации.

3. Кодирование ( в смысле создание кода).

4. Исполнение тестирования и ремонт багов.

5. Релиз.

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

Баг пойманный во время тестирования - дороже, т.к. на него уже "поработали" и программист и тестер.

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

Ошибки в спеке появляются в случае отклонения содержания спека от следующих пунктов:

1. Акцент на деталях и их четкое определение.

2. Забота о недопущении неверного толкования.

3. Непротиворечивость внутри спека и с другими спеками.

4. Логическая взаимосвязь компонентов.

5. Полнота охвата предмета.

6. Соответствие нормативным актам.

7. Соответствие деловой практике.

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

Некоторые продюсеры убеждены, что спеки должны давать программистам указания по сугубо техническим аспектам кодирования, как, например, об установлении связей между таблицами в базе данных или о названиях функций в коде. Если они не понимают всех проблем, вытекающих из этого порочного подхода, и слушать никого не хотят, предложите им самим написать весь код. Скорее всего, они откажутся...

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

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

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

Замораживание спека применяется для предотвращения следующих ситуаций:

1.Спек может быть изменен по-тихому.

2. Изменения к спеку не утверждены программистом и тестировщиком.

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

CVS "си-ви-эс" Concurrent Version System — система по согласованным версиям.

CVS — вещь многофункциональная сейчас она нам будет полезна для следующего:

1. С помощью CVS продюссер может сохранять версии спека и всегда вернуться к старым редакциям.

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

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

а.Одна из частых причин, по которым в ПО появляются баги кода, — этоневерное толкование спека (misinterpretation) — ситуация, когда программисты и/или тестировщики, работающие со спеком, понимают по-своему то, что пытался донести до них продюсер.

б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

в. Отсутствие опыта

Программист может просто не знать, как нужно сделать правильно.

г. Пренебрежение стандартами кодирования

д. Сложность системы

Современные интернет-проекты отличаются такой сложностью, что мозг простого смертного порой просто не в состоянии проанализировать все последствия создания/изменения/удаления

кода и предугадать появление проблемы.

е. Баги в ПО третьих лиц, т.е. баги

в операционных системах; в компайлерах (compiler — ПО для переведения (например, C++) кода в машинный язык и создания исполняемых файлов); в веб-серверах; в базах данных и др.Цикл разработки ПО 89

ж. Отсутствие юнит-тестирования,

т.е. тестирования кода самим программистом: "И вообще, почему я должен искать баги в своем коде, когда есть тестировщики?"

з. Нереально короткие сроки для разработки

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

Юнит-тестирование (unit testing) — это тестирование, производимое самим программистом. Здесь нужно подчеркнуть, что неправильный подход к введению юнит-тестирования вызовет справедливое раздражение программистов, так как за тестирование платят тестировщикам, а отсутствие требований к юнит-тестированию вообще увеличит стоимость багов.

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

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

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

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

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

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

Необходимость в замораживании кода вызвана тем, что продукт (в данном случае код) должен быть в каком-то устойчивом виде, чтобы его проверили.

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

При постоянной интеграции кода баги интеграции ловятся на ранней стадии, значит и стоят такие баги меньше

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

Компилятор ловит баги синтаксиса.

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

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

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

Главные преимущества хранения тест-кейсов в CVS:

• отсутствие возможности случайного удаления файла;

• присутствие возможности возвратиться к предыдущим версиям файла;

• файл хранится на сервере, и каждый, кому нужно (и кто имеет право), может взять его для исполнения тестирования, изменения и удаления существующих или включения дополнительных тест-кейсов.

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

Полезность рассмотрения тест-кейсов заключается в том, что во многих случаях продюсеры и программисты дают новые идеи для тестирования и/или корректируют допущенные неточности.

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

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

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

Если тест приемки не пройден, то программисты и релиз-инженеры совместно работают над поиском причины. Если проблема была в коде, то код ремонтируется, интегрируется и над ним снова производится тест приемки. И так по кругу, пока тест приемки не будет пройден.

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

После того как новые функциональности протестированы, наступает очередь исполнения "старых" тест-кейсов. Этот процесс называется регрессивным тестированием (regression testing), которое проводится для того, чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают. Регрессивное тестирование выполняется по разработанным ранее тест-кейсам. Для новых функциональностей пишутся свои тест-кейсы

20. У нас после каждого релиза появляются тест-кейсы, которые мы должны исполнять в последующих релизах для регрессивного тестирования. Соответственно наступает момент, когда столько тест-кейсов для регрессивного тестирования, что нет никакой возможности их исполнить в пределах временных рамок без ущерба для исполнения тест-кейсов для новых функциональностей. Что делать? (Ответ будет в одном из следующих разговоров.)

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

Тарелка борща на столе - это релиз борща.

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

1. Релиз (major release) - стадия в цикле разработки ПО, идущая за стадией тестирование и ремонт багов, т.е. передача пользователям кода новой версии нашего ПО. Как правило обозначается целыми числами, например 7.0.

2. Дополнительный релиз (minor release) - ситуация, когда после основного релиза планово выпускается новая функциональность или изменяется/удаляется старая. Он не связан с багам, обозначается например 7.1.

3. Заплаточный релиз (patch release) - когда после обнаружения и ремонта бага выпускается исправленный код. Как правило обозночается сотыми, например 7.11.

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

"... может получиться ситуация, когда баг, патч для которого уже был выпущен на машину для пользователей в предыдущем релизе, вновь появляется в следующем релизе. Чтобы избежать таких казусов, тестировщики придерживаются железного правила: на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности."

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

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

Номер релиза 11.44 говорит о том, что:

1. Последний основной релиз является одиннадцатым по счету.

2. О четырех дополнительных релизах, выпущенных после одиннадцатого релиза

3. О четырех заплаточных релизах, выпущенных после одиннадцатого релиза.

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

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

В CVS файлы хранятся в репозитарии, при этом

а) каждый раз, когда мы кладем файлы в репозитарии,

-не нужно менять имени файла;

-мы можем комментировать, что было изменено в этом файле;

- CVS автоматически присваивает файлу номер редакции(версии), уникальный для этого файла;

- CVS связывает номер версии файла, комментарий к изменениям, имя изменившего и время изменения в одну запись ( при желании можно увидеть всю историческую последовательность записей);

б) если Дима взял из репозитария файл, то Митя не может его оттуда взять, пока Дима не положит его обратно.

Поставив СVS мы имеем:

- все версии файла, каждая из которых кроме уникального номера версии имеет еще и запись об изменениях.

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

-возможность сравнить содержание файла в разных редакциях.

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

Ветвь в системах управления версиями — направление разработки, независимое от других. Ветвь представляет собой копию части хранилища (например, одного каталога), в которую можно вносить изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные — после неё.

Системы управления версиями предоставляют инструменты для манипуляции ветвями, прежде всего создание ветви и слияние изменений с другой ветвью.

• файлы, созданные вплоть до момента релиза версии 1.0, были основой, т.е. виртуальным стволом (trunk), нашего ПО;

• из этого ствола мы могли создать виртуальную ветвь (или бранч, от англ. branch) под названием "версия 1.0", которая включала бы все файлы версии 1.0 в редакциях (версиях) на момент, когда мы сказали "Стоп " для версии 1.0. Мы говорим "Стоп" после того, как код написан и готов для интеграции и тестирования; • таким образом, у нас появились бы ствол и одна ветвь;

• программисты, пишущие код для версии 2.0, должны были модифицировать код ствола (нарисунке — пунктиром);

• и когда код версии 2.0 был бы дописан, мы создали бы еще одну ветвь и назвали ее "версия 2.0 "; • таким образом, у нас был бы ствол, из которого сначала рос бы бранч версии 1.0 и затем бранч версии 2.0;

• начиная работать над кодом релиза версии 3.0, мы снова работаем со стволом (на рисунке — пунктиром);

• и т.д.

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

У бранча есть три состояния: 1) открытый, т.е. в нем можно сохранять файлы; 2) условно открытый, в нем можно сохранять файлы, НО при определенном условии, например, программист должен написать номер реального бага в комментарии при со- хранении файла; 3) закрытый. В этом случае файл может быть сохранен в соответствии с процедурой о неотложном ремонте багов (о процедуре через минуту).

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

Если баг критический (например, невозможно совершить покупку), то нужно отремонтировать его и выпустить патч-релиз как можно быстрее. Для такого срочного ремонта нужен формальный документ: процедура о неотложном ремонте багов (Emergency Bug Fix Procedure).

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

Перед тем как мы сделаем основной "официальный" релиз, т.е. откроем новый код всем пользователям, мы откроем новый код лишь ограниченной группе пользователей, которые нам его и протестируют. Эти пользователи (или "бета-тестировщики" — beta testers) должны являться представителями целевой аудито- рии (target group), для удовлетворения потребностей которой и был затеян весь сыр-бор от идеи до поддержки. Бета-тестиров- щики служат подопытными кроликами, ценность которых заклю- чается в том, что они, являясь типичными пользователями, будут делать с бета-версией веб-сайта те же вещи, что и остальные пользователи после официального релиза, и, следовательно, зара- нее столкнутся с непойманными (нами) багами, о которых они и сообщат в нашу компанию. Наша интернет-компания отремонти- рует эти баги и выпустит официальный релиз, более качествен- ный, чем бета.

#тестирование