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 отпала, а вместе с этим и ушло противостояние тестировщиков-программистов-НВ. Конфликты дилетантов и профессионалов сошли на нет из-за наличия стандартов, как единственной инстанцией истины. У разработчиков больше не было опасения быть уволенными из-за неподчинения руководству. Правило, составленное собственными силами, пришлось соблюдать каждому. Примечанием к нему стало постепенное обновление интерфейсных компонентов в окнах с текущими функциональными багами. Но пропуски такой степени карались в соответствии с внутренним распорядком команды, что больше не смущало разработчиков, а лишь служило стимулом повысить градус уважения у тестировщиков, проверки которых упрощались.

SAQSII meeting

Мнемоника SAQSII предназначена участникам любых обсуждений для снижения временных затрат и превращения каждого собрания в эффективное.
Участники совещания делятся по ролям:
организатор (участник команды, у которого возникла проблема, обращается к руководителю проекта или скрам-мастеру с необходимостью провести обсуждение),
ведущий (руководитель проекта/продукта/feature-main-man или scrum-master, который назначает время собрания, зазывает необходимых участников и следит за соблюдением протокола встречи),
эксперты (члены команды или внешние консультанты, готовые помочь в разрешении поднятой проблемы),
дополнительно можно пригласить секретаря для ведения протокола и сбора итоговой инфы, либо поручить эту работу самому организатору. Не стоит выбирать Секретаря из списка Экспертов, так как он является заинтересованным лицом в продвижении собственного мнения.

Subject - тема собрания оглашается его Ведущим и дублируется в приглашениях (объявление в чате, назначенная встреча-задача в e-mail или календаре, иным способом).

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

Questions - третья часть собрания состоит из вопросов Экспертов к Организатору. Каждый вопрос должен иметь оглашённый ответ Организатора, даже если он "не знаю, не задумывался об этом". Эксперты не отвечают на вопросы экспертов, а копят свои ответы для следующего этапа.  Организатор не задаёт дополнительных вопросов экспертам. Тем самым у Экспертов и Организатора формируется собственные решения проблемы.

Suggestions - часть советов от Экспертов Организатору. Каждый Эксперт высказывает своё мнение о проблеме и её возможном решении, даже если это "поддерживаю идею [Name] выступавшего". Организатор может задавать свои дополнительные вопросы, накопившиеся в предыдущем шаге для уточнения собственных последующих действий, либо назначает дополнительную встречу для расширенного и углубленного обсуждения деталей предложенного решения.

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

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

Гендерность на страже качества

Девочку или Мальчика? 

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

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

