QA процессы — можно внедрить, конечно, но

• в разработке ПО гарантирование качества не гарантирует ни качества, ни отсутствия багов. Долго объяснять, но это так, ПО не делается, как клоны на фабрике, это каждый раз уникальный артефакт со множеством особенностей, из которых некоторые наследуемые, а некоторые неожиданно новые.
• тестирование стоит на фундаменте из требований, которые надо сперва наладить и запрягать перед каретой, а не после. Если мы деплоим 256 изменений за один раз по вторникам, то как именно трэкать эти самые требования? Где? Кем? Скорее всего, это ПО развивается не по требованиям, а по невнятным ожиданиям бизнеса. Нет требований — нет и гарантий соответствия им, потому что нечему соответствовать, тестирование живёт в режиме «сравнить наблюдаемое с ожидаемым». Нет ожиданий — не с чем сравнивать, остаётся только исследование в режиме «я не уверен, как оно должно работать…» А исследование ПО в QA этого ПО не конвертируется.

Любопытно, что всё то, что мы сегодня переживаем, уже было — в начале девяностых, когда понадобилось ускорить поставку ПО, потому что бизнес же тестирует гипотезы и идёт вслепую, а не по продуманному и однозначному пути. И пришёл agile, и все ускорились, и в двухтысячных годах XX века я не видел в разработке живых тест-аналитиков и тест-дизайнеров, к тому времени их уже всех свезли на остров Литтл-Сент-Джеймс (в составе Американских Виргинских островов), где американский финансист Джеффри Эпштейн & Co регулярно путали их с девицами красными.

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

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

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

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

Всё, как мы любим — без воды, без резолюции, без нервотрёпки, без коагуляции десереализационного инкремента, без хтонических завихрений, без un pahar de tocănică gustoasă la a voastră masa măiastră.

Хочешь ещё?

Я понимаю коллегу, который тоже задолбан и был вынужден предложить хоть что-то под видом требований, он поднатужился и выдал — дякую, аж пiдскакую. А дальше со всей этой слезинкой ребёнка что делать?

В норме я могу, читая требования

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

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

Осознание

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

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

Обдумывание

… всё равно мучительно медленный разбор — нужны часы.

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

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

Согласование

Очень важный этап, который мы все дружно скипнем. Сколько раз уже скипали, неужели на этот раз что-то бомбанёт? Вроде не должно…

Выполнение

Вручную тестирование делается медленно — нужны часы.

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

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

А если после всего этого ВНЕЗАПНО выясняется, что требования уже где-то как-то непредсказуемо поменялись, то надо всю эту аналитическую работу выполнять заново. Это реалистично? В погоне «успеть вовремя» её будут выполнять частично, а значит, никаких гарантий не будет, ПО поедет в релиз от станции Тревожность до станции Бадабумц, потому что тестировщики опять пропустили какую-то досадную (местами лютую) мелочь.

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

Всё, как мы любим — без воды, в пустыне, под палящим солнцем…

Ок. Мы превратим тестировщиков в бизнес-аналитиков «с сильным навыком тестирования». И пусть эти аналитики сами гоняют LLM и сами «генерируют соответствующие артефакты», которые только им самим и нужны. Пусть Джек идёт строить дом, и пусть всё заверте…

Вот LLM, которая генерирует код проекта.

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту.

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются юнит-тесты для проверки проекта. Лей в прод.

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

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

Тут пропустим ещё один большой бэмц, после которого всех сразу допрашивают (и не только через сфинктер; что вы так сосредоточились на этом сфинктере, вы больные, что ли?!), а как так получилось, что и юнит-тесты работают, и Playwright работает, а ПО — с багами. Почему вам не хватило времени мозгов проверить руками хотя бы основные happy path? Почему этих happy path так много, товарищи? Давайте заново.

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

А что лить-то? Мы сразу втыкаемся в то, что ручное тестирование проекта требует времени два раза — и для подготовки (когда анализируют требования и придумывают тест-кейсы), и для выполнения. И это всё никак не ускоряется. Быстро льётся, если без тестирования. А вы же хотели тестирования? Хм…

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

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

