На входе:
1.) десктопное клиентское приложение, написанное под win, работающее с ms outlook и синхронизирующее данные между outlook и внешней crm системой через http/syncml. продукт, к сожалению, не коробочный.
2.) клиентское приложение должно без проблем устанавливаться и работать на следующих конфигурациях:
— windows: 2000, xp, vista (home, business)
— ms office: 2000, xp (он же 2002), 2003, 2007
— железо: x86, x64
3.) человеческий qa тестер есть в количестве 1. максимум 2.

Вопрос: как обеспечить надежное тестирование приложения на всех сочетаниях указанного хотя бы софта (для начала, железо — потом)? ведь получаются минимум 16 конфигураций:

x86 — win 2000 — office 2000
x86 — win 2000 — office 2002
x86 — win 2000 — office 2003
x86 — win 2000 — office 2007

x86 — win xp — office 2000
x86 — win xp — office 2002
x86 — win xp — office 2003
x86 — win xp — office 2007

x86 — win vista home — office 2000
x86 — win vista home — office 2002
x86 — win vista home — office 2003
x86 — win vista home — office 2007

x86 — win vista business — office 2000
x86 — win vista business — office 2002
x86 — win vista business — office 2003
x86 — win vista business — office 2007

Часть из них, например vista business + office 2000 или win2000 + office2007, кажутся менее вероятными, но тем не менее список конфигураций все равно велик.

Нужны идеи ответа на вопрос выше.

Сам вижу, пожалуй следующее, пока не радует:
1.) бета-тестирование широкой аудиторией (это наверное был бы самый лучший способ, тестируются параллельно все конфигурации, но он хорошо работает только с коробочными продуктами), но у заказчика просить такую аудиторию не кажется логичным, а внутренними ресурами обойтись врядли удастся (т.к. qa = 1 чел).
2.) заготовить набор виртуалок под каждую конфигурацию и заставить внутреннего qa периодически переключаться между ними и вручную гонять смоук тест (частичная автоматизация тестирования есть, но не покрыта как минимум инсталляция, а это важно). Минусы: ограниченным кол-вом людей тестить на виртуалках кажется неэффективно. Нужно добавлять тестеров и менять виртуалки хотя бы частично на реальные железные компы с идентичной конфигурацией, первое позволяет распараллелить, а второе экономит время на закачку/запуск виртуальных образов.

Буду благодарен за любые советы, а также за ссылки на ресурсы, которые освещают подобную тему.

ika>2.) заготовить набор виртуалок под каждую конфигурацию и заставить внутреннего qa периодически переключаться между ними и вручную гонять смоук тест (частичная автоматизация тестирования есть, но не покрыта как минимум инсталляция, а это важно). Минусы: ограниченным кол-вом людей тестить на виртуалках кажется неэффективно. Нужно добавлять тестеров и менять виртуалки хотя бы частично на реальные железные компы с идентичной конфигурацией, первое позволяет распараллелить, а второе экономит время на закачку/запуск виртуальных образов.

у МС кроме VirtualPC есть ещё и Virtual Server 2005 R2 SP1, позволяющий запускать виртуалки на сервере и работать с ними чуть ли не через ИЕ.

Здравствуйте, ika, Вы писали:

ika>На входе:
ika>1.) десктопное клиентское приложение, написанное под win, работающее с ms outlook и синхронизирующее данные между outlook и внешней crm системой через http/syncml. продукт, к сожалению, не коробочный.
ika>2.) клиентское приложение должно без проблем устанавливаться и работать на следующих конфигурациях:
ika> — windows: 2000, xp, vista (home, business)
ika> — ms office: 2000, xp (он же 2002), 2003, 2007
ika> — железо: x86, x64

Разбейте ваше приложение на части, поведение которых реально зависит от ОС, версии офиса и разрядности платформы. Например, можно один раз протестировать *установку* на каждую платформу без учета офиса, и один раз — взаимодействие с каждым офисом без учета платфомы.
Число вариантов сразу сократится.

Учтите особенности платформ, например, то, что ядро у WinXP 64 и Win2003 x64 практически одно, а отличия меджу Vista Home и Vista Business, способные повлиять на ваше приложение, скорее всего будут несущественными. Узнайте у заказчика типовые конфигурации — их должно быть не очень много, если продукт некоробочный.

