QA о двух головах

Подсткажите, пожалуйста, может кто уже сталкивался с такой ситуацией.

В отдел тестирования приходят в основном два потока задач:
1) тестирование новых разроботок, которые должны пройти весь путь еще до появления их в продуктах
2) тесты продуктов, функционал которых уже проверен. Тут тестируется в основном компонентность продукта, локализация и прочее, что делает набор бинарников похожим на продукт для пользователя.
Есть вопрос, а будет ли иметь смысл поделить отдел тестирования на две части и одна будет тестировать глубоко функционал и все новое, а часть будет проверять именно продукт перед его выходом.
Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.

Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.

Вы сами ответили на свой вопрос.
Через очень непродолжительное время у вас разбегуться все, кто делает "черную" работу - тестирует изменения.

Это и есть глобальный подход.

Работать нужно в рамках одного отдела. Если Вы считаете, что задачи по доработке продукта не требуют глубоких знаний и навыков, используйте для этого начинающих тестировщиков. Постройте на этих задачах "школу по подготовке к настоящей работе" ( ).

Идея Vasiliy вполне здравая.
Отдел наверно громко сказано, я бы выделил группу, которая отвечает за итоговую проверку релиза: комплектность поставки, наличие локализации, наличие библиотек под конкретную платформу и т.п.
Обеспечил бы ротацию между теми, кто занимается функциональным тестированием, и теми, кто выполняет итоговую проверку продукта.
Выделение этой новой группы, выделение руководителя группы, поднимет важность этого направления тестирования.

А на счет "черной" работы... не преподносите работу как "черную", и она такой не будет.

А на счет "черной" работы... не преподносите работу как "черную", и она такой не будет.

Работа будет такой, какой она есть. Как бы вы ее не называли.

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

Мой вам совет. Не разделяйте людей (только если их количество не превышает критический уровень). Если людей уже много и один человек не может справиться с вопросами управления. Тогда стоит ввести разделение по проектному принципу. Есть проект - есть команда.

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

Создавать отдел для задвинутых (не продвинутых) никто не предлагал.

Вопрос сейчас именно в глобальном смысле, темы вроде "постоянно тестировать одну локализацию скучно" пока что в стороне.

Вы сами ответили на свой вопрос.
Через очень непродолжительное время у вас разбегуться все, кто делает "черную" работу - тестирует изменения.

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

Работать нужно в рамках одного отдела. Если Вы считаете, что задачи по доработке продукта не требуют глубоких знаний и навыков, используйте для этого начинающих тестировщиков. Постройте на этих задачах "школу по подготовке к настоящей работе" ( ).

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

Мой вам совет. Не разделяйте людей (только если их количество не превышает критический уровень). Если людей уже много и один человек не может справиться с вопросами управления. Тогда стоит ввести разделение по проектному принципу. Есть проект - есть команда.

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

Создавать отдел для задвинутых (не продвинутых) никто не предлагал.

Под луной имеется многое из никем не предложенного.

Подсткажите, пожалуйста, может кто уже сталкивался  с такой ситуацией.

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

Основной вопрос: то, что вы хотите проверять (локализация и т.п.) появляется в продукте позже, после того как продукт уже выпущен и работоспособен? Или это все-же изначальная часть продукта и вы хотите именно тестирование разделить на 2 части?
Если второе, то не самый лучший вариант, по-моему. Я бы предложил максимально автоматизировать те вещи, которые вы отнесли к пункту 2. Тем более, что это вроде бы не так уж и сложно. Более того, при попытке автоматизировать эту проверку, возможно вы выдвинете свои требования к разработке.

Локализация появляется в уже существующем продукте. Считается(в большинстве случае), что функционал уже протестирован на этот момент.
Автоматизированное тестирование не сильно распространено и покрывает в основном именно функционал продукта.

Локализация появляется в уже существующем продукте. Считается(в большинстве случае), что функционал уже протестирован на этот момент.

Совсем не всегда так. Локализация может быть заложена изначально как один из аспектов функциональности. Лично тестировал приложение с 3-мя языками, но при этом ещё даже без дизайна и половины функций: то есть голые ссылки вместо кнопок, нет нескольких функций типа экспортов и валидаций, но перевод уже прикручен.

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