Требования

В данной статье я хотел бы затронуть тему применения требований стандартов безопасности при разработке ПО.

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS. Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют системы и решения собственной разработки, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только, большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS, не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано, а в данной статье приведены именно упомянутые стандарты, а не требования PA DSS.

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

Итак, давайте перейдем к детализации и описанию требований.

Общие разделы стандарта PCI DSS.

Требования PCI DSS (на основе требований PCI DSS 3.2.1)

1. Минимизировать места и сроки хранения критичных данных. В контексте данной публикации критичные данные это данные, безопасность которых регламентируется требованиями PCI DSS + GDPR (карточные и персональные данные).

Нужныли таковые данные впринципе или ихможно анонимизировать? Действительноли необходимо хранить критичные данные втаком объеме? Можноли избежать дублирования данных икак обеспечить ихминимизацию?

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

2. Критичные данные в базах данных, рекомендовано хранить в зашифрованном виде.

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

3. Клиентские сетевые потоки данных должны передаваться в зашифрованном виде.

Критичные данные должны передаваться по шифрованному каналу. Сетевые критичные данные должны передаваться по шифрованному каналу. Формально достаточно использование протокола безопасности TLS, но лучше обеспечить шифрование передаваемой информации на уровне ПО.

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

4. Если собираются фото платежных карт, они должны соответствовать требованиям безопасности.

Сбор пользовательских данных для процессов верификации, часто подразумевает сбор графических материалов с изображением платежных карт, на которых могут быть указаны карточные данные (PAN, CVV). Простое решение - это удалять такие данные из систем и просить клиента самостоятельно повторно предоставлять фото копии требуемогоформата. Следующий вариант - самостоятельно удалять критичные данные и сохранять фото без таковых. Еще более интересный вариант - это самописные или купленные сервисы распознавания и замыливания Cvv и номера карт на графических изображениях.

5. Базы данных должны размещаться в отдельной подсети от подсети приложений.

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

6. Все тестовые параметры при переводе в эксплуатацию должны быть удалены.

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

7. Требуется использовать защищенные технологии и стойкие алгоритмы шифрования.

Не все алгоритмы шифрования считаются стойкими.

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

8. Запрещено хранить пользовательские пароли, только хеш (результат выполнения однонаправленного преобразования над паролем).

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

9. Проверка на OWASP TOP 10.

Необходимо проверять решение на основные уязвимости безопасности перед передачей его в эксплуатацию. Сам данный пункт достоин не то что одной, а целой серии статей от процесса проверок внутри Компании до внедрения систем Bug Bounty. Для начала рекомендуется проверять хотя бы на OWASP TOP 10.

10. Использование персонифицированных учетных записей.

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

11. Логирование действий с возможностью перенаправления во внешние системы.

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

12. Система разграничения полномочий с минимально необходимыми правами.

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

13. Шифрование безопасными ключами.

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

14. Требования к стойкости пароля.

Должны выбираться пароли которые не поддаются атаке перебором. Хранение и передача паролей должна быть обеспечена таким образом, чтобы минимизировать вероятность его компрометации (парольные хранилища, раздельное хранение и пр).

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

Зачем нужна модель знаний

За уже несколько десятков лет существования индустрии информационных технологий создана значительная теоретическая база. Множеством ассоциаций и организаций разработаны своды знаний и методологии в различных областях.

Вот некоторые из них:

• BABOK (A Guide to the Business Analysis Body of Knowledge) - руководство к своду знаний по бизнес-анализу от Международного института IIBA (International Institute of Business Analysis)

• SWEBOK (Software Engineering Body of Knowledge) - международный стандарт ISO/IEC TR 19759 от 2015 г., в котором описана общепринятая сумма знаний о программной инженерии

• SEBOK (Systems Engineering Body of Knowledge) - свод знаний в области системной инженерии, разработанный организацией BKCASE, которая контролируется Управляющим советом, состоящим из трех ассоциаций (т.е. Международного совета по системной инженерии, Центра исследований системной инженерии и Компьютерного общества IEEE)

• BPM CBOK (Guide to the Business Process Management Body of Knowledge) - свод знаний по управлению бизнес-процессами Ассоциации профессионалов управления бизнес-процессами (ABPMP)

• PMBOK (Project Management Body Of Knowledge) - свод профессиональных знаний по управлению проектами института управления проектами PMI

• сертификация IREB CPRE (certification in Requirements Engineering) Foundation Level - методология инженерии требований сообщества IREB.

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

На текущий момент существует множество способов представления знаний: семантические сети, фреймы, языки и нотации и др. (Википедия).

Один из этих способов можно было бы использовать для конспектирования изученного материала в виде модели знаний с целью:

• извлечь существенные понятия о концепциях, описанных в своде знаний

• получить структурированное системное представление о связях между концепциями

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

Что должна включать модель знаний

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

А раз это процессы, то классический подход к такой модели - ответить на основные вопросы:

• кто? - какие действующие лица с какими наборами компетенций выполняют активности в процессах

• как? - какие активности, техники и события включают в себя процессы, в какой последовательности выполняются; кроме описания самих активностей важно отразить:

  • ключевые принципы, на которых базируются активности

  • ключевые свойства и аспекты активностей

  • основные ограничения

  • определения и факты, связанные с процессами