Почему мы вообще занимаемся этим трудом Сизифа, к которому аргонавты каждый день прилетают и клюют печень да «трахаютЪ мозгЪ», уж простите, не знаю как это произносится по-древнегречески!?

Если делать ПО, которое будет взаимодействовать только с другими ПО, то постоянное тестирование будет ненужным, оно перейдёт в режим одноразовой задачи, вы можете видеть положительный эффект этой условности в разделе API. А если делать ПО, которым будут пользоваться люди (местами бесконечно глупые, местами дъявольски умные), то и проверять его надо людьми, причём постоянно. Как это всё ускорить?

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

Может быть, стоит убрать из этой схемы вообще всех, даром, и пусть LLM сами генерируют код и тесты, и впихивают это всё в CI/CD, и выполняют на проде, и пусть другие LLM этим всем пользуются и всё это покупают. Проекты же делают для прибыли, right? Pedal to the metal.

Hop, hop, hop, hop, hop, hop, hoba!

Я уже много лет не испытываю сложностей с написанием тест-кейсов, мне сложно быстро понимать новый объёмный продукт. Очень мешают иллюзии вроде «а, это мне знакомо…», а потом «ну кажетаг-то, мне же казалось, что оно вот так, а оно вон оно как…»

Тест-кейсы выглядят по-разному не по чьей-то злой воле.

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

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

Логично предположить, что если мы будем придерживаться одного ХОРОШЕГО стандарта, то все сложности исчезнут. Однако логично и то, что «стандарты» всегда тяготеют к «пусть будет много нужной и полезной информации», а это всегда в итоге формат «условно-подробнейших тест-кейсов», которые постоянно хочется «переписать попроще», но времени нет.

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

Тест-кейс — инструкция по созданию тестовой ситуации.

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

Не нужно искать один-единый формат тест-кейсов. На одном и том же проекте надо использовать разные форматы тестов в зависимости от условий и контекста возникающих задач.

Общий подход — пишем тесты в виде идей. Коротко.

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

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

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

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

Простейший алгоритм:

1. глянуть на список вопросов к старшакам условному Senior SDET (экспортед ту pdf на всякий случай), или глянуть сюда
2. напрячься и найти ответы на каждый вопрос по списку,
3. по каждому вопросу сделать отдельный файл с собственным рабочим решением, которое можешь выполнить и объяснить самостоятельно.

В примере всё крутится вокруг java, но ЯП не имеет значения, за какой уже хоть как-то взялся, тот и юзай.

Общие вопросы вроде «24. Детально опишите ваш прошлый проект» можно лихо скипнуть, а можно подумать, как ответить, если когда-нибудь такое спросят.

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

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

Кто ж от такого откажется…

In chocolate only, позязязя…

Я всё запомнил и через сто лет его найду. Алэ суть же не в конфет-боксах и не в конфетах вообще. Взял я телефон наперевес и попытался ему это всё объяснить.

В бытность мою главным спiвпрацювальником по підготувальні тестувальників Astound Commerce, в 2018-ом году, произошёл удивительный казус, без которого наша насыщенная и пресная айтишная жизнь была бы совершенно пресной.

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

Кандидатушкой?

Кандидаторкой?

В общем, «Что вы читали про тестирование ПО?» 

Девушка говорит, что про тестирование читала книгу Лупана. Который, как я знаю, книг не писал.

— Вы… уверены?

— Да-да-да!

Уверенность однозначна. Она читала книгу Лупана. Упомянутый Лупан сидит перед ней неестественно ровно и смотрит на неё… неестественно внимательно.

Вот так смотрел: 0_о

Забегая вперёд…

Впрочем, не будем забегать вперёд. Забежим назад.

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

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

Ну… да.

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

Ну и я, конечно, начал орать и сучить ножками 48-го размера. Бо как зафиксировать на бумаге всё то варево в моей голове, из которого только изредка капали здравые идеи и взрывались всёпроясняющие инсайты?!

Никак.

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

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

Назвал я этот файл с небольшой претензией на (тут сами подберите какое-нибудь слово, бо я хз):

«Практика тестирования программного обеспечения.

Курс лекций для тренера интересующихся тестированием ПО»

