Сообщений в теме: 20

[Case]

Интересует формальный признак, что билд или релиз можно выпускать.

[SNord]

А вот есть такая статья С. Трофимова: "Когда прекращать тестирование программ?":
http://www.caseclub....es/testprg.html

[Case]

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

Я наверное не полно выразился.
Интерсует такая ситуация: есть процесс выпуска билдов. Есть желание понять, что полученные билд может стать к примеру релизкандидатом 1.

[ShS]

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

А формальный признак, что билд или релиз можно выпускать определяется сроками плана выпуска версий, если таковой имеется...

[Case]

А формальный признак, что билд или релиз можно выпускать определяется сроками плана выпуска версий, если таковой имеется...

Я так не думаю. Окончание срока разработки далеко не признак качества продукта.

[ShS]

Окончание срока разработки далеко не признак качества продукта.

Согласен на все 200%

Лично я в Плане тестирования, в разделе "Критерии завершения этапа тестирования", пишу так: Критерием завершения цикла тестирования является полное выполнение всех запланированных сценариев и видов тестирования.

[Green]

Вообще то признаков завершения процесса тестирования больше (чем один).

Вот те, которые понмю (не охота лезть в книжки):
1. Выполнены все запланированные тесты.
2. Закончилось время, выделенное на тестирование.
3. Закончились ресурсы (и не только деньги), выделенные на тестирование.
4. Проект потерял актуальность (т.е. всех уволили :D ).

[Case]

Критерием завершения цикла тестирования является полное выполнение всех запланированных сценариев и видов тестирования.

Логично. Так и планируется.
Потом сжимаются сроки. Что-то приходится выкидывать.
Ситуация такая:
Выполнено не всё что планировано, сроки пока терпят, но всё всё равно не выполнить - как выходить из тестирования?

[Case]

1. Выполнены все запланированные тесты.
2. Закончилось время, выделенное на тестирование.
3. Закончились ресурсы (и не только деньги), выделенные на тестирование.
4. Проект потерял актуальность

В принципе тоже самое, включая увольнение :)

Вопрос шире: сроки терпят, всё оттестировать не получается не важно по каким причинам, нужен релиз. Как определить готов ли билд стать релиз кандидатом?

[Green]

Вопрос шире: сроки терпят, всё оттестировать не получается не важно по каким причинам, нужен релиз. Как определить готов ли билд стать релиз кандидатом?

А разве в этом случае начальство оставляет выбор? :P
(предваряя поток возражений - это шутка).

ИМНО:
1. НЕ ДОЛЖНО быть открытых (новых или пофикшенных) багов со статусом critical, т.е. приложение не должно "валиться" в результате необрабатываемой ошибки.
2. Не должно быть открытых багов со статусами critical и major в СДАВАЕМОЙ части программы.
3. Не должно быть открытых багов со статусами critical, major и minor в СДАННОЙ части программы.

Если это релиз кандидат или сам кандидат, то желательно состояния програмы привести к пункту 3, но можно и к пункту 4.

[ShS]

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

всё оттестировать не получается не важно по каким причинам

Пришли к рискам, которые должны учитываться и для которых должны быть описаны пути решения...
Кстати можно темку поднять Риски при тестировании и пути их решения...если еще нет...

[Case]

Поднимайте, мне было бы интересно.

[SALar]

Сначала я бы задал вопрос: "А зачем готовится билд?". Допустим мы выпускаем что-то вроде TheBat!, но например с анимацией. Основное отличие нашей проги от существующих продуктов - анимация, "игрушечность" и т.д..Теперь рассмотрим варианты целей.
-----------------------
Хотим показать EndUser-ам из целевой группы, и дать побаловаться. Цель - сбор откликов. Нам интересно выяснить стоит ли и дальше делать флешки в стиле Масяни, нужна ли озвучка "А пошел ты директор..." ну и т.д.
У нас есть поле запланированных тестов. Часть из них прошла. Часть ошибок даже пофикшена, но работы на год, а есть только неделя.
Выделяем базовую функциональность. Например:
1) Программа должна открываться
2) Письма должны отправляться
3) Письма должны приниматься
4) Анимация должна быть
На это пишем приемочный сьют. Его охват будет в 10-1000 раз меньше общего поля тестов. Если он проходит - можно ставить. При этом нас совершенно не волнует, что при закрытии прога грохает базу писем, что в аттаче приходит мусор, что при заборе с сервака более трех писем система виснет наглухо. Нам это не важно.
Итак первый вариант: Если проходят ограниченные приемочные тесты, то билд можно ставить.
----------------
Очередная поставка билда. Новый функционал важнее наличия мелких ошибок.
Можно говорить "да" при условиях:
1) Прошли хотя бы по разу все запланированные тесты
2) Вышли на сотояние нуля ошибок с важностью "критикал" и "мажор".
3) На последнем билде прошел приемочный тест.
Возможно наличие критичных ошибок в не очень важном или редко используемом функционале. Например можно пропустить такую багу: "При удалении пользователя из адресной книги, становятся недоступны его письма". Но эти баги должны быть задокументированы.
Могут не проводиться большинство тестов. Сейчас фажен GUI и функционал. И хорошо бы целостность проверить при возможности.

