Cheat-sheet for desktop app

За пятнадцать лет работы с десктопными продуктами у меня сформировался определённый список обязательных действий при проверке новой фичи. Его необходимость назрела через год-полтора после начала карьеры тестировщика, а пополнялся он регулярно после выпуска очередной версии и получения отчётов об ошибках от пользователей. Недавно меня просветили, что такие списки называют "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.5-3 см от швов оснований прострочите глухой лицевой шов;
- на этом шаге можно подумать о дополнительном дизайне (нить люрекс, тесьма без пайеток или бусин, мягкая аппликация). Прострочите не менее 4 вертикальных полос (либо диагонально, либо ромбами, либо ромбами, либо пересекающимися синусоидами, либо иным способом) между глухими строчками оснований. Это поможет сохранять форму детали при выворачивании во время смены цвета;
 
- вставьте резинки в простроченные у оснований каналы и скрепите отверстия для их вставки. 

Места и формы применения:
- шляпа или юбка-пачка: совместить резинки, расправить края тора. Для юбки-пачки длиной 30 см при талии 60 см потребуется по 250см при ширине 60 см два полотна без учёта припусков на швы и две резинки длиной по обхвату головы/талии минус 10-20% для крепости. Расчёт произведён из формул L=2пR и l=2пr, где L - длина полотна, l~60см - обхват талии/головы, R-r=30см - длина юбки/полей шляпы, откуда получаем L = (R-r)*2п+l = 30*2*3.14+60 ~ 250см;
  

- шорты, юбка-баллон. Верхняя резинка одевается на талию, нижняя - на бёдра. Длина полотен равна обхвату бёдер плюс 30-40%, ширина полотен равна расстоянию от талии до бёдер/паха плюс 30-40%, длину резинок ориентировать на обхват талии для большей крепости;
 
- рукав, штанина, майка, сарафан или платье с декольте. Длина полотен рассчитывается из обхвата руки/ноги/бёдер/груди плюс 20-30%, длина резинок рассчитывается из обхвата руки/ноги/бёдер/груди минус 10-20%, ширина полотен равна длине изделия: длина руки от плеча до локтя или запястья, длина руки от локтя до запястья, расстояние от подмышек до талии/ног/коленей/икр/лодыжек;
 

- мини-платье, рукав с оборкой. Длина полотен рассчитывается как и в случае шляпы/юбки/пачки. Ширина полотен рассчитывается из суммы длины изделия от подмышек до талии/локтя/запястья плюс двойная длина юбки/оборки. Длина резинок равна обхвату талии/руки минус 10-20% для крепости.
 

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

    

Стестимся?

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

Предлагаю свой минимальный набор вопросов тестировщика потенциальному заказчику:
1. Какой результат Вы ожидаете от проделанной тестировщиком работы? Список проблемных мест и вероятные неприятности от их наличия? Или качественный продукт, удовлетворяющий потребителя и выданный ему точно в срок?
2. Какой тип продукта надо тестировать: desktop, web, mobile, иной гаджет?
3. На чьей стороне и чьём оборудовании должно проводиться тестирование?
4. Существует ли база тестовых данных, тестов, user-cases? Возможен ли доступ тестировщика к этой базе?
5. Возможно ли прямое общение с разработчиками, пользователями?
6. В каком виде предоставлять описания проблем? Имеется ли доступ к внутренней BugTrackingSystem?
7. Тесты какого характера необходимы Вашему продукту? (подробнее в "Смета качества")
8. Каковы критерии приёмки выполненных работ? По количеству отчётов или объёму положительно пройденных тестов, или наличию/отсутствию отзывов пользователей?
9. Каковы сроки исполнения работ по тестированию? Как часто предоставлять отчёт о проделанной работе?
10. Какая система (законность, надёжность) и объём оплаты за услугу?
11. Из каких источников Вы получили контактную информацию и почему решено было воспользоваться услугой тестирования?

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

Кривая LFT

Взлёт и крах секретников

