⚙️✅📕 Ответы на вопросы для самопроверки из книги «Тестирование Дот Ком» Романа Савина

Путеводитель в мире QA-инженерии всегда начинается с книг, рекомендованных сообществом и экспертами. Среди них – «Тестирование dot com» от Романа Савина, несмотря на свою давнюю дату выпуска. В ней скрыта ценная база знаний, даже если часть информации немного устарела. Меня вдохновила идея собрать и систематизировать ответы на вопросы для самопроверки из этой книги. Мне хочется поделиться этими знаниями с другими новичками, которым может быть полезна данная информация.

Прежде чем приступить к чтению этой статьи, хочу отметить, что я – начинающий QA инженер. Мой опыт в этой области пока ограничен, и я все еще изучаю и погружаюсь в мир обеспечения качества продукта. Эта статья отражает мои текущие знания, и я делюсь ими с целью не только усвоить материал глубже, но и помочь другим в начале их пути в QA. Прошу отнестись с пониманием к возможным ограничениям моего опыта и надеюсь, что этот материал будет полезен, несмотря на мою относительную новичковскую субъективно-несовершенную экспертизу :)

Раздел книги «Цель тестирования»

Вопрос № 1

У вас есть 5 функциональностей, и отведенного времени не хватит, чтобы тщательно протестировать их все. На основании чего вы расставите приоритеты в тестировании? Подсказка: помните о счастье пользователя.

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

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

Вопрос № 2

Петров нашел 50 багов до релиза, но пропустил 5 багов, которые были найдены пользователем. Сидоров нашел 12 багов до релиза, не пропустив ни одного. Кому дать премию?

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

Вопрос № 3

Как должен поступить менеджер, чтобы решить вопрос с проблемой оплаты?

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

Задание № 4

Придумайте аналогию, демонстрирующую разницу между QA и тестированием.

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

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

Раздел книги «Искусство создания тест-кейсов»

Вопрос № 1

Без какой части тест-кейс никак не может обойтись?

Ответ: тест-кейс никак не может обойтись без описания шагов, необходимых для выполнения теста (procedure). Если можно сказать еще об одной важной части, то это – ожидаемый результат (expected result). Исполнение тест-кейса должно обязательно завершаться сравнением вывода фактического результата и ожидаемого для выдачи заключения о наличии или отсутствии бага в проверяемой функциональности.

Вопрос № 2

Для чего в тест-кейсе нужны шаги?

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

Вопрос № 3

Два вида исхода исполнения тест-кейса. К какому исходу мы, как тестировщики, стремимся?

Ответ: как тестировщики, мы стремимся к положительному исходу (pass test), т. е. хотим убедиться, что фактическое поведение ПО соответствует заданным требованиям (фактический результат = ожидаемый результат).

Вопрос № 4

Что происходит, если состояние ПО не позволяет исполнить все шаги тест-кейса? Каковы наши действия?

Ответ: необходимо задокументировать это (написать bag-report) и сообщить об этом команде разработки для исправления проблемы. Исполнение тест кейса откладывается до устранения бага.

Вопрос № 5

Обоснуйте, почему у тест-кейса должна быть лишь одна тестируемая идея?

Ответ: чтобы обеспечить четкость и фокусировку на конкретном аспекте ПО. Но на практике во многих случаях имеет смысл включить в тест-кейс два или больше ожидаемых результатов (ОР) работы ПО, так как:

• у вас может просто не быть времени на написание, исполнение и поддержку двух тест-кейсов;
• сэкономленное время можно потратить на написание, исполнение и поддержку тест-кейса, которым мы бы проверили другой аспект ПО.
  

Если у нас есть один случай, когда можно совместить два ОР, то написание, исполнение и поддержка двух тест-кейсов не представляет труда. А что, если у нас появляются сотни дополнительных тест-кейсов? В результате такой экономии мы с течением времени создаем десятки новых тест-кейсов, которые помогают нам провести более тщательное тестирование.

