Тестирование

Разработка более высокого качества с помощью гибких (agile) методов тестирования

Все еще есть необходимость в ручном тестировании, но не так, как вы думаете!

Управление проектом Waterfall разделяет разработку и тестирование на два этапа: разработчики создают функцию, а затем «бросают ее через стену» группе обеспечения качества (QA) для тестирования. Команда QA пишет и выполняет подробные планы тестирования. Они также регистрируют дефекты при тщательной проверке регрессий в существующих функциях, которые могли быть вызваны новой работой.

Многие команды, использующие этот водопад (waterfall) или другие традиционные модели тестирования, обнаруживают, что с ростом продукта объем тестирования растет в геометрической прогрессии, и обеспечение качества  (QA) неизменно изо всех сил старается не отставать. Владельцы проекта сталкиваются с нежелательным выбором: отложить выпуск релиза или сэкономить на тестировании. (Я дам вам одно предположение о том, какой вариант выигрывает в 99% случаев.) Между тем, разработка перешла на что-то другое. Таким образом, не только растёт техническая задолженность, но и устраняется каждый дефект, требующий дорогостоящего переключения контекста между двумя частями базы кода. Оскорбление, встреча травмы.

Что еще хуже, команды обеспечения качества (QA)  традиционно получают вознаграждение в зависимости от того, сколько ошибок они находят, что ставит разработчиков в оборону. Что, если бы как разработчики, так и QA могли найти лучший способ уменьшить количество багов в коде, одновременно устраняя те болезненные компромиссы, которые приходится делать владельцам проектов? Разве это не создаст лучшее универсальное программное обеспечение?

Введите agile  тестирование.

 

Переход от традиционных методов тестирования к agile

Целью agile команды разработчиков является устойчивое предоставление новых функций с качеством. Команды, которые переходят в Agile, часто борются с тем, как включить время тестирования со скоростью Agile. Это законный вызов, потому что традиционные методологии тестирования просто не вписываются в agile контекст. Темпы развития требуют нового подхода к обеспечению качества в каждой сборке. В Atlassian  способ тестирования - agile. Подробно рассмотрите наш подход к тестированию вместе с Пенни Уайатт, старшим руководителем отдела обеспечения качества Jira Software.

ВИДЕО

Подобно тому, как накапливается задолженность по кредитным картам, она начинается с небольшого количества боли, но быстро развивается как снежный ком - и подрывает команду в  критической гибкости. Для борьбы с техническими проблемами, связанными со снежным комом, в Atlassian мы даем возможность (нет, ожидаем) нашим разработчикам стать великими борцами за качество. Мы считаем, что разработчики привносят ключевые навыки, которые помогают повысить качество продукта:

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

Мы считаем, что каждая пользовательская история в списке необходимых требований (backlog) требует как кода функции, так и кода автоматического тестирования. Хотя некоторые команды присваивают разработчикам код функции, в то время как группа тестирования проводит автоматическое тестирование, мы считаем, что эффективнее иметь одного инженера для доставки полного набора.

 

Эта модель не означает, что разработчики работают в одиночку. Также важно иметь в команде инженеров обеспечения качества (QA). Обеспечение качества (QA)   дает важную перспективу в разработке функции, и хорошие инженеры обеспечения качества (QA) знают, где обычно прячутся баги, и могут посоветовать разработчикам возможные ошибки.

Человеческое прикосновение через пробные испытания

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

 

Но не является ли предварительное тестирование ручным тестированием? Нет. По крайней мере, в том же смысле, что и ручное регрессионное тестирование. Исследовательское тестирование - это основанный на оценке риска подход к тестированию, позволяющий тестируемому использовать свои знания о рисках, деталях внедрения и потребностях клиентов. Знание этих вещей на ранних этапах процесса тестирования позволяет разработчику или инженеру по обеспечению качества быстро и всесторонне находить проблемы, не прибегая к помощи сценариев тестирования, подробных планов тестирования или требований. Мы находим, что это гораздо эффективнее, чем традиционное ручное тестирование, потому что мы можем перенять результаты сессий поискового тестирования на исходный код и автоматизированные тесты. Исследовательское тестирование также учит нас опыту использования этой функции так, как это не делает сценарий.

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

Изменения могут быть трудными - очень трудными

Я познакомлю вас с личной историей, которая приятно подводит итог моего путешествия с agile тестированием. Я помню, как в начале своей карьеры руководил командой инженеров, которые сильно сопротивлялись написанию автоматических тестов, потому что «эта работа была для обеспечения качества  QA». После нескольких итераций с ошибочным кодом и выслушав все причины, по которым автоматическое тестирование может замедлить работу команды, я поставил условие: весь новый код должен был быть проверен с помощью автоматических тестов.

После одной итерации код начал улучшаться. И разработчик, который был самым непреклонным против написания тестов, оказался тем, кто вступил в действие, когда тест провалился! В течение следующих нескольких итераций автоматизированные тесты росли, масштабировались по браузерам и улучшали нашу культуру разработки. Но ошибки и доработки значительно сократились, в итоге мы сэкономили огромное количество времени. Изменить редко легко. Но, как и большинство стоящих вещей, если вы можете пристегнуться и создать для себя новые шаблоны, единственный вопрос, который у вас останется: «Почему мы не сделали это раньше ?!»

По материалам Agile Coach "Testing"