Экстремальное тестирование

Хотелось бы уточнить название поста. Я хотел бы написать о тестировании в XP команде.
Экстремальное программирование XP базируется на 12 основных практиках:

1. Разработка через тестирование (Test driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Whole team, Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous Integration)
6. Рефакторинг (Design Improvement, Refactor)
7. Частые небольшие релизы (Small Releases)
8. Простота (Simple design)
9. Метафора системы (System metaphor)
10. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
11. Стандарт кодирования (Coding standard or Coding conventions)
12. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Теперь же попробуем проецировать практики на тестирование.

Программисты и QAS в одной комнате

В принципе ситуацию нахождения программистов и тестировщиков в одной комнате можно воспринимать в качестве практики. Естественно у данной практики есть корень. Корнем я бы назвал практику XP, в которой говорится, что команда разработчиков должна находиться в одном помещении. Что это дает разработчикам в результате?

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

Теперь поговорим о ситуации Dev+QAS. В принципе достоинства такого подхода думаю можно понять сразу же после примера с программистами. В команде, занимающейся над проектом, не должно быть людей лишних или мешающих. Все должны работать над одной большой целью:

О Continuous Integration (ci)

Вытаил время для очередного топика. На этот раз захотел написать о таком понятии как Continuous Integration, ну или просто CI. Для тех кто не знает что это такое, то читаем в Wiki . Прочитав можно сразу понять, что понятие ci было впервые озвучено многоуважаемыми Фаулером и Беком в качестве набора базовых практик которые позволяют команде наиболее быстро получать фидбек по работе софта.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...

Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.

Ну в общем то для начала думаю хватит.

Об организации процесса разработки в нашей компании

Все таки вытоил время для топика).
Производственный процесс в нашей компании основан на практиках 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/ вам поможет ответить на эти вопросы. В статье описывается то к чему и мы пришли спустя время с начала работы нашего отдела. На сегодня все)