Показаны сообщения с ярлыком help. Показать все сообщения
Показаны сообщения с ярлыком help. Показать все сообщения

вторник, 20 мая 2025 г.

Рамка-невидимка

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

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

Если у вас найдутся остатки толстой стальной или медной проволоки, то нарежьте плоскогубцами отрезки: два в ширину картины, один в длину и один в четверть длины. На каждом отрезке загните круглогубцами петлю. На малый (верхний) отрезок нанижите остальные три. Положите эту конструкцию на задник картины. Выровняйте отрезки так, чтобы узел приходился на центр по горизонтали и на верхнюю четверть по вертикали. Загните нижний и боковые концы на лицевую сторону картины. Верхний конец загните скобкой или петлёй под размер гвоздика и по уровню верхнего ребра картины.  Вот и всё, рамка с подвесом готова.

Загнутые проволоки на заднике картины

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

Варианты картин по номерам после раскраски и покрытия акриловым лаком стали скручиваться по вертикали. Поэтому пришлось их до создания рамок положить под пресс (несколько стопок книг). Для деревянной рамки со стеклом были отмерены пять реек ширины картины (3 для задника и 2 для лицевой стороны рамки) и две рейки её длины с добавками в две ширины реек, также куплены 17 болтиков с гайками. Стекло нарезано с неменее чем сантиметровыми полями по периметру картины.

Деревянные рейки и стекло

Собираем рамку.

1. На двух лицевых вертикальных рейках просверлите шесть пар отверстий на концах и по центру.

2. Две горизонтальные лицевые рейки отпилите ровно по ширине картины. В верхней просверлите два отверстия, а в нижней - три.

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

4. Просверлите отверстия в изнаночных рейках. 

5. Теперь соберите картину в рамку (на три изнаночные рейки положите картину, сверху стекло и лицевые рейки), вставьте болтики в отверстия и закрепите их шайбами.

17 отверстий в 7 рейках

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

Возвращаюсь к рамкам-невидимкам. Для второго варианта возьмите пять-шесть скрепок.

Обычная скрепка
Цветные скрепки

Гигантская скрепка

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

Разогните пять скрепок по центральному сгибу. 

Разогнутая скрепка

Меньшие сгибы сверните в кольцо. 

Кольцо на одном конце

На кольцо первой скрепки нанижите вторую, третью и четвёртую.

Схема нанизывания скрепок

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

Узел скрепок на заднике картины

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

Кольца на концах

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

Четыре картины на двух гвоздях

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

Вот такие почти бесплатные рамки продемонстрируют всем ваши шедевры во всей своей красе.

вторник, 25 мая 2021 г.

Тесты Евровидения

