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

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

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

Второй этап использует тесты, созданные на первом этапе, для автоматизации приемочных критериев. В том, что их было бы неплохо автоматизировать, никто не сомневается. Вопрос лишь в инструментах и техниках автоматизации. Тут и начинается самое интересное. Можно использовать специализированный инструмент как FitNesse или Concordion. Преимуществ у такого рода инструментов три. Первое преимущество заключается в том, что с ними могут работать не только программисты. Конечно же помощь программистов понадобится на каком-то этапе, но можно произвести разделение процесса создания тестов. То есть появляется отделение процесса создания тестов от непосредственно программирования. Сторонним эффектом является то, что при изменениях в приложении не будут меняться сами тесты. Вместо этого будет изменяться программный код для соединения этих тестов с приложением. Второе преимущество заключается в том, что данные инструменты заставляют вас разработать DSL (доменный язык) для вашего приложения. Разработка этого языка позволяет вам писать новые тесты без привлечения разработчиков, а также дает представление о имеющихся возможностях системы. Последнее преимущество заключается в возможности хранить тесты вместе с требованиями и запускать их прямо из требований. Это приближает нас к мечте об “исполняемой спецификации”.

Но эти же преимущества могут превратиться в недостатки при определенных условиях. Первое преимущество является таковым только тогда, когда тесты должен иметь возможность создавать человек, не имеющий отношения к программированию. Таким человеком может быть кто-то со стороны заказчика или совершенно не технический тестировщик. Если же таких людей нет, то время на поддержку связывающего кода становится пустой тратой времени. Если тесты создаются и поддерживаются только командой, то трата времени на поддержку никому не нужных возможностей просто неуместна. Второе преимущество разбивается благодаря тому, что большая часть инструментов предоставляют очень бедный функционал для создания доменного языка. Конечно же есть исключения, к примеру Twist, в которые этому аспекту уделяется достаточно внимания. К сожалению, последнее преимущество тоже достаточно спорное. Дело в том, что для хранения требований большая часть компаний использует специализированные инструменты. Это может быть Wiki в Trac, Confluence, Google Docs и многие другие. Эти инструменты упрощают процесс управления требованиями и делают его удобным. Реализация подобного рода функционала в инструментах для приемочного тестирования значительно уступает, поэтому успешное использование их для хранения требований возможно только на сравнительно небольших проектах.

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

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