Понравился текстовый редактор 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/

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

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

Вся инструкция в 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.

Если попасть молотом по башке врага — ты победил. Если промахнулся — иди учись…

Согласно pairwise.org , есть множество софтинок для этого дела, и от Microsoft (их несколько, не только PICT), и от NASA (уже недоступна, в космос улетела), от Motorola, от IBM, и др.

Некоторые эти программы работают через консоль, другие через GUI, третьи через одно место, и все они, в принципе, делают то же самое, что может сделать один нормальный инженер с карандашом и бумагой, но делают это очень быстро. Главное — подать им на вход грамотный набор данных.

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

Есть и онлайновые сервисы: hexawise, inductive, testcover — смотреть большой обзор, я ими не пользуюсь, предпочитаю консольную Allpairs (скачать бесплатно с джеймсобаховского сайта), бо привык к ней, и она не привязана к одной операционной системе.

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

Ведь не может же такого быть, чтобы кто-то занимался тестированием ПО, не понимая, как устроена файловая система, и как организованы файлы на жестком диске, и как управляться со всем этим добром из консоли.

Затем нужно уметь составлять таблицу данных, которая будет обработана Allpairs. В Excel (или в Calc) нужно сделать таблицу с перечислением сущностей и их параметров, затем экспортировать эту таблицу в текстовый файл с разделением столбцов через «TAB». Затем скормить этот текстовый файл Allpairs на обработку.

Непосредственно Allpairs привык использовать так: в каталоге с программой allpairs.exe создаю подкаталог (‘Test’), в который сохраняю текстовые файлы (с таблицами из Excel). В этом же подкаталоге появится и файл с результатами работы allpairs.exe.

Перехожу в этот подкаталог (‘Test’), и уже из него обращаюсь к allpairs.exe, которая находится на одном уровне выше.

Указываю в этом вызове файл, который надо обработать (назвал его input.txt) и приказываю вывести результат работы в файл, который на диске еще не существует (назвал его output.txt).

В Unix алгоритм работы (методология) тот же, но

1. перед вызовом программы обязательно нужно указать ‘perl’,
2. в самом названии программы указывать расширение ‘.exe’ уже нет необходимости,
3. слэши другие.

Нюансы под макой и убунтой (вот, казалось бы): таки надо внятно указать обращение к файлу allpairs.pl:

perl ../allpairs.pl input.txt > output.txt

но по причине скудности эфирного времени не успел.

Вместо картинок слайдов использую заголовки.

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

Для прояснения антуража уточняю, что я — тестировщик из Кишинева.

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

Да, еще тут умеют класть плитку кубометрами и пить вино декалитрами, но это не является особенным достижением местного айтишного народа.

Например, я сейчас работаю над интернет-магазином, которым пользуются только жители США — и оплата и доставка заточены именно под их регион.

У нас нет огромных компаний, как это бывает в Москве или Киеве, в которых можно прожить всю свою карьерную и биологическую жизнь.

Обычный кишиневский айтишник большую часть жизни:

1. мечтает стать программистом,
2. проводит время в маленьких компаниях,
3. поддерживает зарубежные долгосрочные проекты,
4. работает в окружении малочисленного коллектива, большую часть которого составляют вечно приходящие и уходящие «студенты».

Затем обычный кишиневский айтишник как следует учит Java, английский вперемешку с французским и навсегда уезжает в Канаду.

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

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

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

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

В общем, понятно, почему стать тестировщиков в Кишиневе весьма просто.

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

Сложнее опытным тестировщикам, а также тест-менеджерам — тут рынок более узкий, ибо это дело ответственное, а потому сразу дорогое.

Главный вопрос: Кто ты? QC дрожащее, или QA?

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

Был такой случай: меня назначили начальником отдела тестирования.

Круто.

Плохо то, что в компании бытовали технические проблемы, и надо было многое менять. Например, обучить программистов работать с svn (и это совсем не смешно).

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

Работаем мы, спорим, доказываем, что-то решаем, но вот по итогам решения всё принимаются «не те»…

Позже, случайно во внутренней wiki я увидел список участников этой группы, и меня там не было. Я пошел спрашивать. Мне ответили, что «тебя изначально и не думали туда включать, ты же просто тестировщик… Иди, сиди, тестируй…»

Резюме: когда думаешь о том, как «поставить» тестирование, надо сперва понять, действительно ли у тебя есть возможность что-то менять, или же твоя роль номинальна. Выяснять это надо рано и быстро, во время испытательного периода.

Каждая маленькая компания когда-то вырастет

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

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

Начинаются проблемы с уверенностью в результатах работы (действительно ли всё протестировано?).

В том числе и проблемы со временем — народ искренне не понимает, почему тестирование занимает так много времени.

