Гипотезы

Прошедшая неделя заставила меня искать причины багов на порталах для ведения блогов.
Началось с того, что Blogger.COM перестал отображать некоторые картинки. Пройдясь по советам для решения аналогичных проблем, мне не помогло следующее:
- проверка на использование последней версии браузера;
- очистка памяти;
- кроссбраузерные тесты.
Эти все стандартные советы от техподдержки портала блоггеров были испробованы, о чём и было упомянуто в моей первой жалобе. Но золотые и платиновые советчики всё равно мурыжили меня первые дни всё теми же советами.
В первом же моём отчёте о проблеме был описан кейс со скриншотом, где конкретно описывалось место нестыковки back-end-а с front-end-ом. Но моя гипотеза о несоответствии лимитов на стороне пользователя и серверов была проигнорирована. Почему? Это прояснилось позже, когда техподдержка призналась в полном непонимании причин проблемы.
Суть проблемы в том, что картинки блоггер загружает через один интерфейс, который изначально благополучно фиксирует и отражает залитый на портал image, но в режиме просмотра картинка становится недоступной для некоторых пользователей и читателей блога. Из одного из разбирательств, а также проанализировав свои статьи с прикреплениями, выяснилось, что только с  1.bp.blogger.com  и  2.bp.blogger.com  доменов картинки не отображаются, а с  3.bp.blogger.com  и  4.bp.blogger.com  просмотр работает полноценно и в сжатом, и в галерейном режимах.
Поскольку мне известны принципы работы с partition, storage, rac, tns в Oracle DB, то одной из моих гипотез было то, что данные портал хранит разделяя на несколько серверов. И естесственным был вопрос к техподдержке для выяснения несоответствий лимитов при добавлении данных и при их считывании. По моей догадке владелец блога загружал картинки по одним условиям, не имея возможности выбрать сервер, а читатели блога получают данные только из лимитированных доменов. Поэтому мне, как пользователю, нужна настройка выбора места хранения images на момент их загрузки на портал. Но эта заявка, как и гипотеза, оказались излишними после того, как техподдержка разъяснила, что Blogger как бы хранит каждый мой аттач в четырёх экземплярах!
Такая структура данных мне очень импонирует, но всё же, как могло произойти такое, что в один (не-)прекрасный день часть картинок стала недоступна? Заливка всё также осталась автоматической с точки распределения доменов, но некоторым читателям после неизвестного апдейта портала был перекрыт доступ к  1.bp.blogger.com  и  2.bp.blogger.com  доменам. То есть мне, как владельцу блога, пришлось вручную в каждой статье для каждой картинки менять номера хранилищ с 1 и 2 на 3 или 4.
Здесь родилась вторая гипотеза о причине проблемы. Не могу похвастаться своими глубокими знаниями в серверных технологиях, но вполне понимаю, что ограничения на домен могут быть выставлены на обоих концах: как у моего провайдера, так и на исходном сервере. Далее мои рассуждения сводились только к стороне поставщика портала, потому что провайдер интернета обычно перекрывает домен верхнего уровня, а не третьего-четвёртого. К тому же сообщение в браузере о недоступности какого-то IP адреса по причине его внесения в чёрный список значительно отличается от предупреждения об отсутствии адреса.

Так сообщается о сайте из чёрного списка

Edge предлагает несколько workaround

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

К сожалению, мои гипотезы пока не подтвердились и не отверглись, поскольку техподдержка портала Blogger ещё не выяснила конкретные причины ограничения на просмотр картинок с   1.bp.blogger.com  и  2.bp.blogger.com  доменов.
А одним из моих обходных шагов было создание блога-спутника. На выбор альтернативного портала блоггеров ушёл день. В инете много советов по подбору места хранилища ваших мыслей:
12 лучших бесплатных блог-платформ
Какую платформу для блога выбрать
С чего начинается блог: 10 лучших бесплатных платформ
Выбираем платформу для ведения блога

Попытки создать новое пространство для моих записей с полноценным отображением картинок ни единожды заставило меня чертыхаться. Например, LiveJournal был отвергнут из-за малого пространства для прикреплений (до 500МБ), а Яндекс.Дзен и Инстаграм-подобные - из-за размера сообщений (для моих достоевско-толстовских широт никак не хватит нескольких строк). К сожалению, WordPress не оказался таким же простым и удобным, как Blogger.COM:
* наполнение контента страницы очень быстро начинает тормозить, то есть у портала есть серьёзные проблемы при обмене данными во время активности черновика, буквально после вставки 4-5 блоков. Blogger тормозить на черновике начинает намного позже, при объёме раз в 5-10 большем;
* нет возможности быстрого перехода от режима html-редактора к пред-просмотру, как это работает в Blogger. Точнее сказать, мне совсем не удалось найти в WordPress какой-то редактор текста html, чтоб не таскать "недвижимые" блоки и не удалять наугад пустые. Да, в Blogger в режиме просмотра тоже не видны границы пустых блоков и нет построителя таблиц, но их быстро можно переделать в html-режиме;
* те типы блоков, которые предлагаются для автоматической вставки, не могут удовлетворить все мои запросы: раскрасить часть текста, задать фонт отдельному слову и другие мелочи, либо интерфейс WordPress не столь интуитивен;
* дизайнерские штучки оказались совсем не юзабельными, поскольку обучающий режим не очищает за собой интерфейс и последняя плашка не пропадает даже после перезагрузки браузера;
* с большим трудом удалось вставить некоторые плагины для фильтрации, поиска и статистики;
* в WordPress при ведении блога обязательно наличие двух страниц (Home, Blog Feed), а в Blogger страницы можно вообще не показывать;
* Blogger нигде не ограничивает по объёму при бесплатности услуги, а WordPress даёт максимальное пространство (до 1ГБ) без оплаты среди альтернативных "дневников";
* из положительного: в WordPress есть структурированные рубрики и дополнительно метки, а в Blogger только метки.