-------------------------
Коммерческий продукт. Очередная версия. Некоторое время ему многое прощалось, но сейчас поставка по условиям 2) приведет к потере репутации фирмы.
Добавим:
1) Проводилось большинство типов тестов. Ну может нагрузочное забыли (в течении дня прием непрерывного потока писем и их сортировка).
2) Известные "критикал" и "мажор" не только все исправлены, но и проверены.
3) Прошли все автоматические тесты, которые успели написать.
4) Приемочные тесты расширены и включают в себя всю функциональность.
-------------
4) Очень хорошо вылизанный релиз.
1) закрыты все баги, признаные существенными
2) После последнего сделанного изменения прошли все тесты.
-------------
Хотя четвертый вариант я себе слабо представляю...

[Case]

Сначала по процедурному вопросу:

Сначала я бы задал вопрос: "А зачем готовится билд?"

Это по-моему риторический вопрос. Билд позволяет как можно ранее обнаружить ошибку и не надстроить над ней чего-то, что после прийдётся переделывать. Это по-моему основная идея строить билды.
То о чём вы говорили ниже уже ближе к релизам. Вопрос зачем нужен релиз вы осветили достаточно прозрачно: дать поиграться, отдать заказчику, показать прогресс разработки и так далее.
У меня вопрос в другом, я видимо никак не могу достаточно полно поставить задачу :)
Есть вполне реальная задача: определить момент, когда билд может быть релиз-кандидатом.

[Green]

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

На мой взгляд, ответ на этот вопрос очевиден.

Когда будут реализованы все требования, оговоренные техническим заданием и/или запросами заказчика.

Далее по приоритету идут остальные критерии останоки процесса тестирования:
1. Закончились деньги - фирма объявила себя бонкротом. B)
2. Закончилось время - заказчик не может ждать и согласился принять все как есть.
3. Закончились ресурсы - все разбежались и некому работать.

[SALar]

Сначала по процедурному вопросу:

Сначала я бы задал вопрос: "А зачем готовится билд?"

Это по-моему риторический вопрос. Билд позволяет как можно ранее обнаружить ошибку и не надстроить над ней чего-то, что после прийдётся переделывать. Это по-моему основная идея строить билды.
То о чём вы говорили ниже уже ближе к релизам. Вопрос зачем нужен релиз вы осветили достаточно прозрачно: дать поиграться, отдать заказчику, показать прогресс разработки и так далее.
У меня вопрос в другом, я видимо никак не могу достаточно полно поставить задачу :)
Есть вполне реальная задача: определить момент, когда билд может быть релиз-кандидатом.

В тот момент когда он будет соответствовать нормам.
Есть цель релиза. Цель - это нормированное представление о результате. Как только нормы удолетворены билд можно считать релиз кандидатом.
Замечу, что нормы могут быть разными. Например может быть задана такая норма: Релизом считается наиболее работоспособный билд сделанный до 1.01.2003.
------------------------------------------------------------------------------------
Использовалась малоизвестная терминология из "Методологии" (отечественная разработка). В ее терминах это все элементарно описывается. Что интересно, там даже вопроса такого не возникло бы.

[Green]

Все это правильно ... в теории.

На практике мне ни разу не приходилось сталкиваться с ситуацией, когда тестировщики решали, а не объявить ли нам текущий билд релиз-кандидатом? Или не тестировщики, а менеджеры.

Тратить на программу столько времени, сколько хочеться - не позволительная роскошь!

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

Если проект заказной, то существуют рамки договора. Нарушил сроки - получи по заслугам.

Если продукт коробочный, тоже самое. Только здесь все завязано на рекламу и промоушен. Руководство везде трубит:
- Мы выпустим продукт к ххх числу!
- Готовте ваши денежки!
И попробуй не выпустить к указанному сроку!

[Case]

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

А вот про то что тестеры могут решать что билд достаточно хорош для Релиз-кандидата, слышал. Делают так. Успешно.

[Green]

Давайте будем реалистами!

Существет бизнес процесс и он главный! Он диктует сроки, а все под них подстраиваются.

Вначале было слово! И это слово было ... набор требований к программе. Из этого набора получили таски. Добавили тестирование - получили таски по тестированию. Провели оценку тасков - получили прожект план. Суммировали все задачи - получили календарный план выпуска билдов.

Начальство утвердило - все приступили к работ. Уложились в очередной этап - молодцы, не уложились - "козлы". Пересмотрели календарный или прожект план. Работаем дальше.

К намеченному сроку - готов релиз-кандидат? Если да - пьем шомпанское, если нет - сами знаете что. :-)

А теперь опишите мне другую схему работы, если вы ее видели.

<_<