В будущем пришедший тестировщик будет не работать, а «расхлебывать» то, что ему досталось.

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

Когда начинаете работать, думайте о тех, кто придут после вас, и делайте все красиво и чисто :).

Как обустраивать тестирование — никто не подскажет

Большая проблема тестировщика в маленькой компании — одиночество. Прекрасно, что не с кем меряться, но и не с кем советоваться.

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

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

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

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

Позже возникает необходимость в документации, а документировать то, что УЖЕ существует — то еще удовольствие…

Также если нет под рукой опытного работника, «студенты» организуются самостоятельно, по уму и разуму, как удобно.

Удобно ли пользоваться svn, если ты тут единственный программист, и весь код находится только на твоей машине и в твоих руках? Нет, неудобно.

Удобно ли ставить баг-трекер, если ты сам заведуешь всеми багами, и проект, в принципе, небольшой? Нет, неудобно. Да и что такое — баг-трекер?

Нужно ли ставить wiki и записывать туда то, что само по себе очевидно и понятно, и никому не требуется, а если потребуется — подойди, я все детально расскажу? Нет, не нужно ставить wiki.

К чему это приводит в итоге? Понятно, да…

Если не понятно, то вот вам коллектив, в котором все по-отдельности уверены в том, что svn, баг-трекеры и wiki излишни, совершенно не нужны и неудобны.

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

Еще надо учесть то, что «принять ответственность» означает «стать командиром». Обустраивание тестирования в какой-то момент приведет к необходимости как-то подправить и процесс разработки. А там будут нужны и баг-трекер, и wiki, и svn, и воля на то, чтобы давить «бунт на корабле»…

Тестировщик должен медленно «подсадить» народ на свои инструменты, отчеты и документы

Грамотный тестировщик приходит в компанию со своими инструментами.

Баг-трекер, вики, svn – это основные.

Можно также приносить свои кресло и наушники — я так делаю.

Они могут уже быть, но нужно выяснить, пользуются ли ими.

У меня были случаи, когда я спрашивал, есть ли svn в компании, но забывал спросить, пользуются ли им кто-нибудь. Реальные случаи: есть svn, но пользуются им только менеджеры, и то — для сохранения своих ворд-файликов с названиями типа «требования к системе, ver. 152.0». Программисты про svn знают, но не используют. А нафига оно нужно?

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

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

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

Понятно, что большая часть инструментов будут из open-source – слава пингвинам, сегодняшний open-source уже хорош, особенно если у тебя самого руки растут из плеч, и ты можешь его под себя «подтесывать».

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

Шучу.

Убунту рулит.

Срок «подсаживания» – полгода. Это ориентировочный срок. Упоминаю его для того, чтобы еще раз подчеркнуть — подсаживание надо делать мягко. Резкий переход вызовет только отторжение.

Тестировщик не должен резко ломать существующий порядок работы

Китайское предупреждение человечеству:

«Мягко ступающий продвинется далеко».

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

По ночам ему будет сильно икаться. Будет проблема с пониманием: «Пришел невесть откуда, и чего-то хочет…»

По-молодости и неопытности я как-то начинал требовать от разработчиков и от менеджеров изменений в процессе разработки. У меня был большой и обоснованный список требований с доводами 🙂

И всё разбилось об один, но веский довод: «Мы так уже давно работаем, все идет хорошо, иди и не задалбывай».

Я ушел и понял, что они правы.

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

Процессы, которые сложились, обрели определенные черты и характеристики не сразу. Что-то резко менять — чревато и просто опасно. Да и странно, когда «какой-то» тестировщик внезапно требует от всех пользоваться svn и приступить к написанию юнит-тестов.

Да к тому же, не может толком объяснить, что и как надо делать:

— Ладно, будем писать юнит-тесты. А как это делать?

— А я знаю? Это же ваша зона ответственности.

— Ррррыыыы!

В компании, в которой я сейчас работаю, я начал делать изменения мягко. Я не стал говорить, что «мне не нравится то и это, плохо то и сё, никуда не годится так и эдак».

Я сказал, что всё отлично.

Только, сказал я, давайте-ка я поставлю сам себе на наш сервер шняжку, под названием ‘Mantis’ — я сам себе ее поставлю, сам себе ее настрою, вам это вообще ни к чему. Вики в компании есть, репозиторий кода есть, ну и отлично, а вот лично мне не хватает одной мелкой штучки.

Поставил и настроил.

И все баги записывал только в Mantis.

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

И каждый раз, когда я сообщал кому-нибудь о баге, я давал ссылку на Mantis.

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

Мы его под свои нужды поднастроили — вообще улёт.

Разумеется, баг-трекер — только один аспект всей картинки.

Тестировщик не должен полностью «проседать» под быт программистов

Дело в том, что если мягко ступать, боясь потревожить что-либо, шагая по болоту, то можно вообще не дойти.