На моё счастье техподдержка Blogger разродилась подсказкой для временного обхода проблемы (вручную поменять 1 и 2 на 3 или 4 в ссылках на картинки), поэтому дальнейшее сравнение функционала откладываю до следующей критичной проблемы на Blogger.COM.

Publishing cheat-sheet

Эта статья будет полезна тем, у кого разрабатывается десктопный продукт, распространяемый через инет-магазин.
Компания Conquest Software Solutions вышла на рынок с одним десктопным продуктом в 2002 году, с 2005 года стала продавать его через свой сайт, а с 2007 расширяла линейку продуктов. На сегодняшний день это 4 (SD, CS, CDB, FADEX) платных продукта, 1 (DV) бесплатный вспомогательный и 2 веб-продукта (site, WDV). Публикация некоторых из них всегда связана с дочерними, но в основном шаги к успешной публикации одинаковы. Несколько вариантов установки и обновления продукта упрощают работу конечному пользователю, но в теже несколько раз усложняют уровни проверок при публикации. Если в день получения бага от юзера тестировщик - это его адвокат, то в день выпуска QA становится на тёмную сторону и готов быть не только судьёй, но и прокурором для всех юзеро-хотелок.
До тех пор, пока публикацией заведовали только единственный тестировщик и единственный веб-разработчик, процесс протекал без сбоев. Но случалось так, что у кого-то был отпуск, а выложить билд надо было срочно. Тогда процесс не соблюдался в точности, потому что план действий лежал только в голове тестировщика, а веб-программист нажимал кнопки по его запросу. В итоге, конечный пользователь испытал проблемы со скачкой.
Шеф однажды спросил у меня, почему когда я выкладываю билды, то юзер никогда не жалуется. Мой ответ был прост: действия отработаны до автоматизма, и в день билда на листочке с Release Notes публикуемого продукта все пройденные этапы из моей головы перекочевывали на визуальный элемент. К сожалению, хоть и некоторые шаги были одинаковы для продуктов или типов (официальный, бета, специальный) билдов, но автоматизировать процесс даже частично было не на чем (фин.директор жадничал на тулзы, а бесплатных для самописных Delphi-элементов не было и нет). Тогда шеф решил частично помочь. Поскольку BTS у нас была самописная, то в Oracle базе он добавил таблицы, столбцы и триггеры на них, то есть автоматически формируемый список шагов для публикации.

Шаги делились на период ДО закрытия сайта для заливки и ПОСЛЕ операционные. Один триггер срабатывал для таблицы билдов и версий в момент добавления планируемого выпуска: в таблицу чек-листа добавлялся стандартный набор записей с указанием порядка действий для публикации определённой версии. В день публикации выпускающие тестировщик и программист проставляли дату-время каждой записи. Это значительно уменьшило количество проблем "заместителям публикаторов". А когда весь список очищался (таблица велась в "SD/Built-In VCS/SmartDataset" и активно использовались встроенные утилиты редактирования и фильтрации), то срабатывал следующий триггер, отправлявший e-mail нотификации руководству и иным заинтересованным лицам об успешном окончании работ с подробной инфой о выпущенном билде. 
На момент создания первого чек-листа выпуска он состоял из десятка пунктов, в основном касающихся сайта. Но со временем этот список стал пополняться и детализироваться проверками инсталлятора, апдейтера, лицензионных артефактов. Необходимость в расширении списка диктовалась процессом разработки, который касался различных сторон продуктов и сайта. Несколько систем апдейта (с сайта, из файловой системы, через инсталлятор или OSD Updater), заказанные пользователями, частая смена лицензирования, улучшения в системных требованиях увеличивали и количество пунктов чек-листа. Большей частью пункты дробились и конкретизировались.
С расширением штата и переходом на Jira+Confluence ведение чек-листа обзавелось документацией.

К сожалению, в Jira 2014 года не существовало аналога нашим чек-листам. Поэтому решено было оформлять задачи типа TASK (Feature, Improvement, Bug не очень подходили по стилистике, к тому же фича чек-боксов Jira Plug-in TODO была возможна только для одного типа задач) в каждом из выпускаемых продуктов.

