«И я бы сказал, что куда бы вы ни пошли, вам стоит знать Postman…» © оригинал

Нет.

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

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

У нас в конторе на днях произошёл резкий и однозначный переход на Bruno, потому что подписка на корпоративное окружение в Postman уже начало стоить каких-то заметных денег. Если бы мы все были жёстко присевшими на Postman, держали бы там разветвлённую сеть из запросов и покрыли бы их всех тестами на внутреннем фреймворке Postman, и массово запускали бы всё это при каждом релизе, то отказ от Postman был бы «ОЙ БЛЭТ!». А так — ну, не стало Postman, а файлы с коллекцией запросов остались, и дальше делаем то же самое, просто уже в Bruno.

Через какое-то время рынок снова поменяется, и у тех, кто только начинает, начнутся страдания о том, что же учить — или Postman, или Bruno, tertium non datur. И только на пенсии им станет очевидно, что учить надо вообще третье — принципы технологий обмена данными.

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

Вопрос к тем, кто тоже хочет делать подобные видео — может быть, не надо являть себя народу в режиме «я знаю, как надо правильно»?

Может быть, не надо потакать аудитории?

Может быть, надо спрашивать и предлагать порассуждать?

Postman или что угодно другое — это инструмент, который надо или не надо использовать исходя из контекста. Мы же хз, куда попадают айтишники — некоторые сразу в рай, некоторые — на проекты, где этот ваш API вообще никому никуда не сдался, где надо всего лишь целыми днями пихать в консоль sql-запросы и думать о том, куда же тут, бляха, развиваться?! А потом случится то, что и этот ваш Postman, и этот ваш Bruno станут никому не нужным археологическим шлаком, и…

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

Но есть беда. Чтобы тесты генерировать, нужна основа — требования. Без набора требований бедняге ПИ в qase.io не от чего отталкиваться. Мдэ.

Если кто не знает, в qase.io подразумевается, что требования надо создавать и хранить в самом qase.io, там для этого есть отдельный раздел. И если им пользуются аналитики и их ручные тестировщики, то, вероятно, всё норм — требования живут вместе с тестами, видно их покрытие, видно, что откуда начинается и чем заканчивается, и сколько всего надо переписывать, если затеяли обновляться. Но если в проекте нет аналитиков? Требования же надо не просто записать, а ещё постоянно обновлять, добавлять, редактировать, комментировать. И когда весь движняк разработки полностью находится в Jira/Слак, то кто будет вообще возиться с требованиями на отдельном ресурсе? Всегда проще требования (если есть) запихнуть, кагбэ, в Jira…

Вообще, у qase.io есть интеграция в Jira, но с ней, кхм, сложно, постоянно чувствуется, что это два отдельных ресурса. Чем-то это всё напоминает древний Zephyr на дьявольском flash — есть взаимное линкование между тестами отсюда с задачами в Jira, но и только, в глаза это всё не бросается. Решение у древнего Zephyr в конце-концов нашлось естественное адекватное — древний Zephyr был взят и убит, вместо него появился плагин, встроенный в Jira, который и наследует у Jira интерфейс, и сущности типа тест-кейсы подтягивает под рабочую задачу (как и полагается), где они явно заметны… testomat.io тоже по этому пути пошел, Xray пошел… Кто вообще отныне пойдёт НЕ через встроенную интеграцию с Jira? Только смелый qase.io, что гордо реет между молний над ревущим гневно морем и кричит в рожок победы: «Генерируйте тест-кейсы, тестировщиков — поменьше, вам же лучше будет сразу!»

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

А вот что в глаза бросилось — предупреждение о том, что

using Qase’s AI Test Case Generator will not result in your data being used to train the language model. This Beta version uses the ChatGPT API Platform for test case generation. OpenAI explicitly states that «We do not train on your business data».

Да, да, разумеется, да! ChatGPT именно так и работает — всё читает, всё генерирует и сразу всё забывает, он же учится с вами взаимодействовать НЕ на взаимодействии с вами! Быгыгы.

С другой стороны, а какие есть варианты? В тест-кейсах всегда есть sensitive data, и если ты уже выбрал сторонний сервис для управления ими, то нехай уже это всё читает ChatGPT, крестик уже снят. Вот только ему нужны требования…

Им следовало бы сперва придумать бредогенератор требований к проекту… Господи ты боже твой, до чего же смелая и дурная мысль! 🙂

В Кишинёве эти машинки продаются свободно, бо никому особо не нужны.

А красящие ленты для них в Кишиневе не продаются. Их нет, потому что они вообще никому не нужны.

А без красящей ленты пишущая машинка не работает.

(мрачно) Ха-ха-ха.

Почему две:

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

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

«Кого ты хотел удивить?»

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

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

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

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

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

А ещё было удивительно сложно осознать невозможность редактировать что-либо на бумаге — кмх… Клавиша Backspace есть, но… Кхм… да, это было неожиданно.

А ещё выяснилось, что эта штука правильно называется «пишущая машинка», а не «печатная машинка», но всем как всегда…

И что-то подумалось навскользь о том, что сам Роберт Хайнлайн когда-то набирал тексты на вот таких пишущих печатных машинках… Прожил он долго, с 1907-го до 1988-го, а значит, застал начало эпохи персональных компьютеров. Была ли у него возможность набора текстов на персональных компьютерах? Щупал ли он тот же TeX?

Кнут сделал “TeX” в 1978-м и даже полностью переписал в 1982-м году. “LaTeX” появился в 1984-м. “Apple II” появился в 1977-м.

Вполне мог… бы… наверное.

Да работал ли мэтр вообще на компьютерах?

Оказывается — да, был такой опыт. Но прежде всего надо учесть контекст. Если бы у Хайнлайна в самом начале писательской карьеры был персональный компьютер, то он, наверное, и не женился бы…

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

• АВМ («ана́логовая вычислительная машина»; не путать с ЭВМ, которая «электронная вычислительная») в Массачусетском технологическом институте (MIT)
• МВУ (механическое вычислительное устройство) “Z1” Конрада Цузе, модель пробная и в практической работе не использовалась. И даже “Z2” в дело не пошла, а вот “Z3” немецкая военщина взяла на вооружение в 1941-м и начала фигачить расчёты вибрационных характеристик крыльев и оперения в проектируемых военных самолётах для Люфтваффе.

Жалко, но в те времена никаким писателям никаких компьютеров никакие Люфтваффе не предоставляли. Сиди и делай «трака-така» на пишущей машинке.

Дас “Z3” в естественной среде обитания. Клавиатура есть, но на ней только кнопки с цифрами

Однако же Хайнлайн таки кое-что понимал в работе тех больших, тёплых, ламповых компьютеров. Во время WWII Хайнлайн числился в ВМФ США бывшим морским волчистым офицером, списанным на берег по состоянию здоровья, поэтому он, вместе с Айзеком Азимовым и Лайоном Спрэгом де Кампом (ВНЕЗАПНО оба такие же писатели-фантасты, публиковались иногда в одном и том же номере одного и того же журнала — Astounding v28n02 [1941 10]!) работал на благо своей американской родины в научно-исследовательской лаборатории ВМФ в Филадельфии, где разрабатывали методы борьбы с обледенением самолётов на больших высотах, аппаратуру для слепой посадки и компенсирующие гермокостюмы для пилотов — предтечу скафандра для космоса. А компьютеры в той исследовательской лаборатории были (вояки же), и пройти мимо них Хайнлайн, конечно, не мог.

Хайнлайн, де Камп и Азимов на работе работают работу (1944)

Авиация тех времен постоянно развивалась, и оказалось, что на больших высотах у пилотов начинаются проблемы с дыханием — «кислородное голодание» отключает организм чуть менее, чем полностью. Одни только кислородные маски ничего не решали, бо на высоте 15 км давление выделяемого легкими углекислого газа превышает атмосферное давление и сделает дыхание невозможным. А выше 19 км в организме начнут кипеть все биологические жидкости. Поэтому военные начали придумывать специальные лётные костюмы, которые обеспечивают и шланг с кислородом, и давление, при котором человек может жить, работать и пулять ракетами по супостатам. Или, например, летать над «старым добрым мирным» СССР и бесплатно фотографировать крестьянок и прочие военные объекты. Вот к этому делу Хайнлайн и подключился.

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

Опыт щупанья древних компьютеров, конечно, показательный, но с последствиями. В повести «Астронавт Джонс» (1953) экипаж мегасупермежзвёздного корабля «Асгард» (и он — корабль, а судно — это то, что под койкой у бывшего лихого моремана; и вообще у англичан это She, вот так вот) переносится от одной планеты к другой прыжками через гиперпространство. И прыжки эти надо рассчитать по-математике, и это можно сделать или вручную, с помощью таблиц Брадиса с данными для астронавигации, которые переплетены в виде толстых книг, или с помощью компьютера. И Хайнлайн втиснул в тесный «Асгард» компьютер, который был ему знаком и понятен.

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

Вот такой компьютер и был предоставлен мэтром письменной словесности смелым астронавигаторам будущего, и они не отказались:

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

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

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

— Поправка, — прозвучал голос Келли. — Слушай, ты, тупица, тебе не надо вводить те цифирки, которые я говорю, ты вводи те цифирки, которые тебе Ногги скажет. Ну сколько тебе раз повторять?

— Но я же… — начал и осекся Макс. До этого момента никто на борту «Асгарда» не догадывался, что он обладает такой непристойно странной памятью.

— Что «ты же»? — Келли хотел было сбросить последние данные, введенные Максом, но приостановился. — Если подумать, ты же не мог ввести в эту штуку десятичные цифры. Так что же ты, интересно, сделал?

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

— Я ввел те цифры, которые Ногучи собирался мне продиктовать.

— Повтори-ка это снова, — Келли смотрел на него не отрываясь, — ты что, читаешь мысли?

— Нет, но цифры я ввел правильные.

— Хм… — Келли нагнулся над пультом. — Повтори-ка, Ногги, — Вычислитель выдал длинный ряд нулей и единиц, двоичный эквивалент зачитанного Келли выражения; Келли проверял нажатые клавиши, губы его слегка шевелились. Он выпрямился. — Как-то раз один парень при мне тринадцать раз подряд выбросил семь очков, причем кости были честные. Это что, Макс, тебе просто повезло?

— Нет.

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

В конце концов Келли сказал:

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

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

— Попью-ка я кофе, — тихо сказал он и отошел.

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

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

Я.

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

Мда, старые времена… В погоне за оптимизацией некоторые писатели писали тексты сразу на машинке (Хемингуэй, Сименон, etc). Которые уже состоялись — нанимали для этого наборщиц. Которые победнее — брали наборщиц в жёны. Естественно, Хайнлайн тоже апгрейднулся от карандашей сперва до пишущей машинки, а затем и до третьей жены.

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

Это было неизбежно. Все механизмы со временем распадаются. И кое-что кое-кому приходится кое-как делегировать.

А тут как раз произошёл исход семидесятых — начинается явление персональных компьютеров американскому народу. Уже продавались компьютеры Commodore и RadioShack, за ними уже подтянулись Apple II и Atari . Появились очень ценные для тогдашних пользователей дисководы (флопаки на пять дюймов), программы для набора текста и для уже привычных нам электронных таблиц — возможно, самое ценное в быту, бо бюджеты, отчёты, налоги и всё такое прочее эксельное. Было они все в принципе дорогими, «горячими», ненадёжными и по нашим меркам работали медленно, со сбоями, но это было только начало, поэтому все или терпели, или делали всё то же самое без компьютеров — old-school way.

Роберт и Вирджиния Хайнлайны (1980)

И вот на этом исходе семидесятых на сцене появляется Вирджиния Герстенфельд, третья супруга Роберта Хайнлайна — лейтенант ВМФ США в отставке, профессиональный химик, фигуристка (высший любительский уровень), знала джиу-джитсу, латынь и ещё пять-шесть других языков, прекрасно готовила, была способна самостоятельно освоить любую технику, два года учила русский язык для того, чтобы сопровождать Хайнлайна в путешествии по СССР в 1959—1960-м (Москва, Киев, спортивные стадионы). Она не редактировала его произведения, но полностью участвовала в менеджменте публикаций, так что без неё вся эта история не была бы историей.

К тому моменту Джинни (а её все так называли, так позволим себе это и мы) уже видела, как лихо управляется с одной из первых машин «Atari» Мэрилин Нивен, супруга писателя-фантаста Ларри Нивена. Полагаю, что это была модель «Atari 800». И говорят, что Мэрилин приходилось эту шнягу то и дело самостоятельно чинить.

Atari 800. Сперва привыкни к клавишам, потом приходи со своим телевизором

