А как определить объем тестирования

Создается очередная версия ПО.
Есть изменения, которые надо внести в эту версию.
А кто может определить необходимый объем тестирования? И исходя из чего?

Хотелось бы услышать мнения....

Поскольку собственное чересчур привязано к реалиям текущим.

Создается очередная версия ПО.
Есть изменения, которые надо внести в эту версию.
А кто может определить необходимый объем тестирования? И исходя из чего?

Хотелось бы услышать мнения....

Поскольку собственное чересчур привязано к реалиям текущим.

определяется количество модулей, которые необходимо протестировать. Затем определяется какое тестирование проводить (GUI, нагрузочное, функциональное) для каждого модуля. Затем подсчитывается количество примерных тест-кейсов, исходя из требований. Затем считается сколько потребуется времени (для каждого индивидуально), чтобы перевести тест-кейсы в автоматизированный скрипт или методику. Потом все суммируется и получается итоговое время. Возможно, что то забыл, но примерно так наверное.

Создается очередная версия ПО.
Есть изменения, которые надо внести в эту версию.
А кто может определить необходимый объем тестирования? И исходя из чего?

Хотелось бы услышать мнения....

Поскольку собственное чересчур привязано к реалиям текущим.

да, забыл упомянуть, на software-testing.ru была недавно статья на эту тему. Там говорилось, что про регрессионное тестирование обычно забывают при учете времени и что то еще. ..

определяется количество модулей, которые необходимо протестировать. Затем определяется какое тестирование проводить (GUI, нагрузочное, функциональное) для каждого модуля. Затем подсчитывается количество примерных тест-кейсов, исходя из требований. Затем считается сколько потребуется времени (для каждого индивидуально), чтобы перевести тест-кейсы в автоматизированный скрипт или методику. Потом все суммируется и получается итоговое время. Возможно, что то забыл, но примерно так наверное.

Спасибо. Уточняю, ОК?

1. Кто определит количество модулей?
2. Часть изменений - гашение незначительных багов из предыдущей версии. В этом случае что имеется в виду под требованиями?
3. Модули протестировали. А все вместе? Т.е всю систему полностью?
4. Как оценить время на разработку методики? Чисто интуитивно?

Создается очередная версия ПО.
Есть изменения, которые надо внести в эту версию.
А кто может определить необходимый объем тестирования? И исходя из чего?

Хотелось бы услышать мнения....

Поскольку собственное чересчур привязано к реалиям текущим.

да, забыл упомянуть, на software-testing.ru была недавно статья на эту тему. Там говорилось, что про регрессионное тестирование обычно забывают при учете времени и что то еще. ..

Еще необходимо включить риски при тестировании, т.е. прибавить n-ое кол-во процентов к результату в зависимости от оценки некоторых параметрова. Например:
1. Новый разработчик на проекте или нет.
2. Качество написания кода конкретным разработчиком, если он знаком.
3. Вероятность изменения ТС, если оно существует. Это очень сказывается в ходе тестирования, если нужно менять ТС.
4. Возможные условия для текущего проекта, которые могут повлять на срок тестиорвания.

Значение n зачастую трудно предугодать... Но вообще отбрасывать его, думаю не стоит.

@Фрося

• Разбейте приложение на крупные области, для каждой области определите набор функций, после этого посмотрите, какие функции затронуты изменениями. Поговорите с разработчиками о влиянии функций друг на друга. На мой взгляд, так будет проще и понятней чем с модулями.
• Зависит от Вашей системы и характера изменений. Возможно надо тестировать полностью, возможно проверить несколько базовых сценариев.
• Вы точно уверены, что автоматизация Вам нужна?

@Фрося

• Разбейте приложение на крупные области, для каждой области определите набор функций, после этого посмотрите, какие функции затронуты изменениями. Поговорите с разработчиками о влиянии функций друг на друга. На мой взгляд, так будет проще и понятней чем с модулями.
• Зависит от Вашей системы и характера изменений. Возможно надо тестировать полностью, возможно проверить несколько базовых сценариев.
• Вы точно уверены, что автоматизация Вам нужна?

1. Угу-с... имено проговорив с разработчиками - пытаюсь оценить объем. Есть совершенно твердая уверенность -- что о влиянии функций друг на друга разработчики никогда все полностью не скажут. Забывают.. увы....
Но! Честно пишут - в какие классы вносили изменения. Есть мысль - что можно на эту информацию опираться.
2. Т.е. получается -- экспертная оценка?
3. Я точно знаю - что автоматизирования в ближайшее время не будет. Такова специфика.