Для удобства работы были одобрены следующие мои предложения по оформлению задачи:
- Product = [ProductName]. Для каждого продукта создавались свои задачи, в префиксе которых значились буквы короткого имени продукта, но они же дублировались и в Summary для упрощения фильтрации;
- Summary оформляется по формату "Publish [ShortProductName] [Major].[Minor].[Release]  [major|minor|release|spec-build|fix-build] [official|beta]". По короткому имени задачи было ясно, что конкретно будет публиковаться - бета или спец.билд, новая версия или текущие исправления. Например, "Publishing SD 4.7.2 release official" - публикация всем второго релиза платной версии 4.7 продукта SQLDetective, "Publishing SD 5.0.1b spec-build" - выкладывание специального билда бета-версии 5.0 продукта SQLDetective;
- Type = "TASK". К сожалению, только для одного типа задач админ Jira смог прикрутить поле TODO;
- Priority = "Major". Важность задачи велика, но не критична и не блокирует иную работу. К тому же есть дополнительное поле Business Value с самым высоким значением;
- Affected Versions = [LastPublishedBuild]. Последний опубликованный билд давал информацию всем заинтересованным сторонам: скрам-мастер подбирал задачи для бэклога и отчитывался перед вышестоящими, исходя из дат билдов опубликованного ранее и текущей; тех.писатель собирал выполненные задачи для Release Notes, отсекая временные; выпускающий тестировщик ориентировался с билдами и версиями для проверок апдейтера;
- Labels = "internal". Задача не должна входить ни в какие RN и для этого фильтруется лейблой;
- Status меняется по стандартному workflow: создаётся со значением Open; когда становится известна дата публикации, то меняется на Planned и заполняется поле Due Date (эти же данные используются для пина в Slack); процесс публикации сопровождается статусами In Progress + Testing; и финализируется Done|Close;
- Component = "Core". У каждого продукта обязательно существует модуль Core;
- Description = Summary + некоторые детали или примечания об особенностях публикации (кому спец.билд);
- Assignee = выпускающий тестировщик. Хоть в выпуске и участвует несколько членов команды, но большинство шагов исполняет именно тестировщик. На него же и запишется всё время работы - чаще это один рабочий день, если не случалось откатов билда и завершения работ в иной день;
- TODO = чек-лист шагов публикации, выстроенные в порядке исполнения и с префиксами для задействованных членов команды: PT=ProductTester, WT=WebTester, PD=ProductDeveloper, WD=WebDeveloper, TW=TechWriter, DO=DevOps, PM= ProductManager. Пример и подробности будут чуть ниже, а пока немного примечаний. В Confluence поначалу была оформлена таблица с полным списком, их пояснениями и отметками для типов публикаций (официальная, бета, спец.билд), а позже для ускорения работы были созданы конкретные списки по продуктам. Но в них отпала необходимость, когда была освоена фича Jira по клонированию задач. Сразу после окончания публикации (потом и в сам список этот шаг был записан) уже закрытую задачу клонировали и редактировали следующие поля: Affected Versions = только что опубликованный билд; обнулялись чекеры TODO и поля Issue Links, Fixed Versions, Due Date; в Summary и Description увеличивался номер версии. Время от времени список актуализировался, поскольку некоторые процессы удавалось нивелировать (форматирование текстов RNs, LicAgreement, ReadMe в разных форматах - txt, rtf, doc) или автоматизировать (генерация SampleDocu, очистка компа, проверка подписи файлов), или убедить РМ в избыточности и отказаться от объёмных проверок (нагрузочные тесты очень долго были в первых шагах), заменив на более нужные (результаты проверки сайта фиксировались прикреплением скриншотов) или новые (техпрогресс расширял области применимости продуктов, а значит и увеличивал количество багов). Необходимость детализации и разбиения на мелкие шажки усугублялась после очередных "пинков" следующему публикатору, которому приходилось ещё и ещё раз пояснять смысл и назначение чека. А точный порядок шагов сократил сообщения в чате, где передавалась очерёдность, с трёхстрочных до одной фразы "твой ход". А он уже открывал задачу с чек-листом и видел не проставленные чеки, точно зная, что от него ждут. Единственная проблема - после проставления каждого чека необходимо было выполнять сохранение в базу Jira, а иначе очерёдник либо не увидит ваших чекеров, либо ставя свои затрёт ваши;
- Issue Links = список задач, прилинкованных по типу "blocks the TASK", без закрытия которых нельзя начинать публикацию. В простонародье эта часть звалась "КакогоБагаБилд". Поскольку РМ в Jira Structure планировал и отслеживал только Features+Improvements, то включаемые в билд баги решено было мной линковать к этой задаче. И поскольку возможности Jira ограничивались показом только первых пяти прилинкованных, то во время работы (за несколько дней до публикации тестировались именно эти блокеры чек-листа публикации) неудобство просмотра объёма незавершённых работ исправлялось обычной отлинковкой. Принцип сокращения списка был взят мной из самописной BTS, где у меня была отфильтрована база по запланированным на тестирование задачам и без даты окончания теста. Привычка - вторая натура, поэтому и блокеры выкидывались за ненадобностью. Но со временем команда стала извлекать из такой линковки свою выгоду: РМ стал отчитываться руководству по списку блокеров, техписатель фильтровала исправленные баги для написания RNs, программисты опирались на список блокеров только для оправдания занятости хот-багами вместо текущих разработок, группа веба опиралась только на этот список из-за невозможности включить их задачи в автобилдер. Единственная задача, которую никогда не выкидывали из списка блокеров, была с полным отредактированным текстом RNs, поскольку именно их впиливали в билд в последнюю очередь и пересобирали продукт. Видели бы вы глаза представительницы Atlassian на конференции SQADays-21, когда ей были описаны эти "танцы с бубнами" вместо полноценного использования Jira Structure. Но РМ ни за какие коврижки не соглашался вести бэклоги фикс-билдов с одними только багами в "его" Jira Structure, даже после моего рассказа о том, что бэклоги можно делать составными и отчитываться более точно руководству о затраченных усилиях. Из-за его упрямства команда только ещё больше отстраняла тестировщиков от программистов: спрос за импрувы (велись в Jira Structure) был с программистов, спрос за баги (велись блокерами чек-листа) был с тестировщиков. То есть в команде всегда было два разных бэклога, а не единый. Единственным аргументом было то, что баги никогда не проходили стадии эстимации, поскольку проггеры о багах отзывались: "Баг от импрува отличается тем, что его быстрее исправить, чем понять по тексту сколько это займёт времени", и никогда не планировали их или декомпозировали;
- Fixed Versions = публикуемый билд (четырёхзначная версия) выбирается во время закрывания задачи, а на момент оформления ставилась трёхзначная версия без указания билда. Она использовалась для планирования и иной фильтрации.

