Большинство проектов, на которых вам придется работать, скорее всего, будут Agile.
Индустрия разработки программного обеспечения все больше склоняется к соблюдению этой парадигмы, а классический Waterfall продолжает терять свою актуальность.
Почему так происходит — тема для отдельной статьи. Единственное, что вам нужно знать — это так, и именно поэтому каждому тестировщику нужно знать отличия процесса тестирования согласно основам Agile.
Как было раньше
Раньше все происходило очень последовательно и очевидно. Сначала происходила инициация проекта, то есть подготовка к его реализации. Потом собственно разработка программного обеспечения. И только после этого продукт попадал в руки команды тестирования, которая проверяла его на работоспособность, соответствие требованиям, удобство и т.д. Тестировщики имели доступ к готовому продукту и были последним звеном перед релизом продукта.
Такой подход кажется очень понятным и рациональным, когда речь идет о разработке продукта, к которому мы имеем очень четкие требования, сроки, бюджет и вообще имеем представление о том, как его разрабатывать. Однако вся эта схема становится не такой уж логичной, когда мы переходим к разработке инновационных вещей, нуждающихся в регулярном обновлении, корректировке и т.д. И, конечно, регулярном тестировании.
Основные отличия
Вот, в принципе мы и подобрались к первому и, пожалуй, основному отличию. При разработке по Agile, мы имплементируем процесс тестирования во весь проект, от его начала до самого конца. Тестирование функционала происходит в течение каждого спринта или итерации разработки программного обеспечения. Пока разработчики разрабатывают, тестировщики тестируют.
Второе отличие — тестировщики перестают быть отдельным изолированным юнитом и становятся частью команды разработки. Они на более ранних этапах начинают свою работу, ближе сотрудничают с разработчиками и привлекают всех участников проекта к контролю качества продукта. Часто на таких проектах тестировщики также принимают участие в формировании требований к продукту, ориентируясь на потребности пользователя.
Методы тестирования согласно Agile
- Acceptance Test Driven Development (ATDD). Если упрощенно, это когда мы сначала разрабатываем приемный тест, а затем разрабатываем такой функционал, который может его пройти. Этот метод базируется на тесном сотрудничестве тестировщика, разработчика и пользователя (или бизнес-аналитика). Вместе они должны согласовать между собой требования к продукту и описать сценарии, по которым он будет работать. Только после этого разработчики могут переходить к работе, когда мы точно знаем, как должна быть реализована определенная функция.
- Behaviour Driven Development (BDD). Предыдущая методология помогает нам в разработке определенного модуля, но не учитывает взаимодействие этих условных частей продукта. Именно для этого была разработана BDD методология, основная отмена которой состоит в том, что та же команда из разработчиков, тестировщиков и пользователей создают сложные сценарии, пытаясь предсказать поведение пользователя. Эти сценарии и выполняют роль главных требований к разработке продукта.
- Исследовательское тестирование. Один из самых креативных и интересных подходов к тестированию в целом. Оно предполагает совмещение этапа тест-дизайна с самим прохождением и позволяет тестировщику быть хаотичным и более приближенным по своему поведению к реальному пользователю. Этот способ помогает освежить взгляд на продукт и сэкономить время на документацию, ведь при соблюдении именно такого подхода, тестировщик не фиксирует что и как он проходил, только найденные дефекты. Способов проведения исследовательского тестирования множество, а их раскрытие требует еще одной статьи, поэтому советую вам поинтересоваться этим вопросом по случаю.
- Сессионное тестирование. Это, прежде всего, способ управления и систематизации исследовательского тестирования. Хаотичность имеет свои преимущества, но в рамках проекта все же должна быть обуздана. В рамках этого подхода процесс тестирования разбивается на сессии, каждая из которых имеет свою цель, ограничена по времени и предполагает проведение анализа полученных результатов. Такое структурирование хаотического тестового опыта иногда дает очень потрясающие результаты.
Выводы
В конце этой небольшой статьи я хотел бы отметить то, что, по моему мнению, больше всего отличает тестирование по Agile — что это попытка тестировщика отойти от амбиций «проверить все» и приблизиться к работе с тем функционалом, который действительно важен для пользователя.
Это попытка тестировщика не просто бессмысленно находить все новые и новые баги, а искать те, которые действительно критичны для бизнеса. Это разумная и ответственная приоретизация и работа на продукт и команду, а не против нее.
Именно это и есть воплощение принципов Agile.
