Как создать качественный процесс тестирования с множеством маленьких п

Добрый день!

Есть игровая компания, которая имеет множество маленьких игровых проектов (флеш игры). Но в компании нет централизированого QA департамента, т.е. специалисты есть но их мало (и в ближайшее время кол-во не увеличится) для того объема работ что есть и многих "дергают" с одного проекта на другой. Интересует ваше мнение по-поводу того, стоит ли вводит график тестировани, или продолжать on-demand тестинг? Как лучше организовать тестирование в таких условиях? Очень нужна ваша помощь.

Добрый день!

Есть игровая компания, которая имеет множество маленьких игровых проектов (флеш игры). Но в компании нет централизированого QA департамента, т.е. специалисты есть но их мало (и в ближайшее время кол-во не увеличится) для того объема работ что есть и многих "дергают" с одного проекта на другой. Интересует ваше мнение по-поводу того, стоит ли вводит график тестировани, или продолжать on-demand тестинг? Как лучше организовать тестирование в таких условиях? Очень нужна ваша помощь.

А вы смотрели слайдшару доклада Максима Дорофеева
http://www.slideshar.../swp2010-part-i
http://www.slideshar...swp2010-part-ii
http://www.slideshar...wp2010-part-iii

Может это наведет вас на мысли как можно организовать работу. Сделайте подобную доску с веревочками, и очередь к каждому тестеру. Пусть начальство видит, что перебросив данного человека на другую работу все его другие задачи из очереди будут задержаны.

LeshaL, спасибо! А где ещё такие презентации можно посмотреть?

LeshaL, спасибо! А где ещё такие презентации можно посмотреть?

Думаю, что именно таких - нигде :) Посмотрите рядом, там других достойных презентаций много. Кстати, анонсы о них регулярно на форуме появляются.

Возможно что-нибудь отсюда вас может заинтересовать.
http://lib.custis.ru

Думаю, что именно таких - нигде :) Посмотрите рядом, там других достойных презентаций много. Кстати, анонсы о них регулярно на форуме появляются.

Возможно что-нибудь отсюда вас может заинтересовать.
http://lib.custis.ru

Тогда уж блог бы тоже рекомендовали http://team.custis.ru/.

Добрый день!

Есть игровая компания, которая имеет множество маленьких игровых проектов (флеш игры). Но в компании нет централизированого QA департамента, т.е. специалисты есть но их мало (и в ближайшее время кол-во не увеличится) для того объема работ что есть и многих "дергают" с одного проекта на другой. Интересует ваше мнение по-поводу того, стоит ли вводит график тестирования, или продолжать on-demand тестинг? Как лучше организовать тестирование в таких условиях? Очень нужна ваша помощь.

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


PS. Если а вас, как и у многих Bottleneck, находится в группе тестирования, то поздравляю: "Не вы первые, не вы последнии допустили эту грубую ошибку управления".

Добрый день!

Есть игровая компания, которая имеет множество маленьких игровых проектов (флеш игры). Но в компании нет централизированого QA департамента, т.е. специалисты есть но их мало (и в ближайшее время кол-во не увеличится) для того объема работ что есть и многих "дергают" с одного проекта на другой. Интересует ваше мнение по-поводу того, стоит ли вводит график тестирования, или продолжать on-demand тестинг? Как лучше организовать тестирование в таких условиях? Очень нужна ваша помощь.

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


PS. Если а вас, как и у многих Bottleneck, находится в группе тестирования, то поздравляю: "Не вы первые, не вы последнии допустили эту грубую ошибку управления".

Уважаемый, нет времени разбираться что такое Bottleneck, но я подозреваю, что вы имеете ввиду каскадную методику разработки ПО.

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

Уважаемый, нет времени разбираться что такое Bottleneck, но я подозреваю, что вы имеете ввиду каскадную методику разработки ПО.

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

Я имел в ввиду разработку с разделением ролей. Для появления проблем достаточно чтобы одна группа верстала HTML, а другая кодила MySQL. Разработка с разделением ролей может выполнять по любому жизненному циклу.

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

Я говорил ровно о том о чем говорил:
1) бутылочное горлышко должно быть на самом дорогом или уникальном участке
2) час потерянный на бутылочном горлышке - это потери всей системы, час потерянный на других участках - это отсутствие потерь. Поэтому: "составляйте наиболее оптимальный график с минимум переключений для бутылочного горлышка, а работу остальных подстраивайте под них, невзирая на потери. "

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

Очень рекомендую книгу "Цель" Э. Голдратта http://www.chaconne....=2205281&ref=fb