Это не миф, что тестировщик может проверить всё, в том числе и общемировой конкурс. А если вам на собеседовании предложат рассмотреть не карандаш или круглый люк, то вы будете готовы к такому вопросу.
С чего начать тестирование? Конечно же с документации. Но если её нет в явном виде, то "возьмём быка за рога" и подступим к объекту тестирования с фронта. Донесения разведки - это видимые факты и аналитические заключения. А какая явная информация нам доступна? Сперва - наименование, затем - общеизвестные правила. Из этого определим функциональность продукта и попытаемся применить свои знания и опыт тестирования.
Предмет обследования - "песенный конкурс Евровидение". Разложим наименование на функциональные части:
а) соревнование песен;
б) визуальное представление песен;
в) ограниченность территории - Европа.
По факту, только один пункт соблюдается из трёх. Конкурс песен уже давно перерос в политическое действие по голосованию за земляков. Да и визуальное средство - телевидение - никак не способствует уделению внимания песне, её автору и исполнителю. Вместо этого титры, предшествующие выступлению, большими буквами показывают наименование страны участника, а далее по убывающей геометрической прогрессии шрифт имени исполнителя, наименования песни и её авторов говорит о том, что эта информация незначительна. Это ли не подтверждение того, что Евровидение - никак не песенный конкурс, а соревнование стран, то есть тест отрицательный. Как исправить? Элементарно. Сместить акцент на название песни, исполнителя и создателей, а название стран ограничить иконками флагов, как это работает на олимпиадах.
Поскольку наименование конкурса можно перевести, как "европейский взгляд", то в этом плане тест в достаточной мере положителен. А с приходом цифровых технологий в телевидение визуализация песен становится всё эффектнее. Хотя и здесь можно добавить кое-что. Допустим, все участники станут петь только на родном языке. В этом случае, только представители их соседних стран смогут немного понимать смысл песни. А вот такая технология телевидения, как телетекст, могла бы способствовать пониманию всеми зрителями, давая подстрочный перевод.
К сожалению, а может наоборот, охват аудитории расширен с Европы до Австралии. Это не укладывается в рамки наименования конкурса, а значит тест кардинально не пройден. Элитарное ограничение было наложено в самом начале производства продукта. И его несоблюдение путём добавления иного континента нарушает исходный замысел. Можно ли такое исправить и как? Разве что переименованием конкурса или отказом от рамок одной Европы и расширением телевизионного соревнования до полного покрытия всего земного шара. Тем более, что Интернет сегодня способствует распространению европейского хита на всех континентах.
Если вы обычный телезритель, а не нанятый конкурсом тестировщик или хотя бы сотрудник телефонной компании, то полноценное нагрузочное тестирование по приёму и обработке телефонных звонков сделать не в состоянии.
Правила конкурса ограничивают голосющих регионом и количеством звонков:
* нельзя звонить за свою страну из своего же региона;
* в голосовании участвуют только регионы с попавшими в полуфинал и финал участниками;
* количество голосов с одного номера лимитировано двадцатью.
Эти правила вполне можно проверить, если у вас достаточно средств на телефонном счету и вы можете свободно перемещаться между голосующими в текущем этапе странами. Вам не должно быть доступно отдать голос за страну, в которой вы физически находитесь, но номер может обслуживаться по роуминговому тарифу, то есть на ваш звонок должно быть соответствующее сообщение об отказе. Такой же отказ должен быть, если вы находитесь в стране, участник которой не попал в транслируемый этап конкурса (первый или второй полуфинал, гранд-финал). И, так как на карте Европы нет мест, где в нескольких метрах проходит граница трёх-четырёх стран, то максимально за свою страну можно успеть отдать не более сорока голосов, расположившись вблизи границы между двух не своих стран, где вышки сотовой связи определят вашему телефону различные регионы.
Поскольку баллы от профессионального жюри суммируются элементарной алгеброй с голосами телезрителей через целочисленные значения, то контроль здесь собственно и не нужен. А вот подсказки ведущим о минимальном количестве голосов, которые могли бы отдать телезрители, для того чтобы очередной конкурсант обогнал лидера, вполне могли бы помочь.
Места победителей распределяются по сумме двух мнений - профессионального музыкального жюри каждой страны и по мнению рядовых телезрителей. Результаты жюри сильно приближены к геополитической теме, а обычные слушатели либо действительно голосуют сердцем, либо только те, у кого хватило сил не уснуть всю ночь выходных. Казалось бы, убери баллы профессионалов, и конкурс вернётся на свою песенную волну без политики. Но этого делать нельзя в силу того, что любая программа СМИ имеет право обучать и воспитывать. Жюри, расставив своеобразно баллы, пытается привлечь зрительское внимание к мелодичности песни, постановке номера, исполнительским данным. Но наряду с этим, к их взгляду примешивается желание угодить соседям, поскольку голосование открытое и люди не хотят портить отношения с окружающими странами. А может это из-за того, что лингвистика вмешивается - созвучные языки легче в понимании. Как же можно минимизировать влияние политики на результаты песенного конкурса? Вот, например, представителя и песню в каждой стране выбирают на специальных отборах, конкурсах. А почему бы и не выбирать профессиональное жюри таким же способом?
Мне очень импонирует условие конкурса, которое не ограничивает язык песен. Тем самым национальности, издавна проживающие на территории конкурса, могут сохранять и прославлять свою народную культуру. Если именно ради этого в рейтинговой таблице соревнующихся указывают не название песни и исполнителя, то можно пренебречь политической направленностью конкурса. Но, как уже ранее возникла мысль, хорошо бы привлечь телетекст к лучшему пониманию смысла песни. Телевидение вполне позволяет транслировать подстрочный перевод. Подозреваю, что в таком случае голосов станет больше.
Если создателей и исполнителей обязать петь на родном языке, то переселенцам станет сложнее пробиться. А к постановке номера перестанут привлекать сторонних продюсеров, тем самым давая возможность познакомить весь мир с культурой страны более глубоко. Если учесть, что песня-победитель будет весь последующий год в хитах радиостанций, то местные производители от такого будут лишь в выигрыше. Туристический поток будет увеличиваться за счёт знания языка через песню. Скрытый рекламный шаг геополитики - исполнение на родном языке.
Ещё одна сторона телевещания конкурса в рекламировании страны, его проводящей. Ролики, предваряющие каждый номер, показывают наиболее привлекательные места принимающей конкурс страны. Это тоже скрытая реклама туристического бизнеса.
Поскольку конкурс телевизионный и в самом названии заключено "видение Европы", то любой шоу-номер вполне можно включать в хит-парады клипов музыкальных теле-каналов. Но если представление ограничено видеорядом лишь для телекамеры, то у песни меньше шансов покорить сердца зрителей в зале конкурса и на концертах.
Очередной плюс телевещания заключается в многооконности экрана. Во время распределения баллов телезрители оказываются в самом выгодном положении: отслеживают не только шутки ведущих в разных странах, но и таблицу баллов с мультипликацией распределения мест. На этом этапе очень важна слаженность работы монтажёров камер, чтобы титры по смыслу совпадали с назначением и размером части экрана, чтобы в каждом функциональном окне не сбивалась логика и скорость отображения. В числе глюков Евровидения-2021 подмечено, что пара-тройка команд грин-зоны остались за кадром при расстановке баллов. А вот положительно могу оценить переходы на команды, вынужденные отсиживаться вне грин-зоны. Также хорошо отработали точечные камеры команд, когда не перепутали ни одного дивана временного победителя. Подозреваю, что монтажёры создали чёткую базу данных, связав диваны участников с закреплёнными за ними видео-точками.
Компьютерные технологии значительно улучшили с годами восприятие процесса расстановки баллов и сортировки мест. Мультипликация перемещения участников с занимаемого места на иное за счёт прибавки очередной порции голосов всеми воспринимается ярче и быстрее, нежели обычное проговаривание ведущим сумм и мест. Визуализацию единого списка стран, проголосовавших за участников, тоже считаю уместным применением графического программирования. Но в этих списках всегда используется только название страны, вместо имени исполнителя и самой песни. Это очередной факт того, что конкурс имеет политическую направленность. Да, шоу-номер и певца готовила по сути вся страна, но это не значит, что зрители голосуют за регион. Наоборот, слушатель услаждает свой слух и глаз, а не повышает политическую дипломатию. Современные телевизоры имеют достаточные размеры, чтобы показать полное наименование песни, имя исполнителя и авторов, флаг страны-участницы и дополнительно список голосующих стран. На мой взгляд обыденного зрителя результирующая таблица должна состоять не из списка стран с флагами, а из названий песен и фото исполнителей. Только в этом случае песню и певца можно будет дольше помнить. Проверьте себя - много вы можете напеть мелодий, впервые появившихся за счёт конкурса Евровидение? Мероприятию уже 65 лет, а на слуху не более десятка мелодий и пяток певцов. Это ли не подтверждение того, что конкурс из песенного давно перерос в геополитический.
Как и любой выпускаемый билд, Евровидение имеет своего ответственного тестировщика. Здесь его называют супервайзером. Именно он подтверждает благополучный исход производства и даёт своё заключение о полном совпадении принятых значений с отнесёнными к ним данными базы.

