Часто в жизни бывают такие ситуации, что клиент не знает точно, чего хочет – будь то сапоги, сайт или софт. С обувью всё немного проще: тут хотя бы заказчик один. Ну а как помочь заказчику ПО получить после разработки и тестирования то, чего он хотел и за что заплатил? Об этом мы расскажем на примере одного из наших клиентов.
Что решать и как решать?
Итак, имеется некий программный продукт, востребованный и перспективный. При этом, к моменту нашего появления он имеет кучу функциональных дефектов. Главных причин в этом две: нехватка ресурсов для тестирования и отладки, а также отсутствие понимания, каким должно быть ПО и куда ему развиваться. Вторая проблема, как мы уже понимаем, острее.
Мы предложили нашему клиенту использовать методику «Specification by Example» (Спецификация на основе примеров). Один из основных ее принципов состоит в том, что первоначально все стороны, участвующие в процессе создания продукта – разработчики, тестировщики, представители бизнеса – должны совместно согласовать общие требования к системе. В идеале этот процесс предполагает симметричные трудозатраты со всех сторон, но в жизни так получается не всегда.
Основную часть работы мы взяли на себя. Это совершенно не противоречит
методике. По мере погружения в проект мы получили достаточные знания по данному
продукту, что позволило нам сделать 80% описания функционала самостоятельно.
Как это работает?
Процесс шел следующим образом: мы формулировали требования и передавали их на согласование, если надо – устраивали созвоны-конференции. При этом мы не диктовали свою позицию, а шли навстречу клиенту, работая по принципу «у вас нет времени – мы продумаем всё за вас». Таким образом, мы заранее фиксируем требования к еще не написанному (или не исправленному) коду, а также формулируем будущие критерии его приемки, в полном соответствии с принципами ATDD — Acceptance Test Driven Development
Если функционал решают изменить, это сразу же отражается в спецификации, и она идет дальше в работу. Другими словами, еще до того, как система создана или модернизирована, мы уже пытаемся найти ее узкие места и болевые точки. Это хорошо для клиента, так как обеспечивает достаточный уровень качества продукта. И это идеально для тестировщика, ведь написанные требования – суть, сделанные по шаблону готовые автотесты, уже соответствующим способом оформленные. Запускай все эти сценарии, состоящие из блоков «Given – When – Then» (Дано – Когда – Тогда) на языке Gherkin – и наслаждайся результатом.
Что может пойти не так?
В любом деле есть свои сложности. Главная проблема методики «Specification by Example» носит, скорее, организационный характер: при составлении спецификаций команда должна работать как команда. Идеологией должны быть охвачены все ее сотрудники, всем нужно между собой коммуницировать, всем должны быть понятны требования. Иногда бывает сложно донести до всех, для чего это делается. Иной разработчик говорит: “дайте мне задачу, и я ее сделаю, а остальное мне не интересно, больше не хочу принимать ни в чем участие”.
Это повсеместная ситуация, но недопустимая в методике «Specification by
Example». Все стороны собираются, решают, как тот или иной функционал должен
выглядеть, дают свои комментарии. Может быть, его можно сделать проще? И только
после того, как все придут к согласию, он входит в спецификацию. Задача на
разработку берется к исполнению только тогда, когда есть готовый дизайн и
функциональная единица, написанная на языке Gherkin с требованием и критерием
приёмки.
В чем еще выгода?
У этой методики есть и другие преимущества. Возможно, кому-то из заказчиков понравится, что данный подход можно применять без использования аналитики. Случается, такое, что нет возможности получить подробную аналитику по продукту: на это нет времени, средств или и того, и другого. Кроме того, даже при его наличии аналитическое описание может быть не совсем понятно команде, создающей продукт. Разработчик может понять по-своему, тестировщик по-своему – так возникает конфликт интересов. С использованием «Specification by Example» тестировщик может выступать в роли аналитика, в ходе процесса согласования спецификации выставляя определенные требования к продукту.
Вы скажете: бывают ведь и обратные случаи, когда клиент точно знает, что хочет получить. В том случае, если заказчик твердо стоит на своем, процесс пойдет даже быстрее, так как команде тестировщиков не придется брать задачу составления спецификации на себя. При этом все остальные методы применяются точно так же. Требования могут быть представлены в различных видах: классического ТЗ, либо юзерстори – не важно, лишь бы они были понятны всем участникам процесса. Однако на практике такое бывает очень редко, и тестировщики все равно берут ту или иную часть работы на себя.
Мы знаем, что классическое ТЗ описывает техническим языком, каким должен
быть конечный продукт. В таком виде это – документ для разработчиков. Позже,
когда дело дойдет до тестирования, на основе технического задания будет написан
тест-план; это отдельное мероприятие, оно займет какое-то время, особенно если
в ТЗ нечетко указаны бизнес-требования. При любом изменении ТЗ тест-кейсы также
придется переделывать.
Что же касается методики «Specification by Example», то в данном случае спецификация описывает в том числе и работу тестировщиков – не потребуется готовить отдельную документацию. Сразу создаются критерии приемки – продукт изначально полностью готов для изготовления и выпуска. Все это очень экономит время, трудовые ресурсы и нервы этих трудовых ресурсов.
Что мы получили?
Один из ключевых принципов методики «Specification by Example» звучит так: «правильное ПО и ПО, сделанное правильно – это совсем разные вещи». Легко сделать так, что программа просто работала. А вот сделать так, чтобы она работала так, как хочет заказчик – совсем другое. Сам методика несложна в освоении, ей можно научиться буквально за пару недель. Но ее применение требует принципиальности и последовательности, может быть, поэтому ее так мало применяют в России? А результаты, между тем, налицо.
Возвращаясь к нашему заказчику, поделимся своими достижениями: за две недели им было принято 13 предложенных функциональных единиц и 100 сценариев – все они ожидают очереди на разработку. Сейчас ребята набираются опыта, а в дальнейшем мы надеемся, что к нам регулярно будут приходить заказчики, чтобы посмотреть, как легко мы пишем спецификации для их софта. Даже в том случае, если они сами не знают, как именно этот софт должен работать.
Потому что это — наша работа ;).