Идти все-таки надо.

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

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

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

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

И вообще, тестировщик должен подстраиваться под быт программистов, должен сидеть рядом с программистами, и пить с ними одно пиво. Быть отдельной единицей, которая «только проверяет» — неразумно и недальновидно.

Никто не хочет возиться с бумагописанием, и это нормально

Требования, отчеты, описание изменений, планирование релизов и багфиксов — это круто, или это необходимо?

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

Но без основательной бюрократии процесс роста компании будет невозможен. Если не писать требования (хоть какие-нибудь), если не работать над их постоянным обновлением и отслеживанием изменений, то чуть позже, может быть, уже через год, появятся вопросы типа «Что это софт делает, и почему именно так? А кто написал этот идиотский код, гыгы? Стоп, неужели это мой код?»

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

Требований не будет

Вообще, о требованиях можно сказать очень просто — требований не будет.

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

Тестировщик должен сам заняться написанием документации. Это вызов. Это сложно. Это перспективно. Но сразу доверять это дело нам никто не будет. Это дело надо перетягивать на себя, как одеяло ночью с жены.

Как это сделать:

1. надо беседовать с программистами. Задачи приходят от менеджеров, но изменения, которые происходят в ходе переписывания абстрактных требований в рабочий код, лучше всего выяснять у программиста, который эти требования только что воплотил. Это пульс, это настоящий источник знаний.
2. любая информация, которая попадает к тестировщику, должна быть где-то и как-то записана. В любых формулировках и в любом виде. Секрет в том, что если ты напишешь требования в виде хотя бы одной строчки, то потом эту строчку можно будет дописать и доуточнять до размера большого документа. Если же пытаешься сразу написать большой документ, с разделами, титулами и колонтитулами, то вероятнее всего, получится какая-то фигня, с которой никто не захочет возиться.
3. всем обычным людям проще что-то уточнить и подправить, чем писать с нуля на голом экране. Поэтому, вместо того, чтобы требовать у программиста «Напиши для меня в вики список ситуаций, при срабатывании которых генерируется отправка емайла с уведомлением!», надо самому подумать и записать хотя бы пару таких мест, а затем подойти к программисту с вопросом «Я вот тут записал несколько ситуаций, при которых происходит отправка емайла юзеру, но не знаю, полный ли это список. Не затруднит ли тебя глянуть и сказать, все ли там учтено». Спорю на $100 (принимаю наличными), что «не затруднит», и список он дополнит. Ибо кому еще знать про обсуждаемую тему, как не программисту?
4. создать свой Disaster Recovery Plan.

«Disaster Recovery Plan»

Про эту штуку мне рассказал начальник группы системного администрирования компании Moldcell – frumich.

Обычно такой документ создают сисадмины.

Смысл ‘Disaster Recovery Plan’ в том, чтобы собрать (очень тщательно и детально), записать (еще тщательнее и детальнее) и сделать доступной для всех инструкцию действий в случае катастрофы.

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

На написание, тестирование и принятие такого документа у frumich’a ушел не один год. Но когда получилось! Собрал он в одну кучу и инструкции, и описания всех железок на предприятии, и фотографии всех мест, где эти железки находятся, и ежедневную автоматическую проверку наличия определенного железа на рабочих местах наладил — полный план, хоть ложись и умирай, народ подхватит твое знамя и резво двинется дальше 🙂

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

Надо написать собственный ‘Disaster Recovery Plan’. Или его точное подобие.

Дело даже не в том, что мы внезапно смертны. И не в том, что «после себя надо оставлять подробное описание». И не в том, что из маленькой компании всегда все уходят.

Просто при работе с любой документацией (своей или чужой) следует воспринимать её как часть чего-то большого, и соответственно её обрабатывать.

После того, как я стал воспринимать каждый тест-план и каждый тест-кейс как часть большого ‘Disaster Recovery’ плана, мне стало очень ясно и понятно, куда какой кирпичик информации надо положить, и главное — зачем его надо туда класть.

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

Основная проблема при создании документации — найти грань между действительно нужной информацией и «всем прочим». Изначально ведь кажется, что нужно сохранить абсолютно всё, но это не так.

Возможный ориентир: если что-то тебе лично требуется в работе два раза — есть повод подумать о том, чтобы это куда-то как-то записать.

А если это нужно кому-нибудь еще больше одного раза — непременно надо записывать.

Сила любой системы — в накоплении и структурировании информации и запасов

В Полинезии живут папуасы.

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

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

Получается, что сила — в самостоятельности и личностных умениях выживать?

Вроде бы, да.

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

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

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

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

Основная проблема внедрения всех этих средств накопления информации кроется в основном отличии маленькой компании от большой — формализация взаимодействий.