ЗАДАЧА	КОМУ	ПОЧЕМУ
локализация бага, отсеивание незначимых причин	М	Женщины думают «не тем местом», что мужчины — в основном, лобными долями мозга. А они отвечают не столько за логику, сколько за интуицию и эмоции. Мужчины же, решая любую задачу, включают всю свою «мозговую» аналитику, да еще активно подсоединяют зоны, обрабатывающие зрительную информацию. У сильного пола в шесть раз больше серого вещества. Зато у слабого – в десять раз больше белого. Но именно серые нервные клетки отвечают за интеллект. А белые клетки – это отростки нейронов, которые лишь распределяют задачи между разными отделами мозга. У женщин крупнее гиппокамп – важнейший, «записывающий на корочку», элемент мозга. У Ж намного лучше память. У М лучше развито правое полушарие. При осмыслении слов мужчины пользуются преимущественно левым полушарием, а женщины — обоими.
проведение теста с одновременным привлечением зрения, слуха, речи и моторики, либо проведение параллельно двух-трёх тестов	Д
составление шагов теста	М
проверка шагов теста на полноценность охвата	Д
сбор статистики	М
анализ статистики	Д
однообразные тесты ежедневно	Д	Мужское сердце бьётся в среднем 70 раз в минуту, женское — 80 раз в минуту. Для Ж. время летит быстрее. Женщины в большей степени переоценивают длительность временных интервалов. М. выносливее при большой нагрузке. Ж. выносливее при малой нагрузке. Мужчин очень утомляет монотонная работа. Они от нее «звереют». Женщин монотонная работа успокаивает. Она для многих из них часто является отдыхом.
частая смена направленности тестов	М
ускорение и повышение нагрузки в короткое время	М
актуализация и повторная проверка багов	Д
тесты с чётким соблюдением времени	М
срочные смоук-тесты	Д
многообразие новых сложных тестов	М
в качестве перерыва -  выполнение мелких однообразных тестов	Д
многозадачность в исследовательском, комплексном, предвыпускном, интеграционном, параллельном и тому подобных тестах, либо совмещение должностей (QA+support+manager)	Д	У женщин мозолистое тело, которое служит своеобразным «кабелем» между правым и левым полушариями мозга, толще и соединений в нем на 30 % больше. Этому способствует женский гормон эстроген. Большое количество соединений объясняет способность женщины вести несколько не связанных друг с другом дел
составление и проведение опроса, сбор статистики для usability	Д	У мужчин сильнее развито левое полушарие, отвечающее за логическое мышление, у женщин — правое, отвечающее за эмоции и творчество. Женщины очень остро воспринимают настроение собеседника и могут перехватить его переживания. У женщин эмоции связаны с обширной областью обоих полушарий, и их функционирование может происходить одновременно с действием других функций. У мужчин область эмоций располагается только в правом полушарии, что означает возможность ее функционирования в отрыве от других функций мозга. Например, мужчина в споре может оперировать логикой и словами, задействовав левое полушарие, и не испытывать эмоций по существу вопроса.
актуализация, review задач через постановку уточняющих вопросов	М
однозначные положительные тесты	М
тесты, связанные с социализацией, эмоциональной восприимчивостью продукта, вариативностью пользователя	Д
функциональные тесты на полноценность управляющих устройств (клавиатура, джойстик и т.д.)	Д	Ж. более симметричны. Точность левой руки у женщин во всех возрастных периодах выше, чем у мужчин. То есть левая не так сильно отстает от правой. У мужчин асимметрия более выражена. Среди мужчин в 2 раза больше левшей и гораздо больше заик.
раскладка управляющих устройств для левши (мышь, меню и т.д.)	М
нагрузочные и стресс-тесты, растянутые на несколько дней	М	Во время сна электрическая активность мозга мужчин падает примерно на 70%, у женщин лишь на 10%. Восстановление мозга сном эффективнее у мужчин.
тесты гаджетов для детей и лиллипутов	Д	Среднестатистический мужчина на 10% выше среднестатистической женщины
нагрузочное тестирование голосовых записей	М	У мужчин тип дыхания брюшной, в отличии от грудного у женщин. На брюшном дыхании больше раскрывается диафрагма, а значит дольше длится фраза без забора воздуха.
тесты гаджетов, не проверенных на токсичность	Д	У Ж. сильнее иммунная система. У женщин гораздо реже заболевания приобретают хроническую форму. Некоторые исследования показывают, что Ж. более чувствительны к боли. Мужчины более стрессоустойчивые. Женщины более подвержены различным фобиям и депрессиям.
функциональное и дымовое тестирование симуляторов боли (физической, психологической)	Д
нагрузочное тестирование симуляторов боли(физической, психологической)	М
представитель тестировщиков на обсуждении разработок	М	У мужчин в левом полушарии есть центр, отвечающий за речь. У женщин за речь отвечают два центра: побольше – в левом полушарии, поменьше – в правом. Речь мужчин отличается обилием терминов и богатым запасом слов, в то время как женщины в речи опираются на интонации и эмоции. Ж. говорит с собеседником, М. чаще – с самим собой. Всем известно, что дамы могут часами разговаривать с собеседником, причем, обсуждают они одну тему. А вот мужчины могут вести разговор сразу на несколько тем и легко «перескакивать» с одной на другую, объединять совсем разные вопросы. Речевая грамматика у девочек лучше. По крайней мере до 11 лет. Женщине сложно удержать знания в тайне, т.е. легче ими делиться со всеми.
проверка грамотности в оформлении задач, документации, продукта	Д
предоставлять отчёты и доклады, обучать теории	Д
составление и написание документации, ясных и чётких описаний задач	М
проведение тестов с параллельным устным комментированием шагов и результатов	Д
прохождение теста по чек-листу, диаграмме переходов состояний, контрольным точкам	Д	М. видят дорогу, а Ж. указатель. Женщины лучше считывают эмоции, которые выражает лицо, но запоминать и узнавать лица у них получается хуже, чем у мужчин.
составление плана теста	М
прохождение теста по flowchart	М
подбор тестовых данных для фоторобота	М
подбор тестовых данных для видео-игр	Д
цветовое различие и сочетание	Д	На сетчатке человеческого глаза размещаются почти семь миллионов рецепторов-«колбочек», которые отвечают за восприятие цвета. За их действие отвечает Х-хромосома. У женщин их две, и палитра цветов, которую они воспринимают, шире.  Дальтонизм – в основном мужская особенность. В той или иной мере им страдают порядка 8% мужчин и всего лишь 1% женщин. У женщин развито периферийное зрение. У некоторых из них оно достигает 180 градусов. У мужчин зрение сфокусированное (туннельное), а у женщин – рассеянное. Поэтому мужчины лучше видят на большие расстояния, но их зрению не хватает широты охвата.
определение и сопоставление расстояний	М
окуляры для 3D с охватом 360 градусов	Д
составление плана проверки лабиринта, карты, навигатора	М
стратегическое тестирование	М
комплексное тестирование	Д
прослушивание входящих звонков	Д	Женщины лучше различают высокочастотные звуки. Женщины лучше мужчин распознают изменения тона и поэтому прекрасно замечают смену эмоций у собеседника. Мужчины «слышат» направление звука. Голос у мужчины ниже и грубее, чем у женщин (за это отвечает тестостерон). У женщины большая часть впечатлений связана с восприятием речи.
тесты гаджетов объёмного звука	М
запись высокочастотных звуков	Д
запись низких тонов звука	М
составление тестовых данных для аудио-проигрывателей	Д
клавиатура для слепых	Д	Кожа женщины в 10 раз чувствительнее, чем кожа мужчины. А если мужчина занят делом, то чувствительность кожи падает еще больше, и он почти не чувствует боли. Вкус у мужчин менее чувствительный, но в оттенках горького и соленого они разбираются лучше, в то время как женщины лучше улавливают тонкости сладких блюд. Температура мужского тела в среднем на 0,2 градуса выше, чем у женщин. Болевой уровень выше у мужчин, но тактильный у женщин.
автомат соки-воды для взрослых	М
автомат соки-воды для детей	Д
нагрузочные тесты спортивных тренажёров	М
usability игровых автоматов, гаджетов IoT и ЗОЖ	Д
тестирование IoT гаджетов, 5D кино и игр на соответствие запахов, звуков	Д	Ж. более остро чувствует даже самые «утонченные» ароматы, т.к. в носу у женщины расположено гораздо больше рецепторов. В ощущении запаха мужчины уступают женщинам. Слуховые и обонятельные анализаторы у мужчин развиты слабее.

