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

[Green]

Далее, я хотел бы высказать свое - обывательское, понимание стратегии чего-то, в том числе и стратегии тестирования. Прошу не расценивать это как критику, это мысли вслух. :-)

На мой взгляд стратегия - это описание того, как мы достигнем поставленных целей. По сути, очень часто нет необходимости писать заголовок "Стратегия". Достаточно перечислить цели, которые ставяться перед проектом.

Когда цели определены, каждую из них мы можем разбить на задачи, которые, в свою очередь, определяют ряд критериев. Пользуясь методикой SMART каждая задача должна быть четко сформулирована (Specific), измерима (Measurable), достижима (Achievable), значима (Relevant) и соотнесена с конкретным сроком (Time-bounded).

Теперь можно определяться с рисками которые стоят на пути к нашим целям через поставленные задачи.

[Green]

3. Цитата:
Что идеологически более правильно: выделять стратегию для всего проекта, или разрабатывать конкретные подходы для каждой области тестирования, зависит от конкретного проекта.

На мой взгляд, стратегия должна вырабатываться на ту часть продукта (или на весь продукт), который входит в зону ответственности проектной команды. И здесь другого толкования быть не должно. За что отвечаем, на то и распространяем единую стратеги.
Другой вопрос, что могут быть "подстратегии" для различных частей или блоков системы, но они должны вписываться в единую стратегию и подчиняться ей.

Тоже немного отобьюсь :) Проект: биллинговая система. Есть отдельный и крайне навороченный модуль математики рассчёта потреблений, потерь електро енергии. Есть в этом же проекте графический редактор, есть модуль формирования отчётности. Разработка идёт местами параллельно, местами один модуль откладывается весь тим перебрасывается на другие задачи, есть сторонняя сисема с которой мы интегрируемся как с сервисом. Стратегия тестирования в этом случае на весь проект будет достаточно общая и мало интересная на практике.

Так вот в моем понимании этот факт так же должен быть отражен в стратегии тестирования проекта.

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

Давай рассмотрим примеры.

1. Нам поручено тестировать велосипед и мопед. Это два различных проекта. Каждый из них может имееть свою тестовую стратегию и тест план.

2. Мы тестируем велосипед. Причем не весь, а только некоторые новые детали - сидение и спидометр. Это единый проект, который имеет единый срок выпуска, т.е. когда нужно сдавать весь велосипед.

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

Итак, стратегия тестирования может быть следующей:

Общая цель тестирования - провести тестирование новых версий объектов на соответствие требованием, при этом седло имеет более высокий приоритет над спидометром.

Поэтому при выпуске новой версии седла загрузка распределяется следующим образом - 100% ресурсов проводят приемочные тесты, что бы определить, что седло тестопригодно. При выпуске новой версии спидометра загрузка распределяется следующим образом - 50% ресурсов тратится на проверку тестопригодности спидометра, остальные работают на тестирование седла.

После приемке объектов в тестирование ресурсы распределяются следующим образом: 70% - седло, 30% - спидометр.

При проведении тестирования седла необходимо добиться следующих показателей:
седло - покрытие требований не менее 90% ,
спидометр - не менее 60%.

К моменту выпуска велосипеда объекты:
седло - не должно иметь не проверенных багов с высокой и средней степенью критичности;
спидометр - не должен иметь не проверенных багов с высокой степенью критичности, может иметь не более 15% багов со средней степенью критичности.

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

[barancev]

Я так понимаю, что участники дискуссии разделились (грубо говоря) на два лагеря по отношению к тому, что есть стратегия:

-- одни считают, что под стратегией понимается план высокого уровня (стратегический план)
-- другие считают, что под стратегией понимается обобщенная схема действий (метод)

Надо бы определиться, что же иметь в виду под стратегией, иначе будет, как сказал Слава -- одни про Фому, а другие им про Ярёму.

Лично я отношу себя ко второму лагерю.

Мне достаточно близко то, что понимается под стратегией в военном деле. Это проработанные схемы ведения боевых действий. Посмотрите, например, описание ряда существующих стратегий здесь: http://www.voina-i-m...

[Green]

Я так понимаю, что участники дискуссии разделились (грубо говоря) на два лагеря по отношению к тому, что есть стратегия:

-- одни считают, что под стратегией понимается план высокого уровня (стратегический план)
-- другие считают, что под стратегией понимается обобщенная схема действий (метод)

Надо бы определиться, что же иметь в виду под стратегией, иначе будет, как сказал Слава -- одни про Фому, а другие им про Ярёму.

Лично я отношу себя ко второму лагерю.

Мне достаточно близко то, что понимается под стратегией в военном деле. Это проработанные схемы ведения боевых действий. Посмотрите, например, описание ряда существующих стратегий здесь: http://www.voina-i-m...

Тоже поддерживаю второй вариант. Тем более что он может легко быть трансформирован в первый, а вот обратный процесс противоречит логике.

[Case]

1. Нам поручено тестировать велосипед и мопед. Это два различных проекта. Каждый из них может имееть свою тестовую стратегию и тест план.

Пример не того :) Тут не 3-4 разных проекта обьединённых логически в один солюшн, это модули нашей одной системы. По сути своей просто разделы АРМа.

Дальнейшая логика понятна, я просто про пример 5 копеек вставил.