Как стать автором
Обновить

Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят

Время на прочтение13 мин
Количество просмотров93K
Всего голосов 26: ↑26 и ↓0+26
Комментарии26

Комментарии 26

Даже в школе учат считать яблоками и апельсинами. Т.е., на конкретных примерах. Поэтому, при всем уважении к изложенной «технике по работе с требованиями» совершенно непонятно, как она реально работает.

Для меня лично главное требование это способность и возможность реализации некоторой «хотелки». Т.е., желание должно подкрепляться возможностями. Вспомним классику: «Есть желание купить машину, но нет возможности. Есть возможность купить козу, но нет желания!». Все остальное от лукавого.

Вот, допустим, возьмем C++ / WTL. Там есть мастер, генерирующий каркас приложения, на уровне типа приложения и его интерфейса (меню, бары, окна, диалоги, сплитеры, стандартные компоненты и т.д. и т.п.). Все это, конечно, хорошо, но мало. Если мы хотим расширить возможности мастера, сделать что-то типа универсального генератора интерфейсов для бизнес приложений, то, что нам по этому поводу может сказать наука «по требованиям» и «фичам»?

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

А тестировщик когда нам понадобиться? Наверное, только в конце проекта и то не факт.

Короче говоря, проблема многих статей, это недостаточное прояснение ситуации для не посвященных. То, что очевидно автору, далеко не всегда понятно читателю, который просто хочет понять, нужна ли ему эта информация или нет? Если соблазниться идеями статьи, то тогда возникнет заинтересованность в освоении ее технических нюансов. Хотя, у вас их как бы не очень много, но остается вопрос, а так ли они нужны на практике? Мы вот программируем свои программы без тестирования и живем. Правда продукт не глобальный, а местного разлива, но, тем не менее, вопрос полезности озвученных идей, при теоретическом масштабировании остается.
Анализ требований, имхо, это больше для случая команд с более чем одним участником. Когда хочет что-то несколько людей, записывает это все еще парочка, а реализует десяток.
И вот при таких наборах, проверка как минимум конфликтов хотелок, как максимум конфликтов реализаций от девелоперов становится довольно критичной. Особенно учитывая страсть девелоперов к уточнениям «а правильно ли я это понял» ;)

А ваш кейз больше похож на «сам себе придумал, сам себе сделал». Для этого случая, достаточно просто адекватности реализатора.
Когда много участников, можно свести «анализ требований» к качественному техзаданию. Для этого есть архитектор проекта, на нем вся ответственность.

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

Когда уже проектирование ПО перейдет в фазу полноценного ТЗ / сметы? Спроецируйте нашу статью в термины проектирования Крымского моста, там подобных проблем не должно быть в принципе, поскольку культура проектирования, осмечивания и даже научных изысканий подобных сооружений давно уже на высочайшем уровне.

А проблемы проектирования ПО это «детские» проблемы, поскольку дитя программирования появилось совсем недавно и большая наука, за исключением, быть может, «военного» программирования, сюда еще не зашла, особенно в частный сектор, даже уровня «1С», где все еще нет понимания, что фундаментальные технические исследования стоят денег и должны быть доступны всем.

Что касается меня, то да, я считаю себя «свободным художником» от программирования. Старые программы меня кормят, поэтому я могу позволить себе думать о новых спокойно и без суеты.
«Когда уже проектирование ПО перейдет в фазу полноценного ТЗ / сметы? „
Оно там было. Когда-то. В те славные времена, о которых нонче ходят только смутные слухи, когда мы сначала выясняли что мы делаем, а потом это делали, когда ТЗ было не “сделать пистата» а документ с кучей пунктов включая критерии завершенности…
И ушло в то что имеет место быть. см детали в соседнем посте про «плохие технологии».
> Мы вот программируем свои программы без тестирования и живем.

Just curious, а что это за программы? b2b или b2c (или b2b2c)? Каков MAU?
Just curious, а что это за программы? b2b или b2c (или b2b2c)? Каков MAU?

Кормит меня, уже много лет, одна программа: 100%-но собственная конфигурация 1С «Учет и расчет заработной платы на производственном предприятии». Плюс учет рабочего времени, с помощью карт RFID (мой драйвер на С++ плюс обработка данных в 1С). Специфика в том, что эта программа конкретно для ЛНР (где я живу), а еще точнее, заточена 100% на предприятие, где я работаю. Однако распространять ее на другие фирмы, даже в ЛНР, нет смысла, поскольку, система уже морально устарела и ничего кроме критики у народа не вызовет, а оно мне, естественно, не надо.

