Ответы на вопросы для самопроверки из книги Савина Романа "Тестирование DOT COM или Пособие по жестокому обращению с багами в интернет-стартапах". Глава: "ЦИКЛ РАЗРАБОТКИ ПО"

Глава: "ЦИКЛ РАЗРАБОТКИ ПО"

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

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. Почему для бета-тестирования набирают народ из типичных пользователей?

Вопрос номер 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++) кода в машинный язык и создания исполняемых файлов);
  в веб-серверах;
  в базах данных и др.
• Отсутствие юнит-тестирования,
  т.е. тестирования кода самим программистом: "И вообще, почему я должен искать баги в своем коде, когда есть тестировщики?"
• Нереально короткие сроки для разработки

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

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

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

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

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

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

• улучшить качество,
• прикрыть спину,
• стать хорошим людям еще лучше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос номер 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 для процесса разработки ПО и релиза.

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

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

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

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

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

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

• приоритет багов, которые подлежат НРБ. Например, это могут быть только П1 баги;
• список лиц, имеющих право инициировать процесс НРБ;
• последовательность действий между лицами, участвующими в НРБ, например:

1. программист, извещенный о проблеме, фиксирует баг;
2. исправление кода заверяется одним из его коллег через рассмотрение кода (code review);
3. релиз-инженер делает билд для регрессивного тестирования;
4. тестировщик производит тестирование;
5. релиз-инженер делает патч-релиз на машину для пользователей;

• коммуникацию между лицами, участвующими в НРБ.

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

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

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