• что? - какие поставляемые результаты и прочие сущности являются результатом активностей или поступают на вход активностей

• зачем? - какую ценность вносят активности и процессы в общий процесс инженерии требований и системного анализа.

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

• структурные - отношение к группе, связь части и общего

• зависимости - влияние концептов друг на друга или операции, связывающие концепты друг с другом

• динамические - обозначить последовательность выполнения, направление потока информации

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

Archimate для представления знаний

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

Далее описана попытка представить методологию инженерии требований сообщества IREB в виде модели знаний в нотации ArchiMate.

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

Некоторые примеры описания модели знаний элементами нотации Archimate:

1. Активности, группы активностей и связи между ними

Цель описания: ответить на вопрос Как? - описать последовательность и структуру выполняемых в процессе активностей, а так же применяемые техники.

С помощью элемента слоя реализации Пакет работ (Work Package) можно отразить активности и техники используемые в процессах.

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

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

Элемент Ценность (Value) позволяет указать ценность или преимущества использования активности в общем процессе и ответить на вопрос модели Зачем?.

2. Результаты активностей

Цель описания: ответить на вопрос Что? - описать основные ключевые результаты активностей и процессов, информационные потоки.

Результаты активностей описываются элементом Поставляемые результаты (Deliverable).

С помощью связи Реализация (Realization) отражается - какая активность создает поставляемые результаты. Связь Доступ (Access) позволяет показать чтение или запись информации из/в поставляемые результаты. Связь Поток отражает факт передачи информации (без конкретизации сущностей) между активностями или событиям.

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

3. Свойства активностей

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

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

С помощью элемента Требование (Requirement) описываются свойства или аспекты, связанные с активностью или поставляемыми результатами процесса. Элемент Принцип (Principle) позволяет описать ключевые принципы, связанные с активностью. Элемент Понятие (Meaning) можно использовать для описания ключевых понятий и определений.

С помощью связи Ассоциация (Association) описанные артефакты связываются с активностями и поставляемыми результатами.

Например, процесс инженерии требований имеет Ключевые аспекты процесса RE (декомпозируются в отдельном представлении) и основывается на девяти ключевых принципах. Принцип 4. Контекст связан с концептом Контекст (само определение дано в описании элемента).

Факторы, каким то образом ограничивающие пространство свойств или оказывающие влияние на свойство отражаются элементом Ограничение (Constraint), а само влияние отражается связью Влияние (Influence).

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

Цель описания: ответить на вопрос Кто? - описать наборы компетенций и основных действующих лиц, участвующих в процессах.

Элемент Роль (Business Role) позволяет отразить набор компетенций или зону ответственности, связанных с активностью. Элемент Актор (Business Actor) представляет бизнес-сущность, выполняющую активность. Это может быть как конкретное лицо, так и структурные единицы, например, подразделения.

С помощью связи Назначение (Assignment) устанавливается связь между соответствующим активным элементом и активностью, им выполняемой.

Например, Заинтересованные стороны формируют Потребность в изменениях, запускающую процесс инженерии требований, который выполняет роль Инженер по требованиям, обладающая некоторым набором компетенций (указаны в описании).

5. Структурные связи между сущностями. Обобщение и специализация

С помощью связи Агрегация (Aggregation) однотипные элементы могут быть объединены в группы, организованные в сложные иерархии. На схеме элементы могут отражаться как отдельные элементы, связанные между собой, так и располагаться в границах родительского элемента. Например, в группу ключевых аспектов процесса инженерии требований входит аспект Требование и время, который, в свою очередь, включает аспект Спецификация, ориентированная на риск.

С использованием связи Композиция (Composition) отображаются случаи, когда один элемент является неотъемлемой частью другого (не может существовать без него). Например, активность по обучению пользователей является частью процесса выбора CASE-инструмента.

Отразить связь между абстрактным концептом и его конкретными реализациям позволяет связь Специализация (Specialization). Например, к концепту Модель относятся модели системного контекста, которые в свою очередь могут быть реализованы как DFD-диаграммы или UML-варианты использования.

6. Что еще может Archi

К каждому элементу может быть составлено описание или дано текстовое уточнение.

В состав ArchiMate входит инструмент для просмотра всех связей выбранного элемента. Глубина связей может настраиваться.

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

Заключение

Методология инженерии требований сообщества IREB описана моделью представления знаний в формате ArchiMate. Результат здесь:

• Модель знаний о требованиях

Что удалось:

• в графической форме представить знания об инженерии требований

• выделить основные концепции, связи между ними и зафиксировать описание ключевых определений

• реализовать простой и удобный доступ к модели в интернете.

Какие остались вопросы:

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

• область применения модели - достаточность для описания других областей знаний системного анализа

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

Decision Table (таблица решений) техника, помогающая наглядно изобразить комбинатору условий из ТЗ.

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

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

Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

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

2. Decision Table (таблицы решений) текущая статья

3. State & Transition Diagramm (схема состояний и переходов) TBD

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD

Сегодня говорим про Decision Table (таблица решений):

1. Как составлять таблицу

2. Плюсы подхода

3. Минусы подхода

4. Итого

Помимо статьи есть видео о таблице решений с моего канала. Кому что удобнее! :)

Как составлять таблицу