Ещё немного подсказок:
- если какой-то навык у девочки-тестировщицы неполноценно развит, то похвалите её прилюдно за уже достигнутое, либо пригрозите аналогичным наказанием. Это станет стимулом её самостоятельной работы;
- поскольку для достижения цели мальчику нужно её чётко видеть, то для улучшения и расширения навыков мальчика-тестировщика достаточно ему пообещать некое вознаграждение (повышение по службе или оклада);
- тесты с обязательным пошаговым исполнением эффективнее выдавать мальчику, т.к. девочка большой объём работ перекомпанует по собственному усмотрению для снижения затрат, объединит аналогичные на её взгляд подзадачи;
- отчёт о проделанной работе с результатами анализа собирать у девочки после каждого шага, у мальчика по окончании всей задачи;
- регрессионные тесты на старые задачи поручайте девочкам, т.к. у них более длинная память и они могут выявить больше отклонений;
- для более продуктивного результата от мальчика чаще меняйте ему направленность задач, но не объединяйте однозначные тесты, ставьте чёткие цели;
- если на отдел тестирования пришла большая куча разнообразных задач, то их группировку эффективнее доверить девочке, которая привычна к наведению порядка;
- из-за высокой планки чувства ответственности девочек надо ограничивать в глубине и времени тестов, чтоб они не доводили проверки до абсурда. По этой же причине не стоит всю ответственность за качество сваливать на плечи тестировщиц, это может их глубоко ранить и они замкнуться или уйдут;
- "Женщины! Они изумительны! Они фантазируют - и чудом оказываются правыми. Конечно, это не совсем так. Женщины подсознательно замечают тысячи мелких деталей, бессознательно сопоставляют их - и называют это интуицией.", - А. Кристи "Убийство Роджера Экройда", глава 13 "Ствол гусиного пера";
- помните визуализацию полов: М – треугольник с вершиной внизу (со всей силой к цели = от основания к вершине), Ж – треугольник с основанием внизу (расширение воспринятого = от вершины к основанию).

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

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

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

Helping Help

Одним из пунктов при тестировании новшества является проверка Хелпа. А какие пункты можно и стоит включить в чек-лист, чтобы Хелп действительно помогал пользователю?
Под Хелпом ПО подразумеваются несколько его вариаций: ReadMe/FirstRead файл в составе инсталлятора, отдельная документация типа "Руководство пользователя", встроенная справка типа Online Help, Instant Help и Hint, краткий список изменений в конкретном билде/версии типа Release Notes. 
Первоочередная задача Хелпа - помощь в освоении и последующем использовании продукта. Инструкцию юзер должен логко воспринимать и желательно быстро пошагово применять. Говорят, что хорошо сделанное интерфейсное ПО интелектуально-доступное и не нуждается в хелпе. Но поскольку у каждого пользователя свой взгляд на всё, то Хелп нужен даже для самого понятного окна и его элементов. Поэтому предлагаю вам универсальный чек-лист для проверки Хелпа десктопного продукта в OS Windows. Он сформировался из многолетнего собственного опыта в качестве программиста, QA, сотрудника техподдержки и аналитика.

