Война войной, а порядок в файлах держать надо. Представляю сам себе свой же открытый и ещё далеко не завершённый сборник рецептов/инструкций для последовательной настройки Debian/Manjaro c KDE — https://testitquickly.com/bystro.linux/

И даже есть https://testitquickly.com/bystro.linux.nas/ — про настройку NAS на основе OpenMediaVault.

Всё собрано в Zim, десктопном текстовом редакторе для локального сборника wiki pages на основе plain text файлов с markdown разметкой. Рекомендую.

За десятилетия возни с Debian собрался txt-файл на 4 384 строк с рецептами и подсказками по установке и (почти полной) настройке устанавливаемой системы. Копи-паст из plain text в консоль идеален, и простые инструкции в нём воспринимаются отлично. А многошаговые последовательности воспринимаются сложно. И сразу всё плохо с иерархией, ссылками на разные места и с оформлением текста. Хочется локальную википедию. Но в то же время хочется plain text. И чтобы было доступно в том числе и из консоли.

Zim — идеальная «настольная wiki». Хранит всё в текстовых файлах, которые можно читать/редактировать в любом окружении, и синхронизировать и бэкапить их можно как угодно — plain text же. Zim не только помогает упорядочить большие массивы знаний, он ещё помогает самому процессу мышления, как майндмапа. Он потребляет даже меньше ресурсов, чем Kate!

Начал было закатывать всё это через LaTeX в pdf, но с консольными командами в LaTeX всё мерзОтно. Ординарные и даблкавычки там принудительно становятся фигурными, а тильда (~) в открытом виде вообще не используется. Копи-пастить команды из таких pdf в консоль нет смысла, бо в строку подставляются лишние и ошибочные символы. Кстати, ту же ерунду творит и WordPress.

Что с этим можно делать

Всё, что может быть необходимым или интересным, кроме коммерции или издевательства над джунами. Всё открыто, RTFM и погнали экспериментировать.

Debian: sudo apt-get install zim

Manjaro: sudo pacman -S zim

Можно поставить через flatpak или snap, но в нативной установке проще настроить внешнее оформление Zim (я подсел на тёмную тему).

Выкачать все файлы из bystro.linux.

Открыть Zim
> File
> Open Another Notebook (Ctrl+O)
> Add
> [Browse]
> Указать каталог с этими файлами.

Подхватится файл notebook.zim — блокнот откроется.

Следовать инструкциям. Ссылки на них находятся в головном файле раздела про настройку Debian или про Manjaro.

В индексе блокнота Zim невозможно упорядочить/сортировать страницы по своему хотению, а именовать их цифрами — безумно. Поэтому в головной файл раздела добавлены ссылки на каждую страницу/подстраницу, инструкции из которых следует (это не принципиально) последовательно выполнять.

Стилевое оформление страниц Zim настраивается отдельно. Инструкция по натягиванию на него тёмной темы см. на вики-странице.

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

(1) everybody knows what “bug” means;

(2) the standards are inconsistent with one another and with themselves in the definition of “fault,” “error,” and “failure”;

(3) according to the Oxford English Dictionary, the usage of “bug” the way we use it, contrary to popular belief, predates its entomological use by centuries—the first written reference to “bug” = “goblin” is from 1388, but its first use to mean a small, six-legged creature with a hard carapace dates from 1642;

(4) I prefer short, strong, Anglo-Saxon words to effete Norman words. The genesis of “bug” as a computer problem being derived from a moth fried on the power bus of an early computer, thus bringing the system down, is apocryphal. “Bug” is an ancient and honorable word (Welsh bwg) and not newly coined jargon peculiar to the computer industry.

Software Testing Techniques, Second Edition

by Boris Beizer (1990)

ISBN: 1850328803