Вопрос № 6

Перечислите полезные атрибуты тест-кейса и причину полезности каждого из них.

Ответ: полезные атрибуты тест-кейса могут включать в себя:

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

Вопрос № 7

Изменяется ли ID тест-кейса при изменении самого тест-кейса или переносе его в другой документ?

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

Вопрос № 8

Придумайте свой способ индексации тест-кейсов, например, частью ID может быть номер спека.

Ответ: способ индексации тест-кейсов может включать в себя версию ПО.

Вопрос № 9

Что такое data-driven тест-кейс? В чем заключается удобство поддержания такого тест-кейса?

Ответ: data-driven тест-кейс (буквально «управляемый данными») — это тест-кейс, который может использовать различные внешние исходные данные для выполнения одного и того же тестового сценария, т. е. в шагах самого теста-кейса действия прописаны обобщенно без привязки к тестовым данным. Удобство его поддержания заключается в возможности изменения исходных данных без изменения самих шагов тест-кейса.

Вопрос № 10

Как легкость в поддерживаемости тест-кейса позволяет сэкономить время?

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

Вопрос № 11

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

Ответ:

• зависимость тест-кейсов друг от друга;
• нечеткая формулировка шагов;
  
• нечеткая формулировка проверяемой идеи и/или ожидаемого результата.
  

Вопрос № 12

В чем удобство написания новых тест-кейсов в отдельный тест-комплект?

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

Вопрос № 13

Ожидается ли, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО?

Ответ: да, ожидаемо. Тест-кейсы могут не работать на 100% сразу после написания. Дело в том, что они создаются на основании спека (или, как это часто бывает, на основании устного пожелания заказчика), и так как мы физически не видим функциональности этого cпека (код еще не написан), то многие вещи нужно в буквальном смысле представить себе. Кроме того, сами спеки имеют баги.

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

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

Вопрос № 14

В чем проявляется родственность тест-кейсов, являющихся частью одного тест-комплекта?

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

Вопрос № 15

Приведите атрибуты шапки тест-комплекта.

Ответ:

• Author — автор тест-кейсов.
• Spec ID — номер (или иной уникальный ID) спека.
  
• Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека.
  
• Producer — продюсер (бизнес-аналитик), написавший спек.
  
• Developer — программист, пишущий код в соответствии со спеком.
  
• Overview — вкратце рассказывается, чему посвящен этот тест-комплект.
  
• GLOBAL SETUP and ADDITIONAL – здесь мы говорим о повторяющихся вещах, которые будем использовать в более чем одном тест-кейсе, и вообще о любой другой полезной информации для всего тест-комплекта.
  

Вопрос № 16

Состояния тест-кейса.

Ответ:

• состояние — «Новый» (new). Это первая редакция тест-кейса;
• состояние — «Измененный» (modified). Модификации, как правило, связаны с изменением спека, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке;
  
• состояние — «Более недействителен» (retired) – удаление определенной функциональности, элемента интерфейса пользователя и др., либо в других случаях, например, когда один тест-кейс дублирует другой.
  

Вопрос № 17

Почему не рекомендуется удалять тест-кейсы?

Ответ:

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

Вопрос № 18

Есть ли стандартная форма тест-кейса, за несоблюдение которой лишают премий и не приглашают на празднование Нового года?

Ответ: тестирование – это творческий подход, поэтому выбирать нужно ту форму тест-кейса, которая эффективно будет работать в вашей компании и в конкретной ситуации. Соблюдение установившихся стандартов в определенной компании помогает в унификации и понимании тест-документации в команде. Содержание конкретного тест-кейса — это отражение методологии нахождения багов применительно к конкретной ситуации.

Вопрос № 19

Разница между идеей тест-кейса и ожидаемым результатом.

Ответ: Идея тест-кейса — это то, что мы хотим протестировать, в то время как ожидаемый результат — это то, что мы ожидаем увидеть в результате выполнения теста.

