fbpx
Software Testing 2.0. Часть первая. Введение

Software Testing 2.0

Прошло уже много лет с тех пор, как 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!

Обсуждение (0)

Leave a Reply

Your email address will not be published. Required fields are marked *

Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online