Они учат тестированию программистов

Автор: | 12.05.2016
Обложка книги "Тестирование черного ящика"

Обложка книги “Тестирование черного ящика”

В начале декабря 2015-го я неосторожно пообещал Никите Макарову (папа автоматизации тестирования в “Одноклассниках”) объяснить, почему книга Бориса Бейзера — это про тестирование, но не для тестировщиков, а для программистов, поэтому и читать ее надо не так, как Канера.

Судя по календарю, я невероятно шустр и быстр, а Никита — неизменно крут и терпелив.

Итак, да, изрядное кол-во любопытных тестировщицких зубов обломалось о книгу Бориса Бейзера “Тестирование черного ящика”, йо-хо-хо!

Мои там тоже остались 🙁

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

Перевод там гнилой, что ли?

Ну…

К нашему всеобщему нажалию, на русском языке Бейзер распространяется только через уже классический перевод издательства “Питер” (2004-й год, переводчик А. Раздобарин), и после ихних тогдашних переводов там смысл того, что просто хотел автор сказать, конечно, просто так получается, что не всегда, разумеется, но если, однако же, вдуматься, то конечно же, скоро станет ясно, о чем смысл вообще и вот, безусловно, скоро всё прояснится и сразу всё станет понятным.

Будете перечитывать?

И да, оригинал “бейзера” читается намного проще и внятнее. Но где ж его взять?

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

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

Вкратце:

они учат тестированию программистов,

а не тестировщиков.

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

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

Домашнее упражнение:

  1. Оценить этот минимальный уровень врубания в тему.
  2. Посмотреться в зеркало.

И Бейзер

на протяжении десяти лет провел свыше 200 технических семинаров для тысяч тестировщиков,

и Майерс

…served as a lecturer in computer science at the Polytechnic Institute of New York University, where he taught graduate-level courses in computer science,

и Йоргенсен

…since 1986, he has been teaching graduate courses in software engineering, actually in Grand Valley State University, Michigan

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

То есть, не для меня Дон разольется.

Все аналогичные авторы рассматривают тестирование как некую логическую дисциплину, которая направлена на ПРЕДУПРЕЖДЕНИЕ появления багов в ПО. То есть, ДО ТОГО, как пишется код.

Собственно, классическая Analytic school всего нашего тестирования ПО.

Это даже не совсем тестирование программного обеспечения, это тестирование алгоритмов, на основе которых будет написано программное обеспечение. Там даже тест-кейсы не особо нужны 🙂 Бо «предупреждение багов» в академическом смысле делается не посредством наших любимых проверок вроде

  1. Открыть браузер,
  2. открыть сайт,
  3. кликнуть по полю Login,
  4. на серьезных щщах ввести в поле ‘Login’ всякую туфту
  5. и убедиться в том, что залогиниться невозможно

Это «предупреждение» всегда делается задолго до того, как программа написана;

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

это делается посредством изучения логики будущего кода с помощью структурных (белый тезис ящик) или поведенческих аналитических методов (черный ящик);

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

это делается посредством расписывания причинно-следственных диаграмм (“Мне трудно объяснить логические модели без привлечения булевой алгебры, а ее нет смысла учить, если вы не владеете диаграммами Карно-Вейча” © Борис Бейзер);

это делается тогда, когда от вероятных ошибок в ПО мир рухнет в Тартарары и еще дальше, буквально в лапы Скараоцки.

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

Про молдавские болота: долго объяснять, справок на всех вас не хватит…

Парни, которые с детства родились Шелдонами Куперами, всё это понимают органично. Всем остальным соваться в тестирование алгоритмов незачем.

И звучит всё это круто…

Однако, Петька,

есть

один

нюанс… ©

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

Увы.

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

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

Кстати… Буквально недавно на собеседовании спросил “Про пестицид эффекта”, и получил обстоятельный, классический ответ.

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

Я и уточняю у бро, мол, “А ничего, что я спросил про ‘пестицид эффекта’, а не про ‘эффект пестицида’?

Засмущалси бро, покраснел слегка /от ненависти ко мне/, а мне чо, я ж тестировщик, я привычный.

С другой стороны — ну, позитивный джун… Ну, будет писать позитивные баг-репорты…

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

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

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

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

…я посетил лекцию в Инженерном институте. Проходила она так: “Два тела… считаются эквивалентными… если равные вращательные моменты… производят… равное ускорение. Два тела считаются эквивалентными, если равные вращательные моменты производят равное ускорение”. Студенты сидели и записывали под диктовку, а когда профессор повторял предложение, они проверяли, все ли правильно записано. Потом они писали следующее предложение и еще одно, и еще одно. Только я один знал, что профессор говорил о телах с одинаковыми моментами инерции, а уяснить это было трудно.

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