1. Наличие
1.1. Инсталлятор продукта имеет самостоятельный Хелп, не встроенный в инсталлируемый продукт, с подробными пунктами о системных требованиях для установки, шагами установки и утилизации продукта.
1.2. После установки продукта или его первого запуска доступен полный Хелп продукта.
1.3. Вызываемые из продукта внешние программы имеют самостоятельный Хелп от провайдера. Опционально.
1.4. Элементы окна с обязательным хинтом (кнопки, ссылки, иконки/картинки, обрезанные тексты) показывают его после наведения курсора.
1.5. Диалоговое окно с пояснительным текстом открывается по нажатию кнопки Instant Help.
2. Функционирование
2.1. Каждый интерфейсный элемент и функция программы имеет описание в Хелпе, который доступен по нажатию общепринятой горячей клавиши F1, если её замена не предусмотрена настройками продукта.
2.2. Место вызова внешней программы описано и связано с соответствующей статьёй Хелпа. Внешняя программа с собственным Хелпом открывает собственный Хелп, не путая его с основной программой.
2.3. Внутренние ссылки Хелпа открывают статьи в соответствии с наименованием.
2.4. В Хелпе возможен поиск по наименованию элемента окна и функциональности продукта.
2.5. Элементы окна с обязательным Хинтом показывают его спустя секунд после наведения курсора и оставляют видимым в течение секунд или до сдвига курсора.
2.6. Диалоговое окно с Instant Help открывается и закрывается по нажатию соответветствующих кнопок или горячих клавиш.
2.7. Для работы с Хелпом в режиме просмотра, если иное (правка статей, запуск иных продуктов из тела Хелпа) не предусмотрено основным продуктом, установлено достаточное количество вспомогательных продуктов, либо они входят в инсталлятор основного приложения.
2.8. Ожидаемое отображение картинок (масштабирование, размер, формат, скорость показа, внешний вьювер) и специальных символов (региональные настройки продукта и OS, компилированный/форматированный Хелп).
2.9. Стресс-тест: отсутствие переполнения буфера после вызова всех статей Хелпа несколько раз, перезапуск дополнительного окна/приложения/библиотеки для Хелпа в одном или нескольких сеансах основного приложения.
2.10. Ограниченность вызова справки в скрытом режиме работы основного приложения.
3. Полноценность и актуальность содержимого
3.1. Структура Хелпа соответствует требованиям ГОСТ 19 или ГОСТ 34 или IEEE Std 1063-2001.
3.2. Статьи внутри-продуктовых модулей в достаточной мере рассказывают о работе внешних дополнительно-исполняемых подпрограмм, используемых библиотек или ссылки на их документацию имеются и актуальны (соответствующая версия, локализация).
3.3. В Глоссарии перечислены термины, аббревиатуры, иконки приложения и Хелпа. Для каждого элемента имеется несколько статей Хелпа.
3.4. Подробно описаны функциональности продукта и элементы окна: расположение, путь доступа/активации, предназначение, варианты использования, возможные исключения, слинкованы с дополнительными статьями Хелпа.
3.5. Обновление содержимого статей и структуры Хелпа соответствует версии продукта.
3.6. В Хелпе имеется информация: описание продукта, способы установки и утилизации, системные и лицензионные требования, описания интерфейса и функциональностей, стандартные варианты использования и исключения, способы настройки, ссылки на дополнительную инфу.
4. Usability
4.1. Текст имеет ссылки на логически и функционально связанные статьи Хелпа, внешних профессионалов, community продукта.
4.2. Для каждой функциональности имеется пример с подробными шагами и скриншотами.
4.3. Интерфейсные окна и элементы описаны в статьях не только словами, но и картинками. Примечание: содержимое картинок достаточное, но не избыточное.
4.4. Проблемные ситуации описаны в особом блоке каждой статьи и в отдельном блоке всего Хелпа.
4.5. При воспроизведении проблемы в приложении имеется автозапуск Хелпа и локация на соответствующем совете о разрешении проблемы, либо перенаправление в техподдержку.
4.6. Сообщение об ошибке имеет достаточное пояснение по её недопущению в следующий раз.
4.7. Форматирование текста: видимые заголовки, подсвеченные основные термины, линки на связанные статьи из текущего текста, одинаковая структура статей (заголовок, введение, основная часть, примеры, исключения, дополнения), нумерация шагов, структурирование списков, место картинок (в тексте или выделенной панели).
4.8. Короткие предложения, абзацы, статьи. Примеры и дополнения в отдельных статьях. Сворачиваемость древовидных списков.
5. Грамотность и региональная локализация
5.1. Технические термины имеют словарь толкований для низкоподготовленного пользователя отдельно от Глоссария.
5.2. Технологически-грамотно описаны процессы и интерфейс.
5.3. Лингвистика соответствует региональной локализации: структура предложений, синтаксическая и пунктуационная грамотность, стандарты наименований. Корпоративные исключения описаны в отдельной статье Хелпа "Как использовать данный документ".
5.4. Стиль текста и форматирования соответствует технической сфере.
5.5. Отсутствуют недоправки дубляжа. Подробные описания элементов и терминов состоят не только из синонимов, но и подсказывают варианты использования этого компонента.
5.6. Каждая статья Хелпа отвечает на вопросы "Что это?", "Где найти?" или "Как запустить?", "Зачем это всё здесь?" или "Как с этим управляться?"

Для создания правильного Хелпа можете почитать:

• ГОСТ 19.402-78 ЕСПД. Описание программы
• ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению
• ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению
• ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению
• ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.
• ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
• ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем
• РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов
• IEEE Std 1063-2001 Standard for Software User Documentation
• http://www.it-gost.ru/content/view/94/51/
• http://tdocs.su/1391
• http://technicaldocs.ru/гост34/шаблоны/руководство_пользователя
• https://www.drexplain.ru/articles/razrabotka_rukovodstva_polzovatelya_po_gost_34_i_gost_19_v_programme_dr_explain/
• http://ddd.exmachina.ru/content/how_to_make_good_userguide/
• https://habr.com/post/153973/

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

Смета качества

С чего начать тестирование?
Тестирование – это процесс решения задачи, а как учили нас в школе – любую задачу надо и можно разложить на входящие условия и искомый результат. Прежде чем приступить к тестированию нового продукта, модуля или небольшого улучшения необходимо оговорить объёмы проверок с владельцем продукта. Для этого предлагаю составлять матрицу требуемого качества, заполнять её с двух сторон заинтересованности и считать её соглашением о выполняемых работах.
Согласительная матрица тестирования должна состоять из трёх колонок: объём работ, необходимость и возможность. В первую колонку "объём работ" заносим все виды тестирования: функциональное, интерфейсное, системное, защита данных и так далее, но желательна максимальная детализация для конкретного продукта или модуля. Вторую колонку "необходимость" заполняет владелец продукта значениями "надо", "можно", "лишнее". Значения третьей колонки "возможности" могут варьироваться уровнями "справимся собственными силами – можем подучиться или переквалифицироваться – надо привлекать сторонних специалистов" или ценами "время на выполнение работ - денежные суммы". Если же у тест-менеджера есть данные цен для каждого уровня (своими силами – подкачаться – внешние силы), то лучше сразу показать владельцу продукта затраты на каждый из трёх вариантов выполнения работ. Итого, матрица определяет входящие условия и ожидаемый результат не только для группы тестирования, но и для владельца продукта. Тест-менеджеру легко и просто составить план тестирования, распределить специалистов, выявить слабые места команды, подсчитать возможный доход. Владелец продукта такую матрицу может подписать как приложение к контракту с подробностями о выполняемых работах, увидеть расходы на тестирование, просчитать уровень качества выпускаемого продукта.

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

