Классический процесс разработки программного обеспечения делится на 3 этапа: pre-production, production и post-production.

На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.

Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.

На этапе post-production — исправляются остальные баги.

К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.


Миф 1. Если исправление багов отложить на этап post-production, в скором времени количество багов вырастет, как снежный ком, и проект станет плохо прогнозируемым и плохо управляемым.

Управляемость проектом не будет потеряна, потому что:

1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д. Этот прогноз используется в работе отделом QA и менеджментом проекта. Более того, он регулярно корректируется с использованием актуальных данных. Так что ни о какой "плохой прогнозируемости" и "плохой управляемости" не может быть и речи.

2. Во время production отдел QA находит далеко не все баги, а только их часть. В проектах, в которых я принимал участие, их количество составляет от 30 до 40 процентов от общего числа багов. Причина этого проста — основные силы QA подключаются незадолго до того, как все фичи будут реализованы. Подключать их ранее не имеет смысла, потому что фичи ещё не сделаны, и нечего тестировать. Кроме того, ещё не готовы тест-кейсы, т.к. фичи находятся в работе, и представление продюсеров о них может меняться. Во время production отсутствуют необходимые условия для подключения большой команды тестеров.

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

Дальше: http://askofen.blogspot.ru/2013/08/blog-post_19.html

Здравствуйте, Кирилл.

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

Хотел поинтересоваться:

1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д.

А каким образом и какими методами это делается?

Здравствуйте, Эдуард!

Хотел поинтересоваться: А каким образом и какими методами это делается?

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

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

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

А я вот не могу согласиться с каждым словом. Вернее по всем пунктам есть замечания.

Возьмем например:

Миф 5. Если исправление багов откладывать на финальную стадию проекта, то невозможно автоматизировать тестирование, так как тесты бесты будут постоянно разломаны.

Всё прекрасно автоматизируется. Главное, чтобы фичу можно было пройти, и основной flow работал бы так, как запланировано. Как я уже писал, такие баги фиксятся в первую очередь. Без их фикса фича не принимается.

Не согласен. Да, все прекрасно автоматизируется, но не потому, что "основной flow работал". Для автоматизации тестов нет необходимости что бы хоть что-то работало. Более того, для автоматизации тестирования нет необходимости в существовании тестируемого кода. И наиболее правильный (IMHO) вариант, когда код тестов появляется до тестируемого кода. То что по настоящему нужно для автоматизации тестирования - это соглашение об интерфейсах.

Миф 4. Чем больше времени проходит между внесением дефекта и его исправлением, тем дороже исправление

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

Ну и т.д.

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

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

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

Вы рассматриваете процесс разработки с точки зрения разработчика, т.е. пытаетесь организовать его таким образом, чтобы он был удобен инженеру. Между тем, в разработке серьёзной программы принимают участие множество людей разных специальностей: бизнес-аналитики, маркетологи, продакт-менеджеры, менеджеры проекта, инженеры, тестеры, специалисты по пользовательскому интерфейсу, дизайнеры. Если речь идёт об игре, то добавьте с этому списку аудио дизайнеров, 3д моделлеров, продюсеров и т.д. и т.п. Кроме того, программу регулярно отсматривают бизнес-люди и независимые ревьюеры, которым просто необходим визуальный прогресс по запланированным фичам. Им важно "пощупать" фичу, чтобы понять, насколько её в таком виде можно продать клиентам. Чем раньше будут выявлены риски, связанные с неправильным дизайном фичи, тем лучше, т.к. могут быть внесены необходимые изменения.

Кроме того, на большом проекте в разработке принимает участие множество людей. На одном из проектов, в котором мне довелось принять участие, команда состояла из 100 человек. Из них было 40 или 50 инженеров. При таком размере команды адресовать баг тому инженеру, который разрабатывал подсистему, в которой произошла ошибка, не так-то просто. Это, конечно, делается. Но получается не всегда.

Так что, с точки зрения отдельно взятого разработчика, Вы правы - проще баг исправлять сразу, пока детали реализации фичи ещё содержатся в памяти. Однако с точки зрения проекта и команды в целом, это не так.