• По горизонтали выписываем условия, которые влияют на результат. А чуть ниже сам результат, в оригинале Action действие, которое нужно выполнить.

• По вертикали правила:конкретная комбинация входных условий.

То есть мы указываем значения условий и результата

Давайте посмотрим на простом примере когда у нас один результат (action).

Пример 1. Страховка на автомобиль (один результат)

Я прихожу в страховую компанию и заполняю анкету, где есть 2 вопроса:

1. Есть ли 5 лет стажа вождения?

2. Была ли в авариях?

Ответить можно либо да, либо нет.

Получается 2 условия по 2 возможных варианта, итого 4 варианта пересечения условий, 4 правила. На каждое правило свой результат:

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

• Если нет стажа, но нет аварий плачу поменьше, но не сильно. Знаете как бывает первое время катаются очень осторожно, а потом начинают думать да я царь и бог, не попаду в аварию. И понеслось...

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

• Если опытный, да еще и без аварий меньше всего. Очень аккуратный водитель, платить скорее всего не придется!

А теперь то же самое, только в виде таблички:

Согласитесь, табличка выглядит лучше стены текста выше, да? Еще лучше может быть только картинка!

Но для красивой картинки нужно уметь рисовать. А для составления таблички нет! И в этом её удобство можно не быть художником, но наглядно переписать ТЗ.

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

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

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

Пример 2. Интернет-магазин (множественный результат)

Есть интернет-магазин, который предлагает:

• Скидку постоянного покупателя

• Количество вещей, которые курьер привезет бесплатно

Это такие плюшки за лояльность и повторную покупку. Как плюшки высчитываются? Есть два условия:

• Сколько клиент потратил (всего или за какой-то период времени) бонус добавляется при достижении 100р, 500, 1000 и 5000

• Какой процент выкупа (а то, может, курьер зря мотается) бонус получаем при достижении 5%, 30%, 50% и 80%

Если я потратила 100р и почти ничего не выкупила скидки мне не дадут и вещей мало привезут. Если потратила больше и выкупила больше, то дадут небольшую скидочку. Ещё потрачу станут вещей больше привозить... И так далее.

Положим требования в таблицу:

Заметьте, что условия 2, и в каждом возможны 4 варианта это 16 возможных пересечений, 16 тестов!

Попробуем записать все условия:

Даже в виде таблицы уже сложновато читается... А в виде простого текста вообще ничего не разберешь!

Конечно, интернет-магазин явно не будет мудрить, скорее всего они просто завяжут одну плюшку на одно условие:

• Потратил 100 р 0% скидка

• 500 5%

• 1000 10%

• 5000 20%

А количество вещей будет зависеть от выкупа... Тогда и без таблички можно оставить в ТЗ, вполне понятный список!

Но сложные взаимосвязи между разными условиями также встречаются. И если они у вас есть составьте decision table хотя бы один раз. Чтобы разобраться во всех этих правилах, всё учесть и ничего не забыть!

Плюсы подхода

1. Наглядность таблица нагляднее текста. Можно взять таблицу и подойти к аналитику с каким-то вопросом. Или к разработчику. Им будет проще понять, о чём речь, чем если вы принесете стену текста.

2. Нарисовал таблицу = записал тест-кейсы. Поменял в заголовках слово правило на тест-кейс, и вот они, готовые тесты! И это будут основные позитивные тесты, которые мы проводим в первую очередь.

Если неудобно, что тест приходится читать сверху вниз, а не слева направо, таблицу можно инвертировать перевернуть:

3. Наглядность поможет найти баги в документации. Так как косяк формулы будет сразу бросаться в глаза.

4. Таблица помогает взглянуть на ТЗ свежим взглядом, по-новому. Пока мы пытаемся перекомбинировать условия, составляя таблицу, мы можем заметить пропущенный ранее баг.

Минусы подхода

Особых минусов нет, но таблица не нужна, если:

• Слишком простое условие потому что но зачем?. И так все понятно.

• Слишком много входных данных овер дофига будет колонок. Много тестов, но мало результата, потому что тут уже нужен тест-анализ, pairwise и т.д.

Итого

Decision Table используется для описания сложных системных правил:

• Условия представляют собой входные данные.

• Действия это ожидаемый результат.

• Колонки тест-кейсы!

Я настоятельно рекомендую применять эту технику хотя бы однократно к тем требованиям, которые вы уже знаете наизусть. Думаете, проверили все возможные комбинации? Нарисуйте таблицу решений и результат вас удивит!

Отлично подходит для размыливания взгляда и действительно сложных ТЗ, когда таблица получается на 100 колонок. Поддерживать ее довольно накладно и вряд ли кто-то будет это делать, а вот одноразовая акция найдет баги!

См также:

Как составлять вариант использования ещё один вариант оформления требований.

PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале

State & Transition Diagram (сокращенно S&T) схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Мы рисуем:

• кружочки состояния объекта;

• стрелочки то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.

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

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

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

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов) текущая статья

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD

Сегодня поговорим про State & Transition Diagram:

1. Как рисовать диаграмму

2. Примеры S&T

3. Типовые ошибки при составлении карты

   • Вместо объекта GUI

   • Несколько объектов в одной карте

   • Несколько одинаковых состояний

4. Плюсы подхода

