пять баллов, попробуйте найти способ разбить ее на две истории, масштабом в три и два балла. Еще лучше, если у вас получится разделить ее на пару историй по два балла и одну с оценкой в один балл. Поначалу это может показаться сложной задачей, но, как и в большинстве других вещей, со временем это будет получаться все лучше и лучше. Если вы не в состоянии фрагментировать пользовательскую историю, разработчикам следует попытаться разбить ее на отдельные задачи. Если это вызывает проблемы, начните с перечисления шагов, которые планируется предпринять в ходе разработки.
Разбиение пользовательских историй на более мелкие части и задачи позволяет сократить число возможных ошибок. Этот процесс обычно сопровождается более детальным рассмотрением и обдумыванием, что также снижает степень неопределенности и сопутствующие риски. Разбивая историю на фрагменты, вы можете понять, что какие-то из получившихся частей имеют большую важность, чем другие. Это может помочь вам в правильной расстановке приоритетов. Тот же совет применим и к Канбану, даже если вы не проводите оценку масштаба пользовательских историй в баллах. Просто попробуйте разбить карточки, относящиеся к объемным заданиям, на несколько более мелких.
До этого момента речь шла об использовании методов Agile в проектировании и разработке. Еще одной важной частью процесса создания продукта является тестирование, когда вы проверяете качество результата, полученного в ходе разработки, прежде чем представить его заказчикам. Тестирование – это составляющая часть обеспечения качества, более широкой дисциплины, связанной с созданием высококачественных рыночных продуктов.
Гарантия качества
Программные продукты являются сложными по своей природе. Лишь в очень редких случаях они работают на 100 % идеально, поэтому вам необходимо иметь некий план обеспечения качества продукта, прежде чем вы начнете предлагать его покупателям. Отсутствие должного контроля за качеством продукта может привести к головным болям, которые могут обеспечить раздраженные клиенты, потеря дохода и невосполнимые потери ресурсов команды.
Максимально быстрое выявление дефектов – это один принципов бережливого производства, который позволяет сократить количество отходов. Серьезная ошибка, которая обнаруживается уже после запуска продукта, обходится гораздо дороже, чем ошибка, выявленная в ходе разработки. Во-первых, запоздалое обнаружение ошибок вызывает негатив со стороны клиентов. Во-вторых, команде обычно требуется больше времени на выяснение первопричин и исправление ошибок, поскольку к этому моменту они уже прекратили активную работу с программным кодом этого продукта. В-третьих, проблемы клиентов сохраняются до тех пор, пока ошибка не будет исправлена и вы не обеспечите их исправленной версией продукта.
Тестирование должно играть в этом вопросе важную роль, но существуют и другие способы повысить качество программного обеспечения. Стандарты программирования помогают разным разработчикам, работающим в одной команде, избежать произвольных стилистических различий и обеспечить согласованность подходов к созданию программного кода. Это безусловно способствует устранению некоторых причин, которые могут привести к проблемам с качеством продукта. Стандарты программирования также в значительной мере облегчают понимание разработчиком кода, написанного другим разработчиком, что упрощает процессы отладки и обслуживания, а также повышает эффективность разработки.
Обзор кода другим разработчиком помогает обнаружить ошибки, пропущенные его коллегой. Кроме того, он часто может предложить хорошие идеи по улучшению написанного кода. Такие проверки позволяют находить и исправлять ошибки до начала этапа тестирования и являются отличным способом учиться друг у друга.
Еще одним шагом в том же направлении является парное программирование – это метод, предусматривающий, что созданием программного кода одновременно и совместно занимаются сразу два разработчика. Они сидят рядом друг с другом за одним компьютером и клавиатурой, глядя в один и тот же экран. Разработчик, которому досталась роль «драйвера», занимается непосредственным написанием кода. Второй разработчик играет роль «наблюдателя» и просматривает код по мере его создания партнером. Затем они меняются ролями. Работа в паре способствует обучению и обычно приводит к улучшению дизайна и качества продукта. Парное программирование – это центральный принцип экстремального программирования, еще одной популярной методологии Agile.
Возвращаясь к теме обеспечения качества продукта, стоит отметить, что существует два основных типа QA-тестирования: ручное и автоматизированное. При ручном тестировании один или несколько человек проверяют функционал продукта, чтобы убедиться, что он работает должным образом. Ручное тестирование также называют тестированием по методу «черного ящика», потому что тестировщику не требуется иметь представление о том, как был создан продукт или какая технология лежит в его основе. Во многих компаниях имеются выделенные специалисты по контролю качества, нанятые на полный рабочий день. В компаниях, которые не могут себе позволить содержание профессиональных тестировщиков, бремя выполнения их функций ложится на других членов команды (чаще всего, разработчиков и менеджеров по продуктам). В таких случаях разработчики часто вынуждены тестировать свой собственный код. Одним из преимуществ наличия выделенных специалистов по контролю качества является то, что они с большей вероятностью обнаружат ошибки и недочеты, чем сам создатель проверяемого кода, поскольку проводят проверку свежим взглядом. Кроме того, выделенные специалисты обычно проводят тестирование более тщательно. Это объясняется тем, что, во-первых, это их основная работа и, соответственно, у них есть больше времени на ее проведение. Во-вторых, хорошие специалисты по контролю качества подходят к тестированию системно, что позволяет проводить проверку по большему количеству параметров. В-третьих, квалифицированные специалисты по контролю качества знакомы с проблемными местами программного обеспечения и распространенными ошибками, поэтому им бывает проще их обнаружить.
При автоматизированном тестировании используется специальное программное обеспечение, позволяющее сравнивать фактические результаты работы функций с ожидаемыми. Изначально набор необходимых автоматизированных тестов создается членами команды (разработчиком или тестировщиком), после чего готовые тесты можно запускать в любое время. Каждый раз при выполнении генерируется отчет, сообщающий, какие из тестов прошли успешно, а какие закончились неудачей. Одним из преимуществ автоматизированного тестирования является то, что оно позволяет значительно сэкономить ваше время, особенно в тех случаях, когда есть необходимость проводить проверки с регулярной частотой. Однако имеется и потенциальный риск, обусловленный тем, что автоматизирование тестирование хорошо лишь настолько, насколько качественно оно запрограммировано. Если команда не напишет тестовые примеры для какой-либо функции, она останется непротестированной. При проведении тестирования в ручном режиме тестировщик, применяя свой интеллект и творческий подход, осуществляет проверку функционала в том числе с использованием таких условий и комбинаций событий, которые отсутствуют в автоматизированных тестовых примерах. Открытия, сделанные в ходе ручного тестирования следует использовать для добавления соответствующих примеров в автоматизированные тесты. Кроме того, тестовые примеры, на которых построена автоматизированная проверка, должны быть актуализированы каждый раз после внесения изменений в функционал или пользовательский интерфейс продукта.
При создании нового или внесении улучшений в существующий функционал продукта необходимо провести проверку двух различных аспектов. Для этого применяют два вида тестирования. Первый, называемый валидационным тестированием,