Вопрос № 20

Напишите тест-кейс с тестируемой идеей «Я могу убедить свою жену в чем угодно» и ожидаемым результатом «Дорогой, поезжайте с Алексеем на рыбалку. Вы так редко с ним видитесь».

Ответ:

Подготовительная часть тест-кейса (тестовые данные):

• адрес доставки: ул. Садовая, д. 123, кв. 54;
• время доставки: 17:00 …;
  
• номер карты для онлайн-оплаты: 5328-…номер карты для онлайн-оплаты: 5328-…;
  

Шаги воспроизведения:

1. Заказать в любом онлайн-магазине цветов доставку букета на сумму от 10 до 15 $.
2. Заказать в любом суши-ресторане доставку сета cуши на сумму от 15 до 20$.
   
3. Заказать в любом СПА-центре сертификат на процедуры от 20 до 30$.
   
4. Принять заказанные товары согласно п.1-3.
   
5. Принять заказанные товары согласно п.1-3.
   
6. Вручить жене заказанные товары согласно п.1-3.
   
7. Сообщить жене «Мой друг с университета Алексей, едет на этих выходных на рыбалку и приглашает поехать вместе».
   
8. Ожидаемый результат: услышать ответ жены «Дорогой, поезжайте с Алексеем на рыбалку. Вы так редко с ним видитесь».
   

Вопрос № 21

Напишите тест-кейс с одной идеей и двумя ожидаемыми результатами. Используйте пример из жизни.

Ответ:

Идея тест-кейса: Проверка функциональности доставки сообщений в мессенджере.

Ожидаемый результат 1: Сообщение доставляется получателю в течение 10 секунд после отправки.

Ожидаемый результат 2: Сообщение отмечено как «прочитанное» получателем после открытия доставленного сообщения.

Шаги:

1. Открыть мессенджер под тестовым аккаунтом отправителя.
2. Выбрать тестовый контакт для отправки сообщения.
   
3. Набрать любой текст сообщения.
   
4. Нажать кнопку отправки сообщения.
   
5. Зафиксировать время отправки сообщения до секунд.
   
6. Открыть тестовый аккаунт получателя.
   
7. Проверить в тестовом аккаунте получателя, было ли сообщение доставлено.
   
8. Открыть сообщение
   
9. Проверить, что время доставки сообщения не превышает 10 секунд с момента отправки сообщения.
   
10. Проверить в тестовом аккаунте отправителя, отмечено ли сообщение как «прочитанное».
    

Раздел книги «Цикл разработки ПО»

Вопрос № 1

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

Ответ:

стадии цикла разработки ПО обычно включают в себя:

1. Идея.
2. Требования.
   
3. Проектирование.
   
4. Разработка.
   
5. Тестирование.
   
6. Релиз.
   
7. Поддержка.
   

Вопрос № 2

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

Ответ:

Баг, найденный на уровне идеи, — это самый дешевый баг, соответственно баг, найденный после релиза, — это самый дорогой баг. Причем убытки от последнего, как правило, не поддаются объективной оценке

Стоимость бага — это расходы компании, чтобы найти баг и исправить его до передачи кода пользователю.

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

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

Вопрос № 3

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

Ответ: плохую спецификацию определяют следующие вещи:

1. Отсутствие акцента на деталях и их четкого определения.
2. Допущение неверного толкования требований.
   
3. Противоречивость внутри спека и с другими спеками.
   
4. Отсутствие логической взаимосвязи компонентов.
   
5. Неполнота охвата предмета.
   
6. Несоответствие нормативным актам.
   
7. Несоответствие деловой практике.
   

Вопрос № 4

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

Ответ: продюсер (бизнес-аналитик) не должен давать технических инструкций в спеке, потому что его задача – описать требования и ожидания от продукта, не вдаваясь в технические детали, чтобы дать разработчикам свободу выбора технических решений.

Вопрос № 5

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