5. Минусы подхода

6. Инструменты для рисования

7. Итого

Как рисовать диаграмму

Очень важно: S&T рисуется на объект! Один объект. В идеале на объект, имеющий аналог в базе данных продукта.

Шаг 1. Вы выбираете объект в своём проекте (рабочем или учебном, не суть).

Шаг 2. Думаете, какие у него состояния. Они не должны пересекаться, то есть: объект не может быть разом в двух состояниях, и при этом он всегда хоть в каком-то одном есть

Шаг 3. Рисуете эти состояния кружочками.

Шаг 4. Соединяете их стрелочками. Стрелочки - это действия, их надо подписать.

Шаг 5. Смотрите, что получилось и анализируете, есть ли у объекта другие состояния? А другие действия между текущими состояниями? Переход на шаг 2.

Кто не будет выполнять эту последовательность шагов, очень рискует вместо S&T нарисовать схему вышивки крестиком)))

Чтобы начать, задайте себе вопросы:

1. Какой конкретно объект вы выбрали? Как он называется? (только один!)

2. Какие у этого объекта есть состояния?

Основное определение состояния "набор доступных и недоступных действий с объектом". Продукт всегда должен знать, в каком состоянии каждый его объект. Вообще, когда будете думать об объектах и состояниях, старайтесь представлять их аппаратную реализацию.

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

Вот пример хорошей диаграммы:

State Transition на примере тортика!

В чатике моей школы для тестировщиков был очень интересный диалог по поводу рисования State Transition. Студентка рисует его для просмотра сериала и пытается разобраться, как это сделать:

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

Ну смотрите, Вы продолжаете описывать и смотреть на вещи, как пользователь, а надо как тестировщик. Сериалы из пустоты не берутся. Кто-то их закачивает. Значит, все же связка "сериала не существует" и "сериал загружен на сайт" уже есть)

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

По-хорошему у тестировщиков на это есть права) и им дают необходимый доступ.

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

Тут моя коллега решила объяснить рисование карты на примере... Тортика! Дальнейший диалог был просто потрясающий, не могу не поделиться им с вами (разумеется, с разрешения коллеги, все же это ее идея, а не моя). Итак, приступаем:

Вот смотрите... Торт любите? Или другую еду какую-нибудь)

Допустим)

Отлично.

Чтобы приготовить торт, нам нужны ингредиенты, правильно? Это то, из чего он состоит. Как и наши объекты из параметров, но только в граммах.

Так вот, от того, что какого-то ингредиента будет больше/меньше, состояние торта не изменится. Он будет по-прежнему "не существует".

Чтобы его состояние изменилось надо начать что-то с ними делать. Например, смешать, залить в форму и отправить в духовку. Тогда состояние будет "В процессе готовки".

Потом, когда бисквит испечется, мажем его кремом и украшаем. Он становится у нас "Торт украшен".

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

Мы можем съесть торт, тогда он станет "Торт съеден".

Возможно, мы уедем и не съедим торт, пока его можно есть. Тогда он станет "Торт испорчен".

Кстати, в процессе приготовления могли быть и другие ответвления. Например:

передержали бы бисквит, состояние изменилось бы на "Торт испорчен";

не стали бы украшать бисквит и корж испортился бы "Торт испорчен";

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

Ок, изначально торта у Вас не было. Потом у Вас появилось состояние "Торт куплен". А дальше то, что происходит после "Торт готов" \_()_/

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

То есть, я правильно понимаю?

1.Купила

2.Поставила в холодильник на потом

3.Передумала, достала, надкусала

4.Снова передумала, решила съесть целиком, осилила половину

5. Расстроилась и решила не доедать вообще и выкинуть

Это всё не важно и состояние торта не меняется, пока он не съеден или не стух?)

Ну он же еще является тортом? Если его начали есть, но не закончили можно ввести промежуточное состояние "В процессе уничтожения" =))

1-2 это торт куплен

3-4 это в процессе уничтожения

5 выброшен

Тогда чем это отличается от

1. Купила добавлен на сайт/загружен на сайт/находится на сайте

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

3 - 4. Передумала, достала, надкусала, снова передумала, решила съесть целиком, осилила половину в процессе просмотра/уничтожения

5. Расстроилась и решила не доедать вообще и выкинуть просмотр прерван/торт в помойке

5-е он еще в процессе.

У сериалов обычно прогресс есть, и его просто так не убрать :)

- либо досмотрел

- либо он в процессе просмотра

Спасибо!

Примеры S&T

Примеры диаграмм можно посмотреть в конфлюенсе (доступ открытый без авторизации). Туда я выношу хорошие работы своих студентов. Их там сильно больше, чем в этом разделе статьи + обычно там можно и сам исходник скачать, чтобы внимательно всё рассмотреть. Welcome =)

Вот некоторые из этих работ:

Ольга (объект тест)

Кристина (Fallout Shelter)

Fallout Shelter игра под iOS, Android. В постапокалиптическом мире несколько людей было выбрано для создания светлого будущего. Их поместили в небольшое убежище, уходящее под землю. Это убежище необходимо развивать, защищать от угроз из внешнего мира, увеличивать количество жителей, производить ресурсы, выполнять квесты.

State Transition для пина в Pinterest

Типовые ошибки при составлении карты

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