Виды тестирования	Необходимость	Возможность (часов/рублей)
		сами (500руб. за час)	с обучением (750руб. за час)	внеш.спец. (1000руб. за час)
1. Документация (наличие, функционирование, полноценность, грамотность)
1.1. Online Help	надо	1/500	1/750	0,5/500
1.2. Hints for UI elements	надо	0,5/250	0,5/375	0,25/250
1.3. Instant Help	лишнее	1/500	1/750	0,5/500
2. Интерфейс
2.1. Соответствие внутренним стандартам	можно	0,25/125	0,25/190	0,25/250
2.2. Соответствие описанию задачи	лишнее	0,25/125	0,25/190	0,25/250
3. Функциональность
3.1. Smoke-test for each build	лишнее	0,1/50	0,1/75	0,2/200
3.2. Smoke-test for publishing builds	можно	0,1/50	0,1/75	0,2/200
3.3. Приёмочное по описанию	надо	40/20000	40/30000	40/40000
3.4. Негативное	лишнее	2/1000	2/1500	4/4000
3.5. Исследовательское	можно	10/5000	10/7500	20/20000
4. Системное
4.1. Инсталляция, обновление	можно	0,1/50	0,1/75	0,1/100
4.2. Настройки модуля, продукта	можно	1/500	1/750	1/1000
4.3. Интеграционное	надо	4/2000	4/3000	6/6000
4.4. Защищённость, проникновение	можно	4/2000	4/3000	8/8000
4.5. Нагрузочное	можно	4/2000	4/3000	16/16000
4.6. Стресс-тесты, негативное	лишнее	4/2000	4/3000	8/8000
5. Код
5.1. Unit-testing	лишнее	0,25/125	0,25/190	0,1/100
5.2. Code Review by task description, internal structure and metrics standards	можно	0,25/125	0,25/190	0,1/100
6. Usability
6.1. Usability by internal standards	лишнее	4/2000	4/3000	8/8000
6.2. Usability from known vendors	лишнее	4/2000	4/3000	8/8000
7. Регрессионное	лишнее	2/1000	2/1500	2/2000

Таким образом, отдел тестирования отработает около 70 часов, работодатель не повысит квалификацию своих подопечных, но оплатит один рабочий день стороннего профессионала. Учтите, что за выявленные конечным пользователем проблемы ваш внутренний отдел качества не отвечает, и претензии можно будет предъявить только тому временному специалисту. При планировании сметы не стесняйтесь пояснить владельцу продукта последствия его отказа от тестирования того или иного вида, особенно негативного, которое не редко случается уже на стороне пользователя. Баги из числа "можно" при оформлении должны быть с более низким приоритетом.
Дополнительно оговорите список пунктов, проверяемых перед передачей продукта конечному пользователю (иными словами – чек-лист выпускаемого билда), с уточнёнными уровнями качества:
а) интерфейс;
б) сохранение/восстановление опций;
в) первоначальная инсталляция;
г) апдейт предыдущих версий/билдов;
д) благополучное исполнение основных пользовательских алгоритмов, шагов;
е) соответствие лицензионному соглашению и офертным системным требованиям;
ж) отсутствие фатальных и критичных багов;
з) и т.д.

Да, на заполнение такой матрицы требуется время, но ведь на планирование оно отводится. И именно его надо использовать на этом этапе, тем более что после оформления меморандума качества для каждого нового модуля тест-менеджер вместе с владельцем продукта сразу делают несколько дел: планируют объём работ тестировщиков и смету; имеют документ, защищающий права обоих и подтверждающий необходимость отдела тестирования; видят слабые места команды и направления её развития. Ещё раз повторюсь, не удаляйте пункты, которые владелец продукта посчитал лишними. Это позволит вам отказаться от сверх-задач, а сэкономленное время потратить на более глубокое тестирование (пункты "можно" заменить на "надо") или собственное развитие. Например, в компании Conquest Software Solutions существует только устный закон (читай "Меморандум качества") в разрезе продуктов:
- ClearDB обязан иметь идеальный интерфейс и генерить красивые выходные доки, а наличие AV-ошибок (критичные функциональные) не является блокером выпуска;
- в SQLDetective абсолютно не важны интерфейсные глюки, но не должны случаться критичные и фатальные ошибки в выпускаемом билде (иначе в недельный срок будет перевыпуск);
- ClearSQL можно выпускать как с интерфейсными проблемами, так и с функциональными, лишь бы показать видимость фикса бага от конечного пользователя.
Поэтому тестировщикам сложно доказать руководству, что обнаруженный на стороне пользователя баг не является пропуском в работе QA, а лишь следствие планирования.
Так что, друзья, если хотите стабильности и покоя, то составляйте меморандумы качества для каждого новшества, улучшения, изменения.

Лето, баги, огород