В маленькой компании все живут одной семьей (что вредит бизнесу, ну да ладно), дружно и весело. В большой компании нет семьи — есть стая волков, есть место для многолетних интриг и политических течений. Зная, что со временем маленькая компания превратится в что-то большое, можно почти точно предположить, какие проблемы при переходе в новое состояние придется решать.

Например:

• проблемы с отчетностью о работе.
• проблемы с фиксацией и передачей знаний.
• проблемы с разделением задач и зон ответственности.

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

Чем раньше поставишь эту работу на определенные рельсы, тем лучше. Надо обладать несомненным авторитетом и правом что-либо и кого-либо ставить на рельсы.

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

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

Знать путь и пройти его — это две большие разницы

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

Всю работу по проекту надо воспринимать сквозь призму дальних целей роста компании.

Просто представь себе, что вы в будущем именно ты будешь главой отдела тестирования с филиалами в Киеве, Лондоне и на Лиговке — вот и готовь себе почву.

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

Важный момент — надо вообразить себя не владельцем компании, которую ты обслуживаешь, а владельцем собственной компании.

Тестировщик легко может вообразить себя аналитиком, человеком, который думает о всей системе сразу. Может быть, аналитик — следующий этап развития тестировщика?

Тестировщик может и должен взять на себя всю работу по подготовке документации — как аналитик.

Если относишься к тестированию как аналитик, то документация в итоге появится, словно сама по себе.

Даже более того, тестировщик может стать источником информации для всех участников проекта. Если именно он будет ее постоянно собирать и структурировать, то все привыкнут к тому, что «она сама по себе появляется в вики, вот сегодня к семи часам появится описание того, о чем мы вчера говорили…» Это идеал.

Роль аналитика в маленькой компании, как правило, не занята никем. Бери и пользуйся.

Вообще, в маленькой компании можно работать кем угодно — можно стать аналитиком, просто этого захотев, и приступив к выполнению этой работы. Ее же кто-то должен делать?

Нередко тестировщиков СПРАВЕДЛИВО воспринимают как «трату денег»

Причем трату, которая «нужно в принципе», то есть, непонятно зачем. Так, мол, полагается.

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

Из-за этого очень разумного с житейской точки зрения суждения тестировщики в маленьких компаниях почти всегда появляются на поздних этапах развития и разработки, когда уже все написано, но (что было предсказуемо) работает не совсем так беспроблемно, как хотелось бы, и тогда народ принимает решение о том, чтобы пригласить тестировщика, который «найдёт все баги на проекте».

Когда это выражение относится непосредственно к тебе — становится несмешно.

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

Сам не сможешь — кооперируйся с мелким менеджментом, а затем с высшим.

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

Теперь важный вопрос: как осуществить все вышесказанное? Как копить информационные ценности?

Ничего не забывать, всё записывать

Без пощады к себе.

Без «это само собой подразумевается, и все об этом знают».

Без «это слишком долго расписывать».

Одна строчка документации потянет за собой всё остальное…

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

Я для себя решил эту проблему посредством сбора всего в одном текстовом файле в EditPlus, когда работаю в Windows — в этой софтинке можно сдвигать абзацы разных уровней вложенности. Быстрое «свертывание» помогает ориентироваться по разделам, почти как в вики. При работе в Ubuntu адекватного аналога свертывания разных уровней я не нашел, поэтому пользуюсь обычным GEdit.

Все-таки, быстрое сохранение мелких текстовых данных в вики происходит медленнее, нежели в блокнот.

Задачи, которые следует выполнить позже, я сохраняю в rememberthemilk.com

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

А RTM позволяет выносить список задач на экран GMail и GCalendar, и я постоянно вижу задачи. Также к ним можно обращаться с мобильного телефона, что опять же, важно для «записал и забыл», в любом месте и в любом окружении.

В GCalendar надо записывать события, для которых мне потребуется напоминание. Сервис важен тем, что напоминания о событиях приходят с него ко мне в виде sms на мобильный телефон. А также ежедневно письмо с перечнем событий на сегодня.

Еще раз повторю — надо пользоваться «своими» инструментами, что в офисе, что вне офиса. Свой календарь, своя почта, свое кресло, свои часы…

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

Да и — я еще не знаю, как однозначно решить эту проблему.

Спасибо.

.

Обсуждение доклада

.

Александр Александров, эксперт учебного центра Luxoft по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов.

Несколько комментариев.

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

То, что вы сделали, существенно больше той области, которую вы обозначили.

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

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

Вот наш с Мишей (Михаил Павлов) опыт: когда мы пришли в компанию Auriga в начале 2006 года — нас встретили очень жестко. Ногами не били, но все остальное было. Через какое-то время начали уважать, но огрызаться: «Вам надо, вы и делайте». Эти слова нам говорили до августа 2007 года, когда компания получила сертификат CMMI 4-го уровня.