1. Вместо объекта GUI

Очень важно: S&T рисуется на объект! Это не зарисовка графического интерфейса открыта страница такая, открыта страница сякая... Если вы описываете разные странички GUI это уже не S&T.

Зарисовывать страницы смысла обычно нет. Это как при рисовании майнд-карты мы не рисуем графический интерфейс, мы описываем функционал. То, зачем пользователь вообще пришел на сайт. Это намного полезнее!

См также:

Как нарисовать карту приложения (mind map)

Другой вариант той же ошибки: искать билет (результаты поиска) открыть форму покупки (форма открыта) ввести данные кредитной карты (данные введены).

2. Несколько объектов в одной карте

На прошлой картинке у нас несколько объектов: результаты поиска, форма, данные. И все плохие. Потому что там мы явно что-то покупаем, вот это что-то и есть объект!

Но когда мы описываем покупку, тоже легко скатиться в несколько объектов в одной карте: "пицца в корзине", "заказ оформлен".

Товар тоже очень часто путают, потому что есть два варианта:

1. как на авито продается конкретная вещь: "Нет на сайте", "Продается", "Продан".

2. просто "товарная позиция", как какие-нибудь носки в магазине одежды: "Отсутствует", "В наличии", "Ожидается поступление" и так далее.

Если речь о сайте типа авито, то объект лучше выбрать "объявление", будет логичнее. А вот если мы покупаем пиццу это будет товарной позицией.

3. Несколько одинаковых состояний

Вспомните пример с тортиком:

1. Купила.

2. Поставила в холодильник на потом.

3. Передумала, достала, надкусала.

4. Снова передумала, решила съесть целиком, осилила половину.

5. Расстроилась, решила не доедать вообще и выкинуть.

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

• 1-2 это торт куплен;

• 3-4 в процессе уничтожения;

• 5 выброшен.

Другой пример объект пин:

• пин создан;

• пин откоментирован;

• пин перенесен другим пользователем себе на доску.

Но, когда пин откомментирован или сдублирован это тоже самое, когда он просто создан. Состояние самого пина не меняется!

Или например:

• товар в базе

• товар найден при поиске

Одно и то же с точки зрения товара. Он как был, так и есть =)

Плюсы подхода

Плюс рисования это визуализация ТЗ, которая:

1. Красиво выглядит

2. Позволяет увидеть, что мы упустили

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

И пока мы рисуем его маршрут, мы можем сразу же заметить, что Ага! Вот из этого состояния, наверное, можно вернуться ещё вот в это, то есть мы можем понять, что упускаем. А если бы не нарисовали, то даже не додумались бы до такого теста!

Минусы подхода

Не всегда визуализация делает ТЗ понятнее. И тогда начинаем думать, как это решать:

1. Слишком насыщенная карта разбиваем на несколько маленьких.

2. Сложно поддерживать нужна ли она вообще?

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

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

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

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

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

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

К тому же от руки получается быстрее, а иногда еще и красивее. Почему? Потому что когда мы начинаем использовать инструмент, то он нас ограничивает. Вот, нам надо нарисовать стрелочку, так, а как нам это сделать... Мы начинаем думать в стиле инструмента. Это как когда мы создаем презентации в power point, то вместо мыслей о докладе думаем, как бы назвать новый слайд.

А если бумажка рядом, можно спокойно генерить в голове идеи и условия. Что придумал? Зарисовал кое-как. Если очень хочется, потом перерисовал красиво. А, может, и так сойдет.

В любом случае смотрите сами. Если удобен какой-то инструмент используйте его! Хорошо получаются такие схемы в Xmind или Yed, или в гуглодокументах. Попробуйте использовать несколько разных инструментов, а потом выберите тот, что больше по душе. Но в целом бумага и ручка вполне себе вариант!

Итого

Рисунок мощнейший инструмент визуализации. Вот вы открываете статью с картинками, типа этой. На что вы смотрите в первую очередь на картинку или на текст? Правильно, на картинку.

Поэтому я за то, что рисовать! Нарисовали? Добавили в ТЗ! Всем удобнее, даже заказчику. Ведь с картинками текс становится понятнее.

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

Зарисовали, позвали аналитика и стали обсуждать:

А вот смотрите, вот эта стрелочка... может нам стоит сделать еще вот это?

А что будет, если вот так?

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

См также:

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

Decision Table что это и как применять и ещё один вариант, рисуем таблички.

PowerPoint как инструмент тестировщика да, так тоже можно было =)

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

State & Transition Diagram (сокращенно S&T) схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Мы рисуем:

• кружочки состояния объекта;

• стрелочки то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.

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

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

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

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов) текущая статья

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD

Сегодня поговорим про State & Transition Diagram:

1. Как рисовать диаграмму

2. Примеры S&T

3. Типовые ошибки при составлении карты

   • Вместо объекта GUI

   • Несколько объектов в одной карте

   • Несколько одинаковых состояний

4. Плюсы подхода

5. Минусы подхода

6. Инструменты для рисования

7. Итого

Как рисовать диаграмму

Очень важно: S&T рисуется на объект! Один объект. В идеале на объект, имеющий аналог в базе данных продукта.

Шаг 1. Вы выбираете объект в своём проекте (рабочем или учебном, не суть).