Тяжко работать в летние дни, особенно в жаркие. А природа пышет цветом, манит запахом и тенью. Лишь прохладой укрытый офис поддерживает энтузиазм.
И когда выходной отдаёшь на садовый труд, то яснее ощущается необходимость QA. Сорняки, как баги, лезут и лезут. И вручную их рвёшь, и тяпкой, и культиватором. Тестировщики-мануальщики тоже вручную выискивают баги: сначала самые крупные и критичные, как сорняки кустистые и колосящиеся. А нагнёшься к культурному растению и заметны мелкие росточки будущих приживал. Точно как в тестировании - выгребешь крупняк и фаталы, тут и становятся приметными мелкие недочёты, готовые вырасти в серьёзных обжор, забирающих полезные подкормки. А если на грядке работать инструментом, то не заметишь или не подступишься к корням благородной культуры, чтоб её не ранить. А там ведь гнездятся кучками самые вредные сорняки. Пусть ручники и медленные, но качества от них больше - не прорастут критикалы из мелочёвки пропущенной. Аналогична работа культиватора с автотестом: быстро удаляет крупняк, но при этом далеко от благородного кустика копает и не вся земля рыхлится у его корней.
Что есть "рефакторинг" в переложении на огородный манер? Конечно же пересадка. Выкопаешь в одном месте луковицы и корешки, почистишь их от сорной оплётки, просушишь и в новое место уложишь. Так и в коде порядок наводится: вскрывается юнит, удаляется лишнее, оптимизируется остаток и вставляется, компилируется по-новому.
Тест-менеджеры, если к вам пришёл юниор, бывший или заядлый огородник, то разница между фичей и багом эффективно поясняется на примере культурных растений и сорняков. Подобным образом и методы тестирования логично описываются на инструментах, а типы тестирования на внешних воздействиях: град и ливень - стресс-тест, насекомые и кроты - тесты на проникновение, птицы и дети - тупо-пользователи и негативные тесты.
Труд QA - интеллектуальный, поэтому физический перерыв и совершенствование навыков очень нужны. Всё это есть у вас на даче. Сорняки и баги ждут вашего нашествия.

Проект "ТАБУРНЕТ"

 Название состоит из слова "табурет" и фразы "табу нет".

Оснащение:
- сцена в форме табурета;
- размер табурета таков, чтобы на нём взрослый человек выглядел как ребёнок. Примерные высота – 100 см, длина*ширина – 80*80 см;
- дополнительно сзади приставляется лестница

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

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

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

Время использования:
- конкурс чтецов "Наше слово";
- фестиваль любительских театров "Чугиноколь";
- встречи театральных коллективов города для обмена опытом;
- квесты ДК о театре и закулисье;
- презентация спектакля, концерта, выставки;
- школьные перемены перед уроками естественных наук (литература, обществознание и другие).

Создание площадки, её сохранность возлагаются на владельцев помещения.

Правила использования площадки ТАБУРНЕТ (публикуются в месте размещения площадки):
- собрать публику может сам выступающий
- удерживать внимание публики обязан только сам выступающий;
- табурнет, как и сцена, не терпит грязи: запрещён вход на площадку в грязной обуви и одежде; запрещена ненормативная лексика во время выступления;
- время выступления ограничено вниманием публики;
- текст выступления должен быть подготовленным, исключать шпаргалки и подглядывания в записи;
- выступающий обязан отвечать на все задаваемые публикой вопросы;
- тематика выступления определяется выступающим и ограничена только законодательством России.

МОПС - сборщик мусора

МОПС = Метод Отложенного Поиска Смысла, Можно Обдумать После Спринта, Мобильная Организация Проверки Сомнений

Проанализировав свой стиль работы, могу предложить вам верные шаги для повышения эффективности тестировщика.
МОПС реализую через сбор скриншотов и последующее оформление багов и предложений.
Во время тестирования обязательно попадаются случайно-странные баги, на исследование, локализацию и оформление которых не планируется время во взятом в работу тесте. Поэтому с подозрительных мест моментально снимаю скриншоты с помощью виндовых ножниц или Picpick, помечаю маркером или просто пером спорные случаи и откладываю (сохраняю) картинку в особую папку. У каждого файла в имени: исследуемый продукт, билд и краткое имя основного бага. Папка со скриншотами имеет доступ из разных мест - комп с установленным продуктом, развёрнутая баг-трекинговая система, консультанту предоставляется быстрый линк на картинку. На протяжении теста приходит понимание о важности бага, локализуются тонкости или определяются предложения по модернизации. По окончании теста (после рабочего дня или спринта, поэтому имя файла конкретизируется билдом и кратким названием бага) выделяю время на актуализацию и оформление задач. После рассмотрения каждого скриншота его файл удаляется из папки временных багов, тем самым виден объём работ до окончания.

Рассмотрим применение метода. Возьмём тестовое задание - проверить корректность сохранения и восстановления настроек. Список тестов:

- присвоить всем опциям значения, сохранить установки, проверить значения опций после

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

Общее время теста равно количеству опций (по  одной из каждого класса эквивалентности) помноженному на 2-5 минут в зависимости от скорости памяти оперативной (иногда достаточен перезапуск формы) и постоянной (обязателен перезапуск приложения).

Проверка внешнего вида формы настроек (размер и  расположение элементов, грамотность подписей) в тест о сохранении/восстановлении не входит. Поэтому все отклонения выравниваний, размерности шрифтов, цветовые сочетания, опечатки складируются в папку временных багов МОПС. Для таких мелких ошибок обычно достаточно виндовых ножниц, либо настраиваем приложение для снятия скриншотов на активное окно. Первый сохраняемый файл называем "КороткоеИмяПродукта_НомерБилда_КраткоеИмяБага". Все последующие скриншоты, используя возможности приложения, будут автоматически сохраняться в папку МОПС и нам лишь остаётся подправлять окончание в имени файла или увеличивать последовательно номер. Но более полезно менять "КраткоеИмяБага", поскольку на оформление и локализацию задач из папки МОПС обычно время выделяется из числа неоплачиваемого.
Логичность зависимостей опций между собой (например, шрифт в приложении использовать стандартный или индивидуальный; если настраиваемый, то опции формата должны быть доступны для изменений, иначе - только на просмотр) тоже не входит в наш изначальный тест. А поскольку нашим тестом проверяются все опции, то вполне возможно, что какие-то опции могут быть сгруппированы и включаться по глобальной выборке. Эти предложения откладываются в папку МОПС, поскольку требуют вмешательства со стороны консультантов, да и время теста на обсуждение не планировалось. Скриншоты в таких случаях более полезны со всего экрана, то есть запущенный PicPick (или иное приложение) настраиваем на снятие скриншотов всего рабочего стола.
Сопутствующие баги настроек иногда выявляются путём проверок синхронизаций (опция выставляется в форме настроек, а меняться может в пользовательской форме с прямым назначением: параметры принтера удобно корректировать перед самой печатью). Если пользовательская форма не имеет синхронизации с формой настроек, то такие баги, конечно же, не относятся к нашему изначальному тесту, но вполне их можно обнаружить при проверке восстановлений опций. Поэтому такие (чаще спорные моменты, которые программисты называют фичами) сомнительные моменты временно оформляем в папку МОПС. Старайтесь снять скриншот так, чтобы в его область попало сразу всё - и окно настроек, и пользовательская форма, либо воспользуйтесь видео-рекодером.