Поэтому я хочу написать свой вариант платформы 1С (а-ля версии 7.7) на C++ / WTL, но 64-х разрядный, с движком SQLite (для индексов) и MMF (для данных, формата *.sdf). Это будет «толстый клиент» с планами обмена, как в «восьмерке» (1С8х), с серверной службой по обмену репликами данных между клиентами. Ориентация на малые и средние предприятия только. ЛДНР фирма «1С» игнорирует, как Сбербанк России – Крым. Поэтому эта поделка, надеюсь, будет востребована в нашем регионе. По крайней мере, до вхождения Донбасса в состав России, который по прогнозам Симпсонов, будет не позже сентября 2024 года (плюс время нам на раскачку дадут по любому).

Также планирую сделать совместимость по данным с 1С8х, так чтобы, купить одну лицензионную «восьмерку», типа ЗУП, на предприятие, сам учет вести в моей программе, затем готовые данные выгружать в лицензионную версию и регламентную / электронную отчетность делать уже там.

Также на своем предприятии я поддерживаю обычный бухгалтерский учет (на базе адаптированной конфигурации для Украины) плюс мои обработки для ОС, местных клиент – банков, онлайновой отчетности ЛНР и т.п.

Для новой программы придумал даже название: «Модульный Учет + ЗАрплата» (МУЗА).

Однако поскольку я сам себе хозяин, в смысле программирования, то новые программы пишу с некоторой ленцой и в разных направлениях. Одно время было увлечение ассемблером (см. мой сайт erfaren.narod.ru ), обучающими программами ( scholium.webservis.ru ) и т.п., по мелочам.

Сейчас снова вернулся к обучающей программе, но на C++ / WTL. Основу уже сделал, там есть даже встроенный видеопроигрыватель (опенсорсный FFplay.c) с элементами распознавания встроенных субтитров. Но потом переключился на внешние субтитры, а сейчас добавляю функционал для изучения слов и фраз, по принципу: «Интерактивный звук + запоминание руками». Плюс еще пересборка обучающих видеороликов (примеры на my.mail.ru/mail/emmerald/video/_myvideo ).

В последнее время увлекся Питоном, а через него – Блендером и 2d/3d моделированием, но это скорее хобби.

Это далеко не все, но смысл, думаю, понятен. Как-то так :).
Emelian
Очень интересный и развернутый комментарий! Т.к. я в контексте самой техники, того, как она применяется и какую пользу наносит, хотел бы поподробнее пообщаться с вами и уточнить, чего нехватило для понимания применимости техники в вашей ситуации и с точки зрения вашего опыта.

Даже в школе учат считать яблоками и апельсинами. Т.е., на конкретных примерах. Поэтому, при всем уважении к изложенной «технике по работе с требованиями» совершенно непонятно, как она реально работает.

Можете уточнить, какого именно примера оказалось недостаточно? В статье рассматривается приложение для сервиса заказа и доставки еды. Что стоило бы добавить, чтобы более полно продемонстрировать работу изложенной техники?

Если мы хотим расширить возможности мастера, сделать что-то типа универсального генератора интерфейсов для бизнес приложений, то, что нам по этому поводу может сказать наука «по требованиям» и «фичам»?

Вы сами дали ответ на свой вопрос: «Другими словами, мы садимся и разрабатываем алгоритм нашего супер мастера.» — техника помогает в разработке алгоритмов того, как работает проектируемая фича, взглянуть на неё с точки зрения взаимодействия участвующих систем. Позволяет структурировать и визуализировать эти алгоритмы, поможет из неоформившихся пожеланий «сделать что-то типа универсального генератора интерфейсов» вычленить сценарии того, как планируемая фича должна себя вести в разных ситуациях. Какие будут входные и выходные данные. Например, на основании чего мы планируем генерировать универсальный имнтерфейс, будет ли это всегда стандартный набор вроде: одно поле ввода и две кнопки — «Ок» и «Отмена», или будет возможность кастомизации типа элементов и их количества на этапе до генерации шаблона? Ответ на этот вопрос дает нам две разные задачи с соответствующими трудозатратами на их реализацию. Подобные вопросы, сценарии и функциональные возможности стоит уточнять до того, как задача, собственно, попадает в разработку. Таким образом мы говорим не о тестировании готового приложения, а об обеспечении качества посредством тестирования требований на раннем этапе работы над задачей. При этом «качество» нужно понимать не как исключительно функциональую часть приложения, что кнопки нажимаются и все работает без неожиданных ошибок, а, в том числе, и качество с точки зрения UX для конечного пользователя — корректную обработку едж кейсов, отсутствие тупиковых сценариев, в конце концов убедиться, что проектируемая функциональность будет решать проблему заказчика.