Еще необходимо включить риски при тестировании, т.е. прибавить n-ое кол-во процентов к результату в зависимости от оценки некоторых параметрова. Например:
1. Новый разработчик на проекте или нет.
2. Качество написания кода конкретным разработчиком, если он знаком.
3. Вероятность изменения ТС, если оно существует. Это очень сказывается в ходе тестирования, если нужно менять ТС.
4. Возможные условия для текущего проекта, которые могут повлять на срок тестиорвания.

Значение n зачастую трудно предугодать... Но вообще отбрасывать его, думаю не стоит.

мм... простите, я не в курсе что это - ТС? Требования к системе?

Еще необходимо включить риски при тестировании, т.е. прибавить n-ое кол-во процентов к результату в зависимости от оценки некоторых параметрова. Например:
1. Новый разработчик на проекте или нет.
2. Качество написания кода конкретным разработчиком, если он знаком.
3. Вероятность изменения ТС, если оно существует. Это очень сказывается в ходе тестирования, если нужно менять ТС.
4. Возможные условия для текущего проекта, которые могут повлять на срок тестиорвания.

Значение n зачастую трудно предугодать... Но вообще отбрасывать его, думаю не стоит.

мм... простите, я не в курсе что это - ТС? Требования к системе?

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

Так что этот пункт по обстоятельствам.

Создается очередная версия ПО.
Есть изменения, которые надо внести в эту версию.
А кто может определить необходимый объем тестирования? И исходя из чего?

Хотелось бы услышать мнения....

Поскольку собственное чересчур привязано к реалиям текущим.

Если честно, то без реалий всё-равно не получится, поскольку у разных компаний процесс разработки построен по разному. Как организационно, так и процессно. Где-то проектные команды, а где-то матрица. Где-то фичи, а где-то итерации и просто задачи на разработку. Где-то ежедневные сборки, а где-то релизы по мере необходимости. Поэтому и объём и частота тестирования разная.

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

Если говорить про сферического коня в вакууме, то, вообщем, объём тестирования определяют несколько человек.

1. Тест-менеджер (или кто исполняет его роль в данном случае) определяет необходимый объём тестирования исходя из своих знаний о системе: какие требования, что и где изменялось, степень бажности каждого модуля (где-то в каждой итерации находится по полсотни ошибок в клиентской части, а где-то - только пара ошибок в хранимых процедурах).
Хочу заметить, что требования это важный пункт. Поскольку даже при небольших изменениях может потребоваться большой объём тестирования, если требуется проверять нагрузку или проводить конфигурационное тестирование (например: перебрать все ОС, так как у вас разработка драйверов).
2. Спонсор. Он ограничивает Ваши стремления проверить как можно больше своим пониманием, какой бюджет может быть выделен на эти работы.
3. Менеджер проекта. Он учитывает интересы всех заинтересованных лиц и при согласовании плана тестирования старается свести противоречия к разумному компромиссу.

Так что, скорее всего, желаемый объём тестирования будет сокращён. И тест-менджеру (а может и не ему) придётся думать, какие работы выбрасывать.

4. Как оценить время на разработку методики? Чисто интуитивно?

Опять же, без каких-то реалий отвечать очень сложно.

Попробуем из чисто практических соображений.

Предположим (для простоты рассуждений), у Вас водопадная модель разработки, итерация идёт 10 рабочих дней.
Из них: 2 дня на создание и согласование требований, 5 дней на разработку, и 3 дня на тестирование.

Прошу обратить внимание, что при жёстких итерациях не стоит вопрос "Сколько нужно выделить времени на тестирование"(особенно если применяется Agile). Ну, вот назначили срок сверху, что через 10 дней должен быть готов очередной релиз.

Значит, у Вас в данном случае на создание методики тестирования от силы 3 дня, после начала разработки. И ещё пару дней на согласование тест-плана с кем нужно.

Опять же, размер команды сильно влияет на объём работы. Одно дело, когда в команде 2 разработчика, 1 аналитик и 1 тестировщик. Другое, когда в те же 10 дней над выпуском релиза работают 30 человек. Размер методики тестирования скорее всего будет тоже другой.

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

Если говорить про сферического коня в вакууме, то, вообщем, объём тестирования определяют несколько человек.