Шаги МОПСа:
- Создать папку с общим доступом:
-- для консультантов, аналитиков, программистов права на чтение. Не давайте пополнять им эту папку, иначе утонете в завалах;
-- к папке есть доступ из компа с тестируемым продуктом для создания файлов-скриншотов. Поскольку для тестируемых приложений обычно разворачивается виртуальная машина, то следует заранее продумывать её структуру, в том числе и доступ ко всем необходимым папкам, документам и вспомогательным приложениям (для снятия скриншотов должна работать клавиша PrtSc или копирование в буфер, для записи видео нужна специальная программа);
-- к папке есть доступ из системы контроля версий для редактирования, загрузки в баг-трекинговую систему, удаления использованных скриншотов.
- Во время проведения основного теста снимать скриншоты и складывать их в папку временных багов. Файлам давать имена с указанием продукта, билда, основного подозрительного момента.
- Актуализация, локализация и оформление выявленных спорных моментов проводятся по окончании теста, в конце рабочего дня (лучше на следующий день с утра) или спринта. Чем раньше будет выполнена эта работа, тем легче будет проводить локализацию, так как билд может смениться или подробности забудутся. Желательно проводить этот шаг в рабочее время, поскольку иногда требуется консультация других сотрудников, поэтому более лучшее время - утро следующего дня (как в поговорке "утро вечера мудренее" - проверено, локализация проходит быстрее на свежую голову). Поскольку МОПС - это метод организации работы тестировщика, то желательно руководителям запланировать время на работы по очистке папок МОПС для каждого сотрудника, в том числе и консультантов.
- Каждый использованный скриншот удаляется после актуализации и оформления. Полезные скриншоты отправляются в БТС с соответствующей корректировкой (удаляются лишние поля, добавляются пометки). Постепенное очищение папки временных багов показывает скорость вашей работы и даёт надежду на скорое её окончание, то есть мотивирует вас на достижение цели - чистота в папке временных багов ведёт к чистоте всего продукта.

Собаки мопсы - коротконогие, а шаги МОПСа позволяет по скорому тестировать и экономить рабочее время за счёт сокращения отвлеканий от основной идеи. Скарлетт О'Хара твердила: "Об этом я подумаю завтра" и не забивала голову лишними проблемами. Откладывайте актуализацию на завтра, но помечайте каждый момент, тогда ваше внимание не будет распыляться на временные препятствия, да и "всякие мелочи" не ускользнут от профессионала.

GDPR - доверяй и проверяй

Возврат к бюрократии или Сотрудник на доверии
(рубрика - Нюх на баги)