Мы вот программируем свои программы без тестирования и живем.

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

Наверное, я не очень точно выразился. В вашем случае, примера как бы достаточно. Но я имел в виду переносимость на похожие задачи. Что с того, что ваша методика (как по мне, не слишком выходящая за пределы здравого смысла) вполне работоспособна для вашей конкретной ситуации? Хорошо, не будет этой методики, что проблема сразу станет трудно решаемой? Обычная учетная задача, для реализации которой есть масса возможностей. Всего-то нужно, чтобы автор программы нес ответственность за свою поделку. А не как, скажем, в случае 1С, когда разработчиков конфигурации намерено отделяют от контактов с клиентами – пользователями системы. В итоге те злоупотребляют свои положением и пишут свои творения по принципу: «Нам самим с нашей программой не работать!». Вот, мол, вам доступ к конфигуратору, наводите марафет сами.

Другими словами, ваш случай с алгоритмической точки зрения не слишком сложен, что показывает ваша блок-схема. Для логики работы банкомата нужна будет уже другая схема, для учета заработной платы и рабочего времени на производственном предприятии – третья и т.д. Иначе говоря, вы продемонстрировали качественное техзадание на вашу систему. Поэтому, я бы переименовал бы вашу статью в, типа: «Каким должно качественное техзадание на примере несложной учетной задачи?» Соответственно, он включает в себя и ваш заголовок, как находить ошибки в бизнес-логике до, а не после? Поэтому вам бы надо идти в тимлиды, либо разработчики ТЗ, а не заниматься тестингом.

А вот если бы рассмотрели более сложный случай, особенно в плане идей, скажем, по тому же учету зарплаты и рабочего времени, то было бы куда интересней. По «зарплате» ведь нет хороших программ, хотя самих программ валом, от фирм «1С», «Камин», «Парус» и множеств других.

Просто тут очень хорошо проявляется принцип 20-80 либо 10-90. Например, 90% случаев описываются в 10% всего кода и наоборот. Ибо все проблемы здесь связаны в основном с нюансами.

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

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

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

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

Хорошие прототипы интерфейсов у фирмы «1С», версии, 7.7, 8.2 (обычные формы) и 8.3 (управляемые формы). Но, «лучшее – враг хорошего!». Далее можно обсуждать связь программной логики с бизнес логикой. Продукты «1С» для этого подходят идеально. Их реализация не единственно возможная и не самая оптимальная (потому, что коммерчески ориентированная). Но и интерфейс у опенсорных продуктов часто имеет собственных тараканов, мол, нам не до интерфейса, проект бесплатный, кушайте, что дают и смотрите, не обляпайтесь!
Вы описали не сценарий варианта использования, а целый бизнес-процесс. :)
В книге Вигерса (и примкнувшей к нему Джой Битти) метод вариантов использования, конечно же, полностью не описан.

Рекомендую книгу Коберна «Writing Effective Use Cases» (которой очень не повезло с русским переводом названия: то ли переводчик, то ли редактор выпендрился, и по-русски её назвали «Современные методы описания функциональных требований к системам»). Вот в ней этот метод описан, можно сказать, исчерпывающе.
Не слышала про такую книгу. Спасибо за рекомендацию. Почитаю :)
Я читал Writing Effective Use Cases году в 2005 (не помню почему в оригинале, возможно, перевода не нашёл), в памяти осталось только то, что там очень много букв использовано для описания довольно простых вещей. Не то чтобы это прямо плохо, просто не хочу, чтобы у людей были завышенные ожидания ;) Книжка-то хорошая.
Пишите в сценариях смысл действия без опоры на внешний вид
В этом случае, скажем, дизайнер имеет полное право сделать кнопку оплаты не серой, а серо-бур-козявчатой )

имеет. В этом и суть, оторвать требования от реализации, оторвать проблему от способа её решения, потому что способ решения часто выбирается как наиболее известный, а не наиболее эффективный

О, кто-то Вигерса ещё читает! Это радует, а то я уж думал, что книги старше 5 лет уже в мёртвой зоне.

Ну не, не в мертвой. Даже наоборот, найти что-то актуальное для тестирования моложе 5 лет — действительно проблема. Про автоматизацию есть, про аджайл тоже есть пара книг. Да и все, пожалуй. Буду рада узнать, если я ошибаюсь :)

Ольга, вы занимательно и просто оформили часть темы «работа с требованиями». И что приятно — как всегда увлечённые люди дают фору тому убожеству, которое вываливают на нас «профессионалы» (что и побудило оставить комментарий).

Если продолжать в том же духе, то есть постепенно постигать смыслы в своей деятельности, то будет открыта дорога в аналитики (если это интересно). А вот, например, становиться архитектором программных систем вам пока не стоит, потому что помимо требований там всё же остаётся важной техническая часть, котрой, похоже, у вас нет или она слабая.

Но страсть копать вопросы «зачем», «почему», «как работает», «как улучшить» откроет вам почти любую (полезную обществу) дорогу в будущем.

Благо, у меня и нет намерений стать архитектором програмных систем.
А за приятные слова спасибо :)

откуда вывод про "техническая часть, котрой, похоже, у вас нет или она слабая."?

Вопрос. Вы обозначили четыре входных условия:

  • Пользователь авторизован в приложении
  • Доступен как минимум 1 ресторан
  • Заказ делается в часы работы ресторана
  • У ресторана есть блюда в наличии


Значит всего 2 в 4 степени = 16 комбинаций этих условий. Вы будете писать сценарии на все 16? А там ведь еще геолокация, язык, cookies. Уж про то, что нужно тестировать как минимум на двух-трех десктопных веб-движках плюс на паре мобильных.

Жаль что в примере рассмотрен самый стандартный случай. Ошибки и проблемы обычно ведь возникают «с краю». Вот там и начинаются компромиссы:
«Ну мы пока авторизацию закоротили, так что пользователь всегда авторизован»
«У нас в тестовой базе всегда есть ресторан, а у него всегда есть блюда»
«Геолокацию пока не прикрутили так что мы находимся в Москве :). Да в Саранске, но для удобства пусть будет Москва. Тестовые данные рассчитаны на Москву, ну пока что»
«Язык только русский пока»
«В смысле сбрасывать cookies или нет — да какая разница? Ааа… вот что. Не ну наверно лучше сбрасывать. Хотя так неудобно тестировать, постоянно эта простыня всплывает. Да ладно оставь так.»
«Время проведения тестирования случайно совпадает со временем работы ресторана»

И весь этот «аналитический подход» может вылиться в разнообразное тестирование идеального пути. Т.е. это хорошо, чтобы «ничего не забыть», проверяя основной положительный сценарий.

Еще не рассмотрены обратные действия. Т.е. мы все время движемся по приложению строго в одном направлении. А что, если мы решили поменять время доставки когда стали выбирать форму оплаты? Т.е. даже в рассмотренном основном сценарии много допущений.

Значит всего 2 в 4 степени = 16 комбинаций этих условий. Вы будете писать сценарии на все 16? А там ведь еще геолокация, язык, cookies. Уж про то, что нужно тестировать как минимум на двух-трех десктопных веб-движках плюс на паре мобильных.

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

И весь этот «аналитический подход» может вылиться в разнообразное тестирование идеального пути.

Позвольте не согласиться. По моим наблюдениям как раз тестирование по наитию или «опытом и здравым смыслом» — это тестирование идеального пути с кучей допущений и пробелов. Аналитический подход и применение различных техник тест анализа позволяет существенным образом расширить и углубить покрытие. Итоговый результат от аналитики все-таки зависит от совести и опыта того, кто этой аналитикой занимается :)
Спасибо))
Хабравчане, о каких еще техниках по работе с требованиями вам было бы интересно узнать? Пишите в комментариях, поделюсь в следующих статьях.

Спасибо за подробный и информативный разбор темы. В следующий раз хотелось бы статью о диаграмме сущность-связь.
Спасибо за мысль. Обдумаю, как написать про эту диаграмму.

Спасибо за статью! Было интересно почитать! Много буков, но описано всё довольно живо.

Спасибо! Приятно))

Зарегистрируйтесь на Хабре, чтобы оставить комментарий