Итак, мы с вами протестировали телевизионный песенный конкурс "Евровидение". Как вы сами убедились, даже к такой казалось бы отдалённой тематике можно приложить наши знания и умения тестирования. Аналогично моим предыдущим отчётам о тестировании некоторые моменты подсвечены: жёлтым - объект тестирования, зелёным - положительный исход теста, красным - проваленный тест, сиреневым - сомнительный результат или невозможность исполнения, голубым - предложение по исправлению. Прикладывайте свой опыт и разум ко всем случаям окружающей жизни, тогда все ваши действия и предложения станут конструктивными, и никто не сможет вас осудить в голословности. А ваш дар критика разовьётся сам по себе.

суббота, 5 октября 2019 г.

Аналитики для тестировщиков

Список прямых ссылок и лично моё мнение о каждом докладе на конференции Analyst Days 10, проходившей 24-25 мая 2019 года в Санкт-Петербурге.
Зачем такой список? Мне лично не удобно долго смотреть доклады с сайта конференций или по плей-листу youtube. Поскольку мне часто хочется поделиться своими новыми знаниями, то потенциальным читателям облегчаю задачу поиска и запуска конкретного контента. А также мой список всегда имеет аннотации для конкретизации тематики.
Да, программа конфы красиво сгруппирована и есть инфа, по которой можно определить рекламные или заказные доклады, но для меня становятся лишними клики для открытия страницы с подробным контекстом каждого доклада. Составив себе список только из наименований докладов без имён компаний и рассказчиков моё внимание фокусируется лишь на смысле излагаемого материала. А плей-лист портала видеозаписей маловат при скроллинге, его нельзя отсортировать под себя и нет отметок об уже просмотренном. Некоторые откроешь, но для полного просмотра откладываешь, поэтому смена цвета линка в этом случае не помогает. Вот если бы указывался процент моего просмотра, то такой индикатор был бы более полезен.
Раньше площадкой для хранения видео был портал vimeo, но и его проигрыватель сильно перекрывался огромной плашкой куков.
К организаторам конфы, а точнее к тех.группе записи, сложились предложения:
* либо вообще не включать в запись блок вопросы-ответы, либо вопросы записывать в такой же микрофон, как и у докладчика. Потому что ответ без вопроса звучит глупо, непонятно, лишне и тому подобное;
* видео с докладчиком выводить в экран меньшего размера для улучшения восприятия. Нерационально использовать половину экрана на пустоту за телом докладчика, а слайды уменьшать до их нечитабельности;
* мастер-классы и доклады с досками, заполняемыми в режиме реального времени, сопроводить дополнительной видеокамерой, направленной на сам флипчарт для увеличения всем;
* звук из мастер-классов записывать через микрофоны, распараллеленные с ведущим.
Да, понимаю боль организатора - билеты на конференцию плохо покупают, а бесплатная публикация записей не несёт дохода. Но если записи станут удовлетворять вышеописанному, а также будут иметь лёгкую аннотацию от присутствовавших (=реклама из первых рук), то за просмотры можно будет брать ощутимую плату. 20-ю конференцию тестировщиков пытались продавать, но если бы вместо одного и того же ролика каждую запись предварял отзыв от побывавших (аннотация и отзыв бесплатно, а полная запись за плату), то организаторы собрали бы хороший куш.
Слабая наполненность залов и заверения (Никита Макаров про тестирование и конференции  с "01:05:52 - Про гайзенбаг" и далее) организаторов параллельной конференции Heisenbug  навело на мысль, что Analyst Days и SQA Days стоит объединить в одну, но расширить третьим течением - привлечь программистов, разработчиков, архитекторов. Тогда три потока (аналитик, программист и тестировщик) пересекутся в зоне BarCamp, их работодатель сэкономит на билетах, а конференция поднимется в статусе за счёт глобальности.

