За пятнадцать лет работы с десктопными продуктами у меня сформировался определённый список обязательных действий при проверке новой фичи. Его необходимость назрела через год-полтора после начала карьеры тестировщика, а пополнялся он регулярно после выпуска очередной версии и получения отчётов об ошибках от пользователей. Недавно меня просветили, что такие списки называют "cheat-sheet". После заглядывания в словарь мне вспомнился термин "бомба", практиковавшийся в студенческое время и являвшийся не шпаргалкой, писанной мелким шрифтом, а полноценным ответом на экзаменационный билет. Его писали обычным почерком на стандартном тетрадном листе дома, а во время подготовки в экзаменационной аудитории черновик для ответа заменялся на "бомбу", создавая впечатление у преподавателя только что написанного конспекта для ответа. Фактически cheat-sheet является "бомбой" для тест-дизайнера, так что термин вполне верен. Используя чит-лист можно приступать к тестированию сразу при поступлении новой фичи к вам в работу.
Наличие чит-листа в команде разработки может служить профилактикой багов, так как программисты могут ориентироваться на контрольные точки тестировщиков при написании корректного кода. А новому члену группы тестирования по подробному чит-листу можно доверять не только перепроверку исправленных багов, но и принимать новые фичи.
Как уже отмечалось ранее, чит-лист формировался в течение многих лет и на основании запросов об уровне качества, в основном конечных пользователей. Некоторые пункты могут показаться весьма специфичными, но это не значит, что вашему приложению это никогда не понадобится. Некоторые пункты из этого списка перекочевали в чек-лист выпуска версии.
1. Размер формы/окна. У формы должен быть задан минимальный размер и размер по-умолчанию. Он не должен превышать 768 пикселей по-вертикали и 1024 по-горизонтали.
2. Элементы на форме. При первом открытии окна, при выставлении размеров по-умолчанию, при уменьшении до минимальных размеров окна все элементы должны быть видны в видимых границах окна, блока. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
3. Пустоты. На форме не должно быть неоднозначных пустот. Это ассоциируется у пользователя с невозможностью приложения отрисовать дополнительные элементы. Расстояния между элементами желательно выставлять одинаковые, но не настолько отстающими друг от друга, чтобы у пользователя возникало желание растянуть элементы на пустое пространство.
4. Выравнивание. Элементы на окне должны быть выровнены иерархично по-вертикали, по-горизонтали с соблюдением колонок. Стандартные расстояния 6-12-24 пикселей. Значения в редакторах центрированы по-вертикали, по-горизонтали: символьные прижаты к левому краю, числовые – к правому, в особых случаях центрированы, заголовки столбцов выровнены аналогично значениям, кроме центрированных заголовков групп.
5. Масштабирование. Элементы окна не должны обрезаться, наезжать друг на друга при 120DPI, 125% и иных параметрах монитора. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
6. Несколько мониторов. Окна и диалоги должны быть привязаны к главным (родительским) окнам, чтобы не было проблем показа зависимых (дочерних, модальных) окон на не активном мониторе. Основное окно приложения должно открываться на основном мониторе при первом запуске, на пользовательски-выбранном при последующих запусках, на доступном мониторе после отключения пользовательски-выбранного.
7. Операционная система. Используйте новые возможности компонентов при их расширении (animated progress bar, touch screen и другие), но не затирайте полезные старые свойства (например, полноценная работа клавиатурой, а не только мышью). Список поддерживаемых версий операционной системы должен соответствовать перечисленному в системных требованиях продукта.
8. Подписи элементов. У элемента в коде программы должно быть две подписи через слеш на английском и русском языках. В режиме своего языка (английского по-умолчанию) не должно быть видно текстов на втором языке.
9. Хинт. У сложно-названных элементов окна и у действий со сложным функционалом (таких как check-box, link и другие) должен быть хинт, текст которого не равен подписи элемента. Стандартные кнопки OK, Close, Cancel, Yes, No не должны иметь никаких хинтов, если клик по ним выполняет только одно стандартное действие.
10. Хелп. У каждой формы должен быть хелп, вызываемый по горячей клавише F1, с достаточным описанием функционала.
11. Значение подписей. Функционал должен однозначно соответствовать названию элемента.
12. Стили подписей.
12.1. Все слова с большой буквы, кроме союзов, предлогов менее трёх символов в названии
12.1.1. окна,
12.1.2. пункта меню,
12.1.3. кнопки,
12.1.4. закладки,
12.1.5. заголовка столбца,
12.1.6. группы,
12.1.7. ветки дерева.
12.2. Только первое слово с большой буквы, кроме названий продуктов или важных возможностей, в названии
12.2.1. check box,
12.2.2. radio button,
12.2.3. label,
12.2.4. значений в ячейках таблиц/гридов,
12.2.5. значений списка,
12.2.6. в текстах хинтов,
12.2.7. в текстах статусных строк.
12.3. В сложных словах через дефис все части с большой буквы.
12.4. Шрифт по-умолчанию Tahoma 8 без стилей.
12.5. Имена продуктов с применением жирного и наклонного стилей.
12.6. Имена продуктов из нескольких слов не дробить по строкам текста.
12.7. На последней строке текста не должно быть только одного слова.
13. Размер дочернего окна. Диалоги и внутренние (дочерние) окна выравнивать по главному окну, оставляя возможность доступа основного (родительского) окна по клику мышки или горячими клавишами.
14. Сохранение, восстановление при закрытии, открытии. Пользовательские размер, позиция и статус окна должны сохраняться при закрытии окна и приложения, восстанавливаться при следующем открытии.
15. Элементы управления. Форма должна поддерживать полноценную работу мышки, клавиатуры и других, доступных в операционной системе, элементов управления курсором и объектами окна (touchpad, голосовое управление, горячие клавиши, перетаскивание и другие).
16. Горячие клавиши. Главным действиям желательно назначать горячие клавиши и показывать их значение в главном меню. Стандартные горячие клавиши должны работать в привычных для пользователя Windows элементах окна, желательно дублировать их значение в пунктах меню (контекстном, главном).
17. Версии БД и привилегии. Недоступные в рамках прав элементы окна должны быть серыми/выключенными/невидимыми, чтобы избежать появления ошибки “ORA-00942: table or view does not exist” особенно для пользователей базы данных Oracle без DBA прав.
18. Браузеры/вьювера. Выходные документы должны учитывать интерфейсно-функциональные особенности браузеров/вьюверов, перечисленных в системных требованиях продукта.
19. Межмодульная зависимость. Новые внедрённые возможности в одном модуле или продукте не должны исключать аналогичную работу в смежных модулях и продуктах. Продукты и подобные друг другу модули должны быть консистентны.
20. Лимиты лицензии. Ограничения триального и лицензионного ключей должны быть полностью поддерживаемыми и не ограничивать работу продукта неописанными в хелпе лимитами.
21. Инсталлятор/апдейтер. Инсталлятор должен устанавливать полноценную новую версию в соответствии с системными требованиями продукта. Апдейтер должен разворачивать обновление без ущерба для имевшегося функционала.
22. Опции, настройки. Новая опция должна иметь значение по-умолчанию, сохраняться и восстанавливаться при закрытии/открытии формы с настройками и приложения, по возможности иметь дубликат в функциональном модуле.
23. Демо-данные, примеры. Пример использования продукта соответствует версии продукта, системным требованиям, содержит достаточное количество данных для демонстрации использования новой фичи.
24. Функциональное соответствие требованиям задачи.
25. При необходимости нагрузочное, негативно-стрессовое, регрессионное, интеграционное и тестирование безопасности.
Примечание: продукты компании Conquest Software Solutions являются интерфейсами для работы разработчика базы данных Oracle и имеют единые модули.
Наличие чит-листа в команде разработки может служить профилактикой багов, так как программисты могут ориентироваться на контрольные точки тестировщиков при написании корректного кода. А новому члену группы тестирования по подробному чит-листу можно доверять не только перепроверку исправленных багов, но и принимать новые фичи.
Как уже отмечалось ранее, чит-лист формировался в течение многих лет и на основании запросов об уровне качества, в основном конечных пользователей. Некоторые пункты могут показаться весьма специфичными, но это не значит, что вашему приложению это никогда не понадобится. Некоторые пункты из этого списка перекочевали в чек-лист выпуска версии.
1. Размер формы/окна. У формы должен быть задан минимальный размер и размер по-умолчанию. Он не должен превышать 768 пикселей по-вертикали и 1024 по-горизонтали.
2. Элементы на форме. При первом открытии окна, при выставлении размеров по-умолчанию, при уменьшении до минимальных размеров окна все элементы должны быть видны в видимых границах окна, блока. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
3. Пустоты. На форме не должно быть неоднозначных пустот. Это ассоциируется у пользователя с невозможностью приложения отрисовать дополнительные элементы. Расстояния между элементами желательно выставлять одинаковые, но не настолько отстающими друг от друга, чтобы у пользователя возникало желание растянуть элементы на пустое пространство.
4. Выравнивание. Элементы на окне должны быть выровнены иерархично по-вертикали, по-горизонтали с соблюдением колонок. Стандартные расстояния 6-12-24 пикселей. Значения в редакторах центрированы по-вертикали, по-горизонтали: символьные прижаты к левому краю, числовые – к правому, в особых случаях центрированы, заголовки столбцов выровнены аналогично значениям, кроме центрированных заголовков групп.
5. Масштабирование. Элементы окна не должны обрезаться, наезжать друг на друга при 120DPI, 125% и иных параметрах монитора. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
6. Несколько мониторов. Окна и диалоги должны быть привязаны к главным (родительским) окнам, чтобы не было проблем показа зависимых (дочерних, модальных) окон на не активном мониторе. Основное окно приложения должно открываться на основном мониторе при первом запуске, на пользовательски-выбранном при последующих запусках, на доступном мониторе после отключения пользовательски-выбранного.
7. Операционная система. Используйте новые возможности компонентов при их расширении (animated progress bar, touch screen и другие), но не затирайте полезные старые свойства (например, полноценная работа клавиатурой, а не только мышью). Список поддерживаемых версий операционной системы должен соответствовать перечисленному в системных требованиях продукта.
8. Подписи элементов. У элемента в коде программы должно быть две подписи через слеш на английском и русском языках. В режиме своего языка (английского по-умолчанию) не должно быть видно текстов на втором языке.
9. Хинт. У сложно-названных элементов окна и у действий со сложным функционалом (таких как check-box, link и другие) должен быть хинт, текст которого не равен подписи элемента. Стандартные кнопки OK, Close, Cancel, Yes, No не должны иметь никаких хинтов, если клик по ним выполняет только одно стандартное действие.
10. Хелп. У каждой формы должен быть хелп, вызываемый по горячей клавише F1, с достаточным описанием функционала.
11. Значение подписей. Функционал должен однозначно соответствовать названию элемента.
12. Стили подписей.
12.1. Все слова с большой буквы, кроме союзов, предлогов менее трёх символов в названии
12.1.1. окна,
12.1.2. пункта меню,
12.1.3. кнопки,
12.1.4. закладки,
12.1.5. заголовка столбца,
12.1.6. группы,
12.1.7. ветки дерева.
12.2. Только первое слово с большой буквы, кроме названий продуктов или важных возможностей, в названии
12.2.1. check box,
12.2.2. radio button,
12.2.3. label,
12.2.4. значений в ячейках таблиц/гридов,
12.2.5. значений списка,
12.2.6. в текстах хинтов,
12.2.7. в текстах статусных строк.
12.3. В сложных словах через дефис все части с большой буквы.
12.4. Шрифт по-умолчанию Tahoma 8 без стилей.
12.5. Имена продуктов с применением жирного и наклонного стилей.
12.6. Имена продуктов из нескольких слов не дробить по строкам текста.
12.7. На последней строке текста не должно быть только одного слова.
13. Размер дочернего окна. Диалоги и внутренние (дочерние) окна выравнивать по главному окну, оставляя возможность доступа основного (родительского) окна по клику мышки или горячими клавишами.
14. Сохранение, восстановление при закрытии, открытии. Пользовательские размер, позиция и статус окна должны сохраняться при закрытии окна и приложения, восстанавливаться при следующем открытии.
15. Элементы управления. Форма должна поддерживать полноценную работу мышки, клавиатуры и других, доступных в операционной системе, элементов управления курсором и объектами окна (touchpad, голосовое управление, горячие клавиши, перетаскивание и другие).
16. Горячие клавиши. Главным действиям желательно назначать горячие клавиши и показывать их значение в главном меню. Стандартные горячие клавиши должны работать в привычных для пользователя Windows элементах окна, желательно дублировать их значение в пунктах меню (контекстном, главном).
17. Версии БД и привилегии. Недоступные в рамках прав элементы окна должны быть серыми/выключенными/невидимыми, чтобы избежать появления ошибки “ORA-00942: table or view does not exist” особенно для пользователей базы данных Oracle без DBA прав.
18. Браузеры/вьювера. Выходные документы должны учитывать интерфейсно-функциональные особенности браузеров/вьюверов, перечисленных в системных требованиях продукта.
19. Межмодульная зависимость. Новые внедрённые возможности в одном модуле или продукте не должны исключать аналогичную работу в смежных модулях и продуктах. Продукты и подобные друг другу модули должны быть консистентны.
20. Лимиты лицензии. Ограничения триального и лицензионного ключей должны быть полностью поддерживаемыми и не ограничивать работу продукта неописанными в хелпе лимитами.
21. Инсталлятор/апдейтер. Инсталлятор должен устанавливать полноценную новую версию в соответствии с системными требованиями продукта. Апдейтер должен разворачивать обновление без ущерба для имевшегося функционала.
22. Опции, настройки. Новая опция должна иметь значение по-умолчанию, сохраняться и восстанавливаться при закрытии/открытии формы с настройками и приложения, по возможности иметь дубликат в функциональном модуле.
23. Демо-данные, примеры. Пример использования продукта соответствует версии продукта, системным требованиям, содержит достаточное количество данных для демонстрации использования новой фичи.
24. Функциональное соответствие требованиям задачи.
25. При необходимости нагрузочное, негативно-стрессовое, регрессионное, интеграционное и тестирование безопасности.
Примечание: продукты компании Conquest Software Solutions являются интерфейсами для работы разработчика базы данных Oracle и имеют единые модули.
Комментариев нет:
Отправить комментарий