В начале 2008 года, когда я из компании уже ушел, должны были приехать крупные заказчики, которые интересовались процессами. Миша там еще работал, он пригласил меня, и я с большим удовольствием автору слов «Вам надо, вы и делайте» эти слова вернул при достаточно большом сборище. Жесткость, а иногда бескомпромиссность — это качество, которое вытекает из первого вашего тезиса, и противоречит третьему и четвертому тезисам, — я призываю всех присутствующих им пользоваться умело, и не сомневаться в том, что если нужно совершить какое-то воздействие — то нужно это воздействие совершить.

(аплодисменты)

Да мне аплодировать не надо…

Алексей Лупан:

Да, спасибо.

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

Но если в принципе подходить к изменениям сразу жёстко, то молодой тестировщик обязательно столкнется с противостоянием, и никто не знает, чем это закончится.

Скорее всего, возмутителя спокойствия выпилят, особенно если он один.

Юля Нечаева, мама и омега тестирования в компании Innova Systems (Москва)

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

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

Как ты это противоречие решил для себя?

Алексей Лупан:

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

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

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

Александр Александров:

Это надо сделать во-первых, а во-вторых, после того, как все закончилось, надо придти к начальнику еще раз и сказать любимую фразу капитана Зеленого из мультфильма «Тайна третьей планеты»: «Я так и знал!»

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

Юля Нечаева:

Если компания после десятого раза выживет.

Алексей Лупан:

Выживет. Существует много софта, который работает не так, как надо, но он есть и компании продолжают работать.

Вопрос (Симферополь):

Маленькая компания — это по-вашему сколько?

Алексей Лупан:

До 30-ти человек. Но дело не в объемах, а в менталитете и психологии.

Вопрос:

Хотелось пару слов сказать о роли тестировщиков.

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

Алексей Лупан:

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

Эвелина Тананаева (Минск):

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

Алексей Лупан:

Иногда действительно лучше не менять, но вопросы об этом важно задавать. Просто задать открытый вопрос, не предполагая заранее, что именно и как тебе ответят. Если не спросишь, то и не ответят. Например, на многие тренинги попадаю со скидкой просто потому, что я спрашиваю об этом.

Вопрос:

Практический вопрос: при изменении процесса все равно находится какой-нибудь непробивной человек, который упрётся и скажет, что «я 20 лет работал и буду так дальше работать, мне всего полгода до пенсии осталось…» Как вы таких пробивали?

Алексей Лупан:

А никак.

Я таких не пробивал, мы их мягко обходили, и все было хорошо.

Человек, который действительно знает что-либо, потенциально полезен, и не должен слышать «Мы будем делать иначе, ибо вы не знаете или просто не хотите».

Мы все хотим взять деньги и пойти домой, и для опытных в нашей норе всегда есть место. Просто все остальные побегут на охоту, а он будет почетным наблюдателем от ОБСЕ за тем, как и куда мы бегаем.

• JRE — Java SE Runtime Environment — это «настольное» JAVA-окружение, которое нужно для просмотра java-контента в браузере.
• JDK — Java Development Pack — это и JAVA, которая нужна для браузеров, и утилиты, которые нужны для JAVA-разработки.
• То и другое лежит на официальном сайте JAVA.

Windows

Внимание, потребуется полная перезагрузка компьютера.

В момент написания заметки на компутер была установлена jdk1.5.0_14 в следующий каталог: c:\Java\jdk1.5.0_14

Опытными рекомендуется не ставить жаву в каталоги, в имени которых есть пробелы. То есть, c:\Program Files\ лучше не использовать.

В быту никаких отклонений от установки Java в c:\Program Files\ не наблюдалось.

Предполагается, что после перезагрузки Windows будет «знать», где у нее лежит JAVA. Но в этом следует убедиться «руками», забравшись в «System Properties» (нажатием клавиш «Win+Pause/Break»):

1. System Properties > Advanced > Environment Variables > System Variables > JAVA_HOME

   Требуемые значения

   1. Variable name: JAVA_HOME
   2. Variable value: c:\Java\jdk1.5.0_14
2. System Properties > Advanced > Environment Variables > System Variables > path

   Требуемые значения

   1. Variable name: Path
   2. Variable value: C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Subversion\bin;D:\mvn\apache-maven-2.0.9\bin;c:\Java\jdk1.5.0_14\bin

Это кажется довольно сложным для глаза буквосочетанием, но принципиально эта последовательность символов не имеет особого значения кроме того, что выделено красным. Оно как раз и появляется в этом списке после установки JAVA.

В общем, теперь Windows знает, где у нее лежит JAVA: c:\Java\jdk1.5.0_14\bin

