После организации требований и сервисных политик на предыдущем этапе планирования, а также частичного определения информационной архитектуры, структуры меню и пользовательского потока я приступил к созданию спецификаций экранов, которые переводили эту информацию в реальные проекты экранов.
Сначала я думал, что для спецификации экрана будет достаточно указать, какие функции необходимы на каждом экране и какие данные должны отображаться. Однако после создания нескольких экранов в реальном проекте я понял, что в спецификации экрана нужно учитывать гораздо больше, чем я ожидал.
После перехода к этапу разработки я лично проверил, были ли реализованы функции в соответствии с подготовленными мной спецификациями экранов. В ходе этого процесса я выявил исключительные случаи, упущенные на этапе планирования, а также ошибки, возникшие во время разработки. На практике я понял, что функция считается полностью завершённой только после её планирования, проектирования, разработки и тестирования. Кроме того, я начал уделять внимание снижению количества ошибок в сервисе, проверяя и исправляя ошибки, обнаруженные во время тестирования.
В ходе этого процесса я сформировал критерии, которые стал считать важными на каждом этапе проектирования экранов и контроля качества. В этой статье я расскажу о пробах и ошибках, с которыми столкнулся при создании спецификаций экранов и проведении контроля качества в реальном проекте, а также о критериях, сформированных мной в процессе.
1. Детальное планирование экранов — пробы, ошибки и улучшения при создании спецификаций экранов
Базовая структура фактически использовавшейся мной спецификации экрана была следующей.
[Обложка] → [Содержание] → [История изменений] → [Структура меню] → [Список экранов (IA)] → [Матрица разрешений] → [Блок-схема] → [Общие политики] → [Детальные спецификации]
В частности, я считал важными следующие моменты и старался соответствующим образом управлять спецификациями экранов.
1) История изменений
Одной из областей, которой в процессе работы над проектом я неожиданно стал уделять много внимания, было управление версиями документов.
Планирование экранов не было задачей, которая завершалась после однократного выполнения.
При проверке экранов вместе с разработчиками возникали изменения, а при изменении политик существующие экраны иногда приходилось пересматривать заново.
Проблема заключалась в том, что по мере многократного редактирования документа мне всё чаще приходилось проверять: «Является ли документ, который я сейчас просматриваю, последней версией?»
и «Когда и что было изменено на этом экране?»
Поэтому по мере развития проекта я начал управлять именами файлов и версиями по единообразным правилам.
Например, имена файлов я стандартизировал следующим образом.
프로젝트명_화면 설계서_v1.2_20260613.pdfПри значительном изменении политики или существенном изменении структуры экрана я увеличивал первую цифру версии,
а небольшие изменения, такие как правки текста или изменения некоторых компонентов, обозначал увеличением последней цифры версии.
Такое различение версий значительно упростило сравнение предыдущих и текущих документов, а также проверку состояния экрана на определённый момент времени.
-
Правила увеличения версии:
- Версия после развёртывания и первоначального утверждения клиентом/командой: v1.0
- Существенные архитектурные изменения, такие как полная переработка макета UI или изменение ключевых бизнес-политик: увеличивать первую цифру (например, v1.0 ➔ v2.0)
- Добавление небольших подфункций, изменение текста уведомления или улучшение отдельных компонентов: увеличивать последнюю цифру (например, v1.0 ➔ v1.1)
Ещё с одной проблемой, связанной с пробами и ошибками, я столкнулся при управлении версиями.
Сначала я фиксировал на листе истории каждое небольшое изменение экранов.
Например, я заносил в историю всё, включая изменение названия одной кнопки или редактирование текста Description.
Поначалу я считал, что лучше фиксировать каждое изменение без исключений.
Однако по мере накопления правок лист истории становился чрезмерно сложным.
Даже когда мне нужно было проверить важное изменение политики, среди него оказывались небольшие правки, из-за чего поиск нужной информации, наоборот, занимал больше времени.
Поэтому впоследствии я разделил изменения на две категории и стал управлять ими отдельно.
Крупные изменения я фиксировал в общей истории в начале документа, а для небольших изменений, таких как простые правки текста или изменение положения компонентов, оставлял рядом с Description соответствующего экрана отметку о правке.
Например, на этом экране я указывал версию правки v1.2, дату правки и сведения о внесённом изменении.
После этого изменения я смог разделить историю крупных изменений всего документа и подробные изменения отдельных экранов.
В частности, это также упростило работу разработчиков, отвечающих за конкретные экраны: они могли быстро проверить только изменения, относящиеся к этим экранам.
2) Описание
При проектировании детальных экранов я размещал Wireframe в левой части экрана, а Description писал справа.
В Wireframe я размещал компоненты, которые фактически появятся на экране, такие как Input Box, Select Box, Radio Button, Checkbox и Data Grid, и добавлял номера к областям, требующим пояснения.
Сначала я сосредоточился на создании Wireframe, но по мере планирования большего количества экранов понял, что область Description важнее всего остального.
Когда я впервые занимался планированием экранов, я сосредоточился на документировании необходимых функций и их базового поведения. Однако при планировании нескольких экранов я понял, что заранее нужно определить не только обычные ситуации, но и такие случаи, как отображение уведомления при возникновении исключения, а также вид экрана при первом входе пользователя или при отсутствии данных.
Создавая экраны, я старался проверять начальное состояние, способ отображения данных, взаимодействие с пользователем, валидацию и исключительные ситуации.
① Начальное состояние и отображение данных
Сначала я документировал состояние экрана, отображаемое при первоначальном входе пользователя.
Например, вместо простой записи «Отобразить таблицу» я документировал критерии, необходимые для фактической реализации, например: «Таблица сортируется в порядке приоритета статусов “Failed > Warning > Canceled > Running > Passed” и отображает не более 20 записей».
② Взаимодействие с пользователем и правила навигации по экранам
Я также подробно описывал, что должно происходить при нажатии кнопки или компонента.
Например: «При нажатии кнопки [Редактировать] в центре отображается всплывающее окно слоя MB_01_P01 без перехода на другой экран», а также «Данные в нижней таблице обновляются каждый раз при изменении выбранного значения в поле со списком».
Я документировал такие детали, как необходимость перехода на другой экран и вид всплывающего окна.
③Проверка и исключительные случаи
В обычных ситуациях легко представить, как будет вести себя экран, но
-
когда введённые значения недействительны
-
когда результаты поиска отсутствуют
-
при попытке изменить данные, обработка которых уже завершена
-
когда пользователь без соответствующих разрешений пытается получить к ним доступ
подобные ситуации, отклоняющиеся от обычного сценария, было легко упустить из виду.
Поэтому после создания экрана я выработал привычку ещё раз задумываться: «Что должно происходить, если эта функция работает нештатно?»
В ходе этого процесса я понял, что спецификация экрана — это не просто документ, описывающий экран, а документ, который заранее уменьшает расхождения в интерпретации, способные возникнуть в процессе разработки.
2. Что я узнал, самостоятельно составляя тест-кейсы для QA
После того как разработка была в основном завершена, я составил тестовые сценарии, чтобы проверить, был ли сервис реализован в соответствии с написанными мной спецификациями экранов.
Когда я впервые проводил QA, я думал, что достаточно просто проверить, правильно ли работают функции.
Однако, составив тестовые сценарии на практике, я понял, что заранее определить, «что именно тестировать», не менее важно.
Поэтому в тест-кейсах я систематизировал следующие пункты.
-
ID теста
-
Функция и модуль
-
ID экрана
-
Тестовая учётная запись и данные
-
Предварительные условия теста
-
Процедура тестирования
-
Ожидаемый результат
-
Фактический результат
-
Статус теста
-
Сведения об устранении дефекта
При составлении тестов я делил процедуры тестирования и ожидаемые результаты на максимально подробные шаги.
Я описывал их на таком уровне, чтобы человек, проводящий фактическое тестирование, мог в точности им следовать.
Такой подход уменьшил количество пропусков во время тестирования, а также упростил объяснение разработчикам обстоятельств возникновения проблемы при регистрации дефектов.
Результаты тестирования я классифицировал с помощью статусов PASS, FAIL, BLOCK и TO DO.
Когда всё работало ожидаемым образом, я отмечал результат как PASS, а если поведение отличалось от ожидаемого результата, записывал FAIL.
При возникновении FAIL я не ограничивался записью «Не работает», а фиксировал то, что произошло на самом деле.
Например, если ожидаемым результатом было «Кнопка «Редактировать» не отображается для утверждённых данных», но на фактическом экране появлялась кнопка «Редактировать», я записывал: «Кнопка [Редактировать] отображается при запросе данных со статусом утверждения»
в качестве фактического результата.
Такая запись позволяла разработчикам сразу определить условия, при которых возникала проблема.
Кроме того, если следующий тест нельзя было выполнить из-за проблемы с функцией, являвшейся предварительным условием, например из-за ошибки входа в систему, я отмечал его как BLOCK.
Повторяя этот процесс, я понял на собственном опыте, что QA — это не просто задача, заключающаяся в последовательном нажатии на элементы функций, а процесс сопоставления требований, определённых на этапе планирования, с фактическими результатами реализации.
3. Заключение
Когда я только начинал проект, я думал, что спецификация экрана — это документ, описывающий внешний вид и функции экрана. Однако после создания нескольких экранов и сотрудничества с разработчиками моя точка зрения значительно изменилась.
Даже планируя один экран, я начал думать не только о том, «что видно на экране», но и задаваться вопросами: «В каком состоянии находится экран, когда пользователь впервые открывает его?», «Что происходит, когда данных нет?», «Что изменится, если у пользователя другие разрешения?» и «Что произойдёт при вводе недействительных данных?»
Я также понял, что завершение дизайна экрана не означает завершения функции. После разработки необходимо было проверить фактическую реализацию на соответствие написанным мной спецификациям, а также изучить и исправить ошибки или пропуски, обнаруженные во время тестирования. Я пришёл к выводу, что функция действительно не завершена, пока не проведён QA путём сравнения содержания, определённого на этапе планирования, с фактическими результатами реализации.
Вместо попытки с самого начала идеально определить все возможные ситуации я постепенно устанавливал критерии один за другим: отвечал на вопросы разработчиков, обнаруживал пропуски во время QA и сталкивался с неудобствами при управлении документами.
В конечном итоге я считаю, что хорошая спецификация экрана — это документ, который согласовывает стандарты, чтобы все участники проекта могли видеть и понимать один и тот же экран и его поведение, а QA — это процесс проверки того, что фактический сервис реализован в соответствии с этими стандартами.
ryu