Приятно было сознавать, что если я всё-таки умру из компании (что и случилось в 2019-ом), кто-то другой найдёт в моём файле всё для того, чтобы go-go-go дальше.

А неприятно было сознавать то, что этот файл НЕЛЬЗЯ отдавать джунам.

Презентации бывают двух типов:

1. те, которые можно читать самостоятельно,
2. и те, которые сами по себе не имеют смысла, они только оттеняют и иллюстрируют речь докладчика.

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

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

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

Поэтому в самом начале было указано, что

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

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

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

Вернёмся в 2018-й, в Винницу. Я открыл на весь экран pdf, развернул ноут к заявительнице.

— Эта книга?

— Да, она!!!

Титлепейдж «Практика Тестирования» 2014

Неееее можеееет быыыыть!

Забегая вперёд…

Впрочем, не будем забегать вперёд. Забежим вбок.

Может быть, я слишком сильно перегибаю уже перегнутую палку, и не всё так стрёмно?

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

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

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

Это полноценная книга, у ней зарегистрирован номер ISBN (Международный стандартный книжный номер, для книги то же самое, что vin-номер для автомобиля), все дела. Её содержимое вызвало резкие отзывы при публикации в сети. Я был тогда крайне сдержан в оценке, другие не сдерживались, и я их понимаю.

Если очень надо понять, о чём, всё-таки, речь: https://vk.com/wall-35156109_10741 Ваши страхи и ваши риски.

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

Ага. Вот передо мной человек, который/ая от пострадал от прочтения текста, который был для него не предназначен.

С чего начать?

Что объяснить?

Как предложить забыть всё и начать заново?

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

Ещё раз — не все тексты надо оформлять в виде книг и раздавать кому попало. Это может быть очень вредно. Гуманность uber alles же!

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

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

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

А перевзволновавшаяся конкурсантка на самом деле читала книгу сэра Романа Савина, и отреагировала «лупаном» из-за названия каталога и своей общей излишней взволнованности.

Слава молдавскому Аллаху, это уже конец этой истории, почтенный посетитель рынка, собиратель историй. Победила восторжествовала.

Но это не конец всей истории!

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

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

Ой бляяяяя… Кракен хэз бин релизд.

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

Запретить его читать? Никак.

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

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

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

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

А музыка получается у каждого по-разному.

То есть, вредный он-то вредный, но не разрушительный же?!

Ок, файл «Практика тестирования программного обеспечения» принародно объявляется несостоятельным и ненужным. Я им не управляю и не смогу донести ответственность за вероятные последствия его использования. Читать его не возбраняется но и не рекомендуется. Вместо него, если английский позволяет, рекомендую глянуть мой же «Software Testing Glossary».

Он тоже когда-то начинался как служебная записка, которая должна помочь быстро и точно объяснить тот или иной термин из тестирования заказчикам проектов (глоссарий ISTQB для этой цели ВНЕЗАПНО совершенно не подходит), но в корпоративных документах нельзя свободно выражаться и использовать слова stupid или whiskey, поэтому его содержимое было, как следует корпоративным нормам, выглажено и деперсонифицировано, а мой изначальный текст ушёл жить самостоятельно.

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

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

Вас пердупердили.

Мелкий PS про технику этого дела

Файл был полностью набран/оформлен в LibreOffice. В то время я ещё не освоил LaTeX на полную, а то я бы, конечно…

Но оказалось, что нативный LibreOffice — сила, особенно если добавить к нему плагины (нативно либофис в автозамене слабее мсворда, когда надо цепануть концы строк, бо он работает сугубо построчно). Набор текста в режиме разметки first, а оформление опосля — на, всё на хоткеях. Разные типы содержимого (краткое, расширенное, полное) — на. Встраиваемые значения в поля — на. Контроль содержимого в навигаторе — на, и удобнее, чем в MS Word. Свои стили — на на всю катушку. Учёт изображений и таблиц — на. Список литературы в отдельной БД с подсосом значений из неё в файл — на. Обновление ссылок на внутренние сущности — на.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ: надо перейти в режим «Я увольняюсь».

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

Увольняющийся всегда работает очень хорошо.

А он просто делает ровно то, что нужно, не стараясь что-то улучшить.

А он просто делает всё так, как ему было сказано. И вовремя.

