2c4wr

Видим следующие проблемы при организации нового подразделения:
1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?

Есть main product - набор всех функций.
Есть customer product * n (n - количество кастомеров)
Тестируется как главный продукт, так и для каждого кастомера в отдельности. Тк различная комбинация функций - может вызывать различное поведение и соответственно разные баги.
Это, конечно, если вы хотите избежать лишних разговоров с заказчиками.

"1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?"

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

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

В первую очередь нужно наладить процесс тестирования в том смысле, что бы приложение развернулось, прошел какой-то sanity тест, и об этом пошло уведомление далее по CI. Когда система будет работать, можно будет добавлять тесты, обновлять тесты. Но подобную систему спроектировать и наладить должен опытный QA - лид, который сперва разберется в продукте и сможет сделать достаточно гибкую систему, в которую впоследствии можно будет запизхнуть все тесты и все конфигурации.

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

Должны быть тесты, которые мало зависят от версии. Должна быть возможность быстро отключать неактуальные тесты. Тесты не являются самоцелью, они являются дополнительной метрикой качества продукта и упрощения разработки за счет автоматизации. Ведь можно что-то не тестировать, а при этом оно будет работать, потому что тестировалось разработчиком в юниттестировани.
Ну и понятно, что с опытом прийдет понимание сколько и что нужно тестировать, чтобы успевали. Будет много - откинете некритичную часть.

Возьмите опытоного QA и он все вам расскажет, как надо делать.

>1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?

На наиболее часто встречающихся или приносящих основной доход.

>2) К конструктору нет четкой спецификации (и не будет в данный момент), лишь список задач в баг-трекере, а значит тестировщикам непонятно что тестировать. Можно попробовать писать тесты на новые задачи и постепенно они покроют все, потихоньку добавлять тесты на функционал, который не попадает в новые задачи. Сработает ли?

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

>3) Превышение возможностей подразделения по поддержанию тестов в актуальном состоянии. Скорее надуманная проблема, но тем не менее, может ли получится так, что тестов станет слишком много и при выходе новой версии продукта тестировщики не будут успевать актуализировать тесты под изменившуюся платформу?

Это уже проблемы отдела тестирования и того как они будут решать задачу, но в целом такая проблема есть, но без конкретитки тут говорить нечего.
Я знаю системы где 10к тестов держит один человек, и системы где 100 тестов поддерживает отдел из 6-7 человек.