Европейское сообщество решилось на усовершенствование охраны данных. Теперь тестировщикам и сотрудникам отделов тех-поддержки необходимо в срочном порядке совершенствовать свои знания в области юриспруденции.
Начать обучение следует с самого документа - "General Data Protection Regulation (GDPR)".
В большей мере вопрос касается персональных, конфиденциальных данных. А есть ли в них различие? Что об этом думают эксперты? Читайте "Experts on the GDPR #3: What is personal data under the GDPR?".
С технической точки зрения эксперты определили облачные сервисы для защиты данных - "Experts on the GDPR #4. Storing encrypted personal data in the cloud: What is the most secure option?", "EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений".
Какая же ответственность теперь будет у сотрудников техподдержки первого уровня и тестировщиков? Для техподдержки объектом пристального внимания становится информация о кастомерах, которую необходимо дифференцировать по территориальному признаку - индивидуальные данные от покупателей и поставщиков следует хранить и обновлять в рамках GDPR, компаньонов из других стран позволено обслуживать в прежнем режиме, только если они не связаны с европейцами. Было бы проще ко всем применить политику GDPR, но Вы уверены, что иные страны не имеют более жёстких условий? Поэтому техподдержка первого уровня - одно из самых важных звеньев в процессе фильтрации данных. Например, баг от пользователя должен храниться во внутренней системе компании разработки, а все контакты пользователя в независимой базе, вплоть до отдельного сервера. Получается, связующее звено "техподдержка" при этом несёт полную ответственность за линковку данных об исправляемом баге и пересылаемом отчёте пользователю. Тестировщику, оформляющему баг в базу при этом придётся унифицировать проблему, применяя переименование и аггрегацию для сокрытия данных от сторонних глаз. А Ваши базы контрагентов и задач готовы к такой конфиденциальности?
Создавая и тестируя базы данных в программном продукте, выпускаемом Вашей компанией, следует более тщательно контролировать простоту наименований таблиц и полей, связей реляционных баз и доступность их описания. В этом плане хороший пример в OEBS, где таблицы и поля имеют нелогичные наименования, в основном состоящие из цифр, что хорошо запутывает взломщиков. Также должны быть усилены тесты по способам и местам хранения данных - физические носители, облачные сервисы, удалённое управление с ограничением прав доступа и функций. При пересылке данных должны использоваться высоко-защищённые от несанкционированного доступа способы, а пересылаемые данные защифрованы в обязательном порядке. Также не менее важно проверять объём информации, присылаемой с отчётом о баге, чтобы в ней не хранилось что-либо, идентифицирующее пользователя продукта. Объём и содержимое пересылаемых данных необходимо проверять на актуальность, необходимость и достаточность, предотвращать скрытые пересылки (без ведома пользователя) паролей, IP-адресов, списков баз и прав доступа, прочих идентификаторов.
Список ответственных за сохранность данных не ограничивается техподдержкой. Компания, выпускающая десктопный продукт и продающая его через свой сайт, вполне может быть распределённой: например, зарегистрирована компания в США, разработчики и тестировщики фактически раскиданы по России и Украине, маркетологи разъезжают по всему миру, сервера с исходниками и данными пользователей могут быть распределены  по всему миру. Удобнее иметь сервера с исходным кодом и задачами поближе к группе разработки, а сервис продаж в Европе. Но при этом копия базы данных покупателей обязана быть у разработчика в оригинале, а не переименованная, поскольку могут быть проблемы, напрямую зависящие от комбинации исходных данных. Такие моменты прописаны в GDPR как доступ к данным по запросу "Art. 15 GDPR  Right of access by the data subject". О предварительных действиях компании разработки рассказано в "How to prepare for Data Access Requests under GDPR", "GDPR data access portal: Logging into the GDPR data access portal, Making a data access request, The data access request excel template, Making a data deletion request, Making a data change request, Making a consent change request".

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

Ударный Тест

Ударное слово при Тест-дизайне

(рубрики ТТ = Театр и Тестировании, Нюх на баги)

Театральному мастерству много веков, тестирование же намного моложе. Многие приёмы актёрской профессии вполне применимы и к тестированию.
Основные понятия драматургии удобно использовать при планировании работы тестировщика, о чём подробнее будет рассказано позже. Этот мастер-класс нацелен на один из первичных шагов - тест-дизайн. Порою довольно сложно приступить к созданию тестовых случаев, особенно если продукт новый для Вас. Для составления полноценного списка тест-кейсов воспользуемся упражнением по актёрскому мастерству, когда ударения на словах в предложении меняются для разнообразия смысла фразы.
В русском языке имеются такие знаки препинания как "запятая" и "точка", в большинстве случаев ударным считается последнее слово перед запятой или точкой с поднятием интонации перед запятой и опусканием перед точкой, но обычно им является глагол. Для английского языка характерны порядок слов в предложении и отсутствие запятых, более привычные в русском. Поэтому основным ударным словом в английской речи получается какое-нибудь причастие, деепричастие. Но при художественном чтении, а особенно поэзии, ударным словом может быть любое слово из предложения. Для развития навыка театральные курсанты обычную фразу произносят на разные лады, меняют ударное слово, повышая звучание или протяжность гласных.
Пример:
ОТ топота копыт пыль по полю летит
от ТОПОТА копыт пыль по полю летит
от топота КОПЫТ пыль по полю летит
от топота копыт ПЫЛЬ по полю летит
от топота копыт пыль ПО ПОЛЮ летит
от топота копыт пыль по полю ЛЕТИТ

Произнесите фразу 6 раз с различными ударениями на выделенные слова.

По аналогии с вышеописанным упражнением составим тест-кейсы, исходя из текста (короткого и подробного) техзадания. Как принято в большинстве компаний, короткое наименование задачи отвечает на вопросы "Что? Где? Когда?", это упрощает задачу составления тест-кейсов.
Пример техзадачи:
Краткое описание: "Окно Windows Notepad не закрывается с новым (только-что созданным) текстом"
Подробное описание: "По кнопке 'x' (крестик в правом верхнем углу) не пустое окно Windows 10 Notepad не закрывается после благополучного закрытия диалога о сохранении файла, если оно было открыто для создания нового текстового файла."
Из краткого описания выделяем 4 тестируемые сущности:
- окно Windows Notepad;
- не закрывается;
- с новым (только-что созданным);
- текстом.

Тест-кейсы первой группы будут нацелены на воспроизведение аналогичной проблемы в иных текстовых редакторах (MS Word, Aditor, Notepad++ и другие редакторы, доступные на тестовом стенде) или приложениях со сходными функциями (набор или вставка текста, изображения, звука, видео данных из буфера).
Вторую группу тестов описываем на действия с окном: закрытие, открытие, переоткрытие, дублирование экшена вручную и автоматически. Общее правило: если используется глагол, то выпишите его известные синонимы и антонимы, по которым сформируйте тест.
Третью группу тестов формируем для новосозданных и ранее имевшихся файлов. Здесь же стоит проверить способы создания: ручной или рукописный набор, вставка из буфера, drag&drop, виртуальная клавиатура, специальные возможности пользователей с ограниченными возможностями, сканирование и иные новомодные примочки. 
И в четвёртой группе тестов проверяем типы данных: текст и иные символы, пустота и пробелы, двоичный код (исполняемые файлы, аудио-видео, иной не текстовый формат).

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

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