Обратим пристальное внимание на ‘\bin‘ в свойствах переменной Path — путь должен быть записан именно так — каталог «bin», но без закрывающего слэша.

Редкий мазафак

Может так случиться, что (в консоли) java -version говорит, что все ок, а javac -version отвечает 'javac' is not recognized as an internal or external command, operable program or batch file

Это решаемо.

Execute ‘c:\java\jdk1.5.0_14\bin\javac -version to make sure that javac is available.

Then do:

set path="%path%;c:\java\jdk1.5.0_14\bin"

You can also tell which executable (if any) is being used with the command:

for %i in (javac.exe) do @echo %~$PATH:i

This is a neat trick similar to the which and/or whence commands in some UNIX-type operating systems.

Debian

Тут вся Java установлена по-умолчанию. Но есть бэмц: в силу исторических событий там устанавливается усечённая Java (openJDK), которая не подходит для работы некоторых приложений. Поэтому может возникнуть необходимость снести всё и поставить «свою» джаву.

Есть возможность установить две джавы одновременно и переключаться между ними.

Осторожно, если самая свежая Java будет использоваться в коммерческой разработке — Не попадитесь в ловушку используя Oracle JDK 11 — ситуация меняется, но вас пердупердили. Есть смысл остаться на openJDK.

Однако, если джавы нет, и она просто нужна, то:

Смотрим доступные на данный момент версии в соответствующем операционной системе репозитории:

aptitude search openjdk

Ок, узнал, сегодня в моде openjdk-11-jre.

aptitude install openjdk-11-jre && java -version

Если ничего экстраординарного не произошло, то на этом всё.

= 1 =

You will need to know whether you are running a 32 bit or a 64 bit OS:

uname -m

Ответ:

i686: 32 bit kernel

или x86_64: 64 bit kernel

= 2 =

aptitude search ~i~D{sun-java,openjdk}

Пример результата команды — перечень того, что установлено:

i A ca-certificates-java    — общие CA-сертификаты (хранилище JKS)

i A default-jre            — Standard Java or Java compatible Runtime

i A default-jre-headless    — Standard Java or Java compatible Runtime (headless)

i A openjdk-7-jre        — OpenJDK Java — окружение времени исполнения с использованием JIT-компилятора

Или пустота, если java нет.

= 3 =

Вычистить систему от OpenJDK (Эта команда удалит всё, что имеет отношение ко всем версиям OpenJDK.):

sudo apt purge openjdk*

Внимательно читать предупреждение о том, что будет удалено. Например, у меня в список удаления попал Xmind, который без openjdk-7-jre и openjdk-7-jre-headless работать не может.

Есть смысл также сделать

sudo apt autoremove

= 4 =

http://www.oracle.com/technetwork/java/javase/downloads/index.html — скачать JDK (development)

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

Формат скачиваемого файла — разный: tar.gz, deb, rpm…

Установка deb типична: sudo dpkg -i jdk-12.0.1_linux-x64_bin.deb

Дальше рассматриваем установку tar.gz, она чуть заморочена, но позволяет контролировать место установки и ряд нюансов.

= 5 =

Installing Oracle JDK in the /opt folder (with sudo privileges): the /opt directory is reserved for all the software and add-on packages that are not part of the default installation.

Create a directory for your JDK installation:

mkdir /opt/Java/

and extract java into the /opt/jdk directory:

tar -zxf jdk-8u112-linux-i586.tar.gz -C /opt/Java/
ls /opt/Java/

= 6 =

Setting Oracle JDK as the default JVM. In our case, the java executable is located under ‘/opt/Java/jdk1.8.0_112/bin/java’. To set it as the default JVM in your machine run:

update-alternatives --install /usr/bin/java java /opt/Java/jdk1.8.0_112/bin/java 100

and

update-alternatives --install /usr/bin/javac javac /opt/Java/jdk1.8.0_112/bin/javac 100

= 7 =

Verify that java has been successfully configured by running:

update-alternatives --display java

and

update-alternatives --display javac

The output should look like this:

java - auto mode
 link currently points to /opt/Java/jdk1.8.0_112/bin/java
 /opt/Java/jdk1.8.0_112/bin/java - priority 100
 Current 'best' version is '/opt/Java/jdk1.8.0_112/bin/java'.

= 8 =

Определение места JAVA для глобальных переменных (понадобится перелогиниться)

Последовательно выполнить в терминале две команды (результат их выполнения «молчаливый»):

export JAVA_HOME=/opt/Java/jdk1.8.0_112/bin/java
export PATH=/opt/Java/jdk1.8.0_112/bin:$PATH

Для проверки последовательно выполнить в терминале:

echo $JAVA_HOME
echo $PATH
which java
java -version

и внимательно читать, если все указано правильно.

= 9 =

