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

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

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

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

Почему две:

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

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

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

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

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

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

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

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

А ещё было удивительно сложно осознать невозможность редактировать что-либо на бумаге — кмх… Клавиша 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 земном году). Он повидал настолько много всякого, что может в любой момент выдать афоризм на любую тему, с контекстом или без. Характерные примеры его ВНЕЗАПНЫХ высказываний:

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

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

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

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

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

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

Привет друзья! C вами Георгий, основатель сервиса GetMentor.dev.

Если вам лень читать много букв внизу (это нормально), то краткое содержание такое:🎉СПАСИБО ВАМ БОЛЬШОЕ!🎉

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

Только вот в чём дело – у меня нет огромного отдела маркетинга, который придумал бы мне клёвый текст с планами по улучшению мира. Нет отдела дизайнеров, которые бы нарисовали нам крутые картинки для привлечения внимания. Честно признаться – у нас вообще нет никакого отдела. Есть только я, Влада (наша волшебница слова) и Ира (ответственная за придумывание фич). Но зато у нас есть огромное желание помогать людям давать и получать помощь в профессиональном развитии, учёбе, работе и жизни. И я считаю, что этого более чем достаточно! Главное – это искренность своих чувств, а не точно выверенные формулировки в тексте для поднятия продаж. Соу лэт ми спик фром май харт, как говорится.

Наш сервис запустился в феврале 2021 года и за эти неполные 11 месяцев помог состояться более чем 3000 первых контактов между менторами и менти. Сколько там по итогу было встреч – нам неизвестно, да это и не важно. Главное, что люди нашли друг друга и наша задача выполнена. В этом нам помогли эксперты индустрии, профессионалы своего дела, классные ребята и девчата, которые в какой-то момент решили, что больше не могут молчать и хотят стать наставниками. Их с нами уже более 500 человек и это число растёт практически каждый день. Я безмерно рад и счастлив, что благодаря GetMentor получается реально делать что-то полезное, а главное – важное и нужное. Спасибо!

Наверное ни для кого не секрет, что наш сервис не является коммерческим в классическом понимании этого слова. За свои услуги мы не берём комиссии или каких-то иных денег ни с менторов, ни с менти. Во-первых, я твёрдо верю в то, что сервис поиска наставников должен быть максимально простым для обеих сторон, а значит, задача посредника – свести людей и уйти в тень. Во-вторых, я делал этот сервис не ради денег, у меня и так всё хорошо, тьфу тьфу тьфу. В-третьих, это тупо сложно и невыгодно операционно. И в итоге это моё решение, пожалуй, было лучшим стратегическим решением ever с моей стороны. Потому что из-за этого наш сервис получил кучу поддержки с различных сторон. Менторы пишут про нас у себя в блогах, компании предлагают коллаборации и поддержку (как, например, Яндекс.Практикум), а простые пользователи поддерживают донатом. Если вы тоже хотите нас поддержать, то вот вам ссылки на Patreon, PayPal или для перевода на карту. Спасибо!

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

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

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

Ваш новогодний Георгий из https://getmentor.dev

• Открыть в Firefox страницу “about:config”
• Найти параметр toolkit.legacyUserProfileCustomizations.stylesheets
• Одним даблкликом сделать его = TRUE
• Открыть страницу “about:profiles”
• Узнать там КОРНЕВОЙ каталог своего профиля Firefox.
  • Кроме корневого есть и локальный каталог, который находится в профиле юзера. Игнорируем локальный каталог.
  • Скорее всего, будет представлено несколько профилей браузера. Надо найти только тот, у которого в разделе «Профиль по умолчанию» отмечено «да», остальные игнорим.
  • Название профиля будет нечеловеческим, вроде “04l0hhhm.default-1234551996427” или “p191htyk.default-release”. Это нормально.
• Открыть — повторюсь — КОРНЕВОЙ каталог своего профиля — и закрыть Firefox.
• Создать в корневом каталоге своего профиля новый каталог — “chrome”
• Создать в новом каталоге “chrome” новый файл “userChrome.css”
• Записать в файл “userChrome.css” код для управления стилем вкладки в фокусе.