Шаг 2. Думаете, какие у него состояния. Они не должны пересекаться, то есть: объект не может быть разом в двух состояниях, и при этом он всегда хоть в каком-то одном есть

Шаг 3. Рисуете эти состояния кружочками.

Шаг 4. Соединяете их стрелочками. Стрелочки - это действия, их надо подписать.

Шаг 5. Смотрите, что получилось и анализируете, есть ли у объекта другие состояния? А другие действия между текущими состояниями? Переход на шаг 2.

Кто не будет выполнять эту последовательность шагов, очень рискует вместо S&T нарисовать схему вышивки крестиком)))

Чтобы начать, задайте себе вопросы:

1. Какой конкретно объект вы выбрали? Как он называется? (только один!)

2. Какие у этого объекта есть состояния?

Основное определение состояния "набор доступных и недоступных действий с объектом". Продукт всегда должен знать, в каком состоянии каждый его объект. Вообще, когда будете думать об объектах и состояниях, старайтесь представлять их аппаратную реализацию.

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

Вот пример хорошей диаграммы:

State Transition на примере тортика!

В чатике моей школы для тестировщиков был очень интересный диалог по поводу рисования State Transition. Студентка рисует его для просмотра сериала и пытается разобраться, как это сделать:

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

Ну смотрите, Вы продолжаете описывать и смотреть на вещи, как пользователь, а надо как тестировщик. Сериалы из пустоты не берутся. Кто-то их закачивает. Значит, все же связка "сериала не существует" и "сериал загружен на сайт" уже есть)

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

По-хорошему у тестировщиков на это есть права) и им дают необходимый доступ.

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

Тут моя коллега решила объяснить рисование карты на примере... Тортика! Дальнейший диалог был просто потрясающий, не могу не поделиться им с вами (разумеется, с разрешения коллеги, все же это ее идея, а не моя). Итак, приступаем:

Вот смотрите... Торт любите? Или другую еду какую-нибудь)

Допустим)

Отлично.

Чтобы приготовить торт, нам нужны ингредиенты, правильно? Это то, из чего он состоит. Как и наши объекты из параметров, но только в граммах.

Так вот, от того, что какого-то ингредиента будет больше/меньше, состояние торта не изменится. Он будет по-прежнему "не существует".

Чтобы его состояние изменилось надо начать что-то с ними делать. Например, смешать, залить в форму и отправить в духовку. Тогда состояние будет "В процессе готовки".

Потом, когда бисквит испечется, мажем его кремом и украшаем. Он становится у нас "Торт украшен".

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

Мы можем съесть торт, тогда он станет "Торт съеден".

Возможно, мы уедем и не съедим торт, пока его можно есть. Тогда он станет "Торт испорчен".

Кстати, в процессе приготовления могли быть и другие ответвления. Например:

передержали бы бисквит, состояние изменилось бы на "Торт испорчен";

не стали бы украшать бисквит и корж испортился бы "Торт испорчен";

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

Ок, изначально торта у Вас не было. Потом у Вас появилось состояние "Торт куплен". А дальше то, что происходит после "Торт готов" \_()_/

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

То есть, я правильно понимаю?

1.Купила

2.Поставила в холодильник на потом

3.Передумала, достала, надкусала

4.Снова передумала, решила съесть целиком, осилила половину

5. Расстроилась и решила не доедать вообще и выкинуть

Это всё не важно и состояние торта не меняется, пока он не съеден или не стух?)

Ну он же еще является тортом? Если его начали есть, но не закончили можно ввести промежуточное состояние "В процессе уничтожения" =))

1-2 это торт куплен

3-4 это в процессе уничтожения

5 выброшен

Тогда чем это отличается от

1. Купила добавлен на сайт/загружен на сайт/находится на сайте

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

3 - 4. Передумала, достала, надкусала, снова передумала, решила съесть целиком, осилила половину в процессе просмотра/уничтожения

5. Расстроилась и решила не доедать вообще и выкинуть просмотр прерван/торт в помойке

5-е он еще в процессе.

У сериалов обычно прогресс есть, и его просто так не убрать :)

- либо досмотрел

- либо он в процессе просмотра

Спасибо!

Примеры S&T

Примеры диаграмм можно посмотреть в конфлюенсе (доступ открытый без авторизации). Туда я выношу хорошие работы своих студентов. Их там сильно больше, чем в этом разделе статьи + обычно там можно и сам исходник скачать, чтобы внимательно всё рассмотреть. Welcome =)

Вот некоторые из этих работ:

Ольга (объект тест)

Кристина (Fallout Shelter)

Fallout Shelter игра под iOS, Android. В постапокалиптическом мире несколько людей было выбрано для создания светлого будущего. Их поместили в небольшое убежище, уходящее под землю. Это убежище необходимо развивать, защищать от угроз из внешнего мира, увеличивать количество жителей, производить ресурсы, выполнять квесты.

State Transition для пина в Pinterest

Типовые ошибки при составлении карты

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

1. Вместо объекта GUI

Очень важно: S&T рисуется на объект! Это не зарисовка графического интерфейса открыта страница такая, открыта страница сякая... Если вы описываете разные странички GUI это уже не S&T.