Если и это не поможет, возьмите любой инструмент для pair-wise тестирования, только сначала разберитесь, какие риски вы при этом можете получить.

Здравствуйте, ika, Вы писали:

ika>Вопрос: как обеспечить надежное тестирование приложения на всех сочетаниях указанного хотя бы софта (для начала, железо — потом)? ведь получаются минимум 16 конфигураций:

Классы эквивалентности? Вот небольшое введение: http://www.intuit.ru/department/se/verify/5/2.html
Если вы хорошо знаете свой продукт, то сможете снизить количество комбинаций, группируя их по признаку идентичности работы приложения.

Правда, время от времени высказываются сомнения по поводу разумности такого подхода. Вот одно из них: http://blogs.msdn.com/imtesty/archive/2008/09/30/equivalence-class-partitioning-is-it-real-or-is-it-a-figment-in-our-imagination.aspx

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

Спасибо за ответы.
Почитал обзоры Virtual Server, если правильно понял — то штука действительно подходящая, по крайней мере способная снизить объем работы по переключению виртуалок традиционно выполняемый тестером вручную.
Насчет сокращения количества конфигураций — согласен, с админом пройдемся по списку и вычеркнем лишнее, это сократит мои требования к ресурсам для testing farm .
Насчет разбиения приложения на этапы и отдельное тестирование — теоретически конечно возможно, но мне кажется что объем работы по реализации такого механизма будет сопоставим (по кр мере в конкретном обсуждаемом приложении), а то и больше, с объемом работы, затраченным на разработку самого приложения. В этом контексте мне интуитивно кажется, что сокращение числа конфигураций до наиболее значимых и виртуализация их на VS (с возможностью программного удаленного управления, что, как я понял, существует) — это более простой способ. Запускать полный цикл можно ночами на полном списке виртуалок с поочередным переключением между ними программно через virtual server API. Думаю посмотреть в ближайшее время как это сделать.

Здравствуйте, ika, Вы писали:

ika>Буду благодарен за любые советы, а также за ссылки на ресурсы, которые освещают подобную тему.

я бы меньше обращал внимание на 2000 и office. т.к. MS их уже не поддердивает. А вот X64 систем все больше.

Здравствуйте, Сергей Мухин, Вы писали:
СМ>я бы меньше обращал внимание на 2000 и office. т.к. MS их уже не поддердивает. А вот X64 систем все больше.
Заказчики системы — американцы. Причем основная масса будущих пользователей — независимые агенты большой компании, в количестве 10 тыс челов. Согласен, что 2000 системы выходят из обихода, но по своему недавнему опыту помню, что как только начинаешь меньше внимания обращать на корректность работы под 2к, то тут же находится некий единственный вася, у которого именно 2к и начинается головная боль саппорта.

Здравствуйте, ika, Вы писали:

ika>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>я бы меньше обращал внимание на 2000 и office. т.к. MS их уже не поддердивает. А вот X64 систем все больше.
ika>Заказчики системы — американцы. Причем основная масса будущих пользователей — независимые агенты большой компании, в количестве 10 тыс челов. Согласен, что 2000 системы выходят из обихода, но по своему недавнему опыту помню, что как только начинаешь меньше внимания обращать на корректность работы под 2к, то тут же находится некий единственный вася, у которого именно 2к и начинается головная боль саппорта.

как я вас понимаю

Здравствуйте, ika, Вы писали:

Для этого подходит тулза PICT
http://msdn.microsoft.com/en-us/library/cc150619.aspx

Пример:
Вход

OS: winnt, win2003svr, win2k, winxp
IE: 6.0, 6.1, 7.0
CLR: yes, no
LangVer: English, Russian

Выход

OS    IE    CLR    LangVer
winxp    6.0    yes    Russian
win2k    6.1    yes    English
winnt    6.0    no    English
win2003svr    6.1    no    Russian
win2k    7.0    no    Russian
winxp    7.0    yes    English
win2003svr    7.0    yes    English
win2003svr    6.0    yes    Russian
winnt    7.0    yes    Russian
winnt    6.1    yes    English
win2k    6.0    yes    Russian
winxp    6.1    no    English

Вообще на МСДНе описано что,как и почему.