Прошло уже много лет с тех пор, как Agile пришел в нашу жизнь. Этот переход многим дался нелегко. Всем членам команды пришлось учиться работать заново. Ведь работать приходилось в более динамичных и гибких условиях. Никто не остался незамеченным: бизнес аналитики, программисты, дизайнеры. Даже заказчиков заставили быть Product Owners и тесно взаимодействовать с командой. Сама разработка стала быстрее в разы, ведь теперь основной целью стал один из принципов “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. В таком ускоренном режиме вопрос тестирования стал ребром.

Давайте возьмем пример среднего Agile проекта. Работа идет по методологии Scrum, 4 разработчика, Scrum-мастер, Product Owner и тестировщик. Планирование, двухнедельные итерации, демонстрация результатов в конце каждой итерации. При этом, с инженерной стороны есть система сборок и набор тестов. Разработчики пишут модульные и интеграционные тесты, но до UI у них дела нет, мотивируя это тем, что тесты хрупкие и не дают быстрого результата.

Зачастую так продолжается до возникновения первых проблем. Самая типичная проблема – это поставка новой версии системы с дефектами. Когда клиент обнаруживает эти дефекты, команда задумывается, каким образом можно повысить качество продукта перед поставкой. Можно предположить несколько вариантов:

• Повысить качество разрабатываемого кода путем внедрения дополнительных XP практик. Например, внедрение тестов на уровне UI, code review, парное программирование.
• Попросить заказчика тестировать готовые задачи и заводить баги на этапе разработки.
• Нанять инженера по тестированию, который будет отвечать за поиск дефектов в продукте до релиза на систему клиента.

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

Примечание: На самом деле первый вариант и является правильным ответом, но мне кажется, что современные разработчики еще не научились поставлять код без дефектов. А получится это только тогда, когда программисты будут знать о тестировании не меньше самих тестировщиков! Замечательное виденье будущего тестирования описал Джеймс Виттакер в серии одноименных публикаций. Ознакомиться с переводом статьи можно по ссылке.

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

Все сводится к третьему варианту, когда принято решение привлечь к команде инженера по тестированию.

Здесь тоже не все так гладко. Большинство тестировщиков привыкли работать в традиционной среде, где тестирование – это отдельный этап и должен быть тщательно спланирован. На практике это выглядит следующим образом:

• этап написания тест плана;
• этап тест дизайна, написания тестовых сценариев;
• этап тестирования и оповещения о дефектах;
• этап регрессионного тестирования.

Применяя классический подход тестирования к Agile проекту, мы получаем мини-водопад внутри итерации и те самые проблемы, которые возникали и раньше:

• о тест плане, на который было потрачено время, быстро забывают;
• тестовые сценарии, которые были написаны, устаревают;
• тестирование осуществляется хаотично и оценивается лишь по количеству найденных дефектов;
• тестировщикам приходится работать в режиме “пожарника” каждый день.

В конечном счете, все сводится к тому, что тестировщик не справляется с объёмом задач, перед ним стоящим. Решить эту проблему команда пытается путем найма еще одного тестировщика, а затем еще одного. Но основная проблема остается нерешенной – это поддержка тестовой документации. В которую, зачастую, никто кроме самих тестировщиков не смотрит.

Мы зашли в тупик. Что делать в таком случае? Переходить на чеклисты, ментальные карты или внедрить еще какую-то практику?

Давайте для начала дадим ответы на несколько вопросов. Что самое интересное для тестировщика? Что приносит кайф в его работе? Да, именно – это сам процесс тестирования! Это процесс проверки, конфигурации, исследования приложения на ошибки.

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

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

Вторая идея – научить тестировщиков работать больше. Использовать сильные стороны каждого тестировщика для достижения продуктивной работы всей команды. Оптимизировать процесс тестирования с использованием подходов, которые будут применимы в нужном контексте проекта.

Software Testing 2.0 – это не панацея и не открытие Америки. Это попытка систематизировать и направить развитие нового подхода в тестировании программного обеспечения, который позволит командам и тестировщикам в частности получить быстрые ответы на вопросы:

• Как тестировать в сжатые сроки?
• Как тестировать с неявными требованиями?
• Когда стоит автоматизировать?
• Кто должен автоматизировать?
• Что делать, если тестировщики не успевают протестировать все задачи?
• К чему стремиться при построении гармоничного процесса тестирования?

Это и многое другое я буду описывать в дальнейших публикациях на тему Software Testing 2.0. Мы будем говорить о разных моментах и историях из реальных проектов.

Следите за новостями в вашем городе, если хотите послушать эту информацию из первых уст. Жители Киева и Днепропетровска первыми смогут посетить серию докладов и тренингов на тему Software Testing 2.0 и смежным тематикам.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!