Жила-была одна мелкая компания. За 15 лет вращения на рынке вывела на орбиту три с половиной десктопных продукта. И когда папаше-маркетологу стало нехватать дохода от одного из прикормышей, он собрал QA-щиков в тайную команду по отлову интерфейсных проблем. Назвал он это сообщество LFT - Look&Feel Team - и обязал докладывать ему о всех некрасивых местах. Вполне логичный шаг - лицо компании - это его продукция, а лицо продукта - его интерфейс, неудобство которого грозит уходом клиентов.
На первой сходке подпольщиков HighBoss рассказал о своей идее:
- Мы с вами нацелены на качество. Начнём с простого - встречают по одёжке. В процессе ваших регулярных тестов обращайте больше внимания на дизайн окон и их элементов. Собирайте свои вопросы, замечания в отчёт и рассылайте его всем членам LFT. Раз в неделю будем обсуждать, что нам с этим делать. Пока программистам ничего не надо сообщать. Но баги интерфейсные оформлять с высоким приоритетом, и кто из программистов откажется их править, будет возмущаться за пределами нашей команды.
При наличии якобы-демократии в компании приказы начальства не обсуждаются и потому закипела работа, массово потекли отчёты. За неделю HB был засыпан таким разнообразием взглядов на (не)удобство GUI, что просто не смог предложить какого бы-то ни было вменяемого решения. К тому же наше положение низших чинов - тестировщиков - выполнявших секретную функцию по отлову интерфейсных проблем и не смевших проговориться об этом вышестоящим проггерам, было тягостным. Нервы расшатывались. В команде росло напряжённое противостояние. Нельзя было раскрыть тайну шефа, но сотрудников по-приятельски тоже было жалко.
Естественно, не предупреждённые программисты стали возмущаться от обилия мелочёвки, их унижало откладывание интересных и серьёзных задач. Чтобы как-то предупредить о серьёзности террора НВ-а, пригрозившего несогласным увольнениями, мной была придумана и проведена подготовительная работа для профилактики багов в виде ежедневных подсказок, которые излагались на манер баек  и присказок. Конечно же, в первые пару дней на стендапах разработчики отвергали помощь от напоминаний (где это видано, чтоб qa-щики учили проггеров?), но быстро сами влились в игру и стали формулировать свои Tips, особенно по результатам code review.
Но злость программистов, очевидная и понятная, всё равно не утихала: один баг требовал раздвинуть элементы, другой тутже сдвинуть, одно предложение просило перекраски, другое - монохромности в подобных местах. Тестировщики беспристрастно требовали качества, а разработчики в недоумении грозились уходом. В попытке примирить команды у меня родилось предложение выписать все возможные варианты интерфейсных стандартов и выбрать наиболее приемлемые для приложений ConquestSS. На очередном собрании LFT пришли к неутешительным результатам - всё чужое нам не нравится или не подходит, ведь их оказалось много разных: Windows OS, Delphi, новомодные Google, iOS. Какими бы ни были удобными фенечки мобильников, от них пришлось отказаться в пользу правил поддерживаемой операционной системы (WinOS) и среды разработки (Delphi). К сожалению, дефолтные габариты элементов из среды разработки не очень нравились НВ, поэтому пришлось составлять собственные.  Уговорились на следующем: шеф программистов соберёт список всех используемых элементов, подберёт оптимальные размеры шрифта и интервалов. Параллельно с помощью TestComplete мне удалось составить автотесты для вычисления размеров и интервалов между элементами в одинаковых окнах для всех трёх приложений.

Пример старого и нового интерфейса

Первый вариант стандартов был оформлен в виде окна со множеством элементов и указаниями размеров по вертикали и горизонтали между ними, кратное шести пикселям. Презентация стандартов раскрыла существование тайной LFT. Программисты попытались простить тестировщикам месячный террор и дали обещание чётко следовать новому правилу.
В ходе составления списка элементов выяснилось, что не каждому стандартному элементу из набора Delphi можно выставить некоторые параметры. Пришлось доделывать такие элементы самим программистам. Таким образом, за полгода было доработано почти десяток элементов: добавлены возможности менять межстрочные интервалы списков, применять фонты и форматирование из пользовательского списка, обновлена цветовая раскладка градусника процесса для лучшей контрастности и современности, добавлена возможность встраивания подсказок и картинок. Целый пакет интерфейсных компонентов TCSS увеличил значимость программистов в команде и упростил проверку интерфейсов: изменения в стандартах компании применялись автоматически ко всем приложениям в ближайших билдах, тестировщики перепроверяли только окна со старыми компонентами. Необходимость в LFT отпала, а вместе с этим и ушло противостояние тестировщиков-программистов-НВ. Конфликты дилетантов и профессионалов сошли на нет из-за наличия стандартов, как единственной инстанцией истины. У разработчиков больше не было опасения быть уволенными из-за неподчинения руководству. Правило, составленное собственными силами, пришлось соблюдать каждому. Примечанием к нему стало постепенное обновление интерфейсных компонентов в окнах с текущими функциональными багами. Но пропуски такой степени карались в соответствии с внутренним распорядком команды, что больше не смущало разработчиков, а лишь служило стимулом повысить градус уважения у тестировщиков, проверки которых упрощались.