Зарисовывать страницы смысла обычно нет. Это как при рисовании майнд-карты мы не рисуем графический интерфейс, мы описываем функционал. То, зачем пользователь вообще пришел на сайт. Это намного полезнее!

См также:

Как нарисовать карту приложения (mind map)

Другой вариант той же ошибки: искать билет (результаты поиска) открыть форму покупки (форма открыта) ввести данные кредитной карты (данные введены).

2. Несколько объектов в одной карте

На прошлой картинке у нас несколько объектов: результаты поиска, форма, данные. И все плохие. Потому что там мы явно что-то покупаем, вот это что-то и есть объект!

Но когда мы описываем покупку, тоже легко скатиться в несколько объектов в одной карте: "пицца в корзине", "заказ оформлен".

Товар тоже очень часто путают, потому что есть два варианта:

1. как на авито продается конкретная вещь: "Нет на сайте", "Продается", "Продан".

2. просто "товарная позиция", как какие-нибудь носки в магазине одежды: "Отсутствует", "В наличии", "Ожидается поступление" и так далее.

Если речь о сайте типа авито, то объект лучше выбрать "объявление", будет логичнее. А вот если мы покупаем пиццу это будет товарной позицией.

3. Несколько одинаковых состояний

Вспомните пример с тортиком:

1. Купила.

2. Поставила в холодильник на потом.

3. Передумала, достала, надкусала.

4. Снова передумала, решила съесть целиком, осилила половину.

5. Расстроилась, решила не доедать вообще и выкинуть.

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

• 1-2 это торт куплен;

• 3-4 в процессе уничтожения;

• 5 выброшен.

Другой пример объект пин:

• пин создан;

• пин откоментирован;

• пин перенесен другим пользователем себе на доску.

Но, когда пин откомментирован или сдублирован это тоже самое, когда он просто создан. Состояние самого пина не меняется!

Или например:

• товар в базе

• товар найден при поиске

Одно и то же с точки зрения товара. Он как был, так и есть.

Плюсы подхода

Плюс рисования это визуализация ТЗ, которая:

1. Красиво выглядит

2. Позволяет увидеть, что мы упустили

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

И пока мы рисуем его маршрут, мы можем сразу же заметить, что Ага! Вот из этого состояния, наверное, можно вернуться ещё вот в это, то есть мы можем понять, что упускаем. А если бы не нарисовали, то даже не додумались бы до такого теста!

Минусы подхода

Не всегда визуализация делает ТЗ понятнее. И тогда начинаем думать, как это решать:

1. Слишком насыщенная карта разбиваем на несколько маленьких.

2. Сложно поддерживать нужна ли она вообще?

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

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

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

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

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

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

К тому же от руки получается быстрее, а иногда еще и красивее. Почему? Потому что когда мы начинаем использовать инструмент, то он нас ограничивает. Вот, нам надо нарисовать стрелочку, так, а как нам это сделать... Мы начинаем думать в стиле инструмента. Это как когда мы создаем презентации в power point, то вместо мыслей о докладе думаем, как бы назвать новый слайд.

А если бумажка рядом, можно спокойно генерить в голове идеи и условия. Что придумал? Зарисовал кое-как. Если очень хочется, потом перерисовал красиво. А, может, и так сойдет.

В любом случае смотрите сами. Если удобен какой-то инструмент используйте его! Хорошо получаются такие схемы в Xmind или Yed, или в гуглодокументах. Попробуйте использовать несколько разных инструментов, а потом выберите тот, что больше по душе. Но в целом бумага и ручка вполне себе вариант!

Итого

Рисунок мощнейший инструмент визуализации. Вот вы открываете статью с картинками, типа этой. На что вы смотрите в первую очередь на картинку или на текст? Правильно, на картинку.

Поэтому я за то, что рисовать! Нарисовали? Добавили в ТЗ! Всем удобнее, даже заказчику. Ведь с картинками текс становится понятнее.

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

Зарисовали, позвали аналитика и стали обсуждать:

А вот смотрите, вот эта стрелочка... может нам стоит сделать еще вот это?

А что будет, если вот так?

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

См также:

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

Decision Table что это и как применять и ещё один вариант, рисуем таблички.

PowerPoint как инструмент тестировщика да, так тоже можно было.

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

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

Как же сделать ТЗ понятнее? Можно улучшить текст вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое =)

А ещё техники, помогающие лучше понять требования, относятся к техникам тест-дизайна. Значит, о них стоит знать! В одну статью всё запихивать не стала и сделала отдельные:

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

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов)

Но значит ли это, что таблица или S&T единственный способ визуализации? Разумеется, нет! Можно рисовать вообще всё, что вам вздумается. Главное чтобы картинка помогала лучше понять требование или тест (да, при описании тестов визуализация тоже помогает!).

И сегодня я покажу разные примеры визуализации из своей практики, или работ моих студентов. Может, что-то из этого приглянётся и вам! =)

1. Как рисовать картинку

2. Примеры

3. Плюсы подхода

4. Минусы подхода

5. Инструменты для рисования

6. Итого

Как рисовать картинку

Берем требование и представляем в графическом виде. Всё!

Главное отличие от S&T в том, что нам необязательно рисовать именно объект. Мы рисуем всё, что захотим. Всё, что поможет сделать ТЗ более читабельным, да хоть интерфейс в виде карты! Или блок-схема, или что-то ещё.