Apocryphal — это от слова апо́криф (от др.-греч. «скрытый, сокровенный, тайный») — произведение религиозной литературы (иудейской и христианской), преимущественно посвящённое событиям и лицам ветхо- и новозаветной и церковной истории, не включённое в канон. Апокрифы являются запрещёнными для чтения в церкви. Чертей Клириков, которые используют их для чтения в общественном месте, полагается лишать сана.

С одной, непонятно какой именно стороны, можно посчитать заявление Бейзера заносчивым и пафосным.

С непонятно какой другой стороны, он был (1934-2018 же!) прав чуть более, чем полностью.

По-дефолту звуки, которые издает Teams на смартфоне раздражают даже мëртвого Имхотепа — имхо, конечно, да кабы у него был смартфон, коий ему не дадут.

Их можно отключить ВООБЩЕ, но иногда таки надо получать сообщения из этой навязанной корпорациями шняжки, поэтому еë не заткнуть.

Но как тут поменять звук-то?!?!?!?

А вот так:

В приложении Teams тыкнуть по иконке своего аккаунта,
-> Settings (Настройки)
-> Notifications (Уведомления)
-> General activity (Общие действия)
-> Chats (Чаты)
-> Без звука
Или же можно выбрать другой звук, например, тишину.

Понравился текстовый редактор Sublime Text.

Раньше-то Eclipse был нашим всем, но на днях произошло неприятное: Eclipse падает всякий раз при копи/пэйст. Открыт соответствующий баг, решения пока нет, а между тем работать в Eclipse стало и решительно, и нерешительно невозможно. Вероятно, можно откатиться на более старые версии, но не факт, бо тогда и окружающие его пакеты тоже надо даунгрейдить, а это не тру.

Но под Linux есть много всяких IDE для разработки, даже есть почти нативное KDevelop. Из кроссплатформенных на слуху:

• PyCharm от JetBrains — выглядит адекватно, но от него завыли кулеры и памяти поуменьшилось изрядно, при этом проект внутри ещё не создан. Нет.
• Atom от GitHub, которое сегодня тоже от Microsoft. Построен на электроне, а это нет!
• VS Code (он же Visual Studio Code) от Microsoft. Нет.
• Sublime Text от кого-то из гугла (Джон Скиннер). Слово sublime переводится как «возвышенный, величественный, высокий, грандиозный».

Тут и остановимся.

В основе своей Sublime Text разочаровывающе примитивный и требуется время на его освоение и настройку, но это и хорошо. Можно подключать к простой основе только те расширения, которые понадобятся в работе, а это unix way. У него много документации (unix way!)? Он в принципе хочет каких-то денег (not a unix way!), но не настойчиво да и не особо много, поэтому всё норм.

1

Установка Sublime Text в Debian

Следуем общей инструкции:

Install the GPG key:

wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -

Ensure apt is set up to work with https sources:

sudo apt-get install apt-transport-https

Select the Stable channel to use:

echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list

Update apt sources and install Sublime Text

sudo apt-get update && sudo apt-get install sublime-text

1.1

Основная настройка Sublime Text

Для управления пакетами надо включить Package Control (инструкция):

• Tools > Install Package Control…

1.2

Расширение возможностей Sublime Text

• Tools > Command Palette… (Ctrl+Shift+P)
• Начать набор команды «install» > появятся подсказки > Выбрать «Package Control: Install package»
• начать набор названия пакета, который надо установить > появятся подсказки > выбрать нужный и даблклик или Enter.

Последовательно установить

1. AdvancedNewFile
2. Anaconda — autocomplete
3. All Autocomplete
4. AutoFileName
5. Base16 Color Schemes — стили подсветки кода; мне очень зашло «base16-phd»
6. Bracket​Highlighter
7. DocBlockr
8. Emmet — шаблоны для верстальщиков
9. Git
10. GitAutoCommit
11. GitGutter
12. Markdown Extended
13. SideBarEnhancements — слева появляется сайдбар, там и отображаются файлы проекта (и вообще открытые), и появляются команды для управления файлами на ssd
14. SublimeLinter — затем плагины для линтеров по определённым правилам для определённых языков
15. Terminus — более продвинутая консолька
16. по слову Theme можно выбрать иную тему оформления, нежели дефолтную Adaptive (кагбэ рейтинг тем). Для установки темы надо знать её точное название.

Restart Sublime Text.

1.3

Тонкая настройка

каждого плагина Sublime Text по-отдельности займет некоторое время, но оно того стоит. Ковыряние в файлах настроек и прописывание инструкций приносит ощущение полного контроля и управления. Unix way же!

1.3.0

Базовые настройки

Preferences > Settings

{
	// Общий размер шрифта редактора
	"font_size": 21,
	"word_wrap": true,
	// Set to a value other than 0 to force wrapping at that column rather than
	// the window width. See "wrap_width_style" for extra options.
	"wrap_width": 100,
	// Настройки отступов В КАЖДОМ ФАЙЛЕ
		// Ctrl + Shift + P (to activate the command palette)
		// Type "Indentation",
		// Choose "Indentation: Convert to Tabs"
	"detect_indentation": true,
	"tab_size": 4,
	"translate_tabs_to_spaces": false,
	// Тема оформления
	"theme": "Adaptive.sublime-theme",
	"ignored_packages":
	[
		"Vintage",
	],
	"color_scheme": "Packages/Base16 Color Schemes/Themes/base16-phd.tmTheme",
	"dark_theme": "Adaptive.sublime-theme",
	"light_theme": "Adaptive.sublime-theme",
}

1.3.1

Настройка темы

Пусть будет Adaptive.

Preferences > Customize Theme

Откроется два файла, один нередактируемый (общие настройки), второй редактируемый, бо сугубо пользовательский. Идея в том, что из общего можно копировать строки настроек в пользовательский файл и всё будет норм.

Иногда эти файлы открываются поодиночке.

Например, впишем это.

// Documentation at https://www.sublimetext.com/docs/themes.html
{
"variables":
	{
	"font_size_sm": 24,	// размер шрифта вкладки
	"font_size": 20,	// размер шрифта названия файла в Side bar
	"font_size_lg": 18,	// размер шрифта группы файлов в Side bar
	},
}

1.3.2

Настройка Anaconda

В Anaconda встроен довольно строгий линтер, он считает неправильными почти все строки любого кода (и он, конечно, прав), помечая их белыми прямоугольниками. Эту функциональность лучше передать отдельному плагину, бо лучше использовать линтер под свой язык программирования и строго под выбранные юзером правила правописания, которые под тот же Python бывают очень разные. Поэтому

Preferences > Package Settings > Anaconda > Setting — User

Этот файл пуст, можно прописать там и отключение линтера анаконды, и путь к рабочей версии Python:

{
    "settings": {
        "python_interpreter": "/usr/bin/python3",
        "anaconda_linting": false
    }
}

Позже можно будет использовать возможности Anaconda для автоформатирования кода по CTRL-ALT-R (насколько это, конечно, применимо к тому же питону) в соответствии с правилами PEP8. Там тоже надо настраивать точнее, бо по-умолчанию эта шняга заменяет табы четырьмя пробелами.

Быстрое решение:

View > Indentation > Tab Width: 4 //эту настройку в будущем уже не трогаем

View > Indentation > Convert Indentations to Tabs

Или же:

В правом нижнем углу окна отображается эта же настройка ‘Tab Size: 4’.

Левомышечный клик по ней открывает то же самое меню, что из View. Остаётся кликнуть по последней команде: Convert Indentations to Tabs. Можно использовать каждый раз после CTRL-ALT-R.

Надо пореже использовать CTRL-ALT-R и воспитывать в пальцах изначально принудительное правописание и отступы, в Python этот аспект важнее, чем в других ЯП.

1.3.3

Настройка хоткея для вызова Sidebar

Вызов или через View > Sidebar, или через последовательное нажатие «Ctrl+k, Ctrl+b».

Клавиши можно переназначить, например, на Ctrl+\: Preferences > Package Settings > Side Bar > Key Bindings — User

[
  	// Toggle the Sidebar
  {"keys": ["ctrl+\\"], "command": "toggle_side_bar"},
]

1.3.4

Настройка консоли для запуска скриптов на Python

По-умолчанию дежурный запуск скриптов на Python делается во встроенной консольке через Ctrl+B. Годно, если надо просто что-то выполнить, и нет, если подразумевается интерактивность со стороны юзера.

Ctrl+Shift+P > Package Control: Install Package > Terminus

Затем сохранить в каталог с пакетами (/~/.config/sublime-text/Packages/User/) новый файл close_terminal.py — это плагин для тонкой обработки будущих окон терминала. В частности, он будет при каждом билде скрипта в разработке держать фокус на окне со скриптом и фокус только на одном окне терминала, чтобы не открывалось новое при каждом нажатии Ctrl+B.

Tools > Build System > New Build System (откроется пустой файл настроек)

{
    "target": "terminus_open",
    "auto_close": false,
    "title": "Pytnon Output",
    "cancel": "terminus_cancel_build",
    "pre_window_hooks":
        [
            ["windows_focus", {"store": true}],
            ["close_terminus_view_by_title", {"title": "Pytnon Output"}],
            ["windows_focus", {"store": false}],
        ],
    "post_window_hooks":
        [
            ["carry_file_to_pane", {"direction": "right"}],
            ["windows_focus", {"store": false}],
        ],
    "shell_cmd": "/usr/bin/python3 -u \"$file\"",
    "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)",
    "selector": "source.python",
    "env": {"PYTHONIOENCODING": "utf-8"},
    "variants":
    [
        {
            "name": "Syntax Check",
            "shell_cmd": "/usr/bin/python3 -m py_compile \"${file}\"",
        }
    ]
}

Путь /usr/bin/python3 общий, тут можно задать любое направление к разным версиям, буде таковая необходимость соизволит явиться.

Под виндой, соответственно, в shell_cmd надо указать путь к python.exe, и делать это надо чуть заковыристо, через двойные косые: «shell_cmd»: «D:\\.python_venvs\\general_python\\Scripts\\python.exe -u \»$file\»».

Эти самые pre_window_hooks и post_window_hooks пришли из плагина close_terminal.py

Ctrl+S > дать новому файлу sublime-build имя вроде ’BuildPython3.sublime-build’ и убедиться в том, что он сохраняется в /~/.config/sublime-text/Packages/User/

Tools > Build System > выбрать ’BuildPython3‘

Больше эту настройку можно не трогать. Теперь общий хоткей Ctrl+B вызовет консоль Terminus справа от окна с кодом и в ней выполнит код по заветам прописанного интерпретатора Python.

Перевод фокуса с одной панели на другую с клавиатуры через Ctrl+1 и Ctrl+2 — если на экране две панели (их можно понаоткрывать бесчетно).

тубиконтинуедт, конечно, например на https://testitslowly.wordpress.com/category/sublime-text/

1. Сергей Пирогов — кустарный
2. Ярослав Пернеровский — подкастер

Роли озвучивали:

1. Антон Мужайло — лучший QA 2019 всея Украины
2. Алексей Лупан — равнодушный к футболу эксперт по стратегиям тестирования футболистов

Темы:

• 00:01:15 — Начальное начало
• 00:01:17 — Гости-шмости
• 00:02:15 — В чём разница между «Тест-план» и «Тест-стратегия»?
• 00:28:02 — Что сейчас происходит со стандартами разработки ПО (ISO-29119, IEEE-829, TMMI, ISTQB)?
• 00:37:02 — Как планировать оптимально и с пользой?
• 00:48:49 — Как можно планировать в мире аджайла?
• 00:51:04 — Как держать планы в актуальном состоянии?
• 00:58:02 — Приводит ли планирование к успеху, или это просто лишнее время?
• 01:04:42 — Как быстро «сколхозить» стратегию?
• 01:11:21 — Где брать примеры или Какие книги читать про это все?
• 01:17:15 — Тест-менеджмент в эпоху удаленки.
• 01:29:22 — Патроны в магазине.
• 01:31:11 — Фингальный конец.

Можно удалять их перед коммитом.

find -regex '.*\.\(tex~\|sty~\|sh~\|bib~\|backup\|dvi\|ps\)' -print -delete

Можно сказать Kile, что после закрытия надо удалять все «временные файлы». Но закрывать Kile каждый раз перед тем, как сделать коммит — как-то странно.

Можно добавить все такие файлы в .gitignore Но эти файлы так и лежат в каталоге проекта.

А можно компилировать проект, принудительно создавая всякие такие файлы в отдельном каталоге.

В итоге получится такое:

Project directory/
|__ main.tex
|__ main.bib
|__ main.pdf
|__ chapter1.tex
|__ chapter2.tex
|__ …
|__ project_metafiles/
| |__ main.aux
| |__ main.bcf
| |__ main.blg
| |__ main.glo
| |__ main.ist
| |__ main.log
| |__ main.toc
| |__ …
|__ figures/
|__ figure1.pdf
|__ …

Про это всё уже кто-то подумал аж в 2015-ом: texblog.org, но, разумеется, есть нюансы — там нет Kile.

Мои эксперименты с этим трактором заняли часов восемь, самой сложной задачей оказалась неочевидная настройка билд-скриптов в Kile, но он таки завёлся. Заодно я поднаторел в быстром составлении документации по проекту.

Смысл предлагаемого скрипта:

1. собрать pdf с PdfLaTeX.
2. собрать его библиографию с BibLaTeX.
3. итоговый скрипт должен лежать в отдельном каталоге, назовём его kile_scripts/
4. при сборке main.pdf все служебные файлы должны сразу появляться в project_metafiles/
5. сборка глоссария и индекса в этот скрипт не войдёт (она нужна редко и запускается через отдельный sh-файл)
6. билдить нужно по этому скрипту, но из Kile („QuickBuild“ по Ctrl+1)

Ограничения

Это настройка работает глобально, а название главного файла для сборки проекта прописано жёстко — main (.tex).

Если открыть в Kile другой проект, то скрипт будет искать файл main 🙂

Выходом будет прописывание переменной в файле .sh, а неудобство в том, что этот файл при каждой смене проекта надо обновить, прописав в объявляемой переменной соответствующее название файла для сборки (несколько смягчает ситуацию добавление и комментирование строк).

Полная инструкция в Dropbox: http://bit.ly/2IjoqC0 /txt

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

А нужно, чтобы «Любой желающий мог быстро прочесть и понять что это за проект, какой там функционал и как юзеры будут его тыркать» (форум).

Можно набросать вот такой документ:

1. Цель проекта

2. Функциональные возможности приложения

<Из каких частей состоит? Для чего они? Что можно сделать? Их зависимости….>

3. Особенности ролей пользователей

<Какие роли могут быть на проекте? Их права, обязанности,…>

4. Варианты использования

<Список основных сценариев использования приложения всеми ролями пользователей>

5. Зависимости проекта с другими системами

<Как будет использоваться? Специфика, интеграции,…>

Но это объёмная вещь. Это не читается быстро, и быстро не понимается. И написано, как всегда, казённым языком священного армейского устава.

Попробуйте кратко объяснить проект любому уличному бомжу.

Начнете в стиле «Мужик, смотри, это нужно для того, чтобы…«. Потом вы осознаете, что нужно контекст объяснять, а не реализацию, и перейдёте на «Чтобы выполнить такую-то задачу, мы используем такую-то шняжку…«

Потом в документах будете всегда писать грамотно и сразу всем всё будет понятно.

Бомжу опосля не забудьте проставиться, он ждёт вас.

Вся инструкция в txt http://bit.ly/2Er0x6o (Dropbox).

Внимание, даже в txt в ряде случаев происходит искажение символов в тексте — ординарные кавычки превращает в фигурные, а дефис превращается в подобие тире.

Презентабельности ради почти то же самое в pdf — http://bit.ly/2GIUSOX

Познакомиться с LaTeX исчерпывающе просто: достаточно установить Kile (редактор для LaTeX в среде KDE)

sudo aptitude install kile

При установке Kile принудительно потянет за собой зависимости, необходимые для базовой установки LaTeX. Например, будет установлен базовый пакет ‘texlive-latex-base’. Посмотреть информацию о нём:

sudo aptitude show texlive-latex-base

И это, конечно же, хорошо. Однако, как всегда, версия в репозиториях на порядок старее актуальной.

Current release ‘TeX Live 2017’ — от 4 June 2017.

А в репозиториях Debian доступен только LaTeX версии ‘2016.20170123-5‘.

Философия Debian не подталкивает к использованию «всего самого свежего», но речь идет о TeX, который в принципе остановился в развитии на версии 3.14, а обновляются только пакеты LaTeX, поэтому тут можно смело требовать «свежатинки».

Установка LaTeX из сети возможна, но процесс скачивания и установки трёх тысяч файлов долгий, и при сбоях связи слегка… раздражающ. И ещё говорят, что

…if TeXLive is installed via Debian’s own package manager (apt, synaptic, etc), TeXLive’s package manager (tlmgr) will not be available. This means that if a newer version of a package, or a package that is not in one of Debian’s own groups of LaTeX packages is required, it ends up being manually installed and that can make your system messy and hard to maintain.

This can be a big issue with Debian, since it has a very conservative view of what is a ‘stable’ package, and can easily be three years behind the main TeXLive repository.

Таки да, как-то довелось разбираться с установкой пакетов по-отдельности, и это было стрёмно.

Хочется просто поставить LaTeX самостоятельно и заставить Kile сразу работать с установленной программой, а не… Поэтому далее рассматривается несколько замороченная, но исключительно однозначная, точная и грамотная ручная установка всего набора LaTeX из его официального iso-файла  вкупе с неординарной, но смелой установкой Kile.

Место установки произвольное. Но по-умолчанию будет предложена установка в /usr/local/texlive/2017/.

Это разумно. Каталог с названием года выпуска — это фича, бо это позволяет установить сразу 100500 версий LaTeX рядом и переключаться между ними…

В /usr/ хранятся все установленные пакеты программ, документация, исходный код ядра и система X Window и да, к содержимому /usr/ все пользователи (кроме root) имеют доступ только «для чтения». А если система со своим /usr/ ещё и находится на SSD (solid-state drive, твердотéльный накопи́тель), а /home/ положено на HDD, то LaTeX, который и так работает быстро, будет работать еще быстрее нужного (о-ля-ля, куда уж быстрее-то?!).

Однако нет.

1

На моём ноуте только один юзер, и городить «общий доступ» нет резона. И вообще, сделаем установку portable LaTeX (то есть, эту шнягу можно установить даже на флэшку, my ass!).

2

В будущем всегда маячит переустановка системы. Если при этом не заморочиться бэкапом всего /usr/ (что вряд ли, если произойдёт большой и внезапный бэмц вроде «эсэсдэ помрэ»), то LaTeX придётся и ставить, и настраивать с нуля. Ы!

3

То же самое относится к установке программы в /opt/. Тоже, кагбэ, логичное для установки место, но оно тоже будет «обнулено» при вероятностной переустановке системы.

4

Для крупного обновления разумно сносить «устаревший» LaTeX и ставить новый «с нуля» (так гласит официальная инструкция, не будем ей перечить), и очевидно, что жить будет проще, товарищи, жить будет веселее, если новый софт будет установлен в тот же самый каталог с сохранением тех же путей в системных переменных. Поэтому не хочется устанавливать софт в каталог с названием типа /2017/ !

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

И местами — весьма серьёзно, в режиме «раз настроил и забыл», поэтому припоминать «что там менялось» через год-два будет очень, очень затруднительно.

Поэтому далее рассматривается только установка LaTeX в каталог ‘/home/LaTeX/‘.

Enjoy.

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

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

У тест-кейсов должны быть предусловия (‘pre-conditions’ по-вашему).

Во всех этих pre-condition для тест-кейсов уместно учитывать много всякого (и чем больше там будет учтено, тем лучше). Иногда в предусловиях полезно буквально процитировать требования, на основе которых тест-кейс был написан.

Цитировать требование в прекондишнах — это всяческий гуд, но, как всегда, есть сложности с реализацией…

Как это всё сделать?

1

Гиперссылка на требования

Да, но не менее 70% гиперссылок в любом документе неизбежно «дохнут» на протяжении полугода, а когда требования начинают переписывать, менять строки местами и нумерацию следом, то едрить вашу медь…

И очень сильно задалбывает постоянно куда-то переходить по ссылкам и в разбираться в обустройстве другого документа, ведь редкий документ в разгаре работы пишется

• внятно,
• грамотно,
• однозначно,
• красиво
• и понятно.

Увы.

2

Логическая отсылка на нумерацию требований. Не зря они всегда пронумерованы, как законы.

Да, логические отсылки вроде «Смотри Евангелие от Программиста 9.43» более долговечны, нежели гиперссылки, но они почти постоянно нуждаются и в сопутствующих гиперссылках, и в уточнении на предмет «не поменялось ли там что-нибудь».

В какой-то момент и они перестают помогать, и тогда автор кейса начинает громко и смачно икать, бо его постоянно проклинают.

3

Процитировать требование

Самое шикарное решение. Обычно хочется (да редко можется) просто увидеть прямо на экране тест-кейса тот текст, на который сделана отсылка. Логичное решение: буквально процитировать требование в прекондишне.

С другой стороны, полное цитирование требований в тест-кейсах недальновидно, бо когда тест-кейс перестает соответствовать действительности, например, из-за того, что требования поменялись, и его надо переписать, то там переписывать и переписывать… Тогда икается всем.

Шо делать?

От страха перед иканием большинство тестировщиков (97,12%) сильно тупят и не решаются ни на то, ни на сё. А если будут требования переписываться? А если нет? А если будут? А если нет? Аааа…

Ответ: бэээ! Требования иногда переписывают, но не так часто, как может показаться, поэтому отставить панику.

Нет, когда требования начинают переписывать, это действительно Содом и Геморрой, но это беда для всех сразу, а не только для тестировщиков.

Обычно после такой беды тест-кейсы начинают переписывать, через неделю всем понятно, что переписывать — с ума сойти, и что кейсы лучше не переписывать, а написать с нуля. Жалко, конечно, но разумнее.

Заодно тестировщики начинают лучше понимать бедных программистов.

Каждому кейсу свой жизненный срок, это нормально. К этому надо привыкнуть и перестать заморачиваться поиском идеального глобального решения. Надо просто написать понятные тест-кейсы и снабдить их указанием требования, на котором тест основан, а как это сделать — неважно. Можно по-всякому.

Предположим, что ответ «А мы проверяем то, что на сервер разрешено загружать только файлы с расширениями, разрешенными в параметре document-types«.

Сократим его, Сократ! Выбросим необязательное вступление, и  вот нам элегантный заголовок-утверждение «На сервер разрешено загружать только файлы срасширениями, разрешенными в параметре document-types«.

Почему заголовок выглядит как утверждение? А потому, что должно же в этом мире что-то быть однозначным.

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