Как и большинство тогдашних персональных компьютеров, упомянутый Atari представлял собой толстую клавиатуру, в которой было спрятано, собственно, всё то, из чего состоит компьютер. Просто подключи это всё, если получится, к какому-нибудь современному телевизору и be happy.

В 1993-м в компьютерном классе бывшего кишиневского дома пионеров были «Yamaha КУВТ» (Комплект Учебной Вычислительной Техники), которые больше интересовали нас, тогдашних школьников в плане «пошпилять в игрушки после занятий», чем «творить творения на BASIC», но всё-таки. Желто-зеленые мониторы, BASIC, goto, все дела. До Windows 95 ещё было несколько лет.

Но у нас на клавиатурах были отдельные, здоровенные кнопки управления курсором, а на Atari 800 (и других похожих на него компьютеров) эти «стрелки» были кнопками второго уровня, до которых можно было добраться только через Shift. Не сказать, что это мозголомка, привыкнуть можно. Но ептыть же!

И Джинни правильно оценила апгрейд от пишущих машинок до персонального компьютера:

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

Вот это было бы апгрейдом всех апгрейдов процесса создания текстов! В тартарары эти наши/ваши аналоговые машинки. В бездну.

Вирджиния выбрала ЭВМ совмещённый с экраном — «Zenith Z89».

Так выглядел Zenith ’Z89’ (его флоповод отвалился за древностью лет)

Справа от экрана отсек для всякого, например, для дисковода, внутри процессор Z80 с тактовой частотой 2 МГц, 48 КБ ОЗУ и несъёмная клавиатура, которая отличалась высоким качеством сборки и необычным количеством клавиш специального назначения: REPEAT, ESC, TAB, CAPS, CTRL, SCROLL, RESET, BREAK, BACK SPACE, LINE FEED, DELETE, REPEAT и две с красными и синими квадратиками! И над всем этим — 12-дюймовый, выпуклы, монохромный, мерцающий ЭЛТ-экран, на котором помещалось 80 × 25 символов. Ндя.

В наше время такие компьютеры чаще упоминаются под названием “Heathkit H-89”, потому что изначально их делала компания Heath:

Стоил он $2.295 и это таки было дорого (половина нового Кадиллака с рулём и пепельницами), но Хайнлайн, как бывало нередко, пошёл вразнос и взял сразу два экземпляра — для себя и для Джинни. Он взял да и быстро освоил текстовый редактор «Magic Wand», и после волшебного выполнения «поиск-замена по тексту» сделал эпохальное заявление:

Это освобождает меня от тирании машинисток! ©

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

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

Первым текстом, который был набран полностью на “Z89”, был «Фрайди» (который я впервые прочитал в поезде между Молдовой и Украиной в 1994-м или 1995-м и с тех пор… ммм, впрочем, неважно), и с тех пор пишущие машинки в быту Хайнлайнов не фигурировали. Всегда проще иногда выковыривать кнопки и быстро прочистить контакты на клавиатуре, чем вызывать механика и ремонтировать уходящую вразнос пишущую машинку и искать в Киеве красящие ленты для неё.

И если сам Роберт Хайнлайн использовал свой компьютер только в качестве текстового процессора, то Джинни пошла дальше и (в том же 1981-м году) изучила «Basic». А ей было уже 65 лет.

Начинаем ныть о том, что возраст мешает…

Вместе с компьютерами Хайнлайны взяли страшную вещь — дисковый принтер «Sprint Qume». Это такая себе сверхпродвинутая печатная машинка, где вместо множества штанг с литерами перед бумагой постоянно (бешено!) крутится диск с буквами. В нужный момент по соответствующей букве происходит резкое стуканье, на бумаге остаётся оттиск буквы и каретка уносится на один символ влево. Такая машинка с высокой скоростью печати работала с повышенной шумностью, причём настолько, что во время работы её прикрывали звукопоглощающим чехлом. Ну так а шоподелать…. И она тоже требовала возни с бумагой и красящую ленту, которая сегодня в Кишиневе нигде не продаётся (БЛЕАТЬ!).

Дисковый принтер «Sprint Qume»

Так что ответ да — Хайнлайн на персональном компьютере клавишами тарахтел и нам велел.

Послесловие про специализацию

Раз уж речь зашла про компьютеры и Хайнлайна, упомянем его меметичный пассаж про специализацию из «Достаточно времени для любви, или Жизни Лазаруса Лонга» (1973):

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

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

Автор цитаты — Лазарус Лонг — кагбэ, старейший человек, он прожил на момент действия романа более 2000 лет (действие происходит в 4325 земном году). Он повидал настолько много всякого, что может в любой момент выдать афоризм на любую тему, с контекстом или без. Характерные примеры его ВНЕЗАПНЫХ высказываний:

«Если ты не любишь себя самого, другие тебе тоже не понравятся».

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

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

«Мой ей ноги».

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

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

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 — Фингальный конец.

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

Соппсно, у нас в корпорации кто-то туда заплатился (не путать с «зааплаился») и по итогу получил доступ к скрытым ссылкам на все видео на ютюпе и, как партия велела, раздал их по внутренней связи всем принудительно интересующимся. Я интересунулся и сперва посмотрел, ап чём и как там Александра Ковалёва говорила.

Потом посмотрел на других.

И, что?

И это было не то.

Без реверберации зала (с залом) всё воспринимается иначе, нежели… воспринимается как обычный чёртов платный вебинар. А поэтому резко хочется чаптеризации (оглавления), точности и однозначности, чтобы пролистывать, и если этого нет… это надо учитывать. То есть, условно это конференция, а на деле — вебинары.

Выступления надо задумывать и презентовать именно как вебинары, dixi.

Живое выступление потому так и называется, что каждый раз фиг его знает, как оно пойдёт. Оно живое. Оно рождается из взаимодействия, оно живет недолго, оно неповторимо, оно опадает, как сакура весной, самурай точит вакидзаси (второй, «короткий» меч в паре с катаной), завтра в поход. Оно переживается. Даже если оно записывается на видео — это все равно запись пережитого живого выступления. А вебинар записывается по-другому и переиспользуется позже в учебно-напоминательных целях.

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

Ритм и темп речи тоже надо тренировать, выверять, экспериментировать — та еще морока.

И надо выстраивать все «шашлыком», ровно держать одну тему/идею, обходиться без ВНЕЗАПНЫХ роялей, последовательно нанизывая мясо на шампур. И давать прожевать, это можно делать по-разному, хотя бы через краткое резюме каждой главы.

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