Примеры

.

Карта сценариев

Функционал взаимодействия с конкретной книгой (взято из работ моих студентов):

Это карта сценариев, а не S&T, но он этого она не менее полезная!

.

Загрузка инкремента

Блок-схема про то, как это работает под капотом. На одном из проектов мы сделали довольно хитрую схему импорта данных из буферной таблицы. Для пользователей написан вариант использования, и там всё просто:

• Исходная система выгрузила данные в буферные таблицы.

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

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

1. Подготовка данных

2. Загрузка

3. Очистка буфера

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

Это было продуктивное общение! Пока он объяснял, я рисовала на бумажке схему и задавала по ней вопросы. После нескольких вопросов раработчик признал, что я молодец, он про вот это и то не думал. Не зря рисовала! Без рисунка я бы просто не удержала всё в голове, и не обнаружила проблемные зоны.

По итогам обсуждения я создала в вики раздел Техническая сторона сценариев, алгоритмы и переписала туда все со своего листочка, полученный алгоритм и рисунок (в visio накидала):

1. null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.

2. Удаляем неактуальные записи из буферных таблиц (физ лица и телефонов).

3. Грузим физиков по условию in (id_increment, для которого import_status in 1).

4. Грузим телефоны по условию in (import_status in 1).

5. Создаем связи телефон - физик или телефон - юрик (тип контрагента смотрим по таблице staging).

6. Удаляем физиков из буфера, если не было ошибок на этапе загрузки.

7. Удаляем те телефоны, у которых есть связи (проверяем наличие record_id физика/юрика в staging).

8. 1 => 2. Выбираем все записи из таблицы INCREMENTS, где import_status = 1 и устанавливаем им значение import_status = 2.

Согласитесь, при наличии такой картинки тесты на каждый раздел писать намного проще! Я четко вижу, что задача подготовки выполняет три действия. Значит, тестируем каждое!

null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.

Добавляем запись с пустым import_status проверяем, что статус изменился на 1.

А если исходно был статус 1?

А если исходно другой статус?

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

Что у нас дальше? ...

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

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

.

Тесты в PowerPoint!

Метод рисунка работает не только с ТЗ, но и с тестами!

Тестировала оракловые вьюшки (view). Фактически это просто табличка с нужными мне колонками. Как любой отчет в интерфейсе. Cтроится отчет по определенному диапазону времени. Если сущность менялась в этом диапазоне она попадет во view. Если нет то увы.

На входе у меня есть текущее состояние базы когда объект был создан, а когда закрыт. И параметры диапазона:

• from_date начальная дата

• to_date конечная дата

Я набросала все интересные мне тесты в блокноте это быстрее всего. Допустим, объект создали 5 числа, а удалили 10. Какие интервалы между ними мне надо посмотреть?

Рисунки помогают мне быстро охватить картину покрытия тестами. Так, вот только создание попадает в диапазон есть. А оба события сразу есть. А между ними? Есть. А... И так далее. Накидаешь идей за пару минут мозгового штурма, и можно с ними работать. Переносить в код и описывать на вики.

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

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

Обычно я рисую в yEd. Но черточки и текст отдельно там сделать проблематично. Тут не подходит. Хм... Paint? Открыла его, нарисовала кривую "прямую" :) Тоже неудобно, хочется, чтобы симпатичненько смотрелось, а мышкой я прямые линии буду полчаса рисовать. Visio покупать надо... О, PowerPoint!

Открыла, попробовала. Поставила исходные засечки "создан 5, закрыт 10". Добавила прямоугольник на задний план идеально! Просто перетаскиваешь прямоугольник, то сужая, то расширяя его, и делаешь скриншоты. А как наглядно получается:

Добавим картинки в описание тестов на конфлюенсе (вики):

Красота!

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

Есть картинки и посложнее. Когда событий будет поболее, чем просто "создали один объект и его же закрыли". Тут мне было удобнее рисовать время по вертикальной оси:

Вот тут то меня PowerPoint и выручил! Если делать зарисовки от руки, то на каждый тест надо повторять основу, а потом обводить кружочком нужный диапазон. Получится долго. А без визуализации "что я уже сделала" мне тяжело. А в программе вжух-вжух поперемещал желтый прямоугольничек, заскринил каждую вариацию и готово! Даже круче блокнотика и ручки :)

Плюсы подхода

Визуализация!

1. Позволяет увидеть, что мы упустили

2. Помогает там, где много входных условий

Двойной профит визуализации: пока вы рисуете, то видите все слабые зоны ТЗ. А ещё делаете его более наглядным. Теперь каждый, кто будет читать ТЗ после вас, сразу всё поймет!

Минусы подхода

Картинку должен кто-то поддерживать, и это кто-то явно вы =)

Но всегда можно нарисовать ее одноразово!

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

Если задача простая используйте бумагу и ручку. Будет быстрее.

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

Итого

Рисунок мощнейший инструмент визуализации. Если вам сложно что-то понять, зарисуйте это! Это может быть сложный участок ТЗ или чек-лист тестов. Пробуйте, экспериментируйте это время обязательно окупится. Причем сразу же, ведь, пока рисуешь, приходит вдохновение "проверить еще вот тут"!

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале