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

  • Tutorial

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

Часто тестировщики начинают планирование тестирования с составления карты приложения. Т.е. формируют список страниц и перечисляют все контролы на странице. Это приводит к тому, что каждая страница сама по себе работает, но это не значит, что пользователь может выполнить свою задачу целиком. 

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

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

Статья получилась объемной, так что вот оглавление:

  1. Введение

  2. Зачем и для кого фича?

  3. Какую проблему решает фича?

  4. Как пользователь будет использовать эту фичу?

  5. Варианты использования

  6. Основное направление варианта использования

  7. Альтернативные направления

  8. Исключения

  9. От входных/выходных данных к тест-кейсам

  10. Совет как писать сценарии

  11. Общий алгоритм применения подхода

  12. Профит от подхода для тестировщика

  13. Заключение

Введение

Есть разные команды: в одних командах куча аналитиков пишут требования к софту на сотню страниц, в других есть 1 аналитик на несколько проектов и он пишет, как успеется, в третьих вообще нет аналитика и задачи ставит ПМ, а команда уже на ходу придумывает, что именно реализовать. Причем, может быть непонятно, что нужно сделать по задаче, независимо от того, есть ли аналитик на проекте. И чаще всего так и происходит.  То задача идет вразрез с текущим функционалом, то никто не понимает, что там вообще надо сделать, то все всё понимают, но каждый по-своему.

Самые нажористые, сложные в исправлении баги обычно скрываются в требованиях и в постановке задачи.

Есть разные варианты, что может пойти не так:

  • Ожидания пользователей (пользователи хотят одно, а мы думаем, что они хотят другое; нет важных фичей; фичи есть, но неудобные).

  • Ожидания заказчика (ПМ хочет то, что невозможно/дорого реализовать; или то, что противоречит уже существующей логике).

  • Ожидания бизнеса (бизнес хочет платную фичу, а мы не разобравшись даем ее пользователю бесплатно).

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

Если ошибки из списка выше тестировщик найдет после того, как разработчик закончил кодить, то исправление будет стоить очень дорого, ведь нужно переделать все: и требования, и интерфейс, и реализацию, и всё это заново перетестить. 

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

Другой вопрос: а как тестить до разработки, если по постановке задачи ничего непонятно?

Для этого нам нужно определить: 

  • Зачем и для кого фича.

  • Как пользователь/заказчик будет использовать эту фичу.

Это позволит сформулировать задачу понятнее для команды, отловить ошибки в требованиях прежде, чем они будут закодированы и спланировать тестирование.

Зачем и для кого фича?

В первую очередь нужно определить, для кого мы делаем эту фичу, и зачем она заказчику.  

Это можно спросить у автора задачи. 

Стоит различать пользователя продукта и заказчика.

Например, если ваш продукт — это софт для частной клиники, то заказчиком тут будет представитель бизнеса, допустим, владелец клиники. А конечные пользователи - это врачи, регистраторы, медсестры и другой персонал клиники, которые используют продукт, чтобы вести записи о здоровье пациентов.

Пользователи продукта тоже могут быть разные. Важно выявить: 

  • Какие категории пользователей есть в вашей целевой аудитории (ЦА).

  • Зачем люди из каждой категории используют эту фичу.

  • Какие проблемы они решают с помощью нее.

  • Какие есть варианты использования фичи.

Итак, задача может быть для нужд бизнеса, например, чтобы организовать PR-компанию, или уменьшить затраты на Х, или увеличить доходы с У, или предотвратить/остановить отток пользователей.

Или для определенной категории пользователей нужно реализовать фичу, которую пользователи давно хотят и просят.

Задача может быть для ПМа или владельца продукта, например, чтобы собрать статистику и на основе нее принять решение. При этом важно понимать, что это за решение.

Для команды разработки — например, рефакторинг определенной области.

Для саппорта — чтобы лучше локализовать проблему или чтобы снизить нагрузку на саппорт.

Для другой команды — обычно это интеграции или еще какой-то обмен данными.

Какую проблему решает фича?

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

Можно обдумать это еще и в ключе: как пользователь/заказчик решает эту проблему сейчас?

Например: 

  • Делает руками, долго и болезненно. Или наоборот, руками получается быстро и ему ок.

  • Запускает какой-то скрипт.

  • Решает проблему через другое приложение.

  • Никак не делает и страдает.

  • Никак не делает и ему норм.

Ответ на этот вопрос поможет понять: а мы этой фичей точно улучшим пользователю работу или еще хуже сделаем?

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

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

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

Конфликт интересов

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

В книге «Разработка требований к программному обеспечению» (Карл Вигерс, Джой Битти) я нашла замечательную таблицу о том, как разрешать конфликты между сторонами при определении требований. Привожу ее здесь:

Разногласия между...

Как разрешать

...отдельными пользователями

Решение принимает сторонник или владелец продукта

...классами пользователей

Предпочтение отдается наиболее важному классу пользователей

...сегментами рынка

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

...корпоративными клиентами

Решение определяется на основе бизнес-целей

...пользователями и менеджерами

Решение принимает сторонник класса пользователей или владелец продукта

...разработчиками и клиентами

Предпочтение отдается клиентам, но с учетом бизнес-целей

...разработчиками и маркетингом

Предпочтение отдается специалистам по маркетингу

Как пользователь будет использовать эту фичу?

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

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

Если при разработке ориентироваться на пользователя и его работу с продуктом, то этих проблем можно избежать. Для этого удобно использовать технику Варианты Использования (Use Cases).

Варианты использования (Use cases)

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

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

Полную версию использования техники вы можете посмотреть в той же книге «Разработка требований к программному обеспечению». В этой статье я покажу упрощенную версию, которую использую в работе.

Возьмем для примера агрегатор доставки заказов из ресторанов и магазинов. В нем можно найти вот такие варианты использования:

  • Заказать еду из ресторана с доставкой.

  • Заказать еду с самовывозом.

  • Заказать доставку продуктов из супермаркета.

  • Найти, в каком ресторане есть желаемое блюдо.

  • Посмотреть стоимость доставки из ресторана Х.

  • Повторить прошлый заказ.

  • Посмотреть, где находится курьер, который доставляет заказ.

Имя варианта использования должно быть понятное (глагол + объект), описывающее, какую именно ценность пользователю дает этот вариант использования, например, информацию о чем-либо (внутри приложения) или еду на обед (в реальном мире, за пределами приложения).

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

Примеры вопросов, чтобы найти действующих лиц: 

  • Кому приходит уведомление о событиях в системе?

  • Кто предоставляет системе информацию или услугу?

  • Кто помогает системе среагировать и выполнить задачу?

Экосистема агрегатора доставки еды предполагает, что есть приложение для того, кто заказывает еду, есть приложение для курьера, и приложение для ресторана.

Т.е. у нас будет как минимум 4 действующих лица:

  • Покупатель

  • Ресторан

  • Курьер

  • Система (т.е. само приложение)

Для разных вариантов использования список действующих лиц может меняться. 

Если покупатель выберет в заказе оплату картой, то добавится действующее лицо «Банк». Если закажет еду не себе, а бабушке, то появится еще «Получатель». А если будет писать в техподдержку, то добавятся «Бот» и «Оператор техподдержки».

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

Основное направление варианта использования

Определим варианты использования основной фичи агрегатора доставки — заказа еды из ресторана. 

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

Действующие лица: 

  • П — Покупатель

  • Р — Ресторан

  • К — Курьер

  • С — Система (т.е. само приложение)

  • Б — Банк

Предусловия:

  • Пользователь авторизован в приложении

  • Доступен как минимум 1 ресторан 

  • Заказ делается в часы работы ресторана

  • У ресторана есть блюда в наличии

Сценарий (основное направление):

П: Добавляет блюда в корзину

С: Проверяет доступность блюд

С: Показывает пользователю сумму заказа в корзине

С: Подсчитывает сумму и прогноз доставки

П: Переходит в Корзину

С: Показывает текущее содержимое заказа

П: Инициирует оформление заказа

С: Предлагает выбрать параметры заказа (адрес, время доставки, вид оплаты)

П: Выбирает оплату картой онлайн и инициирует оплату

Б: Открывает страницу подтверждения оплаты

П: Подтверждает оплату (вводит код из СМС)

Б: Проверяет подтверждение

Б: Передает в Систему данные, что заказ оплачен

С: Присылает покупателю чек об оплате

С: Показывает покупателю, что заказ принят

С: Запрашивает подтверждение заказа у Ресторана

Р: Подтверждает заказ 

Р: Начинает готовить заказ (в реальном мире)

С: Находит Курьера и запрашивает у него подтверждение принятия заказа

К: Подтверждает, что принял заказ

К: Идет в ресторан (в реальном мире)

Р: Подтверждает, что заказ готов

К: Подтверждает, что принял заказ в доставку

К: Транспортирует заказ (в приложении видна геометка курьера на карте)  (в реальном мире)

П: Получает заказ

К: Подтверждает, что передал заказ покупателю

С: Показывает, что заказ завершен

Альтернативные направления

Дальше нужно составить альтернативные направления развития, т.е. описать, как можно выполнить все то же самое, но немного другим путем. 

Можно посмотреть на сценарий целиком и подумать, как можно получить заказ другим способом:

Например:

  • А-1 Зайти в раздел с завершенными заказами и повторить прошлый заказ

А можно смотреть на каждую строку и думать: «может ли действующее лицо сделать другой выбор на этом шаге?»

Например:

  • А-2 Покупатель оформляет заказ на другого получателя (а не на себя)

  • А-3 Покупатель выбирает оплату наличными (и сценарий минует шаги с онлайн-оплатой)

  • А-4 Покупатель применяет промокод и сумма к оплате пересчитывается

  • А-5 Покупатель выбирает доставку к определенному времени

  • А-6 Курьер сначала принимает заказ, а потом отказывается и заказ берет новый курьер

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

Каждую такую альтернативу можно пошагово расписать, как и основной сценарий. А можно нарисовать блок-схему.

Пример блок-схемы

Исключения

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

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

Например, когда пользователь добавляет блюда в корзину, а система проверяет доступны ли они для заказа, могут произойти такие исключения:

  • И-1.1  Добавляемое блюда закончилось в ресторане и больше недоступно для заказа.

  • И-1.2 У ресторана закончилось время работы.

  • И-1.3 Ресторан прекратил прием заказов и вообще исчез из списка.

  • И-1.4. В корзине лежат блюда другого ресторана (обычно при этом система предлагает убрать блюда другого ресторана из корзины).

На шаге подсчета суммы и прогноза времени доставки может оказаться, что:

  • И2.1 Сумма заказа недостаточна для доставки (возможен только самовывоз).

При оплате онлайн бывает, что страница банка зависает, и невозможно ввести код оплаты.

Вот этот блок в сценарии:

П: Выбирает оплату картой онлайн и инициирует оплату.

Б: Открывает страницу подтверждения оплаты (но страница зависает).

П: Не может ввести код оплаты.

П: Обновляет страницу.

П: Психует и Переходит на предыдущий экран (т.е. обратно в приложение).

Обычно в этот момент система просто отменяет заказ и пользователю нужно пройти весь путь оформления заказа заново.

Так и назовем исключение:

  • И-3.1 Страница подтверждения оплаты зависла.

Еще несколько примеров исключений из этого сценария:

  • И-4.1 Курьер не вышел на связь с рестораном (Система отменила заказ автоматически).

  • И-4.2 Нет доступных курьеров в зоне доставки (Система отменила заказ автоматически).

  • И-5.1 Курьер случайно отменил заказ когда еда уже была у него и отдал заказ бомжу.

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

От входных/выходных данных к тест-кейсам

На основе всех этих сценариев мы можем составить тест-кейсы, чтобы протестить работу фичи. Тест-кейс предусматривает, что мы подаем какие-то данные на вход, делаем нужные действия и ожидаем какой-то результат на выходе. 

При этом одни и те же параметры на входе в разные сценарии могут иметь разные значения. 

Например, при заказе еды в агрегаторе доставки на вход поступают вот такие параметры:

Покупатель:

  • Имя

  • Телефон

  • Адрес

  • Способ оплаты

Заказ: 

  • Блюда и их стоимость

  • Количество приборов

  • Прогнозируемое время доставки 

  • Время оформления заказа

  • Промокод

Ресторан: 

  • Адрес

  • Часы работы

  • Доступные блюда

Курьер:

  • Имя

  • Телефон

  • Местоположение

  • Доступность для заказа

На выходе могут быть такие данные:

  • Доставлен ли заказ

  • Количество доставленных блюд

  • Качество (вкус, температура) доставленных блюд

  • Доставленные приборы (количество, комплектность)

  • Стоимость доставки

  • Стоимость заказа

  • Фактическое время доставки

В случае, если значения в заказе обычные, то на выходе мы получим вовремя доставленную еду. Но некоторые значения параметров могут изменить результат на выходе.

Если Адрес покупателя будет расположен слишком далеко от Адреса ресторана, то доставка будет недоступна вообще, или сумма доставки будет высокой.