После лекции я спросил одного студента:

– А какой будет экзамен?

– Очень простой. Я могу Вам прямо сейчас назвать один из вопросов, – он заглянул в тетрадь и сказал: “В каком случае два тела считаются эквивалентными?”. А ответ: “Два тела считаются эквивалентными, если равные вращательные моменты производят равные ускорения”.

Так что, как видите, они могли сдавать экзамены, и “учить” все это, и не знать абсолютно ничего, кроме того, что они вызубрили.

Императивы учебной программы ISTQB весьма близки к этому способу мышления, но скомпоновано всё чуууууточку проще, поэтому и подходит для многих, а не только для выпускников курса “Программное обеспечение” в системе военного образования США 🙂 Но результативность…

У меня сейчас на учебной сковородке прожаривается очередной обладатель сертификата ISTQB, который с нуля учится тому, что такое тест-кейсы и как их надо придумывать. Ну не поубивав бы?!

И опять же репрезентативное для большинства осертификаченных: “У нас на проекте все это применять не приходится“. Ещё бы… Для занятия тест-дизайном знания и умения нужны, а не сертификаты.

Почему все так неоднозначно и криво?

Ну… потому, что ТАК МОЖНО.

Если бы выпуск ПО с багами был невозможен, если бы ПО действительно нужно было ВСЕГДА тестировать так тщательно, как то подразумевает академическая выучка, то и пресловутый “быстрый вход в профессию” был бы априори невозможен, и скорость разработки была бы невелика, и качество ПО было бы очень, очень высоким.

Но миру не нужно, чтобы всё ПО было высокого качества. Миру нужно, чтобы ПО просто работало.

Поэтому можно выпускать некачественный софт — и он работает.

Просто иногда его надо постоянно обновлять. Блеать!

И поэтому МОЖНО знать, как надо тестировать, но нифига не уметь тестировать.

И также поэтому МОЖНО тестировать, не особо понимая, что именно перед тобой открыто: “браузер” или “фаерфокс”; и откуда открывается интернет-магазин, с “сайта” или с “сервера”; и технику разбиения чего-либо на классы эквивалентности объясняют/воспринимают на примере дурацких карандашей, и тем не менее, компьютеры работают, сайты открываются, цивилизация продолжается. То есть, не всё так страшно.

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

Но попробуйте выпускать обычный, некачественный софт для военщины…

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

Или более приземленное: https://www.google.com.ua/advanced_search протестируйте, используя только классы эквивалентности карандашиков и вписывание лютой туфты в поля ввода…

Или, раз уж речь зашла, подумайте, как иначе, если не “по-академически основательно”, можно спроектировать и протестировать инфраструктуру, на которой когда-то зижделись “Одноклассники” (она однажды ПОЛНОСТЬЮ “сыпанулась” из-за одного бага, который в принципе присутствует у всех и никому не мешает уже сто лет в обед):

…нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.

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

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

Читать Бейзера можно/надо будет когда-нибудь потом, когда/если тестировщик дорастёт до понимания сути тест-дизайна. Все те вещи, о которых говорит великий старик, можно изложить и более простым языком, более простыми образами, и когда начинаешь их понимать — о, Бейзер очень крут для постижения тест-дизайна!

Поэтому “и сейчас, и везде” будут начинающие тестировщики читать Бейзера да Йоргенсена, и удивляться тому, что за хрень там понаписале, бо непонятно.

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

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

\ToDo{Прекратить руководствоваться логичным, но до невозможного дурацким соображением о том, что “Но ведь если тестировщик научится программировать, то он станет программистом!!!“. Не станет. Знание английского языка не делает вас англичанином, но помогает более тонко и всеобъемлюще понимать мир и других людей}.

Next step: “Они учат тестировщиков программировать

Они учат тестированию программистов: 3 комментария

  1. Igor Khrol

    Спасибо! Прекрасный текст и мысли!

  2. SALar

    Прекрасно, Алексей.
    1. Про “бразильскую систему образования” я хотел отдельную статью писать. Уж больно важная тема.
    2. Наконец то вижу критику ISTQB. Надеюсь увидеть критику

  3. Алексей Лупан

    Да кака она бразильска-то, это Фенйман все молдавские/украинские вузы одним махом описал…

Добавить комментарий

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