Перейти к содержимому

Английский для тестировщиков
онлайн, начало 21 июня
Погружение в тестирование. Jedi point
онлайн, начало 21 июня
Тестирование REST API
онлайн, начало 21 июня
Selenium WebDriver: полное руководство
онлайн, начало 18 июня
Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 13

#1 Sonya

Sonya

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 22 марта 2007 - 10:31

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

#2 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 22 марта 2007 - 11:58

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

Просмотр сообщения


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

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

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#3 yamayka80

yamayka80

    Новый участник

  • Members
  • Pip
  • 49 сообщений
  • ФИО:Наталья
  • Город:Минск

Отправлено 23 марта 2007 - 08:36

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

Просмотр сообщения


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

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

#4 Sonya

Sonya

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 23 марта 2007 - 09:53

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

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

#5 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 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. У нас нет жесткого графика выхода версий, версии выпускаются "когда все будет готово".
  • 0
Максим Крамаренко

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#6 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 23 марта 2007 - 12:33

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


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

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

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#7 Diogen

Diogen

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Владимир Трушкин
  • Город:Минск

Отправлено 23 марта 2007 - 14:41

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


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

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

Просмотр сообщения


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

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

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

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

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

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

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

----
Best Wishes,
Vladimir
  • 0

#8 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 924 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 марта 2007 - 14:44

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

Просмотр сообщения

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

#9 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 924 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 марта 2007 - 14:47

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

Просмотр сообщения


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

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

#10 maximkr

maximkr

    Активный участник

  • Members
  • PipPip
  • 96 сообщений
  • ФИО:Крамаренко Максим
  • Город:Смоленск

Отправлено 24 марта 2007 - 07:15

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

Просмотр сообщения


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

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

TrackStudio - система управления задачами (issue tracker) для больших проектов.

#11 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 924 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 24 марта 2007 - 08:40

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


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

#12 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 30 марта 2007 - 15:57

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

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

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

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

Просмотр сообщения


  • 0

#13 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 18 апреля 2007 - 13:56

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

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

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

#14 Pet[EG]

Pet[EG]

    Активный участник

  • Members
  • PipPip
  • 86 сообщений
  • ФИО:Петраш А.Ю.
  • Город:Харьков, Укр

Отправлено 23 апреля 2007 - 09:06

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

Просмотр сообщения

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

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

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


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале