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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Я дебил?!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Нагуглю.

— Реферат?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И да, это чёрно-белая картинка с телевизионными искажениями, бо вы офигели требовать цветной 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 фреймворки, причем совершенно нечувствительно для проекта.

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

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

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

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

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

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

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

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

— А откуда?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приоритет показывает степень важности выполнения задачи ДЛЯ БИЗНЕСА.

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

Рекомендуется использовать всего три уровня приоритета:

1. Приоритетно,
2. Не приоритетно,
3. .

Все очень просто, не так ли? Или задача приоритетна, или нет. Tertium, кагбэ,  non datur.

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

В Jira используется аж пять уровней приоритетности. Надо бы меньше, но мы все тут с Jira бесимся, поэтому будем следовать ее визионерству:

Trivial — Lowest priority, punctuation or any very small issues

In ‘Contact us’ Tahoma font displayed instead of Arial.

Nobody else see the difference. In the future this issue may be fixed. Or not, because nobody cares, this doesn’t broke the business.

Minor — Indicates that this issue has a relatively minor impact.

In the ‘Contact us’ form placeholder text in ‘Message’ field is displayed as ‘Italic’ instead of regular text.

This doesn’t broke the business, but it’s a little annoying to write and read all text in ‘Italic’. Please, can you fix it?!

Major — Indicates that this issue has a significant impact.

Sending message from the ‘Contact us’ form works well, but sender email is unknown.

Unanswered emails can lead customers to nervosity, this can affect whole business, so please, fix the problem in the most appropriate time limit.

Critical — Indicates that this issue is causing a problem and requires urgent attention.

‘Contact us’ page is unavailable.

This is a required functionality for the web store, this can have a bad impact on the business, so, Kowalski, fix the problem ASAP!

Blocker — This problem will block progress of the project.

Web store is down. ‘Contact us’ page unavailable.

User cannot open the ‘Contact us’ page, because the whole web site is down, the business is down, Kowalski, don’t panic, immediately grab the monkeys and act like the server, while we will bring him back online!

Severity

Суровость бага (ну, вы же не дураки, чтобы переводить “Severity” как невнятное “Важность” или “Серьезность“? Суровость!) показывает технологическую степень влияния дефекта на всю систему.

Внимание, на ВСЮ СИСТЕМУ, а не только на отдельно взятый сценарий или функциональность.

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

Важно понимать, что реально суровые дефекты в функциях в современных веб-системах сложно обнаружить, бо современные веб-системы не состоят из цельных кусков хрусталя, который можно расколоть одним движением. Вы больше блокеров найдете в MS Word, чем в Joomla, просто потому, что какой-то хитрый баг может тупо закрэшить вам всю вордину, дальнейшие действия становятся невозможными, надо запускать ворд с нуля. А как «положить» интернет-приложение, построенное на микро-сервисах? Сервак раздолбать кувалдой… Или продумать какую-то троянистую шнягу, которая по цепочке пронесет с собой разрушительный скрипт, и всю эту цепочку будет последовательно уничтожать.

Поэтому в большинстве случаев мы используем Severity  = Major, а Blocker’ом величаем разве что какие-то важные и сложно-составные сценарии, которые по каким-то причинам очень важно пройти, но не удается.

Trivial — Minor loss of function, or other problem where easy workaround is present.

‘Contact us’ form text was designed with Arial font 14 size, but I see the Arial font 13 size instead.

This doesn’t affect the functionality at all. Anybody will care about it?

Major — Major loss of function.

User messages from ‘Contact us’ page are not received by Support team.

Everything else works fine, only this particular loss of functionality can severely affect the business issues. Kowalski, fix the problem!

Blocker — Blocks the interaction with the system, production could not run, crashes, loss of data, severe memory leak, everybody dies.

Web store become inaccessible because ‘Contact us’ script overload the server.

Server continuously restarts, nobody can access it, web store became inaccessible. This severely affect all business issues. Kowalski!

Кстати, для Severity лучше использовать побольше нюансов.

Откуда-то слышны мягкие пианинные трельки.

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

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

— …и поэтому я хочу, чтобы вместо тестировщиков на проекте работали автотесты. Тестирование на нашем проекте уже превышает все бюджеты, заказчик оплачивает только треть всей работы, остальное происходит за наш счет. А качества на проекте как не было, так и нет, постоянно находят какие-то баги! Там уже четыре тестировщика фигачат по девять man/hours в день! Это ж деньги впустую уходят! Это же вчерашний день!

— Дык, тестировщики за качество не отвечают… — из глубин кресла. — Это даже бухгалтера знают. Менеджер проекта отвечает за качество всего проекта…

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

— Где же удешевление, если час работы автотестера в три раза дороже обычного…

— …но они там ненадолго. Автоматизируют всё, и уйдут!

— Нет, они там поселятся очень надолго. Мадам Козятина, нам ещё угля подсыпьте. Смотри… твоя идея здравая и правильная, если воспринимать ВЕСЬ процесс тестирования как одноразовую задачу. В каком-то смысле, написание и прогон тест-кейса — это одноразовая задача. Но софт не разрабатывается одноразово.

— Чё-то как-то слишком сложно…

— Проект у нас существует только потому, что в него постоянно вносятся какие-то корректировки и хотелки заказчика. Основная часть проекта работает стабильно, ведь её не трогают. Всё остальное надо постоянно проверять. Так?

— Так.

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

Мммм…

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

— Так.

— Так вот, твой автоматизатор НИКОГДА не угонится за ручными тестировщиками, ведь они постоянно будут генерировать новый «контент». А если ручных тестировщиков на проекте не будет, то автоматизатору придется придумывать и прогонять тест-кейсы самому. Долго он будет этим заниматься?

— Так… хз же…

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

— Сфигали?

— Дык качество не приходит/уходит. Оно или есть, или нет. Тестировщики его просто фиксируют (как твой градусник), а не приносят.

— Эти тестировщики… (убежденно) Таки это падлы…

— Проблема твоего проекта не в тестировщиках. И даже не в программистах. У тебя программисты на проекте откровенно работают в стиле “good enough”. И заказчики используют свой магазин в стиле “good enough” (я видел, что у вас там триста багов постоянно открыты, из одного релиза в другой переходят, и никто от них не страдает). А от тестировщиков ты требуешь работать в стиле “makes perfect”. Why? Fuck you, that’s why!

— Недопонял.

— “Good enough” означает «достаточно хорошо для бизнеса». Не всегда нужно, чтобы весь софт работал идеально. Не всегда необходимо, чтобы процессы в той же логистике были идеально отлажены. Бизнес идет, деньги идут, все ок. Раздуй угли… Так вот, у тестировщиков всё точно так же. Они не могут доказать, что в софте нет багов. Они также не могут доказать, что баги есть — им надо проверять все предположения. Они очень многое предполагают и на очень многое надеются, обычно необоснованно. Это “good enough” для тестирования. Вообще, чего ты к тестировщикам привязался? На твоем проекте всё, вроде бы, нормально.

— Нормально оно только внешне и только сейчас. В принципе же у нас потенциальная проблема. Через полгода на проекте понадобится больше тестировщиков…

— Не понадобится. Тебе понадобится вообще три человека как постоянная команда — двое ручных тестировщиков, которые больше будут работать головой, чем кодить, и один автоматизатор, который больше будет кодить, чем думать. Гибкость понадобится только в распределении задач на тестирование — их всегда нужно будет ограничивать. “Good enough” так “good enough”.

Конкретно: раздели все функциональные возможности проекта на три чек-листа:

1) New features

2) Critical areas

3) General areas

При выпуске каждого билда тестируется в обязательном порядке всё, что попадает в “New features”. Затем (или одновременно с этим) обязательно тестируется всё то, что попадает в раздел “Critical areas”. А “General areas” — фиг с ними. Если до них руки дойдут – ок. Если не дойдут (а всегда не доходят) — пофигу. “Good enough”.

После выпуска билда начинается обязательная подготовка к следующему. Все штуки из раздела “New features” обязательно переносятся в “Critical” или “General” — по ситуации. “General areas” будет постоянно разрастаться, ну и фиг с ним. Внутри этого списка тоже всё будет ранжировано по степени важности, по убывающей, поэтому самые важные пункты будут проверяться первыми. Зачем тебе вообще тестировщики на проекте?

— Ну, надо же знать, если что-то важное не поломалось…

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

Вообще, всё тестирование обычно сосредоточено на том, чтобы сравнить работоспособность функционала (или возможностей), который перечислен в разделе “Critical areas” с предполагаемым идеалом. Но идеал… Если там что-то работает в принципе, то этого “good enough”. Ты постоянно выпускаешь софт с какими-то багами, я видел.

— Но без критикалов! У нас условие такое, что в выпускаемом релизе не должно быть ни одного критического бага. Или, упаси Шива, блокер…

— Вот именно. Проверяется и чинится самое важное. Всё остальное проверяется или на ходу, или по возможности, но редко целенаправленно. И еще баги тоже ранжируются, самые важные баги — из раздела “Critical areas”. Вообще, требовать «тестировать всё!» — это очень, очень, очень глупо и самонадеянно.

— Разве “New features” не самые важные?

— Это важнее важного только в день выпуска, а завтра все твои “New features” уже должны отображаться в списке “Critical” или “General”. Поэтому, всё равно всё сводится к одному и тому же.

— А что из этого надо будет автоматизировать?

— Всё то, что находится в разделе “General areas”. Остальное — если руки дойдут. То есть, никогда.

— То есть, как это — никогда?

— Так, что все штуки из “Critical areas” тестировщики в принципе будут обязательно проверять руками, да ещё и неоднократно. Пусть робот тестирует то, что в “General areas” находится, ведь туда тестировщики могут и не дойти, время на тестирование все-таки ограничено. Да и, как правило, именно такие места реже всего изменяются, что для автоматизации благо. Автоматика будет проверять надежность самого надежного функционала. Ведь хуже всего, когда ВНЕЗАПНО находится баг там, где, казалось бы, все очень надёжно.

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

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

— Такое вот начало лета…

— Да… Наверное, черешня не уродится.

— Да, наверное…

Канер, Фолкнер и Нгуен…

«Жрум-хрум, жрум-хрум»…

Мимо в юго-западном направлении проходит молодой надежда киевского тестирования.

~ Привет, — говорит.

~ Спасибо! — отвечаю.

~ А, приятного аппетита.

~ Привет! — отзываюсь.

~ Гы! Умеешь ты запутывать! — 🙂

~ А то! — )))

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

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

И мы его, милай, зарезолвим в лучшем виде, но после релиза.

А пока — не сообщай.

В общем, запутался он.

Что делать?

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

~ Но при этом совершается должностное преступление, ты не сообщаешь информацию, для добывания которой тебя и пригласили в проект! — науськиваю я…

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

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

Если не сообщить, но слабо рассчитывать на то, что баг будет исправлен…

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

Вооооот!

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

А если этот баг найдет закащщик? Баг был найден четко по тест-кейсу…

А если вдруг ВНЕЗАПНО что-то случится?

Надо сообщать о баге. Но программист… Боится он, что ли?

Ну…

Все равно ведь про баг узнают…

Вердикт: сообщить о баге закащщику должен сам программист (с поддержкой в виде тестировщика на фоне декораций).

Если сообщить с уточнением: «Фикс займет столько-то дней, и если его фиксить, то мы рискуем не успеть сдать объект к 22 апреля* …«, то весьма вероятно, что релиз могут выпустить с багом, но учитывая риски, и фикс таки случится.

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

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

Обед закончился.

По итогам:

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

Щастье 🙂

Дорогой разработчик,

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

Для этого используются системы управления дефектами вроде «Mantis».

• Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

Принципиальная схема работы с Mantis

1. Если ты видишь баг — сделай об этом запись в Mantis. Не емайлом, не в скайпе, и не лично, и не молча, если на его починку нужно больше, чем десять секунд. Просто запиши это в Mantis.
2. Заполнить там надо всего лишь четыре поля:
   1. Category — это выпадающий список категорий в отдельно взятом проекте.
   2. Summary — заголовок репорта о проблеме. Опиши свой «wtf?» кратко и без подробностей.
      • Пример неправильного заголовка: «Не могу сохранить пароль».
      • Пример правильного заголовка: «Не могу сохранить пароль если использую заглавные буквы».
   3. Description — а вот тут пиши подробности.
   4. Steps To Reproduce — пожалуй, самая важная часть репорта. Ведь программист, который получает сообщение о баге, но не понимает, что и как ты сделал и почему появился баг — это очень рассерженный программист…
      1. Пример шагов для воспроизведения:

         1. Залогиниться на сайте (tester101/tester101)

         2. Создать тикет в суппорт.

         3. На третьем экране в поле Label вписать слово с двоеточием - 'doc:doc'.

      2. Конечно, записать это требует чуть больше времени, чем сказать «Слушай, это, там чего-то не работает, вот...» Зато потом в ответ не получишь «Я там чо-та пофиксил, я хз, если оно то, о чем ты говорил ваще-та…«
3. Приложи скриншот найдненного тобою бага. Иногда это важнее слов.
4. В Mantis появляется новая задача со статусом New.

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

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

Что такое issue?

Все записи в Mantis называются issue.

Принципиально это переводится как «предмет спора, разногласие, проблема». Обычно это переводят как «Задача».

Фишка в том, что каждое отдельно взятое issue может быть или в любой момент стать как «СООБЩЕНИЕМ О БАГЕ», и «ЗАДАЧЕЙ НА РАЗРАБОТКУ».

Если я сделал запись с сообщением о дефекте — это сообщение о баге.

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

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

Общие правила работы с Mantis