(Optional) To update Java, simply download an updated version from Oracle’s website and extract it under the /opt/jdk directory, then set it up as the default JVM with a higher priority number (in this case 110):

update-alternatives --install /usr/bin/java java /opt/Java/jdk.new.version/bin/java 110
update-alternatives --install /usr/bin/javac javac /opt/Java/jdk.new.version/bin/javac 110

You can keep the old version or delete it:

update-alternatives --remove java /opt/Java/jdk.old.version/bin/java
update-alternatives --remove javac /opt/Java/jdk.old.version/bin/javac

rm -rf /opt/Java/jdk.old.version

Как удалить Java

Просто удалить /opt/Java/

Если после этого будет установлена другая версия java, и в echo $PATH будут отображаться два пути к исполняемым файлам, то:

1. echo $PATH
2. copy details into a text editor
3. remove unwanted entries
4. PATH= # pass here your edited list of entries

Windows

• DeskPin — прикрепляет любое окно «поверх всех«. Окно помечено иконкой-«иголкой». Дефолтный хоткей — Ctrl+F12.
• EditPlus — самая майндмапперская софтина из всех текстовых редакторов. Рулезнее, нежели AkelPad (а рулезнее AkelPad нет ничего).
• Console2 — open-source — Windows console window enhancement. Multiple tabs, text editor-like text selection. Не требует установки.
• Hot-keyboard — смертельно удобный, многофункциональный менеджер «горячих клавиш» всея винды. Спокойно перекрывает дефолтные хоткеи Windows, позволяет волшебничать напропалую. Например, при нажатии Ctrl+Shift+Ins у меня в текстовом поле в окне (в заголовке которого — обязательное условие — присутствуют символы «Mozilla Firefox«) вставляется вот такой текст:

h3.

#

##

###

h4. Expected result

h4. Actual result

Осталось только заполнять пункты.

Если надо разрешить вставку этого текста в несколько разных приложений, то ключевые слова следует разделять точкой с запятой: «Mozilla Firefox;EditPlus«

• VirtualWin — весьма, весьма грамотная утилита для работы с виртуальными столами. Плюсы — можно сполна управлять ею аккордами клавиш, коих очень много. Работает адекватно с окнами скайпа. Даже — можно перетаскивать окна между столами.
• Launchy— free cross-platform utility designed to help you forget about your start menu, the icons on your desktop, and even your file manager. Launchy indexes the programs in your start menu and can launch your documents, project files, folders, and bookmarks with just a few keystrokes.
• …

Debian

apt-get install …

• Parcellite — маленький менеджер буфера обмена.
• ChmSee — для просмотра .chm. Поддерживает русский язык, легко меняет размер шрифтов. Еще есть Gnochm, kchmviewer и Okular (для KDE), и xCHM — просмоторщик chm файлов не зависящий от оконного менеджера. Существуют Add-On для FireFox, которые способны читать CHM, и даже создавать, но это не то.
• Skype Call Recorder — сидит в трее и (зависит от настроек) при начале созвона спрашивает, хочу ли я этот разговор записать. Пишет в MP3, Ogg Vorbis или WAV, автоматически именуя создаваемые файлы. Макс. битрейт — 160 kbps.

WEB

• /rememberthemilk.com/ — список дел. Интегрируется с Gmail и Gcalendar.

Разное

Как отсортировать строки в Kate:

• Настроить Kate > Модули > «Текстовый фильтр»
• Выделить строки, которые надо отсортировать
• Сервис > Текстовый фильтр > написать команду ‘Sort’ (вызов команды sort — sort lines of text files, она уже установлена в системе) > [OK]

Будет пополняться решениями проблем по мере их возникновения.

В установленном по-умолчанию О_о постоянно встречается проблема:

1. выделяем текст,
2. применяем к нему какой-то цвет,
3. и видим фигу — цвет текста не меняется. Но О_о честно врет, что все в порядке, цвет к выделенному тексту применен…

Решение проблемы: надо снять галочку по адресу Tools > Options > OpenOffice.org > Accessibility > Options for high contrast appearance > Use automatic font color for screen display.

По-русски: Сервис > Параметры > OpenOffice.org > Специальные возможности > Параметры контрастного режима > Автоматически подбирать цвет для отображения текста

В Writer есть особенность, знакомая опытным пользователям MS Excel — автозавершение слов по мере набора. То есть, если в документе уже есть слово «Имматериализация», то при повторном наборе этого сочетания символов в другой ячейке программа сделает так: «Имматериализация«, и при нажатии [Enter] это слово будет полностью вписано в ячейку. Удобно, да.

О_о успешно делает это и в Calc, и в Writer, но поначалу бывает непонятно, какие клавиши отвечают за это автозаполнение и можно ли эти клавиши переназначить. Например, завершать автозаполнение клавишей [Tab], а не [Enter].

