Критерии приостановки тестирования проекта.

При оформлении тест-плана требуется заполнять пункт «Критерий приостановки и возобновления тестирования», естественно, что для каждого проекта этот критерий свой. Сейчас оформляю общий регламент работ отдела, и требуется как-то обобщить информацию, т.е. написать, что-то типа того, что при наличии N% неработающего функционала продукт возвращается заказчику на доработку.
Интересует, как определен этот критерий в других фирмах, когда вы продолжаете работать, несмотря на наличие критичных ошибок, а когда сразу приостанавливаете работу? Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!

Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!

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

R&D выпускает новую версию сразу после исправления _всех_ известных ошибок. Раньше выпускать смысла нет - к уже имеющимся багрепортам добавятся новые и время реакции на багрепорт увеличится. Если все известные ошибки исправлены - "держать" версию тоже смысла нет.

R&D выпускает новую версию сразу после исправления _всех_ известных ошибок. Раньше выпускать смысла нет - к уже имеющимся багрепортам добавятся новые и время реакции на багрепорт увеличится. Если все известные ошибки исправлены - "держать" версию тоже смысла нет.

Позвольте не согласиться с тем, чтобы "держать" версию до исправления ВСЕХ_ИЗВЕСТНЫХ_ОШИБОК.
Редкий выпуск версий может повлечь за собой позднее обнаружение новых ошибок или необнаружение скрытых ошибок.
И еще у ошибок есть такой атрибут, как приоритет. И некоторые ошибки (на разных стадиях с разной степенью серьезности) могут исправляться "как только появится время" или вовсе откладываться на какой-то срок.
Поэтому менеджеру проекта важно определить график выхода билдов согласно плану разработки ПП.
Нужно найти золотую середину между ранним выпуском плохой версии и поздним выпуском хорошей версии. Здесь уже помогает опыт, профессионализм и интуиция.

А для того, чтобы определить готовность билда к тестированию, существует такое понятие, как Smoke Test = Тест на герметичность = МПТ (минимальный приемочный тест), который проверяет базовую функциональность, длится не более часа, часто в автоматизированном режиме. И по его результатам принимается решение о дальнейшем тестировании сборки. Иногда даже при наличии критических ошибок (но не блокирующих) имеет смысл тестирование доступных веток приложения.

To maximkr:
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?

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

Позвольте не согласиться с тем, чтобы "держать" версию до исправления ВСЕХ_ИЗВЕСТНЫХ_ОШИБОК.
Редкий выпуск версий может повлечь за собой позднее обнаружение новых ошибок или необнаружение скрытых ошибок.
И еще у ошибок есть такой атрибут, как приоритет. И некоторые ошибки (на разных стадиях с разной степенью серьезности) могут исправляться "как только появится время" или вовсе откладываться на какой-то срок.
Поэтому менеджеру проекта важно определить график выхода билдов согласно плану разработки ПП.
Нужно найти золотую середину между ранним выпуском плохой версии и поздним выпуском хорошей версии. Здесь уже помогает опыт, профессионализм и интуиция.

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

По поводу приоритета - откладывать исправления багов "на потом" не очень хорошая идея т.к.:

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

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

3) Предположим, мы выпускаем очередную версию продукта (например, 3.0), и пользователи начинают сообщать о проблемах. Теоретически, мы можем заниматься исправлением этих проблем, или делать следующую версию (4.0), но практически не стоит даже начинать делать следующую версию (4.0), пока не исправлены все ошибки в текущей:
- после создания branch-а для новой версии все багфиксы придется дублировать и проверять дважды.
- чем больше мы кода в новой версии наменяли, тем сложнее переносить багфиксы из старой версии в новую.

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

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

PS. У нас нет жесткого графика выхода версий, версии выпускаются "когда все будет готово".

To maximkr:
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?

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

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

To maximkr:
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?

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

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

Позвольте вмешаться в спор...

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

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

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

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

Имеет смысл так же расписать что это за тестирование будет. Рекоммендуется полное регрессионное тестирование.

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

----
Best Wishes,
Vladimir

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

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

Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!

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

На бумаге такие критерии у нас нигде не записаны, решение каждый раз остается за PM'ом продукта.

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

Если процесс сборки/инсталляции новой версии занимает 2-3 минуты - большое количество итераций не так страшно. Да, внутренние тесты у нас не очень большие - проверяем ошибки, о которых сообщали пользователи и самую базовую функциональность в течении 1-2 часов.

К тому же, через некоторое время количество находимых пользователями ошибок заметно снижается (от 5-10 в неделю сразу после релиза до 3-4 в месяц через полгода), это несколько упрощает дело.

Если процесс сборки/инсталляции новой версии занимает 2-3 минуты - большое количество итераций не так страшно.  Да, внутренние тесты у нас не очень большие - проверяем ошибки, о которых сообщали пользователи и самую базовую функциональность в течении 1-2 часов.

Ну тогда да. Пересобрать саму инсталляшку за 3 минуты это хорошо. У нас итерация пересборки стоит несколько больше по времени.

С моей точки зрения тут явное противоречие.

Если есть достаточное количество ресурсов, я бы советовал выполнять весь план тестирования на каждой сборке.
Но я орентируюсь на наши проекты и наши процессы.

Т.к. ресурсов не хватает, приходится действовать по ситуации.

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

Гы... Интересный спор :) Все равно что гонщик будет спорить с водителем фуры о приемах вождения. И там и там вроде автомобиль, но есть нюансы... ;)

По сабжекту.
Общих критериев нет и быть не может. На них воздействует такое множество факторов таких как:
Технология разработки
Ресурсы на стороне разработки
Ресурсы на стороне тестирования
Размер проекта
График
И т.д.
Соответственно выводить что-то общее для всех бесполезно.
Обычно все же стараются прогнать все тесты к концу тестирования... или все тесты высокого приоритета... или смоук тесты или... ;)
К чему это я?.. К тому, что не ищите универсальное решение для всех - сконцентрируйтесь на своих новых и выполненных проектах и попробуйте вывести критерии, которые именно вам полезны.

Не совсем понятно, что в вашем случае значит приостановка тестирования. А что тогда тестировщики делают после этого? Курят бамбук? Идут в отпуск?)

Не совсем понятно, что в вашем случае значит приостановка тестирования. А что тогда тестировщики делают после этого? Курят бамбук? Идут в отпуск?)

Тут скорее всего существительного не хватает: Приостановка тестирования версии\модуля\продукта?

И некоторые общие критерии вроде есть, типа уже упомянутой выше блокирующей ошибки, когда функциональность просто не работает и workaround-ов нет, или же когда smoke\acceptance test не прошел.

Но тут опять таки все упирается в ресурсы и технологию разработки\тестирования. Я-то ни разу не встречал еще проекта, где бы смоук/акксептанс тест не позволял выявить критичные ошибки, но не факт что подобных проектов нет :)