Ответ: утверждение спека нужно для обеспечения понимания и согласия всех заинтересованных сторон (заказчика, разработчиков, тестировщиков и т. д.) требований к продукту.

Вопрос № 6

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

Ответ: замораживание спека означает временную фиксацию требований и запрет на их изменение для обеспечения стабильности процесса разработки.

Вопрос № 7

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

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

Вопрос № 8

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

Ответ: причины появления багов в коде могут быть разными:

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

Вопрос № 9

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

Ответ: юнит-тест — это тестирование отдельных компонентов (юнитов) программы для проверки их корректности работы. Тестирование производится самим программистом.

Вопрос № 10

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

Ответ: инспекция кода — это процесс рассмотрения и анализа программного кода для выявления ошибок, несоответствий стандартам и потенциальных проблем. Она помогает выявить сложности в коде и проблемные участки, позволяя исправить их до того, как они приведут к серьезным ошибкам в работе программы.

Вопрос № 11

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

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

Вопрос № 12

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

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

Вопрос № 13

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

Ответ: компиляторы и интерпретаторы обычно ловят синтаксические ошибки, ошибки типов данных, некоторые ошибки логики.

Вопрос № 14

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

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

Вопрос № 15

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

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

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

Вопрос № 16

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

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

Вопрос № 17

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

Ответ: Тест приемки — это проверка ПО на соответствие заданным требованиям перед его внедрением или передачей заказчику. Это проверка, проводимая заказчиком или его представителями.

Вопрос № 18

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

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

Вопрос № 19

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

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

Вопрос № 20

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

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

Вопрос № 21

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

Ответ: аналогия из жизни для «релиза» может быть, например, запуск новой модели автомобиля на рынок.

Вопрос № 22

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

Ответ: виды релизов могут включать в себя:

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

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

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

Вопрос № 23

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

Ответ: в основном релизе не должно быть кода с известными критическими багами, однако это может зависеть от сроков и значимости ошибок.

Вопрос № 24

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

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

Вопрос № 25

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

Ответ: номер релиза 11.44 может указывать о трех вещах:

• о том, что последний основной релиз является 11 по счету;
• о четырех дополнительных релизах, выпущенных ПОСЛЕ 11 релиза;
  
• о 4 заплаточных релизах, выпущенных ПОСЛЕ 11 релиза.
  

Вопрос № 26

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

Ответ: CVS необходима для совместной работы над кодом, управления версиями кода, отслеживания изменений, возвращения к предыдущим версиям кода, если новая будет некачественной.

Вопрос № 27

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

Ответ: бранч в CVS – это создание отдельной ветки разработки кода для работы над определенной функциональностью или решением проблем без влияния на основную ветку разработки.

Вопрос № 28

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

Ответ: у бранча есть три состояния:

• открытый, т. е. в нем можно сохранять файлы;
• условно открытый, в нем можно сохранять файлы, НО при определенном условии, например, программист должен написать номер реального бага в комментарии при сохранении файла;
  
• закрытый, в этом случае файл может быть сохранен в соответствии с процедурой о неотложном ремонте багов.
  

Вопрос № 29

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

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

Процедура о неотложном ремонте багов должна содержать:

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

– программист, извещенный о проблеме, фиксирует баг;

– исправление кода заверяется одним из его коллег через рассмотрение кода (code review);

– релиз-инженер делает билд для регрессивного тестирования;

– тестировщик производит тестирование;

– релиз-инженер делает патч-релиз на машину для пользователей;

• коммуникацию между лицами, участвующими в НРБ. Например, в начале и конце каждого из этапов ответственное лицо отвечает всем на последний е-мейл этой цепочки. Причем в начале этапа посылается е-мейл типа «Начал делать билд для регрессивного тестирования. Примерный срок до завершения операции — 30 минут». В конце этапа посылается е-мейл типа «Билд для регрессивного тестирования завершен. Тестировщики. Ау!».

Вопрос № 30

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

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

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

Продолжение следует ... :)