1. Созданная задача получает уникальный номер в системе, и статус New.
2. Если при создании задачи был выбран человек, который будет за нее отвечать, статус задачи становится Assigned.
3. Конечный статус задачи closed. До тех пор, пока задача не получила статус closed — она все еще находится в работе.
4. За каждую отдельную задачу отвечает тот, на чье имя она записана. Для этого используется поле Assigned To. Если ты уверен, что твое участие больше не требуется — переведи задачу в статус Resolved и укажи имя того, кому ты ее передаешь.
5. Прекрасен принцип «One Bug — One Issue». Например, существует задача, которая была источником разработки. А мы нашли баг, который касается непосредственно этой задачи.
6. Не надо вписывать баг как комментарий к задаче — надо сделать новое issue. Иначе потом будет очень сложно «управлять багами», и будет сложно понять, сколько багов было найдено, и сложно объяснять, что «это задача, и она сделана, но в комментариях есть баг, и он не починен». Все задачи, которые связаны между собой, можно слегко «линковать» посредством поля Relationships.
7. Не стесняйся адекватно и вовремя менять статус задачи, с которой работаешь.
8. Будь внимателен с типом задачи (Issue type). Каждый тип («Feature Request», «Change Request», «Bug», «Information») обрабатывается по-разному в процессе разработки. Простейший пример: тестировщик написал Change Request, а программист, не разобравшись, принялся воплощать изменения, считая их задачей…
9. Прежде чем описывать баг или задачу, попытайся написать ее так, чтобы она была понятна всем, в том числе и твоей маме, которая опасается компьютера. Представь себе, что эту задачу назначут твоему коллеге. Представь себе, что он будет ее читать в конце рабочего дня, сильной уставшим. В кого полетит первый камень с вопросом «Ты тут вообще о чем пишешь?»
10. Если возможно, указывай не только то, что надо сделать, но и причину по которой это надо сделать. Это поможет понять приоритетность задачи. Иногда это не очевидно, или очевидно, но не всем.
11. Не используй Mantis как personal task list. Он не для того предназначен.
12. Указывай версию софта, в которой была обнаружена проблема, и указывай версию, в которой это проблема была/будет решена.
13. Есть глубокий смысл в том, чтобы акаунты уровня Developer и Tester (по-умолчанию роли тестировщика в Mantis нет) были лишены возможности ставить статус Closed. Принципиально это должен делать менеджер проекта. Менеджер должен получать прошедшую весь девелоперский цикл задачу только в статусе Tested.
14. Администратор должен всячески связать Mantis с существующей в компании subversion-системой, как бы она ни называлась. В крайнем случае, следует добавить новый цифровой Custom Field, который будет являться обязательным для заполнени при переводе issue в статус Resolved.

Подробная схема работы с Mantis

Разруливание багов через Mantis

На картинке весьма подробная, но все-таки принципиальная схема.

Подобные схемы разнятся от конторы к конторе, но это именно «принципиальный подход».

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

Управление проектом через Mantis

Это фантастика. Дело в том, что Mantis сделан для разработчиков, и вовсе не предназначался для раздачи задач и составления графиков успеваемости.

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

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

Второе и последнее обращение к нации

Итак, Mantis это инструмент для разработчиков.

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

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

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

Дефолтный пароль администратора при первой установке Mantis:

Username: administrator

Password: root

Все вышесказанное относится к работе с баг-трекеров В ПРИНЦИПЕ, а не только к Mantis в частности.

Официальщина:

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

Почему не смог?

1. Из-за разницы в конфигурации компьютеровВ веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.
2. В описании бага отсутствуют какие-то шаги или нюансыА вот это очень серьезно, и идет прямым минусом в карму тестировщику. После ревью баг будет переоткрыт, что неприятно ни им, ни нам, ни этим, которые за всеми нами приглядывают.
3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом «обновленном»Это самое противное и требующее рассмотрения.

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

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к

рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже будет как-то починен? Если рассматривать ситуацию абстрактно, то вероятность весьма, весьма, гм, вероятна.

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

Не является.

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

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться — в коде.

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

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

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде — он все-таки «Fixed», или «Can’t reproduce»?

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

1. 1. Техническое мышление

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

1. 1. Креативное мышление

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

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

1. 1. Критическое мышление

умение оценивать идеи и делать далеко идущие выводы, правильные умозаключения.

1. 1. Практическое мышление

умение воплощать идеи в конкретные дела. Умение применять инструменты и техники для тестирования.

Можно собрать команду из четырех тестировщиков, каждый из которых представляет одну из этих сторон. Психологические тесты (пример) на интервью могут помочь определить общий стиль мышления. Если все получается, то, вероятнее всего, это будет супер-командой, это будет «стая фолксов»^*, которая наводит страх на округу и девелоперов 🙂 Удивленные заказчики штабелями умирают от счастья, забыв подписать счета на оплату.

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

^*Термин «фолкс» образован из американского обращения folks (ребята), и подразумевает как «член команды», так и «волк».