Мой список сгруппирован по приоритету для тестировщика (по-жизни я из числа критиков и оценщиков качества), но не отсортирован по порядку важности (мой просмотр получился в такой очереди, обусловленной наименованием каждого доклада).


полезное:
Байки из Банка. Как нам помогли пользовательские истории - о влиянии метода на весь процесс разработки
Единый язык проекта - два документа, которые должны быть изначально, словарь терминов (продуктовый, внутрикомандный) и диаграмма сущностей продукта
Погружение в новую предметную область, чек-лист аналитика - универсальный список дел для любой должности (аналитик, программист, тестировщик) + пункт о % выполненности + причины задержки
«Пиши-упрощай»: как сделать требования легкими для восприятия? - в помощь issue review
Трассировка: лучшие практики - реальные советы-напоминалки к шагам issue review
4 правила археолога: как «раскопать» систему - легаси, зачем первейший документ - структура проги, визуализация кода = карта (плохо слышно)
Фасилитация рабочих встреч: творчески и результативно - не подготовленное совещание не обеспечивает комфортного обсуждения (неожиданное прерывание текущей работы, недостаточность информации о материале дискуссии)
Все лгут. Живите с этим - техники практической психологии применимы тестировщиком на стадии планирования
Сценарии неэффективного использования ресурсов аналитика - что на кого спихнуть и когда
Игра в разработку. Опыт оценки профессиональных качеств аналитика - аттестация для доверия, статуса, планирования (не используемых в CSS), можно подменить покер-разработкой
Роль бизнес аналитика в решении нестандартных задач на сложных проектах - алгоритм решения проблем
Система мониторинга: продвинутый набор технических метрик или панорама успеха? - приятно слушать понятную речь о собственно изобретённом методе сбора и обработки информации
Самопредставление - мастеркласс от актёра в год театра для работников с первоочередной надобностью - общение и написание текстов (правильных, интересных, читабельных = по законам драмматургии)
Антикризисный аналитик: как подхватить проект и не надорваться - не так весело, как у Дорофеева про прокрастинацию, но также полезно и разложено по полочкам
Как мы оцениваем и развиваем больше сотни аналитиков - больше о том, как выбрать область развития в конкретной компании, есть подсказки надобности по ролям
Ценность ясности цели - про типы оппонентов и как их раскручивать
Кто и как на самом деле пользуется системой: от догадок к цифрам - как собрать и применять стат.данные о пользователях web-приложения
UX дашборда мечты. Как превратить хаотичные данные в один красивый динамичный экран - о правилах построения отчётов для верхнего звена
Учимся играть в бизнес-анализ - коротко о необходимости игры, но забыта обучающая роль
Учимся играть в бизнес-анализ (мастер-класс) - визуализация с подробными пояснениями, обучение от хорошо подготовленной лекторши; более пол-записи - самостоятельная работа в группах - не попал звук в ролик = бесполезный просмотр записи
Тактические приемы при работе с субподрядчиками - об одном успехе одной команды (что помогло, без перечисления помех)
Проверка гипотез требований к функциям и UX/UI с помощью Customer Journey Map. Рабочий кейс - альтернатива сочетанию методик демка+ретро
Свой DSL на проекте: когда и как - шаги по созданию своего и под себя не фреймворка, а намного глубже - целого языка, который ускорил написание кода и выявление багов (на уровне аналитика и кода)
Чек-лист для описания требований к интеграции - в помощь при тест-дизайне интеграции
TM Forum API: что, зачем и почему - телеменеджмент правила про стандарты
Ограниченность как источник вдохновения. Проектирование систем на базе идей инклюзивного дизайна - составление данных для тестов доступности
Дневник аналитика или как не стоит писать на gherkin - забавно о соблюдении правил
Заповедная зона – где продукт живет в мире с госзаказом - эмоционально о подводных камнях приоритетности качества в том числе
Работа аналитика в медицинской компании - тестировщику, идущему в мед.сферу, есть из чего дизайнить тесты