Лучший подход для подобных видео — стоять у доски с фломастером. Или у доски со слайдами. Главное — стоять. Это влияет на то, как докладчик дышит, как говорит, как двигается, и, соответственно, в статичном кадре из ничего появляется достаточно адекватная движуха, а не «говорящая голова».

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

И важнецки важнейшего становится место, из которого докладчик вещает. Те, которые вещают откуда-то «с под крыши дома своего» в стандартные телефонные гарнитуры… вот сразу в сад.

Отрицательный пример: …ну, например, почти ВСЕ видео из уже неоднократно проведённых онлайновых конференций https://www.onlinetestconf.com/ — смотрим каноничный пример того, как несколько участников одного доклада звучат очень по-разному. Ухи, ухи!

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

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

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

И отдельный вопрос про доступ ко всем таким видео.

Ок, причинная конференция была с платным доступом, этим можно объяснить доступ к записям только для участников «только по ссылке». Формально да, но оно же через йо-хо-хо всё равно расползается достаточно свободно и бесконтрольно. В чём смысл их полупрятать?

Но и видео с бесплатной онлайнтестконфовской движухи тоже распространяются в виде «только по ссылке». В чём смысл их полупрятать?

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

Иногда полезно.

Иногда впустую.

Некоторые делают это эффективно (книги Эдварда де Боно могут помочь), бо мышление — навык, который нужно тренировать.

Некоторые делают это быстро и безо всяких книг, бо природа.

Некоторые вообще не понимают, о чём речь.

Да?!

Блог появился как способ осмысления темы тестирования ПО. Каждая статья — как обобщение какой-то идеи. Или явления. Или что там ещё есть…

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

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

А можно дать ребенку поиграть со спичками.

Что правильнее?

Что эффективнее?

Что дешевле?

Что разумнее?

Обстоятельства сложились так, что в моё время были только спички и возможность свободно поджигать занавески на проекте. Кто выжил, тот умеет как надо поджигать и не давать разгораться. И умеет вовремя тушить. И идёт читать про термодинамику, а там уже история, а там процессы, а там ГОСТ и есть о чём подумать.

В наше время от джуна заранее ожидают возможность рассчитать объём раскалённых газов и время, за которое сгорит дотла одна комната, на 14/88 заполненная каким-нибудь горючим материалом. Надо начинать с истории, процессов, ГОСТ-ов и учебников. Сперва получи кандидатскую по горению занавесок, потом подумаем, можно ли доверить тебе написание тест-кейсов.

Начал бы я сегодня осмысление тестирования ПО с ведения блога?

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

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

То есть, не всё делится на строго agile отдельно и waterfall отдельно. Это вообще не противоположности… да, долго объяснять.

Скипнем.

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

…бле, и это надо долго объяснять.

Скипнем.

В августе 2008-го я появился в Киеве, и там уже было с кем обо всём этом поговорить, было с кем соревноваться. И меня пёрло.

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

Всё это закончилось в 2011-ом.

Статистика публикаций

У меня появилась аудитория, и это хорошо.

Но аудитория приходила за объяснениями, однако не ради объяснений.

Сложно?!

Ок, объясняю.

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

Со стороны кажется, что у меня тут объясняют простыми словами сложные слова. Это, кагбэ, тангенциально, и даже ортогонально моему основному занятию, поэтому чего дёргаться?!

«Here we are now, entertain us» © sCurt şi Cobain

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

А кто знает?

Я не должен каждый раз волноваться, что кто-то не сумеет в гугл и надо заранее объяснять, что такое тангенциальность и ортогональность.

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

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

На эти годы как раз пришёлся рост штурмующих IT через тестирование, ведь оно «вроде легче». И мы быстро приехали: я уже хочу сказать, что тестирование нифига не «легче», даже если снаружи так кажется, и что внутри оно очень сложное, бо оно происходит из того самого Computer science, объёмом которого пугают взрослых и детей, и что надо читать старые книги… вот это вот всё. А моя аудитория хочет узнать про то, что тестирование «легче», а не… вот это вот всё.

Запал иссяк. Я выкинул график, удалил все черновики и перешёл в режим «писать только тогда, когда уже невозможно терпеть» (ставьте ударение как угодно, бо правильно и так, и эдак).

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

Статистика посещений и просмотров

Кто бы мог подумать (не я), что когда публика [наконец-то] приходит — её надо ублажать. Надо подыскивать интересные [только] для неё темы, надо выдерживать график публикаций. Надо танцевать вприсядку, даже если незачем и не хочется.

И знаете что…

За это время я ещё и стал постоянным тренером тестировщиков, и для осмысления блог уже был нужен всё реже. Он превратился в средство для ссылания.

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

Но это не та функциональность, ради которой всё затевалось.

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

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

Что осталось в итоге?

Количество публикаций упало до их естественного минимума.

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

Аудитория [наконец-то] скукожилась.

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

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

В целом я доволен.

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

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

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

Дык вот…

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

Итого, блог «только про тестирование» закончился.

Со временем придумается и новое название. Сейчас оно несущественно.

Далее я буду публиковать тут всё то, что мне интересно и полезно здесь и сейчас, от каких-то необязательных рассуждений до инструкций по автоматизации (ранее это всё уходило в siderulezzz.wordpress.com, но инструмент обновился и когда-то полезный мне блог требует кардинального переосмысления, и ресурс переименовался в afftomat.wordpress.com) или решений по вёрстке в LaTeX, или настройке обновления времения в Debian через systemd, или схеме нарезания японской катаной херсонского арбуза. Очевидно, что всё это интересно только мне, а не большому количеству благодарных читателей.

Всем спасибо, давайте расходиться.

Откуда-то глухо доносится «Fuck the police comin’ straight from the underground…»

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

Легкая задымленность и маниакальный блеск в глазах говорящего:

— …их стало слишком много! Каждую неделю кто-то спрашивает у меня лично, а получится ли у него стать тестировщиком. Каждый мнит себя уникальным, каждый считает себя подготовленным просто потому, что у него есть «ОГРОМНОЕ ЖЕЛАНИЕ», но он ещё ничего не делал, ничего не пробовал, ни одной книги не прочитал, а если разговор зайдёт про книги, то меня спрашивают, какую конкретно книгу надо прочитать…!

— Дык, скажи им, какую книгу прочитать-то, — из глубин кресла. — у нас даже бухгалтера знают ваши книги. Как их там… Савин, Фолкнер и Нгуен?!

