Normal testing

Темные подворотни киевского Подола.

Опиумная кальянная мадам Козятиной.

“We know English! Visa accepted! 24h!”

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

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

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

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

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

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

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

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

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