/* Active Tab text color */
.tabbrowser-tab[selected="true"] {
    font-weight: bold !important;
    font-size: 15px !important;
    color: #d9c3c5 !important;
    }
/* Active Tab background color */
.tab-background[selected="true"] {
    background-color: #4753bd !important;
    background-image: none !important;
    } 

• Запустить Firefox.

А давайте ещё фокусы!

/* Source file https://github.com/MrOtherGuy/firefox-csshacks/tree/master/chrome/multi-row_tabs.css made available under Mozilla Public License v. 2.0
See the above repository for updates as well as full license text. */

/* Makes tabs to appear on multiple lines */
/* Tab reordering will not work and can't be made to work */
/* You can use multi-row_tabs_window_control_patch.css to move window controls to nav-bar*/

/* You might want to move tabs-new-tab-button outside tabs toolbar for smoother behavior */

/* Change the --multirow-n-rows to change maximum number of rows before the rows will start to scroll  */

:root{
    --multirow-n-rows: 2;
    --multirow-tab-min-width: 80px;
    --multirow-tab-dynamic-width: 1; /* Change to 0 for fixed-width tabs using the above width. */
}

/* Scrollbar can't be clicked but the rows can be scrolled with mouse wheel */
/* Uncomment the next line if you want to be able to use the scrollbar with mouse clicks */

/* #tabbrowser-arrowscrollbox{ -moz-window-dragging: no-drag } */

/* Uncommenting the above makes you unable to drag the window from empty space in the tab strip but normal draggable spaces will continue to work */

#tabbrowser-tabs{
  min-height: unset !important;
  padding-inline-start: 0px !important
}

@-moz-document url(chrome://browser/content/browser.xhtml){
  #scrollbutton-up~spacer,
  #scrollbutton-up,
  #scrollbutton-down{ display: var(--scrollbutton-display-model,initial) }

  scrollbox[part][orient="horizontal"]{
    display: flex;
    flex-wrap: wrap;
    overflow-y: auto;
    max-height: calc((var(--tab-min-height) + 2 * var(--tab-block-margin,0px)) * var(--multirow-n-rows));
    scrollbar-color: currentColor transparent;
    scrollbar-width: thin;
    scrollbar-gutter: stable;
    scroll-snap-type: y mandatory;
  }
}

.scrollbox-clip[orient="horizontal"],
#tabbrowser-arrowscrollbox{
  overflow: -moz-hidden-unscrollable;
  display: inline;
  --scrollbutton-display-model: none;
}

.tabbrowser-tab{ scroll-snap-align: start; }

#tabbrowser-tabs .tabbrowser-tab[pinned]{
  position: static !important;
  margin-inline-start: 0px !important;
}

.tabbrowser-tab[fadein]:not([pinned]){
  min-width: var(--multirow-tab-min-width) !important;
  flex-grow: var(--multirow-tab-dynamic-width) !important;
  /*
  Uncomment to enable full-width tabs, also makes tab dragging a tiny bit more sensible
  Don't set to none or you'll see errors in console when closing tabs
  */
  /*max-width: 100vw !important;*/
}

.tabbrowser-tab > stack{ width: 100%; height: 100% }

/* remove bottom margin so it doesn't throw off row height computation */
#tabs-newtab-button{ margin-bottom: 0 !important; }

#tabbrowser-tabs[hasadjacentnewtabbutton][overflow="true"] > #tabbrowser-arrowscrollbox > #tabbrowser-arrowscrollbox-periphery > #tabs-newtab-button {
  display: flex !important;
  align-items: center; /* Fx <112 compatibility */
}

#alltabs-button,
:root:not([customizing]) #TabsToolbar #new-tab-button,
#tabbrowser-arrowscrollbox > spacer,
.tabbrowser-tab::after{ display: none !important }

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

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — садись и слушай. Однажды, давным-давно…

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

Верификация — проверка соответствия приложения прописанным требованиям.

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

Ну, и чо?

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

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

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

А валидационные запросто отклоняли, бо «тестируется сценарий, которые не предусмотрен требованиями».

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

Если в этот момент юзер решит вернуться на шаг назад — он должен передвигаться между экранами только через JS-кнопки «back» и «forward» в приложении (почти каждый современный сайт — приложение). Так написано в требованиях, так реализовано программистами.

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

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

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

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

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

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

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

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

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

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким? 🙂

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

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

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

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

Совершенно ненужный эпилог

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

You know it’s sad but true.

А Любомир Геревич не знает, кто дядя Боб. Так вот, это один из тех семнадцати чуваков, которые собрались в феврале 2001-го в Snowbird ski resort в Юте для того, чтобы потрындеть о том, как можно было бы обустроить жизнь программистскую.

На этом фото Роберт Мартин третий слева.

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

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

Книга воспринимается как трёхсоставная:

1. общий обзор
2. технарные штучки
3. менеджерские дрючки

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

1. Да! Именно так! А я говорил! Да!
2. Неужели!? Неужели я настолько ошибался? Нет!

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

Контекст важнее всего. Непонимающие контекст и желающие перенимать только практики (best practices only!) — долбанные придурки с излишним запасом энтузиазма, блеать.

Контекст

важнее

всего.

Контекст определяет содержание и способы решения задачи.

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

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

В общем, нет никакого противопоставления Agile vs Waterfall. Сегодня всё точно так же, как было раньше, когда молодой дядя Боб фигачил код на старых компьютерах. Иногда получается. Иногда нет.

In 1970, I was 18 years old, working as a programmer at a company named A. S. C. Tabulating in Lake Bluff, Illinois. The company had an IBM 360/30 with 16K of core, an IBM 360/40 with 64K of core, and a Varian 620/f minicomputer with 64K of core. I programmed the 360s in COBOL, PL/1, Fortran, and assembler. I wrote only assembler for the 620/f.

We wrote our code on coding forms using pencils, and we had keypunch operators punch them onto cards for us. We submitted our carefully checked cards to computer operators who ran our compiles and tests during the third shift because the computers were too busy during the day doing real work. It often took days to get from the initial writing to the first compile, and each turnaround thereafter was usually one day.

What process did we use during those days? It certainly wasn’t Waterfall. We had no concept of following detailed plans. We just hacked away on a day-to-day basis, running compiles, testing our code, and fixing bugs. It was an endless loop that had no structure. There was no discipline in the way we worked. It was just code and fix, code and fix, day after day, month after month.

I first read about Waterfall in a trade journal sometime around 1972. It seemed like a godsend to me. I felt the power of the concept. I wanted to believe it. Because, if it worked, it was a dream come true.

Apparently I wasn’t alone, because many other programmers and programming shops caught the bug too. And, as I said before, Waterfall began to dominate the way we thought.

It dominated, but it didn’t work. For the next thirty years I, my associates, and my brother and sister programmers around the world, tried and tried and tried to get that analysis and design right. But every time we thought we had it, it slipped through our fingers during the implementation phase. All our months of careful planning were made irrelevant by the inevitable mad dash, made before the glaring eyes of managers and customers, to terribly delayed deadlines.

Вот и Agile сегодня dominated, but it didn’t work. Точнее, и не должен работать. Это же не метод, с чего бы ему работать? Это набор принципов, которые просто помогают понять, что правильно, а что нет. Подменять процесс принципами — ой, всё…

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

И сегодня на эту тему дядя Боб сделал твит:

Agile is not about going faster. Agile is about destroying hope. The data produced by a good agile team provides a cold dose of reality to the managers — in time for them to — manage.

Делать замеры метриками, да ещё и менеджерскими — нельзя.

Warning

Test coverage is a team metric, not a management metric. Managers are unlikely to know what the metric actually means. Managers should not use this metric as a goal or a target. The team should use it solely to inform their testing strategy.

Double Warning

Do not fail the build based on insufficient coverage. If you do this, then the programmers will be forced to remove enough assertions from their tests in order to get the coverage numbers high enough. Code coverage is a complex topic that can only be understood in the context of a deep knowledge of the code and tests. Don’t let it become a management metric.

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

An Agile project begins with analysis, but it’s an analysis that never ends. The first thing you know is the date. We subdivide that time into regular increments called iterations or sprints.

Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.

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