И наоборот, если Адрес покупателя находится в соседнем доме от ресторана, то доставка будет по минимальной стоимости. 

Но если при этом время оформления и доставки заказа — в час-пик, то стоимость будет выше. 

Если способ оплаты — «Наличные курьеру», но по факту покупатель не заплатил курьеру, то заказ не будет доставлен (отменен).

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

Из менее очевидного: 

Что если покупатель закажет очень много блюд? В 2-3 раза больше, чем влезет в курьерскую термосумку. Сработает ли ограничение в, допустим, 15кг на 1го курьера? Или системе придется искать 3х курьеров?

Как будет в таком случае спрогнозировано время доставки? Ведь все эти блюда нужно еще успеть приготовить.

Если покупатель закажет доставку из ресторана за минуту до закрытия и ресторан не успеет подтвердить заказ, заказ доставят? Или перенесут на другой день? Или отменят?

Такие вопросы следует уточнять у постановщика задачи, ПМа или аналитиков на вашем проекте и не пытаться угадать/придумать «правильную» логику самостоятельно.

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

Пишите в сценариях смысл действия без опоры на внешний вид

При написании сценариев важно опираться на смысл пользовательского действия, а не на интерфейс. Это позволит не переписывать их при каждом редизайне. Т.е. мы можем написать:

  • Покупатель выбирает вид оплаты Картой.

И не стоит писать:

  • Покупатель кликнул на серую кнопку «Visa/Mastercard» в правом нижнем углу формы.

Кнопка может поменять цвет и перестать быть серой. 

В текущей версии приложения это кнопка, а потом ее поменяют на плитку/выпадашку/любой-другой контрол. 

В десктопной версии термин «кликнуть» еще приемлем, в мобильной версии приложения это может быть тап, или свайп, или другое действие.

Кнопка может поменять название и расположение. 

Более того, в мобильной версии приложения кнопка может быть не в правом нижнем углу, а просто внизу или вообще посередине экрана. 

Т.е. при описании сценариев желательно не использовать:

  • Цвет

  • Форму

  • Расположение на экране

  • Точное название 

  • Вид элемента интерфейса

Общий алгоритм применения подхода

Чтобы составить тест-кейсы по фиче с помощью техники Use Cases нужно сделать следующее:

  1. Определить, зачем и для кого фича:

    • Какие категории пользователей есть в вашей целевой аудитории (ЦА).

    • Зачем люди из каждой категории используют эту фичу.

    • Какие проблемы они решают с помощью нее.

  2. Выписать, какие есть варианты использования фичи.

  3. Для каждого варианта использования нужно определить:

    • Какие действующие лица участвуют в сценарии (включая само приложение, ботов и сторонние системы).

    • Основное направление варианта использования.

    • Альтернативные сценарии.

    • Возможные исключения, когда что-то пошло не так.

В результате мы получаем кучу пользовательских сценариев с предусловиями, шагами и ожидаемым результатом. 

Профит от подхода для тестировщика

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

  • Найти пробелы в бизнес-логике.

  • Помочь дизайнеру и разработчику разобраться в том, как будет работать фича.

  • Убедиться, что есть обработка всех возможных ошибок.

  • Проверить, что пользователь может пройти сценарий от начала до конца.

  • Выявить все неочевидные предусловия, варианты развития событий, возможные входные/выходные данные.

Заключение

Есть много техник, чтобы тестировать требования, и Use Cases, показанные в этой статье — это тоже не панацея от всех бед. 

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

В то же время, подход не применим в задачах, где вообще нет никакого взаимодействия между сторонами. 

Но не стоит забывать, что требования можно протестировать с помощью других инструментов, например, используя диаграмму «Сущность-Связь» (Entity-relationship), анализируя состояния объектов в продукте (State machine diagram) и т.д. Как при работе с требованиями, так и в тестировании все эти инструменты только усиливают друг друга, но это уже тема для отдельной статьи.

Хабравчане, о каких еще техниках по работе с требованиями вам было бы интересно узнать? Пишите в комментариях, поделюсь в следующих статьях.

Plesk
Plesk – панель управления хостингом

Comments 22

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

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

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

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

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

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

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

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

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

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

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

        Just curious, а что это за программы? b2b или b2c (или b2b2c)? Каков MAU?
          0
          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 моделированием, но это скорее хобби.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

                      Only users with full accounts can post comments. Log in, please.