Примерный список чекеров (поле TODO)	Пояснения (статья в Confluence)
PT_All planned bugs fixed?	Проверить список багов - блокеров публикации, запланированных на фиксирование, и разработок из Structure
PT_Smoke tested?	После инсталляции проверить основной функционал на триальном и лицензионном ключе.
PT_Internal files in the setup program are correct and they are enough for first start or update, upgrade?	Проверить корректность и достаточность служебных файлов для инсталляции и апдейта
PT_The setup program tested against all supporting OS?	Проверить инсталляцию и открытие приложения на всех ОС из списка System Requirements
PT_Stress test passed?	Шеф не различал нагрузочные и стресс-тесты, а также слышать не хотел, что для тестирования больших данных нужно много времени. На выпуск давался только один день, и он наивно полагал, что мы проверяли обработку монстров на выпускаемом билде. Очевидно, что подобному пункту не место в чеклисте. Но если у вас есть автоматизтрованные регресс-тесты, которые выполняются за минимальное время, то слово stress меняйте на regress и смело оставляйте.
PT_DemoProject or SampleDocus included into installer and updater?	Примеры использования продукта включены в инсталятор, апдейтер. Версия примеров актуальная. Проверку этого пункта вполне можно совместить с иными (smoke, инсталлятор с ключом, апдейтер и апгрейд)
PT_Copyright date correct in the program, readme file?	Имя компании и год лицензирования проверить в файлах и интерфейсе продукта (About, Welcome Window, Preferences, ReadMe, …)
PT_The setup program correctly shows the program name, default installation path, etc.? The setup program shows "beta" in the program name and installs to the beta folder?	Проверить инсталлятор на корректность имени проги, установочного каталога, иконок., префиксы beta и др. Проверить инсталляцию на чистую машину(предварительно почистить реестр и папки ОС), на имеющуюся старую версию.
PT_License agreement file in the setup program is for an official/beta version? It's the latest version.	Проверить текст лицензионного соглашения на отсутствие/наличие Beta примечаний
PT_Release notes shown in the application on first start up?	"What’s New?" показывается при первом запуске нового приложения
PT_Readme file in the setup is for an official/beta version?	Проверить файл ReadMe на отсутствие/наличие Beta примечаний
PT_The trial key file in the setup program is for an official/beta version?	Проверить наличие и длительность триального ключа в файле инсталлятора и апдейтах
PT_Check license limits: trial, after trial, lic numbers.	Проверить триальный ключ на ограничения в период действия и вне его пределов, лицензионный ключ на количество юзеров при совместной работе.
PT_All executible files, including updater and installer e-signed?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении имеют электронную подпись
PT_All files checked by several antiviruses?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении не имеют препятствий антивирусами
WD_Close site. Make back-up.	Закрыть сайт для доступа обычным юзерам и сохранить копии заливаемых страниц и прочих файлов. Начало заливки считалось по американскому времени (для Москвы это 16-00). Все предыдущие пункты выполнялись с 10-00 утра (автосборка утреннего билда) до 15-00 или 16-00 часов дня, при сбоях билд пересобирался или сообщалось шефу о стоп-билде.
WD_All pages and child sites are updated? The product teaser on the website shows correct product version?	Каждый продукт имеет свою первоначальную страницу и коротко-названные сайты, которые надо обновлять самостоятельно. Некоторые продуктовые рекламные заставки могут размещаться на общих сайтовых страницах, но должны быть актуальны
WD_The setup file uploaded to the website?	Инсталлятор залит на сайт. Проверить скачивание через страницы Free Download, Upgrade/Update или Buy Online. Веб-разработчик обычно единым шагом заливал инсталляторы и апдейтеры во все места, менял номер версии и оформлял RNs. Так что разбивка сайтовских пунктов больше касалась веб-тестировщика.
WD_The OSD updates uploaded to the website? The OSD updates uploaded to the website to both folders (non-beta and beta if it's official publishing)?	Апдейты загружены на сайт. Проверить OSD Updater на скачивание Core и Kits, апдейт с беты на официальную
WT_Website pages and news ready? All modified webpages copied from the test website to the live website?	Веб-разработчик заливает обновления страниц сайта, а веб-тестировщик проверяет готовность сайта
WT_Copyright date correct in website?	Имя компании и год лицензирования проверить на сайте, прикрепить скриншоты
WT_Release notes availabe on the website?	Зайти на сайт и найти соответствующие выпускаемому билду Release Notes, сделать скриншот и прикрепить его к таске публикации.
WT_License is the same in website (updater from site) and application (installer, updater from file system, About).	Тексты лицензионного соглашения идентичны на сайте, в инсталляторе, апдейтере, продукте.
WT_The setup program available to download, correct and can be installed? Renaming folders enabled?	Скачать с сайта инсталляционный файл и установить на чистую машину, на старую версию в триале и лицензионно, проверить смену имён папок
WT_KeyGen works for current version? New key delivired? KeyDeliveryProcs includes data from the previous version?	Генератор ключа на сайте формирует файл для текущей версии и отправляет линки или сам файл всеми задуманными способами, смена версии продукта или генератора ключа не препятствует процессу обновления
PT_Release notes availabe in OSD Updater?	Запустить OSD Updater и проверить наличие Release Notes текущей и промежуточных версий.
PT_BETA release notes not visible in OSD Updater?	OSD Updater не должен показывать Release Notes для Beta версии, если выпуск официальной. В бета-версии должны быть видны RNs официальной и беты.
PT_OSD Updater updates the previous official/beta version to the new version? The product version on the website displayed correctly?	Проверить возможность апгрейда со старой версии триально и лицензионно, из файловой системы и с сайта. В личном кабинете юзера на сайте и в общедоступных местах скачивания актуализирована версия продукта
WD_Open site.	Обычно заливка и проверка обновлений через сайт занимала около часа времени, поэтому в 17-00 (окончание рабочего дня в Москве и 9 утра в Америке) можно было открывать сайт и рапортовать руководству об успешной публикации
DO_VCS branched, Slack pins updated, Jira builds updated, Installers renamed?	По окончании работы с опубликованным билдом начинается работа со следующим: разветвляется СКВ кода, в чате и на доске версий БТС убираются выполненные задачи и оформляются новые, в файловой системе перименовываются инсталляторы (добавляется постфикс "_р" - public)
TW_Wiki topics updated?	Одно время тех.писатель вела топики в Wiki и актуализировала инфу о доступных версиях, фичах. Но редакторы Wiki запретили эти статьи, т.к. они стали более рекламными, нежели информационными.

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

Пока RNs собирались вручную и хелп-примеры готовил первый член команды, публикация была неожиданностью для всех:

или

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

или

Со временем шефу скучно стало ждать выпуска и моё предложение использовать канал билдов для связи в день публикации было поддержано:

И процесс потёк, как по маслу:

Новичков вливали постепенно:

или

Позже шеф просто умилялся:

Бывало, конечно, что новички, стесняясь общего канала, молча проставляли чеки. Тогда РМ дёргал весь отдел качества фразой: "Что там с выпуском? Почему тишина?" и приходилось его "посылать" в Jira, дабы не отвлекать народ от важных дел.
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!

И укладывались в ровно отведённый час. Перевыпуски, конечно, случались, но никак не по причине пропуска какого-то пункта публикации.

Cheat-sheet доступности

На днях предложили протестировать рекламу, а перед этим довелось посмотреть доклад на SQADays-24 "Manual and Automated Accessibility Implementation". Индиец, конечно, в своём духе перескакивал с темы на тему, но из множества его мыслей скомпоновался нижеследующий cheat-sheet для тестирования доступности. Начинать, изучать и закреплять тестирование доступности лучше всего на рекламных проспектах и роликах. Мы все её потребители, а вдобавок ещё и имеем профессиональный взгляд тестировщика.  Цель любой рекламы - доступно донести до потенциального потребителя продукта много важной информации, то есть тест на доступность - первоочередной для рекламы. Доступная реклама = польза информации производителю и потребителю.
Доступность программного обеспечения тестируют для того, чтобы:
- любой пользователь смог полноценно работать в вашем десктопной программе, на вашем сайте, в ваших web- и мобильном приложениях;
- к вашему продукту не было судебных исков из-за несоблюдения законодательств;
- расширялся круг пользователей за счёт людей с ограниченными физическими возможностями;
- пользователи, привыкшие к определённым действиям, не отвергали ваш продукт по причине несоответствия общепринятым стандартам, их привычкам и приоритетам;
- в гонке за хайпом и новомодным интерфейсом не затерялся основной функционал, предназначение продукта;
- вовремя проводить профилактику багов, предотвращая невозможность ввода и просмотра данных, как обычными пользователями, так и людьми с физическими ограничениями.
Большинство пунктов cheat-sheet accessibility основано на WSAG принципах:
 
Да, тест доступности - часть юзабилити и интерфейсного тестов, местами похож на негативный, но, если заглянуть в руководство WCAG и проанализировать статистику экранов пользователей, он превращается во вполне положительный.
В своём списке мне хотелось бы ограничиться такими пунктами, которые были бы адекватны для всех типов приложений и не претендовали на стандарты для особых пользователей. Это скорее смоук-тест доступности, а не обязательные проверки для получения сертификата. К слову сказать, с 2002 года мной был собран список того, что подлежит обязательной проверке перед передачей продукта на тестирование. В нём были многие пункты из ниже перечисленных, а каждый добавлялся после случая на стороне конечного пользователя. Так что, это не утопия, а реальные вещи, которые надо проверять в рамках позитивных тестов, несмотря на то, что эти параметры не включены в системные требования конкретно вашего продукта. Если начальство начнёт сопротивляться: "Негативные тесты - это излишество. Стартапу не по-карману!", то вашим аргументом будет фраза: "Наш продукт, по Вашему требованию, соответствует общепринятым мировым стандартам после прохождения теста доступности."

По cheat-sheet accessibility можно идти турами, поскольку группировка отлична от WCAG принципов. В пояснениях даны примерные места проверок, куда заглянуть во время очередного "путешествия". А также перечислены пункты и уровни из положения о доступности. По-моему, некоторым пунктам в положении явно завысили уровень, так как поведение программы в этих случаях более чем очевидное и ожидаемое.
1. ТЕКСТ
1.1. размер шрифта и межстрочный интервал (слипшийся мелкий текст во всю ширину экрана 9х16 вряд ли кто-то дочитает до конца, огромные заголовки принижают значимость основного текста или вынуждают много прокручивать экран, все символы и интервалы зуммируются пропорционально) - п.1.4.4(АА), 2.4.10(ААА), 1.4.12(АА);
1.2. цвет основного текста и подложки, контрастность (рекламные объявления для консистентности с логотипом могут быть в старославянском коричневом шрифте на "а-ля папирусе" бежевого цвета, либо детский сайт использует розовенькие буковки на жёлтенком коврике)- п.1.4.3(АА), 1.4.5(АА), 1.4.6(ААА), 1.4.8(ААА);
1.3. перевод на региональный язык (полное переключение и дублирование в титрах, быстрое и точное осознание содержимого может быть только на родном языке) - п.1.3, 1.3.1(А), 1.3.2(А), 1.4, 3, 3.1.1(А), 3.1.2(АА);
1.4. восприятие смысла (краткость и однозначность терминов всегда способствовали взаимопониманию, расшифровки аббревиатур, глоссарий, контекстная помощь) - п.1, 1.3.1(А), 3, 3.1, 3.1.3(ААА), 3.1.4(ААА), 3.1.6(ААА), 3.3, 3.3.5(ААА), 4.1.2(А);
1.5. восприятие синтаксиса, лингвистики (в инструкциях пользователя строго не рекомендуется использовать сложно-подчинённые предложения, язык Достоевского уместен только в классической литературе) - п.1, 3, 3.1, 3.1.5(ААА), 3.1.6(ААА), 4.1.2(А);
1.6. пропорциональное масштабирование надписей (изменение DPI, разрешения экрана, использование зуммирования не должны существенно искажать пропорции интерфейсных элементов и их подписей) - п.1.4.4(АА);
1.7. наличие видимых подписей всех элементов интерфейса (новомодная фича сайтов - перекинуть название окон ввода данных в сами редакторы до момента начала набора символов, оставляя пользователя только догадываться о полноценности вводимых данных) - п.1.4.5(АА), 1.4.9(ААА), 3.2.2(А), 3.2.4(АА), 3.3, 3.3.2(А), 4.1.2(А), 2.5.3(А);
1.8. изменение пользователем цвета текста и фона, размера шрифта пропорционально зуму - п.1.4.8(ААА).
2. КУРСОР, КООРДИНАТЫ, МАСШТАБИРОВАНИЕ
2.1. расположение элементов сверху-вниз, слева-направо или регионально справа-налево, снизу-вверх, ландшафтно или портретно, совпадение точек верх-низ экрана с положением монитора - п.1.3.2(А), 1.4, 2.4.3(А), 3.2, 3.2.3(АА);
2.2. пометка обязательных к заполнению полей, подсказка формата поля (шаблон даты, звёздочки замены, разделитель e-mail) - п.3.2.2(А), 3.3, 3.3.2(А), 1.3.4(АА), 1.3.5(АА), 2.5.6(ААА);
2.3. вместимость всех важных, сгруппированных элементов в единый кадр, прокрутку - п.1.3.2(А), 1.4, 1.4.8(ААА), 2.4, 3.2.4(АА), 3.3;
2.4. удержание подсказки курсором (окно хинта не исчезает пока в его области активен курсор) - п.2.1.3(ААА);
2.5. управление курсором - клавиатура реальная и остальные инструменты (вспомогательная клавиатура, мышь, сенсорная панель или сам экран, джойстик, видеорегистратор, шлем телепатии) взаимозаменяемы - п.2, 2.1, 2.1.1(А), 2.1.2(А), 2.1.3(ААА), 2.4, 2.4.3(А), 2.5.1(А), 2.5.4(А), 2.5.6(ААА);
2.6. подсветка текущего курсора не пересекается с иными пометками и выборками (визуализация фильтрации и изменения данных, навигация в деревьях и схлопывающихся окошках опций, действия между нажатым и отжатым курсором обратимы) - п.2.4.7(АА), 2.4.8(ААА), 3.2.1(А), 3.2.2(А), 1.4.13(АА), 2.5.2(А), 2.5.6(ААА);
2.7. встроенные лупа, зуммер или глобальная смена DPI масштабирует весь контент пропорционально (жёстко-заданный, а не пропорциональный, размер шрифта может не среагировать на изменения пользователя) - п.1.4.4(АА), 1.4.8(ААА);
2.8. прокрутка вертикальная, горизонтальная, диагональная (мышью, клавиатурой, сенсорным устройством, джойстиком) - п.1.4.10(АА);
2.9. минимальные размеры окон и размещаемых на них элементов (полноценная видимость при DPI-100%, наличие скроллеров при увеличении DPI до 200% и разрешении 600*800 пикселей) - п.2.5.5(ААА).
3. ИЗОБРАЖЕНИЕ
3.1. ассоциативность ряда картинок и всего остального содержимого страницы (кнопка выхода с картинкой двери или крестика - логично, перемешанный порядок изображений путает восприятие) - п.1.3.2(А), 1.4, 3, 3.2;
3.2. наличие подписей, хинтов у кнопок с картинками (мелкие детали требуют пояснений, нестандартные и непривычные изображения слабо ассоциируются с предлагаемыми действиями, программы-ассистенты распознают элемент экрана по имени, браузер с выключенным показом картинок) - п.1.1.1(А), 1.3.1(А), 1.4.9(ААА), 3, 3.2.4(АА), 3.3, 3.3.2(А), 3.3.5(ААА), 1.3.6(ААА), 2.3.3(ААА);
3.3. пикселизация, размытость, нечёткость ухудшают понимание - п.1.4.3(АА), 1.4.5(АА), 1.4.6(ААА), 1.4.11(АА).
4. ЦВЕТ
4.1. привычные многим: красный цвет - ошибок, жёлтый - предупреждений, зелёный - разрешение продолжать, синий - рабочая норма (частичная подсветка объектов для ассоциативного привлечения внимания) - п.1.4.1(А), 3, 3.2;
4.2. недопустимость цвета без подписи (дальтонизмом страдают 20% мужчин) - п.1.3.3(А), 1.4.1 (А), 3;
4.3. контрастность (тема ОС или монохромный монитор не ухудшают функционал продукта) - п.1.4.3(АА), 1.4.11(АА).
5. ТАЙМЕР
5.1. системная обработка удержания клавиш (длительное нажатие считается повторным в играх на строго определённых этапах) - п.2.1.3(ААА), 3.2;
5.2. подсказка, хинт элемента не исчезает пока на ней курсор - п.2.1.3(ААА), 2.2.3(ААА), 2.2.4(ААА), 3.3, 2.2.6(ААА);
5.3. для прочтения или просмотра анимации отведено достаточно времени (текст может быть иностранным или объёмным, процентная шкала ведёт обратный отсчёт) - п.2.2, 2.2.3(ААА), 2.2.4(ААА), 3.3;
5.4. секундомер работы с базой (транзакции в БД обязательно настраиваются админом) - п.2.2.4(ААА), 2.2.5(ААА), 3.3, 2.2.6(ААА).
6. ЗВУК
6.1. подпись объекта (воспроизведения аудио-ролика может начинаться по клику на всю картинку плейера или только на одну маленькую кнопку-иконку - неожиданное поведение) - п.1.3.3(А), 2.4.4(А), 2.4.9(ААА), 3, 3.2, 3.2.4(АА), 1.3.6(ААА);
6.2. краткое описание или содержание аудио-ролика (прослушивание всего ролика отнимает время, упоминание в тексте основных моментов привлекает внимание) - п.1.2.1(А), 1.2.3(А), 1.3.1(А), 3;
6.3. пауза, возврат, перемотка, повтор, длительность ролика, громкость звука (управление всеми параметрами повышает степень восприятия содержимого) - п.1.4.2(А), 2.2.1(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.6(ААА);
6.4. плейер (имеется встроенный, указан формат файла для выбора альтернативного плейера) - п.1.2.3(А), 2.4.4(А);
6.5. аудио-фон отсутствует или выключается (часто аудио-фон применяют в играх или на страницах сайтов с множеством объявлений - это мешает или раздражает) - п.1.4.7(ААА);
6.6. нет заглушки системных звуков (залипание или долгое удержание клавиш, окна с сообщениями системы сопровождаются аналогичными звуковыми эффектами или перенастраиваются на пользовательские) - п.3.2.
7. АНИМАЦИЯ
7.1. "переливающийся курсор" в движении во всё время длительного процесса (длительная загрузка данных не означает зависание программы) - п.2.2.2(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.5(ААА);
7.2. затянувшуюся загрузку можно прервать (окно с "градусником" процесса имеет кнопки остановки и отмены, либо перевода в фоновый режим для продолжения иной работы) - п.2.2.2(А), 2.2.3(ААА), 2.2.4(ААА);
7.3. всплывающие окна имеют достаточный период (более 5сек) до исчезания (обратный отсчёт, задать большой интервал программно) - п.2.2.1(А), 2.2.2(А), 2.2.4(ААА), 3.3;
7.4. всплывающие окна закрываются по временному интервалу или нажатию функциональной кнопки в зоне окна, клавиши ESC - п.2.2.1(А), 2.2.4(ААА);
7.5. всплывающие окна не перекрывают друг друга, занимают только рабочую область экрана (хороший пример - появления alarms поочерёдно в ICQ Miranda, хинт за пределами экрана или наложенный на предыдущий -  нечитаемый) - п.1.3.2(А), 2.2.2(А), 3.3;
7.6. мерцание не более 24 кадров или 3 вспышек в секунду (слишком частые изменения экрана ведут к глазным и нервным заболеваниям) - п.2.3.1(А), 2.3.2(ААА);
7.7. предсказуемость изменений (обновление страницы браузера по F5, автозаполнение полей ввода, смена экрана по запросу пользователя) - п.3.2.5(ААА);
7.8. браузер с выключенным показом картинок не ограничивает функционал - п.2.3.3(ААА).
8. ВИДЕО
8.1. подпись объекта (воспроизведения видео-ролика может начинаться по клику на всю картинку плейера или только на одну маленькую кнопку-иконку - неожиданное поведение) - п.1.3.3(А), 2.4.4(А), 2.4.9(ААА), 3, 3.2, 3.2.4(АА), 1.3.6(ААА);
8.2. краткое описание или содержание видео-ролика (просмотр всего ролика отнимает время, упоминание в тексте основных моментов привлекает внимание, браузер с выключенным показом картинок) - п.1.2.1(А), 1.2.3(А), 3, 2.3.3(ААА);
8.3. пауза, возврат, перемотка, повтор, длительность ролика, громкость звука (управление всеми параметрами повышает степень восприятия содержимого) - п.1.4.2(А), 2.2.1(А), 2.2.3(ААА), 2.2.4(ААА), 2.2.6(ААА);
8.4. плейер (имеется встроенный, указан формат файла для выбора альтернативного плейера) - п.1.2.3(А), 2.4.4(А).
9. ТЕХ-ПОДДЕРЖКА
9.1. поддержка встроенных в ОС средств (лупа, зуммер, секундомер, смена разрешения экрана в ОС, смена региональных параметров ОС, плагины-помощники для браузеров) - 3.2, 4, 4.1;
9.2. полноценность кода для распознавания программами-ассистентами (закрытые тэги, имена и параметры, тех.подписи элементов) - п.2.4, 2.4.1(А), 2.4.2(А), 2.4.4(А), 2.4.5(АА), 2.4.6(АА), 2.4.9(ААА), 2.4.10(ААА), 3.2.4(АА), 4.1, 4.1.1(А), 4.1.2(А), 1.3.6(ААА), 2.5.3(А), 4.1.3(АА);
9.3. горячие клавиши (стандартные наборы работают только в своей области, можно переназначать или отключать, имеется достаточно предупреждений об использовании) - п.2.1.3(ААА), 3.2, 3.2.4(АА), 2.1.4(А);
9.4. проверка, отмена, подтверждение, шифрование значимых действий (скрытый ввод пароля, ограничения на обмен персональной инфой, финансовые операции с предпросмотром и подтверждением, пред-просмотр вместо печати больших объёмов) - п.2.2.4(ААА), 2.2.5(ААА), 3.2, 3.3, 3.3.4(А), 3.3.6(ААА);
9.5. конкретизация ошибок подсветкой и поясняющим сообщением (нет заглушек для ошибок ОС или базы, внутренние ошибки продукта имеют инструкцию дальнейших действий, неверные данные локализуются цветом или позицией курсора) - п.3.2, 3.3, 3.3.1(А), 3.3.2(А), 3.3.3(АА), 3.3.4(А), 3.3.5(ААА), 3.3.6(ААА).

Для подтверждения WCAG уровня, конечно же надо будет ужесточить и увеличить количество проверок.
Инструменты для автоматической проверки сайтов:
 
Больше примеров можете подчерпнуть из доклада Екатерины Шепелевой "О тестировании доступности" на QA-Fest-2017.

Полезные ссылки:
Изучайте оригинал самостоятельно и расширяйте список тестов - "Web Content Accessibility Guidelines"
На русском - "Web Content Accessibility Guidelines (WCAG) 2.0"
Дополнения за 2018 год - "WCAG 2.1 на русском" (в 2007 г. появился Национальный стандарт ГОСТ Р 52872 и его актуализированная редакция от 2012 г., авторизованный перевод международного стандарта WCAG 2.0 в 2013 г.)
Первая версия содержала 14 принципов - "WCAG — рекомендации, которые никто не слушал"
Практические рекомендации программистам - "Приведение сайта в соответствие со стандартом WAI-WCAG"
Мобильные приложения не отделяют от web-app - "Mobile Accessibility at W3C"

ПэйджСэйвер

ПэйджСэйвер = PageSaver
Современное общество всё чаще получает информацию из Интернет источников: газеты, блоги, соц.сети и прочие сайты СМИ.
Случается, что текст или картинку, или видео необходимо передать в юридические инстанции. А некоторым порталам отказывают в распространении на определённой территории из-за ограниченного доступа силовикам.
Конечно, можно сделать копию страницы в присутствии нотариуса. Но наличие специфической функции на портале соц.сети или СМИ, да и любых других распространителей информации, например, оферта магазина или турагентства, упростила бы процедуру. И не только облегчила бы работу юристов, но и повысила бы авторитет компании, предоставляющей контент.
Представьте, что каждая страница сайта имеет кнопку для сохранения всего видимого содержимого с авторской подписью издателя и датой публикации без возможности правки.
Возможно? Да, технологий достаточно!
Просто? Да, программисту работы на чашку кофе!
Удобно? Да, всем: издатель получает своеобразный патент, рядовой пользователь не напрягает юристов, силовые инстанции получают быстро и без затрат достаточный объём подтверждений дела!

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

Скриншоты в доке

Для лучшего понимания инструкций в них включают скриншоты приложений. Но не всегда такие картинки проходят тест на безопасность данных. Чаще ограничиваются только внешней привлекательностью и стройностью интерфейсных элементов, поскольку изготовители документации придают им рекламный тон.
Яркий пример, не прошедший никакого тестирования - Инструкция для ClearSQL.

Техническая подсказка - скриншот окна со скроллером может делать PicPick. Поскольку у меня есть надежда, что опасности будут исправлены вовремя, то намеренно был усложнён полный просмотр.
Первым шагом упор делается на клиента базы данных, но в приложении ClearSQL вполне можно работать и без этой настройки: скрипты в проект импортировать из обычных текстовых файлов, а выполнять в базе напрямую в SQL*Plus (из редактора ClearSQL запускается в один клик и не требует клиента базы). Картинки и текст про версии клиентов базы, приложения и операционной системы в исследуемом нами документе не полноценны:
- в картинках нет пояснения о каком клиенте речь (не хватает слова Oracle - смотри  пункты 1 и 2), потому что чуть ниже прописаны настройки приложения и операционной системы. Такие двойные стандарты путают читателя - сочетать приложение только с операционкой или и с клиентом базы тоже;
- 32-битное приложение работает только с 32-битным клиентом Oracle, но вполне спокойно функционирует в 64-битной операционной системе (смотри пункт 3), а инструкция строго ограничивает 32-битного клиента базы, при этом напрочь забыт универсальный Instant Client. Полноценную информацию следовало разместить в матрице сочетаний.
Инструкция пользователя должна давать необходимую и достаточную информацию для верного выбора шагов применения приложения. Для этого документация проходит тест полноценности.
Четвёртым пунктом отмечена самая опасная информация - персональная. Ответственный тестировщик никогда бы не допустил распространения индивидуальных данных, с помощью которых халявщики могут достать лицензию через запрос о восстановлении (Forgot password) пароля к сайту (customerID имеется, по имени и географии владельца иммитировать e-mail - простая задача даже для junior-tester), а иные мошеники могут начать вытягивать из пользователя приложения мнимую оплату за лицензию. При этом пострадает не только раскрытая всему миру персона, но и компания-владелец продукта на потере оплат за лицензии, спам-атаках по "восстановлению" пароля и исков

о нарушении GDPR. И это после многочисленных статей о пользе и применимости GDPR в продуктах самой же компании.
Интерфейсный тестировщик не пропустил бы такие ляпы, как помечены пункты 5, 7 и 8:
- лишний двойной разделитель в тулбаре;
- разношёрстные кнопки в одном блоке тулбара - разворачиваемость обозначена как соседняя или встроенная функциональность;
- лишний разделитель кнопок в тулбаре, где и без того места мало.
Инструкция рассказывает об импорте скриптов, но создатель скриншотов пожадничал информацией с собственного компа, а тестовый стенд со стандартным набором папок и файлов развернуть поленился. Из-за этого скриншот получился абсолютно бесполезной картинкой: дерево проекта из мастера импорта бессмысленно без дерева файловой системы или объектов базы данных, без кнопок по добавлению скриптов и формированию проекта.
Вроде бы над сайтом и продуктами работает единая команда, но поскольку в блоге существует иная статья про начальные шаги в ClearSQL (смотри пункты 9 и 10), то очевидно отсутствие в команде координатора, который помнит в первую очередь про нужды пользователя и умеет переводить с языка разработчика на доступный пользователю лексикон. То, что важно для программиста, чаще всего является излишним или непонятным для конечного пользователя.
Это был конкретный пример необходимости тестирования любой информации, предназначенной для обычного пользователя и распространяемой в общем доступе.
Игнорирование проверок документации отрицательно сказывается не только на имидже производителя, но и может серьёзно подорвать всю работу над продуктом. Такая болезнь стартаперов зачастую банкротит вполне устойчивые разработки. Предупрежу желающих заработать на конкретной доке от Conquest Software Solutions - пустая затея. Максимум, который вы получите за отчёт об ошибках - подтверждение о получении и последующая публикация исправлений. Моему альтруизму уже много лет, и его первоочередной смысл - в предупреждении и уменьшении чужих пробелов (ошибки программистов, повышение знаний тестировщиков). Но, имея ClearSQL, очень не плохо можно подняться на баг-баунти в любой другой группе разработки (подробнее говорилось в Easy white-box testing).

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".

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

ТнаТ

Тестировщик на техподдержке (ТнаТ) или Слуга на все четыре стороны

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

Копим куки

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

Предварительная настройка:
- в FireFox отключить все куки ("Открыть меню / Настройки / Приватность и защита / Принимать куки с веб-сайтов" = отключено)
- очистить имеющиеся куки ("Открыть меню / Настройки / Приватность и защита / Показать куки" = "Удалить выбранные")
- можно перезапустить браузер, но не обязательно.

Пример 1
- открыть сайт "mail.ru"
- в левом верхнем углу набрать свои (полностью корректные) параметры входа в почту:

- по нажатию на кнопку "Войти" неожиданно появляется опять форма для входа в почту с пустыми данными:

- вводим ещё раз свои корректные (!!!) данные. Хотя, очень непонятное явление - может какой вирус желает перехватить вводимую инфу? или сервис настолько наворочен, что впихнул в одну фичу все пять? или мои данные потерялись где-то? или ещё что...

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


Ожидаемый результат: сообщение об ошибке должно говорить о некорректно настроенных или отключенных куках браузера.
Решение проблемы: добавить "https://mail.ru" и "https://account.mail.ru" (обратите внимание на протокол) в разрешённые веб-сайты для сбора куков.

Примеры 2, 3
Аккаунты в "Blogger.COM", "Blogspot.RU", "Google.COM" недоступны без включенных куков:






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

Пример 4
Аккаунт в Facebook становится доступным после добавления "https://www.facebook.com" в список веб-сайтов для сбора куков, но очень желательно перезапустить браузер после изменения настроек, чтоб не получить неожиданное сообщение:


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