Но это так же глупо, как верить в то, что часы отсчитывают время.

Ничего они не отсчитывают.

Если часы остановятся (или мы их поменяем), то что, время перестанет отсчитываться?

Если положение стрелок поменяем, то что, солнце быстрее уйдёт за горизонт?

Но часы нужны, чтобы ориентироваться относительно времени.

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

— Но ведь нам нужен Product Owner! — тонко заскулили из-под шконки. — А если не вовлекать закащщика в нашу кухню, то аджайла не будет!

Вот пример того, до чего доводит это скулёж: эффективные чуваки додумались нанять Product Owner:

Так все же, где найти PO?

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

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

Ну не пиф-паф ли?!

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

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

Если же тыкать в заказчика этим нашим аджайлом, то придётся очень упрощённо объяснять, что это такое, придётся это всё продавать. И будет вот это вот всё «Ну, это когда быстрый деплой. Всё будет очень быстро. И вам не нужны будут тестировщики. И после каждого спринта у вас будет работающий продукт» с очень далекозаползающими последствиями. Упрощение же. Для дебилов.

Работающий продукт ≠ Хорошо/правильно работающий продукт.

Остальное додумывайте сами.

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

Без звука. Автор видео — Жека Козлов.

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

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

Бо если не понять, почему всё именно так, то и не понять, как сделать иначе.

Все «старые» книги про тестирование написаны программистами, которые объясняют тестирование программистам. Майерс, Бейзер, Вайнберг, Йоргенсен — не так уж много их, но что дошло до наших дней, то если не блестит, то поблёскивает.

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

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

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

Пример такого подхода:

— Чтобы это сделать, надо написать вот такую команду и в ней передать такие-то параметры. Затем будет выполнен вот этот код.

— А если я после команды не буду выполнять этот код? (мечтательно) Я же пользователь, я могу ВНЕЗАПНО передумать или решить перейти к другой задаче

— Надо делать именно так, как было предусмотрено.

Незабываемый звук затвора Colt 1911.

Расширенные зрачки того, кто всё понял про реальные способы обеспечения качества.

Directed by Robert B. Weide (титры).

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

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

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

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

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

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

Знания о программировании можно условно разделить на академические и прикладные, и таки это было сделано. Новичкам приходится [спрашивать на DOU, какой именно язык надо учить] принимать странное решение: или учить абстрактные теории о том, как работают машины, или учиться просто управлять этими машинами. Разве это не следует делать одновременно? Которые башковитые, те умудряются переключаться между этими сторонами, как в старину, а остальным и так всё норм.

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

Современным тестировщикам нет нужды учиться сперва технарному мышлению, затем программированию и потом уже тестированию — это ли не ебалайтунг? Можно не знать Computer science — это и у современных программистов бывает, и, казалось бы, чо? А ничо. Можно не понимать, что такое файл или «временная/пространственная сложность алгоритма». Тестировщику можно вообще не уметь читать/писать код. Тест-дизайн упростился до двух пунктов (разбиение на классы эквивалентности и выявление граничных значений), и это самое сложное из того, что объясняют новичкам, а всё остальное ушло в раздел «просто знайте, что оно существует». Можно просто запоминать термины, не понимая их суть. Можно писать тест-кейсы, не понимая, почему они имеют такую форму. Можно верить в то, что найти все дефекты невозможно, что всё протестировать невозможно, что абыр, извините, валг.

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

Ммм…

Если ждать, то сколько и чего конкретно?

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

Можно компилировать новые книги из старых. Так делают преподаватели (Майерс, Коупленд, Куликов). Можно наматывать поверх компиляции собственный контент (Савин, Виттакер, Блэк, Криспин). Но компиляция основывается на «старых книгах», поэтому опять ничего нового.

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

Тестирование — цельная система, в которой нет ничего лишнего, и всё со всем взаимосвязано. Тестирование полностью зависит от программирования.

Тестирование ПО следует воспринимать и объяснять слитно с программированием, а не отдельно.

• whole picture first,
• details.

The main behaviour of a tester is do not rush with any conclusions about software and to always start with