ну, послушайте...:
Зачем вам ПО. Драма в трех частях - нет 3 частей, нет драмы, но множество пунктов для общения с заказчиком
10 советов по организации удалённой работы аналитика - не затронуты технические и экономические стороны
Управление временем для аналитика - балабол
Управление требованиями в работе с удаленной командой - не столько специфичность управления требованиями, сколько общие подсказки по удалённой работе в области инструментов
Выбираем качество требований - забыто время доставки, как часть качества
IT Дирижер - слишком заумно и книжно
Единым махом семерых побивахом! или почему нельзя создать единственный понятный документ для всех - не 7, а только 3 типа доков; коучер, а голос дрожит как у дебютантки; чит-лист параметров для ума писателя доки
Эволюция процесса разработки продукта: роль аналитика - от аналитика к владельцу продукта
Путь из Бизнес-заказчиков во Владельцы продукта - как нашли или переименовали "козлов отпущения"
Визуализация данных - просто и наглядно - мисс-очевидность про место uml в техзадании
Нестандартный подход к разработке через тестирование. Практический кейс - реклама своего продукта, написанного для внутренних нужд
Как управлять аналитиками? - сплошная теория от любительницы поболтать бессвязно
Аналитическая орда. Как захватить "Козельск" стейкхолдера без потерь! - о необходимости распределить роли, планировании и строгом соблюдении правил в резко выросшей команде для идеального agile
Передача знаний: быстро, весело, полезно - на примере эстафеты, при смене сотрудника, структуризация подготовки и самого трансфера по законам педагогики
Аналитик 2.0. Как информация, которой владеет аналитик, влияет на мотивацию в команде - куда бежать, когда уже и так всё хорошо
УПРАВЛЕНИЕ. ЛИДЕРСТВО. ПАРТНЕРСТВО - о результатах опроса
Оценка соответствия модели основных бизнес-процессов стратегии компании - теория экономики стартапа
Влияние аналитиков на развитие компании - аналитики отвоевали своё место
Нерешенные вопросы в бизнес-анализе - нудный искатель серебряной пули
Сторителлинг в бизнес коммуникациях (командостроение, продвижение, переговоры, продажи). Сторибанки - неподготовленный лектор постоянно мычит и скачет с темы на тему, попытки отвечать на неслышимые вопросы
Сторителлинг (мастер-класс) - разговоры участников еле-слышны, поэтому сложно уловить смысл и важные моменты мастер-класса, сплошные недомолвки
Use Case VS User Story. Выбираем подход к специфицированию требований - скучно, нудный "учитель"
Мы строили, строили и наконец построили или краткая история эволюции интеграционного сервиса - весьма специфичен для аналитиков
Декомпозиция системы или "ну пусть это будет подсистема интеграции..." - весьма специфичен для аналитиков, теоритезировано
Практика архитектурного проектирования ИТ решений - яркий пример спешившего на конфу "учителя" - избыточность инфы на слайдах, опечатки, нудность голоса
Интеграция и пустота. Заглядываем внутрь моков - более для тестировщиков, но сказка не к месту
Опыт управления изменениями с помощью формирования концепции - специфичная хеппи-стори отдела аналитиков
Особенности сбора требований в Data Science-проектах - теоритезировано сугубо для аналитиков
Роль аналитика в Data Governance - специфично для сообществ аналитиков
Общебанковский модельный репозиторий - прикручивание графического приложения к нуждам архитектора
Автоматизация бизнес-процессов в строительстве - реклама собственного продукта
Archimate — швейцарский нож аналитика - об инструменте для рисования диаграмм


