Классический
процесс разработки программного
обеспечения делится на 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 заводит баг и помечает его, как критический. Этот баг тоже фиксится, поскольку он мешает проверить работоспособность фичи до конца.
Миф 2. Если не исправить баги сразу, то список багов надо постоянно поддерживать в актуальном состоянии, оценивать их, анализировать их. Чем больше живёт баг, тем больше сил на него тратит ПМ.
Все баги должны вноситься в систему контроля багов всегда. Оценивать и анализировать баги — это и есть прямая и непосредственная обязанность продюсеров и менеджеров проекта. Продюсеры смотрят, насколько критичны баги с точки зрения фичи (мешают они закрыть фичу или нет), а менеджеры проекта смотрят, чтобы критичные баги были бы закрыты к очередному майлстоуну.
Миф 3. Чем больше в программе багов, тем дороже обходится починка каждого конкретного бага из-за того, что, во-первых, появляются наведённые баги, а во-вторых, находить причины дефектов трудно, т.к. дефект с высокой вероятностью может быть вообще где угодно.
Сложность починки бага определяется не количеством багов в программе, а сложностью самой программы, объёмом имеющегося кода и наличием подходящих инструментальных средств. Например, если значительная часть программы написана на скриптовом языке, и у вас нет подходящего отладчика для этого скриптового языка, то причины многих багов в скрипте будет найти сложно, т.к. вам придётся довольствоваться логированием и той информацией, которую Вы можете получить, заглянув в код интерпретатора скрипта. Если же вам не доступен исходный код интерпретатора, то сложность починки бага возрастёт ещё.
С другой стороны, если у вас есть наведённый баг, который блокирует приёмку фичи, то этот баг (и его прародитель) будет исправлен во время production'а, т.к. в противном случае фича не будет принята. Если же баг не препятствует приёмке фичи, то нет никакого смысла фиксить его прямо сейчас. Он может быть спокойно пофикшен и на стадии post-production, когда под это дело выделено время.
Миф 4. Чем больше времени проходит между внесением дефекта и его исправлением, тем дороже исправление, так как:
1) Разработчик уже забыл код, и ему надо заново в нём разбираться.
2) Тестировщик уже забыл, как воспроизводить дефект, и ему надо заново разбираться в шагах воспроизведения (которые могли быть записаны не совсем точно) и готовить окружение для воспроизведения.
Очень похоже на описание ситуации, когда над проектом работает маленькая команда, и баги не документируются, так что тестер должен помнить способ воспроизведения бага, а разработчик — помнить свой код.
На серьёзных проектах все баги вносятся в систему контроля багов по определённому формуляру, который включает:
1) адекватное название бага;
2) шаги для воспроизведения;
3) фичу и под-фичу, во время проверки которой проявился баг;
4) скриншоты;
5) стек вызова (если произошёл креш или ассерт);
6) лог;
7) и многое-многое другое.
Если описание бага не содержит какой-либо важной информации, то баг возвращается тестеру для того, чтобы он дополнил описание.
Кроме того, на больших проектах нередко получается так, что баг вынужден исправлять не тот программист, который писал код фичи. Это происходит по нескольким причинам:
1) сложно установить, кто писал данный код (хотя и можно);
2) тот разработчик уже занят исправлением других багов.
Конечно, когда есть такая возможность, то баг отсылается автору фичи. Но часто такой возможности нет, или процесс выяснения занимает достаточное время, что его нецелесообразно тратить.
Миф 5. Если исправление багов откладывать на финальную стадию проекта, то невозможно автоматизировать тестирование, так как тесты бесты будут постоянно разломаны.
Всё прекрасно автоматизируется. Главное, чтобы фичу можно было пройти, и основной flow работал бы так, как запланировано. Как я уже писал, такие баги фиксятся в первую очередь. Без их фикса фича не принимается.
На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.
Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.
На этапе post-production — исправляются остальные баги.
К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.
Миф 1. Если исправление багов отложить на этап post-production, в скором времени количество багов вырастет, как снежный ком, и проект станет плохо прогнозируемым и плохо управляемым.
Управляемость проектом не будет потеряна, потому что:
1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д. Этот прогноз используется в работе отделом QA и менеджментом проекта. Более того, он регулярно корректируется с использованием актуальных данных. Так что ни о какой "плохой прогнозируемости" и "плохой управляемости" не может быть и речи.
2. Во время production отдел QA находит далеко не все баги, а только их часть. В проектах, в которых я принимал участие, их количество составляет от 30 до 40 процентов от общего числа багов. Причина этого проста — основные силы QA подключаются незадолго до того, как все фичи будут реализованы. Подключать их ранее не имеет смысла, потому что фичи ещё не сделаны, и нечего тестировать. Кроме того, ещё не готовы тест-кейсы, т.к. фичи находятся в работе, и представление продюсеров о них может меняться. Во время production отсутствуют необходимые условия для подключения большой команды тестеров.
3. Если фича работает не так, как нужно, то это не баг, а не сделанная фича. В таком виде она не принимается у программиста, и он должен сделать так, чтобы она работала, как и было запланировано. Если во время работы фичи происходит крэш или ассерт, то отдел QA заводит баг и помечает его, как критический. Этот баг тоже фиксится, поскольку он мешает проверить работоспособность фичи до конца.
Миф 2. Если не исправить баги сразу, то список багов надо постоянно поддерживать в актуальном состоянии, оценивать их, анализировать их. Чем больше живёт баг, тем больше сил на него тратит ПМ.
Все баги должны вноситься в систему контроля багов всегда. Оценивать и анализировать баги — это и есть прямая и непосредственная обязанность продюсеров и менеджеров проекта. Продюсеры смотрят, насколько критичны баги с точки зрения фичи (мешают они закрыть фичу или нет), а менеджеры проекта смотрят, чтобы критичные баги были бы закрыты к очередному майлстоуну.
Миф 3. Чем больше в программе багов, тем дороже обходится починка каждого конкретного бага из-за того, что, во-первых, появляются наведённые баги, а во-вторых, находить причины дефектов трудно, т.к. дефект с высокой вероятностью может быть вообще где угодно.
Сложность починки бага определяется не количеством багов в программе, а сложностью самой программы, объёмом имеющегося кода и наличием подходящих инструментальных средств. Например, если значительная часть программы написана на скриптовом языке, и у вас нет подходящего отладчика для этого скриптового языка, то причины многих багов в скрипте будет найти сложно, т.к. вам придётся довольствоваться логированием и той информацией, которую Вы можете получить, заглянув в код интерпретатора скрипта. Если же вам не доступен исходный код интерпретатора, то сложность починки бага возрастёт ещё.
С другой стороны, если у вас есть наведённый баг, который блокирует приёмку фичи, то этот баг (и его прародитель) будет исправлен во время production'а, т.к. в противном случае фича не будет принята. Если же баг не препятствует приёмке фичи, то нет никакого смысла фиксить его прямо сейчас. Он может быть спокойно пофикшен и на стадии post-production, когда под это дело выделено время.
Миф 4. Чем больше времени проходит между внесением дефекта и его исправлением, тем дороже исправление, так как:
1) Разработчик уже забыл код, и ему надо заново в нём разбираться.
2) Тестировщик уже забыл, как воспроизводить дефект, и ему надо заново разбираться в шагах воспроизведения (которые могли быть записаны не совсем точно) и готовить окружение для воспроизведения.
Очень похоже на описание ситуации, когда над проектом работает маленькая команда, и баги не документируются, так что тестер должен помнить способ воспроизведения бага, а разработчик — помнить свой код.
На серьёзных проектах все баги вносятся в систему контроля багов по определённому формуляру, который включает:
1) адекватное название бага;
2) шаги для воспроизведения;
3) фичу и под-фичу, во время проверки которой проявился баг;
4) скриншоты;
5) стек вызова (если произошёл креш или ассерт);
6) лог;
7) и многое-многое другое.
Если описание бага не содержит какой-либо важной информации, то баг возвращается тестеру для того, чтобы он дополнил описание.
Кроме того, на больших проектах нередко получается так, что баг вынужден исправлять не тот программист, который писал код фичи. Это происходит по нескольким причинам:
1) сложно установить, кто писал данный код (хотя и можно);
2) тот разработчик уже занят исправлением других багов.
Конечно, когда есть такая возможность, то баг отсылается автору фичи. Но часто такой возможности нет, или процесс выяснения занимает достаточное время, что его нецелесообразно тратить.
Миф 5. Если исправление багов откладывать на финальную стадию проекта, то невозможно автоматизировать тестирование, так как тесты бесты будут постоянно разломаны.
Всё прекрасно автоматизируется. Главное, чтобы фичу можно было пройти, и основной flow работал бы так, как запланировано. Как я уже писал, такие баги фиксятся в первую очередь. Без их фикса фича не принимается.
Мое свидетельство Всем привет. Я здесь, чтобы засвидетельствовать, как я получил ссуду от мистера Бенджамина после того, как несколько раз обращался за помощью к различным кредиторам, которые обещали помочь, но не дали мне ссуду. Пока мой друг не представил меня г-ну Бенджамину Ли, он пообещал помочь мне, и он действительно сделал, как обещал, без каких-либо задержек. Я никогда не думал, что есть еще надежные кредиторы, пока я не встретил г-на Бенджамина Ли, который действительно помог с кредит и изменил мою веру. Я не знаю, нужна ли вам настоящая и срочная ссуда. Не стесняйтесь обращаться к г-ну Бенджамину через WhatsApp + 1-989-394-3740 и его электронную почту: 247officedept@gmail.com, спасибо.
ОтветитьУдалить