1. Тест-менеджер (или кто исполняет его роль в данном случае) определяет необходимый объём тестирования исходя из своих знаний о системе: какие требования, что и где изменялось, степень бажности каждого модуля (где-то в каждой итерации находится по полсотни ошибок в клиентской части, а где-то - только пара ошибок в хранимых процедурах).
Хочу заметить, что требования это важный пункт. Поскольку даже при небольших изменениях может потребоваться большой объём тестирования, если требуется проверять нагрузку или проводить конфигурационное тестирование (например: перебрать все ОС, так как у вас разработка драйверов).
2. Спонсор. Он ограничивает Ваши стремления проверить как можно больше своим пониманием, какой бюджет может быть выделен на эти работы.
3. Менеджер проекта. Он учитывает интересы всех заинтересованных лиц и при согласовании плана тестирования старается свести противоречия к разумному компромиссу.

Так что, скорее всего, желаемый объём тестирования будет сокращён. И тест-менджеру (а может и не ему) придётся думать, какие работы выбрасывать.

Сферическмй конь в вакууме и интересует! Общий подход без конкретики.

1. Т.е. получается, что тест-менеджер должен представлять как ПО реализовано? Какие модули есть, как минимум? И, видимо, как они взаимосвязаны.
Изменения в Требованиях видимо следует распределять по критичности (обязательные для исполнения, или так - чтоб поудобней было) ?
И , видимо, оценивать по объему требуемого тестирования для изменения?

2,3. Это понятно. Есть ограничения хотя бы по срокам.

1. Т.е. получается, что тест-менеджер должен представлять как ПО реализовано? Какие модули есть, как минимум? И, видимо, как они взаимосвязаны.
Изменения в Требованиях видимо следует распределять по критичности (обязательные для исполнения, или так - чтоб поудобней было) ?
И , видимо, оценивать по объему требуемого тестирования для изменения?

Лично моё мнение - да. При возможности, хороший тестировщик должен знать архитектуру того приложения, которое он тестирует. Не до уровня классов. Но потоки данных, проходящих через систему он должен представлять. (Ну, у меня в работе попадались только сложные системы. И я предполагаю, что мы говорим не о ПО сопоставимом с калькулятором). Поскольку большинство серьёзных ошибок связано именно с интеграцией разных модулей. Особенно, если их разработкой занимаются разные команды, которые могут быть разнесены и географически и лингвистически.

Если уж мы говорим о сложном ПО, то неизбежно должны быть какие-то требования/задания на разработку, которые попадают к тест-дизайнерам для создания тест-планов. Так что и список модулей и объём необходимых изменений нам известен.

В принципе, если процесс разработки построен на достаточно высоком уровне, то требуемые работы определяются ещё на этапе создания плана проекта. Менеджер проекта с тест-менеджером согласует список работ по тестированию и примерное время на них, на основе имеющегося vision. И потом уже ставятся конкретные задачи тест-дизайнерам. А на основе результатов их работы уточняется план проекта.
При ещё лучшем случае, тест-менеджер вначале проекта пишет стратегию тестирования.

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

определяется количество модулей, которые необходимо протестировать. Затем определяется какое тестирование проводить (GUI, нагрузочное, функциональное) для каждого модуля. Затем подсчитывается количество примерных тест-кейсов, исходя из требований. Затем считается сколько потребуется времени (для каждого индивидуально), чтобы перевести тест-кейсы в автоматизированный скрипт или методику. Потом все суммируется и получается итоговое время. Возможно, что то забыл, но примерно так наверное.

Спасибо. Уточняю, ОК?

1. Кто определит количество модулей?
2. Часть изменений - гашение незначительных багов из предыдущей версии. В этом случае что имеется в виду под требованиями?
3. Модули протестировали. А все вместе? Т.е всю систему полностью?
4. Как оценить время на разработку методики? Чисто интуитивно?

1. Количество модулей вроде бы должно быть известно изначально, или может что-то не пойму.
2. Тут не совсем требования, а скорее проведение регрессионного тестирования.
3. Все вместе это часть интеграционного и комплексного тестирования. Так что тоже входит в тестирование и должно учитываться.
4. Исходя из среднего затрачиваемого времени человеком на разработку тест-кейса и умножить это на количество тесткейсов. Получится среднее время (необязательно точное).
Если такого опыта не было, то да интуитивно.

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