Не подумайте, что доклады из папки "ну, послушайте..." попали на моё плохое настроение. Нет, в первоначальном списке они перемежались с полезными. Просто на фоне хороших презентаций, вкупе с накопленными знаниями и специализацией для аналитиков вторая половина для QA - не вариант. Факт того, что ни один доклад не попал в разряд ненужных, говорит о том, что подобная конференция и её информационно-познавательная роль не менее важна в жизни тестировщика

среда, 19 декабря 2018 г.

Храни меня..

Главное в работе тестировщика - сравнивать реализацию со стандартами. Для операции сохранения объекта стандартов нигде не прописано, значит мы в своих исследованиях должны оперировать привычными действиями от большинства крупных продуктов. Но с появлением Windows 10, как минимум одно приложение Notepad/Блокнот перестало быть логичным: окно редактора не закрывается по нажатию кнопки "х" с новосозданным файлом. Особенно странным выглядит это поведение на фоне всех остальных подобных редакторов, например, WordPad и MS Word.
Возможно аналогично размышляли и разработчики ClearSQL, когда программировали свой алгоритм для операции "Save As". По их мнению все изменения должны сохраняться как в новом проекте, так и в исходном оригинале.
По результатам моего возмущения на основе вышеописанных багов у меня родились две схемы об операциях сохранения объекта. Под объектом подразумеваю файл, проект приложения, строку таблицы или пакет базы и тому подобное.