А он просто делает не больше того, что было указано.

Отличный работник.

Замечательный работник.

Почему он раньше не был таким? Весёлый, креативный, как жалко, что он уже уходит. Вот всем бы так.

Почему увольняющийся так весел и креативен? Почему так унылы остающиеся?!

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

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

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

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

Какой такой здравый смысл в школе? Вот те два! Вот те шаблон! Вот что имел ввиду автор сей поэмы, когда раскрывал образ Онегина в образе Татьяны!

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

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

А если увольняешься, то уже не страшно. Уже как раз всё делаешь как надо. Уже и экспериментируешь (ну и хрен с ним, если не получится — переделаешь). И ни с кем ни о чём не споришь, не сомневаешься, просто делаешь.

И начинает получаться!

Повторюсь, что речь идёт не о реальном движняке в ближайший порт, а всего лишь о психическом настрое начинающего весляра, будущего капитана своего боевого швертбота класса USS Enterprise.

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

Будете варить мыло?

К манагерам

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

1)

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

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

2)

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

Однако!

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

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

То же самое видно и у спортсменов.

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

P.S. А, ну да, если вы досюда дочитали, то вам интересно узнать, как понять, не болван ли вы. Ну, если вам кто-то что-то вякнул про вашего джуна, а вы не достали плазмаган для защиты своих пацанов, а побежали к вашему виновнику торжества, вытащили его в коридор и начали рвать ему пасть, приговаривая «Почему я должен слышать жалобы от чужих про тебя и краснеть за тебя и страдать за тебя?!», то увы…

Про всё то, что из нашего царства аутсорсинга постоянно не видно.

«Люди, мы дышим воздухом!»,

но мне это всё кажется очевидным сейчас,

а ранее я об этом и не думал.

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

Явление первое. Как-то хозяин постоялого двора, у которого работал упомянутый джун, послал юношу за информацией к главному погонщику каравана, который как раз медленно входил в город. Джун завёл осла, метнулся кабанчиком туды-сюды, и доложил: «Это караван Сноги Мехмеда Ушатаевича».

— А куда он идет?

Джун опять метнулся туды-сюды, и доложил: «В Бухару».

— А откуда?

Джун снова развернул ослика туды-сюды, и доложил: «Из Ташкента».

— А что он везёт?

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

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

Сеньор оседлал мёртвого осла, почапал туды-сюды с перерывом на плов, и по возвращению доложил:

— Сообщаю тебе, о наисветлейший из мегапросветленнейших хозяев постоялых дворов, да воздаст тебе Джызус Крайст за все благодеяния, что там Саид Панталонович Бебуришвенко ведёт караван с Бухары в Пакистан, и везёт для паши сорок тонн анаши. Ох, широк Каракум, нет нигде саксаул, нет нигде учкудук и не видно аул. Хочет пить их верблюд, хочет жрать мудак такой, и не хочет вести караван за собой. Их жена, злой шайтан, их ругает башка, съели они свой почтенный ишак до последней кишка. Их жена, гель манды, у них там кутак турды, будет он ом сиктым, растуды его туды. Ковры и пряности погонщик продаёт по двадцать динаров, и я уже договорился, что мы можем всё взять по шешнаддцать динар за древнеперсидский килограмм, да продлит бесконечный Аллах их благословенные дни, а они уже скажут продакт оунеру, что их на границе обокрали злые запорожские закарпатцы, и всем нам будет навар.

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

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

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

Давайте лучше поговорим о погонщике каравана.

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

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

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

1. конкретно выполняя то, что говорят (и ничего более);
2. расчехлять аналитику (действовать системно).

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

Второй как раз типичен для тех, кто уже много чего знает-умеет, и попусту уже не дёргается.

Но оба эти способа экстремальны до глупости. Вот более сбалансированный подход:

1. получить задачу и «переспросить, правильно ли я всё понял»;
2. спросить, какую информацию хочет получить Хозяин постоялого двора о караване;
3. уточнить, зачем ему нужна эта информация;
4. пойти к караванщику, представиться, объяснить, кто ты такой, что тебе нужно, куда и кому пойдёт эта информация;
5. передать надыбанное кому надо в запрошенном формате.