• Stop! Explain this software, even if it looks understandable. What are the purposes of this software? Why this functionality is needed? How it should work?
• Stop! I need a time for think (analyze this).
• Stop! What are the final expectations?

The basic skill of a tester is to imagine (and to write them as scenarios) a chain of situations

• where the software is intended to work ‘as expected’ (correct user login),
• those that may happen, and should be tolerated by software (wrong user login),
• those that should not be tolerated, even if they are possible (wrong data encoding).

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

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

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

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

Видео после текста.

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

В 2014 году в Киеве было под тридцать курсов по тестированию. И ещё плюс в Одессе и во Львове. Для Украины это было не так, чтобы мало, и большое количество курсов обещало то, что (наконец-то) на рынке появится много обученных тестировщиков. Их можно будет брать на работу и кидать на проекты — бизнес пошёл! Ожидалось, что количество будет переходить в качество.

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

Что будет дальше? Как нам себя вести, и вообще — что нас ожидает?

То, что нас ожидает в будущем зависит от того, что у нас есть сегодня. Есть такой ресурс qatrends.com, где проводятся опросы на различные темы, связанные с тестированием. В последнем опросе участвовало около полутора тысяч респондентов. Этот опрос принёс сразу несколько выводов.

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

Люди, у которых опыт работы больше 3-х лет, осваивали профессию тестировщика самостоятельно (я из их числа), и они пришли в тестирование в 2010-2012 годах. То есть шесть лет назад. То есть тестировщики, которые приходили на работы, которые появлялись, казалось бы, из ниоткуда, по качеству своему, и по техническому оснащению, и по своему состоянию намного превосходят тех тестировщиков, которые появляются сейчас.

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

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

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

Она присутствует на рынке в виде ужасающей ямы, в которую скатываются все. Яма-воронка, скажем так, которая затягивает, даже тех, кто понимает, что можно сделать что-то по-другому, так или иначе. В большинстве резюме, которые были ещё лет 5 назад тестировщики писали, что владеют Microsoft, Excel, PowerPoint, Word и прочие интересные вещи. В современных резюме тестировщиков (практически у всех) указано, что «закончил такие-то курсы». Такой вот тренд времени. Это не хорошо и не плохо, просто фиксируем то, что есть.

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

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

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

Среди преимуществ курсов было заявлено, что преподаватели — реально работающие практики с огромным опытом. Это хорошо для привлечения аудитории, которой ещё можно сказать, что, например, учим английскому языку с носителями языка. Кто-нибудь научился английскому языку, изучая его именно с носителями, находясь здесь, в русско-украиноязычной среде?! Логика говорит, что это — призрачный путь. Опыт показывает, что для того, чтобы выучить английский язык, нужно сначала понять, как он устроен. Для этого не нужно сразу начинать говорить только на английском, да еще и с носителем. То есть, идея о том, что если на курсах преподаватели с реально работающей практики, с огромным опытом, следовательно, там можно научиться чему-то хорошему — ошибочна.

У практика можно научиться тому, что он уже может делать, и зачастую делает неосознанно. Если вы наблюдали когда-нибудь за людьми, которые работают на уровне неосознанности, они делают все очень быстро. Все, чему можно научиться в работе у практика, это просто перенять какие-то навыки или же шаблоны поведения. Практик не объясняет, почему он что-то делает, он не объясняет, почему этот феномен существует, как этот феномен появился, как он связан с другими феноменами — именно всё то, что нужно объяснять другим начинающим.

А минусы существующих курсов в том же опросе заявлены совершенно по-идиотски — нехватка практики. 50% опрошенных на это указали. То есть они приходят на курсы, на которых рассказывают реально работающие практики, а после того, как курсы проходят, выпускники жалуются, что практики было мало. Вот каг таг?

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

1. пойду на курсы —
2. значит, подготовлюсь к работе —
3. значит, возьмут на работу.

Это логично. А опыт показывает, что это тупиковый путь.

Следующий тренд, который тоже ведет к однозначности, но он представляет собой видение работодателей. У них ожидание следующее:

1. пришел с курсов =
2. подготовлен к работе —
3. значит, возьмем на работу.

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

Чем отличаются краткосрочные курсы от долгосрочного вузовского образования? Ничем. Просто вуз — это курсы длинной в несколько лет. Современные курсы это обучение длинной в несколько месяцев. Какая может быть практика за несколько месяцев?! Да и даже за несколько лет её бывает сложновато получить.

Сложность обучения современных тестировщиков (это то, что я заметил) в том, что тестировщики старой школы проходили тестирование уже понимая, что такое программирование, или, по-меньшей мере, могли на HTML могли сделать что-нибудь. Хотя бы. Это представители того поколения, которое ещё живо, они ковырялись в компьютерах из интереса, а не будучи принужденными это делать, потому что нужно работу найти. Я когда ковырялся в компьютерах — я ещё и журналистом был! У меня не было дома компьютера — это приветствие тем, кто говорит, что невозможно научиться программировать, потому что у меня дома нет ноутбука. Можно научиться.

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

Ну, и вузы. В вузах тестировщиков не учат. Там и программистов не учат, на самом деле.

Делаем выводы.

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

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

Итак, курсы высшего образования ничего не стоят. Краткосрочные курсы, оно же ПТУ древнее, оно же нынешние курсы — не вуз, следовательно, они чего-то стоят.

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

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

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

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

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

Например, есть такое понятие — регрессионное тестирование. Всем знакомо? А еще есть понятие регрессивное тестирование. Знакомо? В чем разница между регрессионным и регрессивным тестированием?

— Регрессивный это ухудшающийся, а регрессионный это в обратном направлении.

— Нет! Нет разницы между этими терминами. Regression Testing — это однозначный феномен. Просто он переводится по-разному. Люди, которые учились тестированию, читая только Савина, привыкают к слову «регрессивный», потому что Савин именно так его использует — все регрессионное называет регрессивное.

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

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

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

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

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

Ещё неприятное еще. Все однотематические курсы, общенаправленные, со временем неизбежно усредняются. Чем отличается выпускник SkillUP от выпускника GoIT? Цветом футболки они отличаются…

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

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

Из-за того, что всё усредняется, студенты становятся абстрактно знающими тестирование. Абстрактное знание тестирования — идиотизм совершенный! Представьте себе, что нам надо сейчас кого-нибудь обучить тестированию, и мы не знаем, где он будет работать. Чему его учить?! Тестированию десктоп, веб, основам чего? Как? Что он будет делать?

Тестирование — неоднозначный феномен. Хоть и слово одно и то же, но когда тестируешь алгоритмы, это вообще другие подходы и другое мышление, нежели когда тестируешь функциональные вещи. Поэтому: чему должны учить курсы? Тому, что сейчас на рынке востребовано? А что сейчас востребовано на рынке? Веб и мобайл, очень неоднозначные шняги. Веб разный бывает. Мобайл постоянно меняется. Чему именно надо учить? Конкретным технологиям, или общим принципам?

Ок, не надо учить тестированию ВООБЩЕ, это логично. Учить нужно по-другому. Учить нужно частностно и личностно. Нужно не учить, а тренировать. Это очень сродни со школами, которые учат боксу, шахматам, плаванью. Школ много. Стилей обучения очень много. Но это все не командное обучение. Каждое обучение происходит личностно. Каждый пловец учится личностно, каждый борец учится сам, а не наблюдая за тем, как другие плавают, делая выводы о том, что когда мне нужно будет нырнуть, я скачаю учебник, и… значит, шаг один, шаг два… что делать?

Поэтому учить тестированию означает — нужно тренировать. Слово «тренировать» неоднозначно. Большинству людей до одного места разница между лекцией и тренингом. Вот то, что я сейчас делаю это что? Лекция? Это доклад вообще. Лекция — это когда просто рассказываешь о том, что существует нечто, некий феномен, у него есть какие-то свойства, особенности. А тренировать означает дать задание и предложить его выполнить. Даже если не знаешь, даже если не понимаешь. Просто возьми и сделай хотя бы что-нибудь.