Расширенная схема операций с объектом
1. SAVE / Операция доступна как для новосозданного объекта, так и для всех последующих его вариаций
1.1. объект существует
1.1.1. объект изменён
1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление
1.1.1.1.1. замена предыдущей версии объекта его новым вариантом / Обработка ошибок может выполняться на уровне операционной системы
1.1.2. объект не менялся
1.1.2.1. проверки файловой системы: доступ на запись/перезапись, изменение, удаление; разрешены изменения параметров объекта
1.1.2.1.1. замена параметров: даты-времени сохранения, без изменения даты создания объекта
1.2. новый объект создан
1.2.1. выбор места хранения нового объекта / Диалог выбора сервера/диска, папки для хранения объекта
1.2.1.1. присвоение имени новому объекту
1.2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
1.2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться  на уровне операционной системы
1.2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
2. SAVE AS.. / Все изменения сохраняются только в новый объект. Первоначально открытая версия остаётся неизменной на момент открытия объекта в редакторе
2.1. выбор нового места хранения  / Диалог выбора сервера/диска, папки для хранения объекта
2.1.1. присвоение имени новому объекту
2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
3. COPY TO..  / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
3.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
3.1.1. присвоение имени новому объекту
3.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
4. ARCHIVE / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
4.1. выбор одного или нескольких объектов для операции
4.1.1. уменьшение объёмов объектов / Функция стороннего архиватора
4.1.1.1. переформирование нескольких объектов в один / Функция стороннего архиватора
4.1.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
4.1.1.1.1.1. присвоение имени новому объекту
4.1.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
5. BACK UP / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
5.1. выбор одного или нескольких объектов для операции
5.1.1. сжатие, группировка объектов в один объект или папку / Опциональная функция стороннего копировальщика
5.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
5.1.1.1.1. присвоение имени новому объекту
5.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
6. DUPLICATE / Операция выполняется на основе последней сохранённой версии объекта. Количество дубликатов и новые уникальные идентификаторы объектов изменяются в процессе операции.
6.1. определение количества копий
6.1.1. авто-определение места хранения новых объектов / Используется внутренняя настройка редактора
6.1.1.1. проверки: прав на создание новых объектов, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
6.1.1.1.1. авто-присвоение новых имён объектам  / Используется внутренняя настройка редактора
6.1.1.1.1.1. создание новых объектов / Внутренняя функция редактора
7. CLONE / Операция выполняется на основе последней сохранённой версии объекта. Копия возможна только одна, уникальный идентификатор объекта изменяется в процессе операции.
7.1. авто-определение места хранения нового объекта / Используется внутренняя настройка редактора
7.1.1. проверки прав на создание нового объекта, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
7.1.1.1. авто-присвоение нового имени объекту / Используется внутренняя настройка редактора
7.1.1.1.1. создание нового объекта / Внутренняя функция редактора
8. Закрытие редактора с сохранением объекта / Диалог Save или Save As.. для сохранения объекта открывается в перечисленных случаях
8.1. кнопка ОК
8.2. кнопка Yes to All
8.3. кнопка "х"
9. Закрытие редактора без сохранения объекта / Редактор закрывается без предложения о сохранении изменений объекта в перечисленных случаях
9.1. кнопка Cancel
9.2. кнопка No to All
9.3. кнопка Skip
10. Параметры объекта, устанавливаемые/изменяемые в редакторе / Настройки объекта определяются в параметрах редактора, но могут изменяться в процессе сохранения
10.1. формат/расширение файла
10.2. тип данных столбца в таблице БД
10.3. статус подобъекта в проекте
11. Полезняшки/Удобства
11.1. горячие клавиши
11.1.1. Ctrl+S
11.1.2. Ctrl+Shift+S
11.1.3. самонастраиваемые/внутренние для редактора
11.2. стандартные окна и диалоги операционной системы
11.3. авто-предложение места хранения, локализация папки
11.4. фильтр расширений файла
11.5. авто-предложение нового имени объекта
11.5.1. по шаблону
11.5.2. постфиксы/префиксы
11.5.3. с добавлением даты-времени