Повторюсь: тестирование — сервис.

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

Пример подобного слайда (элементарно нагуглено)

Да, говорят вам. Понятно, чоуж.

Тестировщики, добавляете вы, особенно профессиональные, которые получают по две, три, четыре, пять, шесть, а то и семь (восемь) тысяч долларов в месяц, обычно тестируют чёрным ящиком.

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

А программисты тестируют методом белого ящика, бо там надо смотреть в код, а тестировщики в код не смотрят, поэтому у нас всегда черный ящик. Всё ли понятно?

Да, говорят вам. Продолжайте, всё понятно. Восемь тысяч, вы сказали?

Да, так вот, перейдём к следующей теме, говорите вы, но для начала будет всего четыреста, надо же пройти этап джуниора. А потом будет уже девять (на экране слайд с графиком с DOU, и таки да, медиана и персентиль, обратите внимание на медиану и персентиль, они доказывают, что всё будет хорошо!), говорите вы, и переходите к следующей теме. Техники тест-дизайна, объявляете вы, и первая техника пусть будет доменное тестирование, или тестирование доменов, или тестирование доменным методом, оно же домэйн тэстинг. А ещё мы научим вас тому, как правильно общаться с HR.

Да, говорят вам. Обязательно научите!

На слайде появляется текст «Domain testing is one of the most widely practiced software testing techniques. It is a method of selecting a small number of test cases from a nearly infinite group of candidate test cases. Domain knowledge plays a very critical role while testing domain-specific work» — ну да, на английском, бо в русской википедии про это же ничего не написано. Зачитывать это вслух вы стесняетесь, бо произношение у вас не то, поэтому вы переводите всё на лету — доменное тестирование это один из самых крутых методов техник тестирования, это метод выбора небольшого количества тест-кейсов из группы кандидатов тест-кейсов (мелькает вопрос «Ой, что я несу в массы?!» — но у вас нет времени ответить себе на этот вопрос, ведь урок продолжается), и… и, короче, это всё очень важно при тестировании доменно-специфичного ПО. Ну, вы там просто используете тестирование классов эквивалентности методом граничного значения, и когда это вместе, то получается доменное тестирование. Всё ли понятно?

Ещё бы, слышите вы. Доменная печь, доменный метод, доменный дом. Всё ясно, это всё очень важно для нас. Продолжайте.

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

Вы вспоминаете про «Ото я подумав, а що якщо замінити ІТ скажімо на музику», но на ваших слайдах написано про другое. И вы продолжаете.

Продолжаете точно так, как вас учили в школе — а там вас учили способом «Объявление». Вам просто объявляют о существовании чего-то (про domain testing, например), и предлагают запомнить определение.

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

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

Вы не идиот. Вы нормальный человек, вас наделили полномочиями инфицировать практичными, лишёнными воды знаниями (белиберда-белибердень) всех интересующихся практичными, лишёнными воды знаниями. Вы честно работаете, стараясь всех научить. Вы веселите зал и приковываете их внимание, а потом заявляете о том, что подписаться на курс Full HD со скидкой можно только сегодня, здеся и сейчаса, если подписать контракты на обучение прямо сегодня, только сегодня, сегодня-сегодня! И вы дарите всем присутствующим возможность оплачивать контракт частями — в зале начинается движуха, к вам целенаправленно идут целенаправленные девушки, которые готовы отдать вам 14 000 або 16 000 гривен здесь и сейчас, или потом, но уже частями. Вы призываете всех поверить вам, ведь вы уже столько лет работаете на работе и занимаетесь профессиональным обучением.

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

Единственным адекватным способом обучения чему-либо является способ, который можно назвать «Через объяснение», и вам даже можно объяснить, в чём разница, но вы ничего не поменяете. Это же долго, это же работает только личностно (Группа отпадает?! Но ведь я учу только группами!), это же требует понимания того, как работает когнитивный аппарат психики человеческой, это же требует терпения. Этого же у нас никто не требует! Вы искренне не понимаете, почему мне не нравится ваш обычный, стандартный, всем подходящий формат учёбы «Через объявление».

А Заратустра, как известно, не позволяет.

Мудаки, блеать.

De parabel der blinden