— Фолкнер… да, это было смешно.

— Слишком налитературенная особа попалась. Вообще, tg-каналы джунов — это, знаете ли… уникальная… хрень.

— Дык, если сегодня они хотят ОДНУ книгу, то завтра будут спрашивать, какие конкретно страницы из той книги надо прочитать!

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

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

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

— Я спрашивал, в какой книге я могу найти материал по нужной теме.

— И библиотекарю казалось, что дело его свято, что тебе нужна вся КНИГА, что ты её целиком прочитаешь и сделаешь выводы, и он тебе её находил… Сегодня ты бы не ходил к библиотекарю, ты насиловал бы гугель в поисках готового реферата по нужной теме. Ты не стал бы даже листать нужные книги, ты обходился бы двумя страницами целиком, даже особо не вчитываясь в них.

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

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

— Дык, они же говорят, что хотят стать профессионалами… Я и объясняю с самого начала, что там просто и что там сложно.

— Они-то говорят, а ты воображаешь, что их понимаешь, как тот библиотекарь. Ну, и кто дебил?

— Я дебил?!

— Именно это они про тебя и говорят.

— Да я им тогда…

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

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

— …«И тут он увидел глаза Киры. Кира глядела на него с ужасом и надеждой»…

— Ну, да… Если у тебя есть возможность влиять, то не пользуйся этой возможностью.

— Но если просят о куске хлеба…

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

— Дай ему рыбу, и он будет сыт один день. Дай ему удочку…

— …и он будет ворчать о том, что ты мудак, что раньше рыбу давал, а теперь не даёшь. Вернёмся к первой проблеме, которую ты вскользь обозначил: о том, что тебя постоянно спрашивают, а получится ли стать тестировщиком, и ты не знаешь.

— И никто не знает.

— Я, кагбэ, знаю. Но это требует какого-то времени на выяснение.

— А мы и не спешим.

— Значит, для того, чтобы стать тестировщиком, нужен определённый mindset, а не набор навыков. Навыки нарабатываются и прилагаются, а предрасположение к этому делу нужно природное. Хотя, его тоже можно тренировать, как тренируют детей в школе, но это долго и не факт, что получится. Бо если бы получалось, то любая школа была бы очень эффективным заведением для подготовки всех сразу ко всему сразу.

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

Вот, ты, например, что сделаешь?

— Нагуглю.

— Реферат?

— Если найдётся реферат, то ок. Если нет, то нагуглю всё, что можно, и из того, что соберётся, сделаю реферат.

— А нагуглишь ты гулю с маком, бо скульптора О.Пикушена не существует.

Скульптор О.Пикушен был пчелой укушен

Вероятно, найдётся что-то про скульптора Александра Опекушина (1838 — 1923), но в задании сказано найти информацию про О.Пикушена.

В этом моменте все люди начинают действовать ровно по учебникам для психиатров (к слову о том, насколько мы все уникальны). Они останавливаются и говорят, что ничего не нашли. Или нашли, но не то, поэтому «ой, всё!». Аллес капут. Пусть это будет первая группа.

Вторая группа — те, кто говорят, что ничего не нашли, просят уточнения и предлагают свой вариант, мол, вы могли ошибиться, вот, был же Опекушин. Экзаменатор сделает морду кирпичом и скажет, что по условиям задания, надо искать реферат про О.Пикушена, а не всякие там фигли-мигли… Вы тут что, самые умные?! Заказчик так сказал. Я так сказал. Исполняйте.

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

Другие отступают от «морды кирпичом», но не сдаются. Они ищут аргументы. Они предлагают посмотреть на экран.

— А я смотреть не стану, сказал ученый монах Томас Люпиан, когда Галилей, исчерпав все аргументы, попросил монаха взглянуть в телескоп…

— Вот именно. Догматика давит, их легко переубедить. Морда кирпичом просит кирпича, но бить нельзя, Бендер не позволяет. Большинство из второй группы останавливаются перед авторитетом, подавляя своё несогласие. Они боятся неопределённости, они хотят внятности, они могут успешно работать годами, просто делая ровно то, чему их в самом начале научили — примитивные искусства аборигенов Полинезии, культ карго, над которым они же так весело смеются. Они очень хотели бы изучить тест-дизайн, но не могут, бо на проектах этого не требуют, а учить что-то абстрактное самостоятельно они не могут. Они ждут, когда работодатель попросит у них «А научись автоматизировать…»

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

— ТИХО! Я понял! Они же подменяют аналитическое мышление логическим, поэтому они никогда не выйдут из логического капкана «я опытный тестировщик, но я не понимаю тест-дизайн, следовательно, я неопытный тестировщик, а я не могу называться неопытным, ведь я уже опытный…» Их я на собеседованиях спрашиваю о том, в чём разница между регрессионным и регрессивным тестированием, и они эту разницу находят и даже объясняют!

— Точно так, детектив Пикачу. Из второй группы тестировщики тоже не получаются.

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

Вот с третьей группой можно работать.

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

И ещё есть четвёртая группа… Этих людей мало, но именно их вы ищете. Они могут не просто нагуглить реферат на нужную тему, они могут его самостоятельно собрать из какого-то неструктурированного массива информации. Они могут закопаться до утра в настройке SQLite или настройке вывода команды „ls“, даже если их об этом не просят, и сделают

alias ls='ls --group-directories-first --color=auto -p -1'

и засунут это в .bashrc, чтобы оно работало всегда. По пути они нахватаются информации о том, что ещё вообще можно делать, и интегрируют эту информацию, и в ходе работы будут ВИДЕТЬ решение множества ситуаций, о которых люди из первых групп вряд ли додумаются, даже если их об этом попросят.

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

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

Но все те, кто могут стать отличными или нормальными тестировщиками, не спрашивают, могут ли они стать тестировщиками. Прав был Андрей Макаревич. Твоя помощь им не нужна, они сами справятся.

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

— Где ты вообще придумал этого неправильного архитектора Мендисабале? Пекушин? Пикушин?

— Ох… Когда-то я работал «апиратаром» в интернет-кафе, видел много школьников, которые скачивали себе рефераты самостоятельно. А однажды пришла взрослая тётя, которую дочь послала за рефератом про скульптора О.Пикушена.