Решение проблемы: надо пройти по адресу Tools > AutoCorrect > Word Completition > Accept with > выбрать удобную клавишу.

По-русски: Сервис > Автозамена > Дополнение слов > Принимать автозамену при нажатии

Полезно оставить галочку для При закрытии документа сохранять список…

Список регулярных выражений в О_о

Полный список (таблица).

Следует учесть: О_о обрабатывает строки поодиночке. То есть, замену делает только внутри одно строки. Увы.

MS Word в этом смысле рулит необычайно.

Управление списками и отступами с клавиатуры

Увеличить отступ от левого края

Customize > Keyboard > Shortcut Keys > Alt+Shift+N > Category = Format > Function = Increase Indent > Modify.

Уменьшить отступ от левого края

Customize > Keyboard > Shortcut Keys > Alt+Shift+M > Category = Format > Function = Decrease Indent.

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

Customize > Keyboard > Shortcut Keys > Alt+Shift+K > Category = Numbering > Function = Numbering On/Off > Modify.

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

Customize > Keyboard > Shortcut Keys > Alt+Shift+L > Category = Numbering > Function = Bullets On/Off > Modify.

Как разделить текст на две (и более) колонки

Применить ко всему документу: Формат > Страница > Колонки.

Результат: плохо. Вообще весь документ уложен в две колонки, и текст, и заголовки. А заголовки надо ставить по центру печатного листа.

Надо подойти к делу через разметку отдельных разделов в документе:

1. Выделить текст, который необходимо уместить в две колонки и поместить его в отдельный раздел: Вставка > Раздел (здесь его можно проименовать) > Колонки.
2. Настроить нужное разделение текста на колонки.

При вызове «Навигатора» (F5) можно проследить добавленные разделы. Внимание, они могут наслаиваться друг на друга (дочерняя структура).

Как убрать отступы в нумерации

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

1. Выделить весь сектор списка, к которому нужно применить изменения.
2. Формат > Маркеры и нумерация > Положение.
3. В поле «Начало отступа» установить значение «0,10 см».

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

1. в поле «Выравнивание» установить значение «0,00 см»,
2. для поля «После нумерации» выбрать значение «Ничего».

Если покажется, что «всё поломалось», то на владке «Положение» есть кнопка «Стандарт».

Приводится пример понятия «Кристаллизация» — речь идет об эффекте увеличенной производительности, который присущ наиболее работоспособным командам разработчиков.

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

Местные примеры: «IQ labs» в васильковскую эпоху. Или газета «Вечерний Кишинев» в исаевскую эпоху.

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

Как только начинается кристаллизация команды, вероятность успеха очень резко возрастает. Управлять этой стихией — одно удовольствие. Управление в традиционном смысле этого слова им не нужно, и уж точно не нужны дополнительные стимулы. Они уже обладают собственным импульсом.

Кристаллизацию команды обычно сопровождает сильное чувство индивидуальности.

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

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

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

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

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

Удивительное заключалось не в том, насколько хороша была Чёрная Команда на заре своего существования, а в том, насколько она улучшилась за последующий год. Происходило что-то волшебное: в команде началось формирование индивидуальности. Эта индивидуальность находилась под влиянием оппозиционной философии тестирования, созданной участниками группы. Философия гласила, что они должны желать и ожидать недостатков в программах.

Они вовсе даже не болели за разработчиков, но напротив находили наслаждение в том, чтобы подвергнуть программу (и программиста) испытаниям, которые были бы не просто тестом. Когда программист приносил программу на тестирование в Чёрную Команду, он чувствовал себя, как на аудиенции у Мина Беспощадного (персонаж комиксов, воплощение чистого зла).

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

Чтобы усилить неприятный образ, участники команды начали носить чёрное (отсюда и название «Чёрная Команда»). Они взяли в привычку страшно фыркать, когда программа давала сбой. Некоторые отращивали длинные усы, которые крутили, подражая Саймону Легри (страшный работорговец из романа «Хижина дяди Тома»).

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

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

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

Проблема:

На PC1 в Krusader есть протокол sftp.

А на РС2 в Krusader доступен один только ftp протокол.

Так жить сложно. Чтобы открыть любой pdf на «просмотрение», нужно копировать его на РС2. А если постоянно перекидывать файлы с РС1 на РС2, то легко запутаться, где что лежит. А уж если в файле были сделаны какие-то изменения…

Не проблема через ssh коннектиться в консоли, но оттуда запустишь разве что MC, который нам друг, но который не любит длинные имена файлов.

Рецепт (искал почему-то долго, дольше пяти минут): в убунту нужно установить кдешные библиотеки для поддержки самбы и sftp в Krusader:

sudo apt-get install kdebase-kio-plugin

sudo apt-get install kdepim-kio-plugins

Enjoy.