Все таки вытоил время для топика).
Производственный процесс в нашей компании основан на практиках XP. Что за практики и с чем их едят в принципе описывается на http://exprogramming.ru/ . От себя же добавлю что эти практики были ответами на простейший вопрос "Как создавать софт(да и не только) быстрей, не потеряв при этом качество продукта". Практики весьма полезны и самое главное были придуманы на основе хорошего опыта и рациональных решений.
Подчеркну сразу что не все 12 методик применены в компании по тем или иным причинам. Тем кто хочет внедрить у себя XP посоветовал бы рационально подумать какие из методик им бы подходили, а какие нет.
Весь производственный процесс основан на вербальной коммуникации и здравом смысле, инициатива только приветствуется. Парное программирование, 40 часовая неделя, TDD, рефакторинг, небольшие релизы и т.д. все это присутствует. Но отсутствует методика "заказчик всегда рядом" в силу разных географических местоположений. Вместо этого есть масса альтернативных средств для общения с заказчиком, которые и используются).
Теперь о месте отдела QA в этом процессе.
В цепочке реализации софта наш отдел занимает последнюю стадию, но перед самим заказчиком. Самое главное то, что без одобрения отдела QA билд заказчику не может быть отправлен, если только сам заказчик не согласится с имеющимися недостатками и попросит его нефиксеный.
Деление проекта на мелкие релизы и итерации позволяет оперативно тестировать поставленные задачи. Кроме этого автотесты становятся просто необходимыми при итерационной разработке софта.
Говоря более детально: Любой проект по началу делиться на мелкие итерации, затем каждая итерация делится на мелкие задачи(task). Кроме типа тикета "задачи" имеется и тип задачи defect тобишь баг. Любой тикет проходит тот самый "жизненный цикл" в статусах тикета, а именно: InQueue, InStart, InProgress, NeedTest, FoundBug, Done, DeployedTest, DeployedReal. Значение и предназначение каждого статуса таится в их переводе)).
Trac открыт для самого заказчика, что позволяет ему быть осведомленным о текущих задачах и иметь возможность контролировать их с помощью приоритетов для тикетов.
Каждый тикет в конце концов приходит в статус NeedTest, т.е. в QA-отдел. Перед началом тестирования пишется "test case" и производится само тестирование функциоанала. На тип тикета defect, test case не пишется, поскольку описание бага и должно быть test case-ом.
После него следует статус FoundBug либо Done.
Первостепенной проверкой всегда должна быть проверка на валидность выполненной бизнес логики. Только после этого ручное, юзабилити, crush и регресиионое тестирования.
На последок если вы ищете какова разница построения QA-отдела в Ajile и других типах, то эта статья http://it4business.ru/articles/749/ вам поможет ответить на эти вопросы. В статье описывается то к чему и мы пришли спустя время с начала работы нашего отдела. На сегодня все)