Краткая схема обращения с объектом
1. Запустить редактор
2. Открыть объект в редакторе
2.1. редактор оставляет исходник как резервную копию в оригинале (место, имя, другие параметры)
2.2. редактор делает копию объекта во временном пространстве, но с темже именем
2.2.1. редактор отображает объект для последующей работы
2.2.1.1. в объект вносятся изменения
2.2.1.1.1. выполнить Save
2.2.1.1.1.1. резервная копия заменяется рабочей версией
2.2.1.1.1.2. обе идентичны
2.2.1.1.2. выполнить Save As..
2.2.1.1.2.1. рабочая версия объекта сохраняется в новое место с новым именем
2.2.1.1.2.1.1. новая версия объекта копируется во временное рабочее пространство, но с темже новым именем
2.2.1.1.2.2. резервная копия остаётся со старыми параметрами: место, имя, без модификаций
2.2.1.1.3. выполнить Clone, Duplicate, Back Up, Archive
2.2.1.1.3.1. проверка на наличие изменений
2.2.1.1.3.1.1. рабочий объект отличен от оригинала, вносились изменения
2.2.1.1.3.1.1.1. предупредить об изменениях
2.2.1.1.3.1.1.1.1. предложить применять операцию к объекту с изменениями
2.2.1.1.3.1.1.1.1.1. изменения объекта сохраняются / Сохранение в авто-режиме или через диалоговое окно
2.2.1.1.3.1.1.1.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.1.1.2. предложить откатить все изменения и применить операцию к исходной копии
2.2.1.1.3.1.1.1.2.1. рабочая версия с последними несохранёнными изменениями уничтожается
2.2.1.1.3.1.1.1.2.1.1. создаётся новая рабочая версия объекта из оригинала
2.2.1.1.3.1.1.1.2.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.2. рабочий объект и его оригинал идентичны, изменений не вносилось
2.2.1.1.4. закрыть редактор / Закрыть окно редактора можно: из меню Exit/Close, по кнопкам интерфейса "х" или Close, по нажатию горячих клавиш Alt+F4 (стандарт в Windows). При наличии изменений в объекте закрытие редактора зависит от ответа в диалоге о сохранении объекта.
2.2.1.1.4.1. предупредить о наличии изменений
2.2.1.1.4.1.1. диалог о сохранении объекта закрывается по кнопке OK, Yes, Yes to All, Save
2.2.1.1.4.1.1.1. изменения объекта сохраняются  / Сохранение в авто-режиме
2.2.1.1.4.1.1.1.1. оригинал заменяется рабочей версией: запись поверх или уничтожение оригинала и копирование рабочей версии на место оригинала
2.2.1.1.4.1.1.1.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.1.1.1.1.1. закрытие редактора
2.2.1.1.4.1.2. диалог о сохранении объекта закрывается по кнопке No, No to All
2.2.1.1.4.1.2.1. оригинал остаётся неизменным
2.2.1.1.4.1.2.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.2.1.1.1. закрытие редактора
2.2.1.1.4.1.3. диалог о сохранении объекта закрывается по кнопке Cancel, Close, "x"
2.2.1.1.4.1.3.1. оригинал остаётся неизменным
2.2.1.1.4.1.3.1.1. рабочая версия остаётся в прежнем состоянии
2.2.1.1.4.1.3.1.1.1. редактор остаётся открыт с рабочей версией объекта
Дальнейшие операции (редактирование, перемещение) применяются к рабочей версии, идентичной оригиналу

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

воскресенье, 25 ноября 2018 г.

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

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

среда, 11 июля 2018 г.

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