Ну, ок. Я поискал, быстро понял, что ничего нет, и попросил уточнить, правильный ли мы ведём поиск О.Пикушена, ведь я нахожу только А.Опекушина (1838 — 1923). Она позвонила дочери за уточнением. Дочь ей объяснила, что такой тупой мамы, как у неё, мир ещё не видел, что она ясно сказала, что ей, блядь, нужно, и что без этого реферата она будет самым несчастным ребёнком во всём городе, и что… Было слышно хорошо.

Ну, ок. Я попросил уточнить, откуда было взято имя искомого скульптора. Мать снова позвонила, и дочь ЧЛЕ НО РАЗ ДЕЛЬ НО сообщила, что это домашнее задание ей по телефону передала подруга, и что подруга не может ошибаться. То есть, ей по телефону по слогам (для повышенной точности) была передана информация. Повышенная точность на стороне приёмника была воспринята буквально. Вот и причина искажения.

— Созвучность слов! Корова через «а».

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

Мадам Козятина! Нам еще трошки угля, пожалуйста… Наконец-то, жара сошла. Такое вот начало лета…

— Да… Думаешь, черешня уродится?

— Да пофигу уже…

Чтобы люди объединились в сообщество, нужны следующие элементы:

• Общие враги. Наличие врагов — отличный способ сплотить сообщество. Для «Гринпис» это правило легковыполнимо, но есть ли враг у вас?
• Общие цели. Спасение чилийских шахтеров — достойный повод к объединению. Дайте людям почувствовать вовлечённость.
• Защита от нападения. Насилие не обязательно. Даже словесная критика может быть расценена как нападение. Вы никогда не видели спортивных фанатов (меломанов, политических сторонников) сплотившихся, чтобы защитить себя от нападения?
• Страх. Существует разница между реальным нападением и наличием угрозы. Страх — доказанный способ объединить людей. Иногда страх бывает и позитивный, но чаще это негатив. Позитивно можно использовать страх неудачи, страх позволить другим совершить ошибку. Страх быть обыгранным конкурентом и т.д. …
• Разделение на своих и чужих. При наличии чёткого разграничения на своих и чужих люди объединяются плотнее. Пять лондонцев, которые никогда не заговорят друг с другом дома, в лондонской подземке, будут намного общительнее в пекинском метро.
• Великие достижения. Достижение чего-то замечательного отлично объединяет группу, особенно если все ощущают себя частью целого. Избрание своего кандидата. Освещение в прессе. Достижение важной вехи. Общие достижения придают людям гордости.
• Общий опыт. Один из самых сильных связывающих элементов. Люди охотнее объединяются, если прошли через что-то хорошее или плохое вместе. Участие в мероприятиях, совместная поездка, любой совместный опыт делает людей ближе.

Если в вашем сообществе есть хоть часть этих связующих элементов — можете не беспокоиться.

Беспокойтесь, если их нет совсем.

© https://habr.com/ru/post/288224/

Иногда в телевизоре начиналась телепередача «В гостях у сказки». Было волнительно.

Анастасия Зуева

И да, это чёрно-белая картинка с телевизионными искажениями, бо вы офигели требовать цветной FullHD в советском телевизоре.

Александр Александров сказок не читает, но при запуске видео с его докладами у меня всегда возникает то самое ощущение из навсегда ушедшего времени и волнение ожидания торта.

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

И там вообще не для джунов (там над вами хохмят).

Я перегнал доклад в полноценную текстовую версию, бо оно того варто. Видео — в конце.

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

Экономика тестирования. Версия 1.0 (2018)

О чём будем говорить

• Общеизвестные (но не до конца) истины, или почему такая тема
• На что влияет экономика тестирования
• Что такое Версия 1.0 — Подробно
• Зачем нужна Версия 2.0 — Кратко

Почему такая тема

Эту тему я обдумывал на протяжении прошедшего года, и ещё не нашёл ответы на многие важные вопросы.

Например, для меня было неожиданностью узнать, что тезис о том, что «Исчерпывающее тестирование невозможно» — не для всех очевиден. Когда меня спросили «А почему?», я сослался на книгу Гленфорда Майерса «Надёжность программного обеспечения» (1979), где был приведен пример причины. Ответ был: «Ну, там же математически не доказано, что это так!..» Я вспомнил своё математическое образование, и указал на теорему Кантора, которая говорит о том, что множество натуральных чисел — счётное (то есть, это бесконечное множество,  элементы которого можно перенумеровать натуральными числами), а раз счётное, то оно не конечное. И если сделан калькулятор, который складывает натуральные числа, то НЕВОЗМОЖНО  провести его исчерпывающее тестирование — и так далее, и так далее.

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

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

Наконец, есть здравый смысл: все мы тестировщики (или все, кто не тестировщики, но, очевидно, хотят ими стать, потому что другого пути развиваться у человечества, конечно, нет 🙂 ), и у нас есть опыт тестирования, который приносит понимание того, что невозможно написать ВСЕ тест-кейсы и выбрать ВСЕ тестовые данные, нельзя пройти ВСЕ пути в коде и выполнить ВСЕ действия, которые может делать пользователь и так далее и так далее.

Вроде бы абсолютная истина, но вопросы на эту тему появляются снова и снова на самых разных уровнях, и особенно на уровне топ-менеджмента:

• «Когда вы завершите тестирование?» (Когда? «Завершить» означает «Сделать всё». Когда можно сделать всё?).
• «Когда будут найдены ВСЕ дефекты?» (не то что половина, но даже 99% найденных дефектов, конечно же, никого не устроит)
• «А когда мы поставим заказчику ПО без дефектов?»
• Если дефект в продакшн — «Почему этот дефект не был найден?»
• «А почему ВСЕ дефекты, которые были обнаружены в продакшн, не были найдены до передачи в продакшн?»

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

Возникает следующая тема: критерии тестирования. Практически любые критерии завершения тестирования должны учитывать условия вроде:

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

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

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

• Все разработать — Можно
• Все протестировать — Нельзя

Разработчики могут сделать всё. Они могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» — например, два с половиной месяца. А почему? А потому, что там 18 фич, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты в этих 18-ти функциональностях? А сколько времени нужно тестировщику, чтобы написать для них ВСЕ тест-кейсы? А сколько времени нужно тестировщику, чтобы проверить ВСЮ функциональность? Никакого времени не хватит. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.

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

Пример: «Если потратить столько-то человеко-часов, получится приемлемое качество (не очень много дефектов останется). А если потратить меньше, то качество будет хуже (больше дефектов останется)». Это значит, что если мы потратим 5 000 ч/часов, то мы найдём 97% дефектов, а если мы потратим меньше, то мы найдём меньше дефектов. В такой формулировке мы можем говорить, как нам организовать тестирование — конечно, при определённой зрелости процессов разработки.

И тут можно было бы остановиться. Мы знаем чисто технически, на что расходуются трудозатраты на тестирование (как правило, на следующие активности):

• Рецензирование требований
• Разработку тест-кейсов
• Ручной прогон тест-кейсов
• Автоматизацию тест-кейсов
• Анализ результатов и подготовку отчетности

Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги — мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации  и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Качество.

На что это влияет

Давайте рассмотрим анатомию процесса планирования.

Надо планировать так, чтобы затраты были реалистичными (укладывались в бюджет проекта) и эффективными (давали бы ожидаемый результат). Если мы пообещаем, что нам нужно 5 000 ч/часов, а за эти 5 000 ч/часов мы что-то протестируем, то нам головы открутят, и, естественно, извинения после этого приносить не будут. Если мы пообещаем, что мы гениальные тестировщики и что за три дня найдём все дефекты, то нам тоже головы открутят, но позже, когда необнаруженные дефекты выскочат на продакшне. И тогда зачем обещать? Ведь за свои слова надо отвечать.

Значит, необходимо пользоваться методами и моделями оценки трудозатрат на тестирование (я рассказывал об этом в 2011 году на SQA Days в Москве в докладе «Оценка трудозатрат на тестирование в проектах сопровождения» https://sqadays.com/ru/talk/12185). На основании полученных оценок планируются активности по тестированию. Необходимо также  отслеживать процесс тестирования, чтобы вовремя обнаружить отставание от плана и скорректировать его.

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

Мы можем недооценить трудозатраты на тестирование. Да, мы можем их недооценить с самого начала. Например, мы запросили 5 000 ч/часов, а их в проекте нет, и нам предлагают —  возьмите 3 500 ч/часов и как-то выкручивайтесь. Что ж, давайте крутиться.  

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

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

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

Подробно о Версии 1.0

Недооценка трудозатрат на тестирование часто приводит не к изменению  стратегии тестирования, а лишь к увеличению трудозатрат (дополнительному времени, персоналу и др.) и, как следствие, к увеличению сроков и/или стоимости проекта. Или мы недооценили трудозатраты, или нам их недооценили — что делать? «Дайте нам то, чего нам не хватает! Да, мы получили оценку в 3 500 ч/часов, но поскольку всё пошло не так, нам надо ещё. Нам надо больше людей и времени». Чем это плохо? Мы выходим за обещанные рамки, за сроки и за стоимость, а для заказчика ничего хуже этого не бывает, потому что ложка дорога к обеду. Конечно, если вы сделаете работу в срок, но плохо — это неприемлемо, но если вы сделаете хорошо, но на полгода позже — подумайте, что хуже. 

Рассмотрим решения реальных кейсов. Первый: «Главное — получить проект, а там посмотрим». Мы участвуем в тендере. Мы оценили трудозатраты на тестирование  в 500 ч/часов. Получилось дорого, поступает указание урезать трудозатраты, но разработчиков урезать нельзя! При таких трудозатратах проект продать нельзя, поэтому уменьшили тестирование до 300 ч/часов. Дальше — больше. «Непонятно, что в проекте делают тестировщики. Если они поставляют ПО с дефектами — от этого проекту только хуже. Если они тест-кейсы пишут — да кому эти тест-кейсы нужны?!» Мне приходилось эту фразу слышать от топ-менеджмента неоднократно.

Хорошо, мы согласились на 300 ч/часов. Как мы это сделаем за 300 ч/часов — мы не знаем. Но мы согласились с этой оценкой, пообещав тем самым  сделать все в полном объеме, со всеми артефактами. И вот эти часы исчерпались. Дальше что? Чудес не бывает: либо тестирование останавливается, что для проекта губительно с технической точки зрения, либо тестирование продолжается себе в убыток, и приходят грозные дяди из финансового подразделения и спрашивают, почему компания несёт убыток. А если к тому же компания торгуется на бирже, нам говорят «вы показываете низкую маржу, от нас побегут инвесторы». Результат: качество проекта непредсказуемо.

Второй кейс: «Любой каприз за ваши деньги». Сколько раз мы говорим это заказчику? Заказчик воспринимает это буквально, и начинает требовать любой каприз за свои деньги. Проект выполняется по модели Fixed Price, потому что все стремятся минимизировать затраты, начинаются изменения, повторное тестирование, мы получили свои 500 ч/часов, мы их честно израсходовали, потому что мы подписались под «ваши капризы» и всё, результат печальный. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

Третий кейс: «Тестирование от забора до обеда». Мы оценили трудозатраты  на тестирование в 500 ч/часов и получили согласие на эти трудозатраты. У нас есть команда, и мы начинаем тестировать, не заботясь о  приоритетах и целях, мы тестируем всё, что под руку попадается, потому что всё это заказчику нужно — он же сам нам об этом сказал. Мы заказчика очень любим и хотим сделать работу хорошо, но вот 500 ч/часов исчерпались. А что происходит с приложением, когда эти 500 ч/часов исчерпались? А бог его знает. Что-то протестировано, что-то нет, где-то написаны скрипты автоматизации, которые, правда, ничего не находят, но они же написаны. Регрессионное тестирование с помощью автоматизации — это такая фишка, которая с одной стороны, может ничего не дать, а с другой стороны, деньги жрёт так, что никакая расточительная длинноногая молодая так не сможет. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

Четвёртый кейс: «Кавалерийский наскок, или Авось». Да, мы профессионалы, нас много, мы команда, мы всё можем.  Все тестировщики, которые есть в компании, поставлены «под ружьё», мы выполняем тестирование так, как можем — да, не хватает квалификации для тест-дизайна, зато у нас огромное количество новичков, но они ретивые, они по выходным работают. Тестирование заканчивается в момент окончания проекта. А чем оно закончилось? А бог его знает. Как карта ляжет. Карта, как правило, ложится плохо. Качество проекта непредсказуемо.

Кратко о Версии 2.0

Поговорим о том, в чём разница между экономиками тестирования версии 1.0 и 2.0.

Версия 1.0 — это парадигма, в которой, к сожалению, мы с вами сегодня работаем. Нам дали сколько-то ресурсов, а теперь мы должны дать результат. Почему всё так устроено? А потому, что мы знаем, как эти ресурсы использовать. К примеру, мы знаем, что из 500 ч/часов 200 мы потратим на написание тест-кейсов, 100 на автоматическое тестирование и 200 на ручное — но это все в идеальном мире, если не будут радикальных изменений, все тестировщики будут прекрасно работать, и так далее. А если мы обосновываем оценку, показываем ее реалистичность и  эффективность, и будем оценивать все риски, то за эту оценку, уж извините, любой нормальный менеджер проектов открутит вам голову, ибо ему непонятно, почему тестировщики должны ошибаться — они же тестировщики! Это разработчики могут ошибаться, но чтобы тестировщики — никогда 🙂

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

А что такое Версия 2.0? Вот мы получили оценки. Эти оценки играют роль запасного парашюта. Это то, как мы будем работать, если у нас ничего более эффективного не получится. Но Версия 2.0 говорит нам о том, что надо использовать обоснованные трудозатраты эффективно, анализируя проектную ситуацию. Мы будем писать тест-кейсы? Если будем, то какие? Какие тестовые данные мы будем использовать и где мы будем их брать? От заказчика? Свои? Какие нам нужны тестировщики — мало сильных (но дорогих) или много слабых (зато недорогих)? Нам нужна стабильная команда для данного проекта или нет? Нужна нам автоматизация вообще, и если да, то какой инструмент, какое покрытие должно быть обеспечено?

Если для Версии 1.0 критерии — это возврат инвестиций в трудозатраты (ROI), то для Версии 2.0 критерий — это максимизация выгоды. И это разные вещи.

Заключение

Перечислим кратко основные тезисы.

• Исчерпывающее тестирование невозможно.
• Тестирование — это в том числе и экономическая деятельность.
• Версия 1.0, или Что надо сделать. Работаем в рамках плана и оценки, при нехватке ресурсов просим их добавить (экстенсивный подход)
• Версия 2.0, или Как надо сделать. Работаем в рамках плана и оценки максимально эффективно (интенсивный подход)

Благодарности

Наконец, позвольте поблагодарить:

• Организаторов конференции SQA Days # 24 за приглашение и возможность выступить.
• Моих коллег Андрея Ладутько, Александра Лукашева, Андрея Павлова, Алексея Федорова и Александра Куцана за детальное обсуждение тематики доклада и поддержку.
• Программный комитет конференции SQA Days # 23, благодаря усилиям которого на SQA Days # 24 появился этот доклад и, надеюсь, на SQA Days # 25 появится доклад «Экономика тестирования. Версия 2.0» и его широкое обсуждение.

Вопросы и ответы

Стоит ли вообще тестировщику отстаивать свои 500 ч/часов, которые он рассчитал, долго и упорно, или согласиться с оценкой менеджеров, перекладывая на них, таким образом, ответственность за результат?

Не стройте иллюзий о том, что вы перекладываете ответственность. Если вы согласились на 300 ч/часов вместо 500, то вы взяли на себя ответственность, что протестируете всё за 300 ч/часов. Придут и спросят: ну как же, вы же обещали? Вы же сказали, что за 300 ч/часов ВСЁ протестируете, и дефектов не будет. Но дефекты есть. Тогда за что вы зарплату получаете?

Если вы знаете, как протестировать за 300 ч/часов, и 200 ч/часов для вас было «большой подушкой» — ради бога. Иначе — вот вам горящий фитиль в бочке с порохом, на которой вы сидите, и радуйтесь тому, что вы не знаете длины фитиля и не знаете, когда оно жахнет.

Сколько времени у вас занимает разработка оценки для проекта и кто это делает?

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

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

Если говорить про ресурс, то этим занимается тот ресурс, у которого хватает квалификации для этой работы (наука, поверьте, не дворянская).

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

Стоит ли закладывать оценку трудозатрат на оценку трудозатрат в тестировании?

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

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

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

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

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

Этот расчёт может быть очень полезным с точки зрения обоснования трудозатрат на тестирование. Когда вам заказчик говорит «А на что вам 500 ч/часов на тестирование?» можно ответить «ОК, давайте снизим до 300. В этой функциональности раз в месяц у вас будут возникать отказы, и центральная система банка будет простаивать шесть часов. Можно посчитать, сколько вам будет стоить этот простой?» Вот это и будет объём убытков. Вы нам не даёте деньги на 500 ч/часов — значит, у вас будут убытки, и вот столько они будут стоить (обычно, больше пресловутых 500 часов на тестирование).

Это гипотезы, но гипотезы должны быть обоснованные. Есть такое понятие «Защита оценки» — вас спрашивают «Почему?», а вы отвечаете не просто «Потому», но аргументированно «Потому, что…» и дальше разъясняете объективные аргументы  тому человеку, который этот вопрос задаёт.

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

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

Пример — штрафные санкции из  контракта Сбертеха: шесть серьезных дефектов в продакшн за полгода — штраф в размере стоимости контракта на разработку ПО. Шесть дефектов в огромной системе — это абсолютно реальная вещь. Есть резон брать на себя такие риски?

Если всё протестировать нельзя, то следует ли из этого, что у нас всегда непредсказуемое качество? И как можно его предсказать?

 Позволю себе сослаться на свой доклад на SQA Days в 2009-ом в Питере, где это обсуждалось https://www.slideshare.net/SQADays_2009_Piter/ss-1703956 (сохранились только слайды).

Предсказать можно. Да, есть методы количественного управления — «шесть сигм», статистическое управление и так далее. С вероятностью 99,97% можно оценить количество дефектов, которые у нас будут на выходе. Если есть более тридцати измерений, то статистика весьма достоверная, и можно предсказывать количество дефектов. Это требует определённой процессной культуры и определённой профессиональной инженерной культуры в тестировании, но до конкретного уровня и с конкретной точностью это оценивать можно. Тогда вы скажете, что если тестирование будет проводиться с такими-то параметрами, то у нас будут в продакшн (упростим для простоты) два серьезных дефекта на 10 000 строк кода. Мы можем соотнести затраты и выгоду, и защитить эту оценку.

А в ситуации «Дайте нам 500 или 5 000 ч/часов, только мы не знаем, что получится в результате», демонстрируется профессиональная  беспомощность, что не есть хорошо.

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

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

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

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

Оценивали ли вы затраты на обучение и на тестирование? Есть ли техники нахождения баланса, когда дешевле привлекать специалиста извне, или дешевле обучить своих сотрудников?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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