Те, кто по психике своей не способны дальше продвигаться, на этом ломаются. И это очень хороший показатель. Сломался — не надо дальше заниматься. Если же не сломался и попытался хотя бы что-то сделать, объяснение того, почему получилось или не получилось, ляжет на уже подготовленную почву. Обучающийся начнет понимать намного лучше то, что он уже сделал, хотя бы чуть-чуть, или не получилось. Даже если ему сначала абстрактно, как в школе, рассказать о том, что существуют различные алгоритмы, и эти алгоритмы разруливаются вот 150-ью способами. До большинства из этих до способов можно додуматься. Когда учишься самостоятельно, это, на самом деле, тренировка и есть. Не обязательно в зале тренироваться боксу. Можно в Grand Theft Auto потренироваться. Как бы там ни было, личностно надо все делать. Научиться тестировать в группе, на курсах логично и разумно, но нецелесообразно вообще.

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

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

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

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

Разница достаточно проста. Все те, кто пытался это дело освоить, знают, что поначалу ничего не получается, так ведь? Слишком абстрактно все. Но мы занимаемся абстрактными вещами, мы создаем абстрактные артефакты. Программное обеспечение создается по абстрактным артефактам, которые называются «требования». Абстракции выше крыше, ничего не поделать.

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

Зачем проходить собеседование, если потом будешь тупить?! Жизнь заставляет, безусловно. Сначала нужно работу получить, потом я буду учиться тому, что нужно на работе. Логично? Глупость ужасающая! Но логично. Есть очень много людей, которые учат только то, что нужно будет на работе. Бить их нельзя, но идею эту надо из людей всячески выбивать.

Почему то, о чём я сказал, является проблемой? Рынок курсов создают безработные люди, то есть нынешние студенты. Безработному человеку нужны не хлеб и не поэзия Шевченко, и не автомобиль. Нужна работа. На входе на курсы должна светиться огромная вывеска: «После курсов будет работа!». Всё, что делается на курсах, это подготовка к получению работы. Не к работе, а к её получению!

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

Можно ли в этом что-нибудь изменить? Ну, логика обыкновенная говорит о том, что преподаватели должны отойти от парадигмы «опытный практик». Преподаватели должны готовиться к тому, чтобы преподавать, это особый вид искусства. Есть такое хорошее выражение у каратистов — хороший мастер не обязательно хороший учитель. И наоборот — хороший учитель не обязательно Брюс Ли. Потому что это разные навыки. Потому что для того, чтобы научить нужно иногда наказать, нужно иногда поощрить. В работе нет понятий «наказывать» и «поощрять». В работе всё однозначно — умеешь делать, сделал; не умеешь делать — не занимайся тем, что не умеешь делать. На работе надо понимать, что результат успешности это просто выполненная работа, и как ты её сделаешь, неважно. Сделал сам или зааутсорсил её кому-то моментально. Этому научить очень тяжело. Это начинаешь понимать только тогда, когда уже попадаешь в окружение рабочее.

Преподаватели тоже друг от друга чем отличаются — непонятно. Как отличить сильного от слабого преподавателя? Количеством выпущенных студентов? Цветом футболки? Восторженностью студентов? Залысиной? Непонятно.

Что такое хорошие курсы? Чем их отличать? Хорошие курсы от плохих отличаются качеством выпускников. Следовательно, если будет хороший преподаватель на курсах, то и курсы будут хорошие. То есть, все ищут хороших преподавателей, но искать их среди практиков разумно, но тяжело, потому что, повторюсь, практики не обязательно умеют объяснить. Быть тренером — это отдельная профессия, ей где-то тоже надо научиться. А где? А как? А сколько времени для этого нужно?

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

Так вот что такое «Регрессионное Тестирование»!

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

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

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

Реальными курсами будут признаваться те, которые обеспечивают нужды владельцев проектов. Представьте себе, что вы заказываете не тестировщика, а сантехника домой. Сантехника вы будете брать того, который только что закончил курсы ВООБЩЕ, или того, который закончил курсы по подготовке конкретно к выполнению тех задач, которые именно вам нужны? Логично же…

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

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

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

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

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

Точно так же надо тренировать тестировщиков.