Критерии приостановки тестирования проекта.
#1
Отправлено 22 марта 2007 - 10:31
Интересует, как определен этот критерий в других фирмах, когда вы продолжаете работать, несмотря на наличие критичных ошибок, а когда сразу приостанавливаете работу? Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!
#2
Отправлено 22 марта 2007 - 11:58
Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!
При обнаружении критичных ошибок (тут критерии могут быть разными) сразу останавливаем тестирование и ждем исправления. Если ошибки некритичные, то тестируем текущую версию пока не достигнем состояния "за последние X дней не нашли ни одной ошибки".
R&D выпускает новую версию сразу после исправления _всех_ известных ошибок. Раньше выпускать смысла нет - к уже имеющимся багрепортам добавятся новые и время реакции на багрепорт увеличится. Если все известные ошибки исправлены - "держать" версию тоже смысла нет.
#3
Отправлено 23 марта 2007 - 08:36
R&D выпускает новую версию сразу после исправления _всех_ известных ошибок. Раньше выпускать смысла нет - к уже имеющимся багрепортам добавятся новые и время реакции на багрепорт увеличится. Если все известные ошибки исправлены - "держать" версию тоже смысла нет.
Позвольте не согласиться с тем, чтобы "держать" версию до исправления ВСЕХ_ИЗВЕСТНЫХ_ОШИБОК.
Редкий выпуск версий может повлечь за собой позднее обнаружение новых ошибок или необнаружение скрытых ошибок.
И еще у ошибок есть такой атрибут, как приоритет. И некоторые ошибки (на разных стадиях с разной степенью серьезности) могут исправляться "как только появится время" или вовсе откладываться на какой-то срок.
Поэтому менеджеру проекта важно определить график выхода билдов согласно плану разработки ПП.
Нужно найти золотую середину между ранним выпуском плохой версии и поздним выпуском хорошей версии. Здесь уже помогает опыт, профессионализм и интуиция.
А для того, чтобы определить готовность билда к тестированию, существует такое понятие, как Smoke Test = Тест на герметичность = МПТ (минимальный приемочный тест), который проверяет базовую функциональность, длится не более часа, часто в автоматизированном режиме. И по его результатам принимается решение о дальнейшем тестировании сборки. Иногда даже при наличии критических ошибок (но не блокирующих) имеет смысл тестирование доступных веток приложения.
#4
Отправлено 23 марта 2007 - 09:53
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?
To yamayka80:
Конечно приемочное тестирование существует, но оно ведь именно что приемочное, поверхностное, и с первого взгляда вроде все работает, а критичные ошибки могут быть найдены и после него. Приемочное тестирование - это лишь проверка того, что система стабильна и можно проводить штатное тестирование
#5
Отправлено 23 марта 2007 - 12:21
Позвольте не согласиться с тем, чтобы "держать" версию до исправления ВСЕХ_ИЗВЕСТНЫХ_ОШИБОК.
Редкий выпуск версий может повлечь за собой позднее обнаружение новых ошибок или необнаружение скрытых ошибок.
И еще у ошибок есть такой атрибут, как приоритет. И некоторые ошибки (на разных стадиях с разной степенью серьезности) могут исправляться "как только появится время" или вовсе откладываться на какой-то срок.
Поэтому менеджеру проекта важно определить график выхода билдов согласно плану разработки ПП.
Нужно найти золотую середину между ранним выпуском плохой версии и поздним выпуском хорошей версии. Здесь уже помогает опыт, профессионализм и интуиция.
Я не совсем точно выразился - мы держим версию до исправления всех известных ошибок, _которые мы в состоянии исправить_.
Т.е. сюда не попадают ошибки в коде третьих фирм, если для их исправления требуется серьезно менять версию используемого стороннего продукта, или переходить на другой сторонний продукт (сейчас мы знаем 4 таких проблемы - из-за JDK, MySQL, Struts и IE).
Еще мы не ждем исправления известной ошибки, если клиент пока не прислал запрошенной информации (версия, скриншоты, дамп базы и т.п.), обычно такие вещи исправляются в следующей минорной версии.
По поводу приоритета - откладывать исправления багов "на потом" не очень хорошая идея т.к.:
1) быстрое исправление ошибки побуждает клиента к диалогу. Если ошибка исправлена через месяц, то клиенту может быть просто лень пытаться ее повторить и сообщить о результатах. Кроме того, в следующий раз клиент может просто забить ("а зачем сообщать об этой ошибке, если та еще не исправлена").
2) клиенты плохо реагируют в ситуации, когда они сообщали об ошибке месяц назад, с тех пор уже вышло 2 билда, а их ошибка все еще не исправлена. Если клиент сообщил об ошибке, ему было не лень тратить время на повторение, присылание дампов и скриншотов - значит эта проблема достаточно важна для клиента и игнорирование чревато.
3) Предположим, мы выпускаем очередную версию продукта (например, 3.0), и пользователи начинают сообщать о проблемах. Теоретически, мы можем заниматься исправлением этих проблем, или делать следующую версию (4.0), но практически не стоит даже начинать делать следующую версию (4.0), пока не исправлены все ошибки в текущей:
- после создания branch-а для новой версии все багфиксы придется дублировать и проверять дважды.
- чем больше мы кода в новой версии наменяли, тем сложнее переносить багфиксы из старой версии в новую.
4) Предположим, мы выпустили новую версию с известными глюками, пользователи смотрят эту новую версию, находят несколько новых проблем и сообщают о них. Сразу исправить эти проблемы мы не можем, т.к. еще "сидим" со старыми, а значит время исправления новых проблем для пользователя необоснованно увеличивается.
5) Сложный софт становится изучать еще сложнее, если пользователи предполагают там наличие глюков. Если что-то работает не так, как ожидает пользователь, то он может (1) прочитать документацию и понять где был не прав или (2) решить, что это очередной глюк и пойти искать чего понадежнее. Т.е. один мелкий реальный глюк может привести к тому, что пользователь "найдет" еще парочку мифических :-)
PS. У нас нет жесткого графика выхода версий, версии выпускаются "когда все будет готово".
#6
Отправлено 23 марта 2007 - 12:33
To maximkr:
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?
Если мы все равно не собираемся выпускать версию с известными глюками - зачем ее тестировать ? Метод работает, если исправления глюка не нужно ждать неделю, иначе процесс разработки может в самом деле затянуться.
Т.е. я за то, чтоб сразу сообщать об ошибках, сразу их исправлять и пытаться увеличивать количество итераций, а не количество исправленных проблем в рамках одной итерации. Для публичных билдов это получается не всегда (пользователь может игнорировать слишком частый выход минорных версий), но по крайней мере у него есть выбор.
#7
Отправлено 23 марта 2007 - 14:41
To maximkr:
Билд может состоять из независимых друг от друга модулей связанных одним интерфейсом, и если критичная ошибка в одном из модулей, то вы возвращаете весь билд? или всё таки продолжаете тестить оставшиеся куски?
Если мы все равно не собираемся выпускать версию с известными глюками - зачем ее тестировать ? Метод работает, если исправления глюка не нужно ждать неделю, иначе процесс разработки может в самом деле затянуться.
Т.е. я за то, чтоб сразу сообщать об ошибках, сразу их исправлять и пытаться увеличивать количество итераций, а не количество исправленных проблем в рамках одной итерации. Для публичных билдов это получается не всегда (пользователь может игнорировать слишком частый выход минорных версий), но по крайней мере у него есть выбор.
Позвольте вмешаться в спор...
У меня сложилось впечатление что стороны находятся в совершенно разных обстоятельствах. В зависимости от того чего больше, четкого документирования функциональности или хаотичных и не всегда последовательных "просьб" сделать изменения со стороны кастомера.
Что касается начального вопроса, то при наличии четкого плана, который позволяет вывести проект на необходимый уровень качества к дате релиза, такое понятие как критерий когда останавливать тестирование теряет свою ценность.
Если же (по каким либо из миллиона возможных причин) четкой даты нет, а нужен критерии то обычно они звучат так:
- соответствие продукта требованиям подтверждено тестами.
- не обнаружено критических ошибок в течение двух недель активного тестирования перед релизом.
Имеет смысл так же расписать что это за тестирование будет. Рекоммендуется полное регрессионное тестирование.
Но в реальном мире решение о дате релиза принимается не столько на основании результатов тестирования сколько на основании бизнес требований.
----
Best Wishes,
Vladimir
#8
Отправлено 23 марта 2007 - 14:44
Данный подход череват стремлением количества итераций к плюс бесконечности.Т.е. я за то, чтоб сразу сообщать об ошибках, сразу их исправлять и пытаться увеличивать количество итераций, а не количество исправленных проблем в рамках одной итерации. Для публичных билдов это получается не всегда (пользователь может игнорировать слишком частый выход минорных версий), но по крайней мере у него есть выбор.
Тем более получается, что вы никогда не дойдет до конца тестов, если будете обрывать их после нахождения ошибки. Или дойдете очень нескоро.
#9
Отправлено 23 марта 2007 - 14:47
Есть ли у вас этот критерий общий для всех проектов (или группы проектов)?
Спасибо!
Если тестирование релизное, а ошибка серьезная, то версия отзывается из тестирования.
Если просто функциальное тестирование и баг не блокирует работу всего прилдожения, то почему бы не продолжить тестирование других операций?
На бумаге такие критерии у нас нигде не записаны, решение каждый раз остается за PM'ом продукта.
#10
Отправлено 24 марта 2007 - 07:15
Данный подход череват стремлением количества итераций к плюс бесконечности.
Тем более получается, что вы никогда не дойдет до конца тестов, если будете обрывать их после нахождения ошибки. Или дойдете очень нескоро.
Если процесс сборки/инсталляции новой версии занимает 2-3 минуты - большое количество итераций не так страшно. Да, внутренние тесты у нас не очень большие - проверяем ошибки, о которых сообщали пользователи и самую базовую функциональность в течении 1-2 часов.
К тому же, через некоторое время количество находимых пользователями ошибок заметно снижается (от 5-10 в неделю сразу после релиза до 3-4 в месяц через полгода), это несколько упрощает дело.
#11
Отправлено 24 марта 2007 - 08:40
Если процесс сборки/инсталляции новой версии занимает 2-3 минуты - большое количество итераций не так страшно. Да, внутренние тесты у нас не очень большие - проверяем ошибки, о которых сообщали пользователи и самую базовую функциональность в течении 1-2 часов.
Ну тогда да. Пересобрать саму инсталляшку за 3 минуты это хорошо. У нас итерация пересборки стоит несколько больше по времени.
#12
Отправлено 30 марта 2007 - 15:57
Если есть достаточное количество ресурсов, я бы советовал выполнять весь план тестирования на каждой сборке.
Но я орентируюсь на наши проекты и наши процессы.
Т.к. ресурсов не хватает, приходится действовать по ситуации.
...естественно, что для каждого проекта этот критерий свой...
...и требуется как-то обобщить информацию...
#13
Отправлено 18 апреля 2007 - 13:56
По сабжекту.
Общих критериев нет и быть не может. На них воздействует такое множество факторов таких как:
Технология разработки
Ресурсы на стороне разработки
Ресурсы на стороне тестирования
Размер проекта
График
И т.д.
Соответственно выводить что-то общее для всех бесполезно.
Обычно все же стараются прогнать все тесты к концу тестирования... или все тесты высокого приоритета... или смоук тесты или... ;)
К чему это я?.. К тому, что не ищите универсальное решение для всех - сконцентрируйтесь на своих новых и выполненных проектах и попробуйте вывести критерии, которые именно вам полезны.
Не совсем понятно, что в вашем случае значит приостановка тестирования. А что тогда тестировщики делают после этого? Курят бамбук? Идут в отпуск?)
#14
Отправлено 23 апреля 2007 - 09:06
Тут скорее всего существительного не хватает: Приостановка тестирования версии\модуля\продукта?Не совсем понятно, что в вашем случае значит приостановка тестирования. А что тогда тестировщики делают после этого? Курят бамбук? Идут в отпуск?)
И некоторые общие критерии вроде есть, типа уже упомянутой выше блокирующей ошибки, когда функциональность просто не работает и workaround-ов нет, или же когда smoke\acceptance test не прошел.
Но тут опять таки все упирается в ресурсы и технологию разработки\тестирования. Я-то ни разу не встречал еще проекта, где бы смоук/акксептанс тест не позволял выявить критичные ошибки, но не факт что подобных проектов нет :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных