02:29​ Как разобраться с black box

04:08 В чём смысл тестирования

05:13 Что такое «интеграционное» и всякое другое тестирование

​07:02 Тестирование — сервис, который «приносит вопросы на ответы»

07:50 Должен ли тестировщик давать рекомендации о том, как делать ПО?

09:47 Что такое «требования»

10:14 Что такое «анализировать»

Прошедшей осенью поговорил со студентами кишинёвского политеха про тестирование ПО.

Доклад я зачитал на полагающемся нам всем румынском языке. Ох, ніколи знову! Штирлиц таки ощущает десятилетие размышлений сугубо на русском и очень быстро задрался запинаться про тестирование на родном, увы мне.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контекст

важнее

всего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Warning

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

Double Warning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот что было предложено:

Шаги: 

1. 1. Зайти на сайт https://translate.go…e&sl=auto&tl=en
   2. Нажать на кнопку в левой стороне «АНГЛИЙСКИЙ»
   3. Нажать на кнопку в правой стороне «РУССКИЙ»
   4. Ввести слово на английском языке.

Ожидаемый результат

1. 1. Окно с допустимыми языками открывается при нажатии.
   2. Можно выбрать желаемый язык.
   3. Перевод выполняется автоматически при вводе слова.

Позитивные тест-кейсы

Условия: 

1) Все буквы в слове строчные.

2) Все буквы в слове заглавные.

3) Буквы в слове и строчные, и заглавные.

4) Слово содержит небуквенный знак.

5) Текст без пробелов.

Пример:

1) hello, hi, bye

2) QUEEN, KING, WE

3) ForeVeR

4) j`unior, impa%ct, cl-ass

5) hellohowareyou

Негативные тест-кейсы 

Условия:

1) Цифры и другие небуквенные знаки.

2) Многократное дублирование буквы в слове.

Пример: 

1) ###, 12, @

2) helllp

Приговор: предлагаемые тест-кейсы — имитация тестирования. Автор всего лишь словами перерассказал «слепому» о том, как он курсором по экрану тыкал.

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

Надо подумать…

Таки да, это надо обдумать.

И надо думать по-другому.

Про вопросы

Вот три вопроса, на которые тестировщику НАДО получить ответ ДО начала тыканья курсором по экрану:

1. Что это?
2. Зачем это нужно?
3. Как оно делает то, что нужно?

Как вы это сделаете — неважно.

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

Что это?

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

Ок, гуглопереводчик мне уже знаком, я знаю, что он помогает переводить

• слова,
• предложения,
• абзацы текста.

Среди них бывают отдельные слова и словосочетания (Break a leg — «Сломать ногу» — это идиома, которая иронично желает исполнителю «удачи». Доброжелатели обычно говорят «сломай ногу» актерам и музыкантам, прежде чем они выходят на сцену для выступления. Происхождение фразы остается неясным). Как гуглопереводчик переведёт эту идиому? «Сломать ногу». Аллё, так и должно быть?

Зачем это нужно?

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

Как оно делает то, что нужно?

Нужна справка.

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

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

Поэтому мне нужна справка, чтобы ТОЧНО ЗНАТЬ, что там внутри и что оно ВООБЩЕ может делать.

Мне надо знать, а не догадываться.

Программистов рядом нет, но в левом верхнем углу страницы есть меню «гамбургер» > [О Переводчике Google]. Открылась англоязычная страница https://translate.google.com/intl/en/about/

Так и должно быть?

Я хочу переключить справку на русский язык. Как это сделать?

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

Ок, я опытный, я могу изменить URL — https://translate.google.com/intl/ru/about/ А кнопками это можно сделать?

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

«Теперь Google Переводчик доступен в любом приложении». Какие приложения подразумеваются? В любом? В ЛЮБОМ? У меня на андроиде их не меншье 20. ТОЧНО В ЛЮБОМ? Так и должно быть?

Смотрим поясняющее видео. Там говорят, что иконка гуглопереводчика висит поверх всего, «Это функция «Быстрый перевод», она доступна в последней версии гуглопереводчика». А у меня какая версия? Как это узнать?

Там же показывают, что надо тыкнуть по сообщению, которое надо перевести, потом по иконке скопировать, и взлетит «Быстрый перевод». Ок, есть первый тест-кейс.

Скроллим справочную страницу дальше. «Общение без границ». Ыыы, это чем-то напоминает Шелдона Купера в китайском ресторане с требованием «Покажите мне ваши сопли!» Это просто рекламная пропаганда. Отложим.

Скроллим дальше. Раздел «Всегда под рукой» говорит о том, что гуглопереводчик есть:

1. в телефоне
2. офлайн
3. на компьютере

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

«Несколько способов ввода».

• говорить в микрофон
• запихнуть в программу фотографию с текстом
• нарисовать текст стилусом
• набирать текст

Ок, это четыре разных окружения и они тащут за собой множество тест-кейсов для проверки. Плюс будем комбинировать эти способы ввода с упомянутыми ранее разными окружениями. В телефоне четыре способов ввода, в режиме «офлайн» сколько их будет доступно? На компьютере рисовать… не помню такого, но можно подключить перьевой планшет. Сколько в итоге получается проверок? Есть смысл их всех учесть, записать, согласовать требуемые усилия с начальством/заказчиком? Конечно, есть!

Остановимся.

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

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

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

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

Наглядный пример: клавиатура моего программируемого калькулятора МК-61.

Красава ж ты моя!

Он, конечно же, может выполнить операцию 2+3, но на его клавиатуре НЕТ клавиши [=], поэтому привычные последовательные нажатия клавиш [2] [+] [3] [=] к нему неприменимы.Он делает это как-то иначе.

Можно ли самостоятельно догадаться о том, как он работает?

Нет.

Нужно посмотреть в справку.

Нужно спросить о том, как он работает.

Как вы это сделаете — неважно. Не беритесь за гуж, не спросивши.

Про позитивные/негативные тесты

А всем видно, что ВСЕ предложенные автором «негативные тест-кейсы» являются позитивными?

В основе тестирования находится сравнение ожидаемого результата с наблюдаемым.

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

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

Ну, ввели мы в гуглопереводчик всяку шнягу по вашему предложению — 123!»№%*(). И что? Сайт рухнул? К вам прибежал админ гуглопереводчика и лично надавал по шее? Нет, всё в норме. Более того, у вас есть ожидаемый результат, следовательно, вы выполняете позитивные тест-кейсы. А называете их негативными.

Как настырный тестировщик вы придумаете/обнаружите сценарий, в ходе которого будет сделано НЕ ТО, что гуглопереводчик должен делать, или то, но НЕ ТАК, как это было предусмотрено.

Например, вставим в гуглопереводчик в режиме «Рус / Eng» транслитерированный текст:

Transliteratsiya shiroko ispolzuetsya vmesto kirillitsyi pri rabote na nerusifitsirovannyih sistemah dlya vvoda nazvaniy faylov, papok, a takzhe dlya perevoda nazvaniy ili imen iz odnogo yazyika na drugoy.

Что произойдёт? Это русский текст, или английский?

Вставим тот же текст, но переведем гуглопереводчик в режим «Eng / Рус». Что произойдёт?

Иногда вы будете знать точно, что должно происходить. Это тестирование.

Иногда вы будете знать точно только то, что НЕ ДОЛЖНО происходить. Это тоже тестирование.

Иногда не будете знать результат никак, никакой, даже приблизительно. Это уже не тестирование, это исследование.

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

Поэтому не привязывайтесь к вводу «неправильных значений». Рассматривайте «позитив» и «негатив» в русле сценариев, которые должны выполняться. Все сценарии, в ходе которых мы проверяем, что гуглопереводчик делает именно то, что должен (то, что в его справке написано, а не то, что вы воображаете), можно назвать позитивными. Назовём их скопом happy path. Додумаетесь/обнаружите сценарий, который отклоняется от happy path — вот это и будут негативные тест-кейсы.

То, что тест-кейсы обслуживают сценарии — вы уже знаете.

• whole picture first,
• details.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К манагерам

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

1)

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

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

2)

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

Однако!

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

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

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

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

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

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

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

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

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

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

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

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

— А откуда?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У тест-кейсов должны быть предусловия (‘pre-conditions’ по-вашему).

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

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

Как это всё сделать?

1

Гиперссылка на требования

Да, но не менее 70% гиперссылок в любом документе неизбежно «дохнут» на протяжении полугода, а когда требования начинают переписывать, менять строки местами и нумерацию следом, то едрить вашу медь…

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

• внятно,
• грамотно,
• однозначно,
• красиво
• и понятно.

Увы.

2

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

Да, логические отсылки вроде «Смотри Евангелие от Программиста 9.43» более долговечны, нежели гиперссылки, но они почти постоянно нуждаются и в сопутствующих гиперссылках, и в уточнении на предмет «не поменялось ли там что-нибудь».

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

3

Процитировать требование

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

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

Шо делать?

От страха перед иканием большинство тестировщиков (97,12%) сильно тупят и не решаются ни на то, ни на сё. А если будут требования переписываться? А если нет? А если будут? А если нет? Аааа…

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

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

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

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

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

Видео нет.

Определения тест-дизайна

Вот самое простое определение понятия «тест-дизайн», одно из самых распространённых, и самых логичных:

1) Тест-дизайн — это способ

придумать поменьше тест-кейсов,

но при этом сохранить

«максимальное покрытие»

…и при этом оно же самое идиотское (бо невозможно сохранить то самое драгоценное «максимальное покрытие» при насильном уменьшении количества проверок).

Возможно, вам понравится другое, тоже распространённое определение, которое всплывает при первом же гуглеже:

2) Тест-дизайн — это

этап процесса тестирования ПО,

на котором проектируются

и создаются

тестовые случаи (тест кейсы)

Это определение неадекватно, бо тест-дизайн — это не штука для создания тест-кейсов. Неочевидно? Прекрасно!

Далее:

3) Тест-дизайн — это

«The act of careful, complete, systematic,

test design will catch as many bugs

as the act of testing» © Boris Beizer

Процитировано в предисловии к книге Lee Copeland “A Practitioner’s Guide to Software Test Design”, и звучит хорошо, но… Чего он имел ввиду?

И ещё припомнилась классика джуниорской изворотливости на собеседованиях — самое няшное и глупое определение:

4) Тест-дизайн — это

дизайн тест-кейсов!

Что там ещё:

• способ создания наборов тест-кейсов,
• выбор тестов для тестирования при определенных ограничениях,
• …

Короче, всё верно… Но это дело надо не узнавать, а понимать. А чтобы понимать, надо сомневаться в тех определениях, которые предлагается узнать.

Давайте сомневаться.

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

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

Ну, да. Это нормально. Waterfall крут. Ему много тысяч лет, его придумали задолго до появления компьютеров.

«Это работает» ©.

Максим Дорофеев тысячу лет назад нарисовал картинку про Waterfall.

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

Но 50-х годах ХХ века, когда было придумано то, что вы сейчас называете «программирование» и «тест-дизайн», эта картинка ни у кого не вызвала бы удивления, бо тогда всё было как раз наоборот.

Просто вообразите эту картину Малевича перевёрнутой.

Ибо было так: с самого начала у нас очень мало документов, и чем их больше будет, тем лучше будет.

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

Старые компьютеры и старый тест-дизайн

Вот фоторобот самого первого компьютера, который был установлен в университете Гарварда.

Он назывался «Марк-1» (а тот самый мотылек, который «сдох в микросхеме», сгорел в следующем компьютере, в «Марк-2»).

Компьютер был большой, слабый, часто ломался, и делал только то, ради чего он был создан. Был запущен в 44-м, участвовал в программе по разработке атомной бомбы в США, упокоился аж в 59-ом.

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

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

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

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

Затем подаёте на всё это электрический ток, который пройдёт по этой структуре от начала до конца (это означает, что в память или делается запись, или делается считывание, доступна только одна операция за раз). У каждого магнитика два состояния: или туда пришёл заряд нужной силы, или нет. Если пришёл, то магнитик будет хранить состояние «1». Если нет, то в нем хранится «0». Вот и всё, классическое

0000111000101111 0001111000001110 0010111100011100 0000111000101110 00100010

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

Принцип работы такой памяти:

• 155la3.ru/ferrite_memory.htm
• habrahabr.ru/company/ibm/blog/266425/

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

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

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

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

Для нас уже изменилась не только система взаимодействия с компьютерами, изменился сам концепт того, как работает программа. А тест-дизайн не изменился.

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

Раньше тестировали ДО того, как написать код (карандаш и бумага, парни), и код писали уже с учётом всех потенциальных проблем, которые были обнаружены на этапе тестирования.

Сегодня мы тестируем УЖЕ работающие приложения.

Тестирование как процесс можно представить в виде вот такой диаграммы:

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

Причинно-следственная связь полностью соблюдена, да?! Появлению тест-кейсов предшествует тест-дизайн, следовательно, «тест-дизайн» — это деятельность по созданию тест-кейсов.

На самом деле — НЕТ, абсолютно нет.

Всё это становится очевидным, если учитывать, как и когда эта штука родилась, и где и в каких условиях она работала.

А работала она следующим образом. Вместо слова тест-дизайн подставим слово «анализ»…

А что такое анализ? Кто не знает — бегом в википедию, мазафака, там упоминается расчленёнка:

Анализ (др.-греч. Ἀνάλυσις — разложение, расчленение, разборка) — метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования

Можете соврать, что теперь-то всё стало понятно, но сперва ещё проясните слово «метод» (позже пригодится):

Метод (от др.-греч. Μέθοδος — путь исследования или познания) — систематизированная последовательность действий, которые выполняются для решение определённой задачи.

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

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

Позже всё то, на что всё раздробилось, мы будем группировать и осмысливать. Но сперва — раздробить.

Собственно, в этом Анализ и состоит.

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

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

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

Если бы нам пришлось работать с теми самыми старыми компьютерами, то и мы начали бы делать то же самое.

И неважно, что у нас компьютеры сейчас быстрые…

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

Переходим к следующей составляющей анализа.

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

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

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

Посему:

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

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

Но анализ делается ДО осознания. Основная ошибка в том, что мы анализ не проводим, мы заменяем анализ каким-то… быстрыми домыслами.

Не надо так.

Ещё одно важное понятие, которое используется в тестировании:

Вы функциональные тестировщики. Следовательно, вы должны тестировать функциональность.

Большинство тестировщиков начинают тестировать не Функциональность (способность программы выполнить задачу), а то, из чего эта способность создана (функции).

Например, когда предлагается протестировать часы, мы начинаем с проверки «а есть ли стрелки». Ну, реально… это самое дурацкое начало тестирования: убедиться в том, что часы вообще есть. Все же с этого теста начинают?! А почему бы не начать тестирование часов с проверки того, что тестировщик проснулся и умылся? Ведь это важное предусловие для начала тестирования.

Еще пример: протестировать отсылку смс с телефона можно несколькими способами, на разных телефонах это ещё и делается по-разному. Но если не привязываться к тому, как это реализовано, то всё равно МОЖНО протестировать функциональность.

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

Думайте про тестирование функциональности, а не функций.

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

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

Мы профессиональные тестировщики, нам только дайте любую шнягу, и мы её протестируем, так?! И скажите нам точно, что именно надо делать. И мы сделаем именно то, что вы скажете, что надо сделать. А чего не скажете делать — ну, так надо было говорить!… Всё правильно?

Не надо так.

Надо понимать, зачем всё это делается. Надо спрашивать. Надо понимать сверхзадачу тестирования.

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

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

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

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

Прояснение метазадачи тестирования выглядит следующим образом:

1. понять, зачем что-то надо делать,
2. потом осознать, что конкретно надо сделать,
3. и уже потом в самом конце понять, как именно это надо сделать.

Начинаем с «Зачем», затем переходим к «Что», и уже потом спрашиваем «Как».

Обычно мы ВСЕГДА начинаем с самого конца этой схемы — сразу уточняем, как устроена программа, которую надо протестировать; где у неё находится кнопка, и есть ли там кнопка, и… есть ли стрелки на чёртовых часах. Народ, часы — это объект, который может быть без стрелок, но тем не менее он выполняет свою функцию — показывает время. Соответственно, и тестировать часы надо без привязки к стрелочкам. И программное обеспечение надо тестировать точно так же, не привязываясь сразу к тому, как оно устроено. Иначе вы будете обречены тестировать только то, что видят глаза здесь и сейчас, а не то, что может случиться.

Как устроен «тест-дизайн»

Рассмотрим это поэтапно, как процесс.

Всё ВСЕГДА начинается с анализа и осознания ситуации.

Надо провести анализ Контекста (отдельно) и анализ Задач (тоже отдельно).

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

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

Древние программисты умели фокусироваться, но… они уже почти все поумирали, поэтому выкручивайтесь самостоятельно. Это не так уж и сложно.

После завершения анализа начинается осознание «Контекста» и «Задач» по-отдельности. Если игнорировать последовательность осознания контекста и задач, то будут сложности с анализом и осознанием того, что называется «функциональность». И будут сложности с определением метазадачи тестирования. Тут всё связано.

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

Следующий этап, если этот прошел хорошо, — Комбинаторика.

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

Тест-дизайн вообще основан на таблицах. Тест-дизайн = анализ. Анализ = контроль. Для того, чтобы контролировать все, необходимо все записать. Затем комбинировать. А это таблицы.

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

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

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

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

Ответ: вы возьмете карандаш и бумагу. Или будете рисовать мелом на асфальте, или фломастером на обоях, но вы будете записывать. Чем больше документов, тем лучше (вспомните картинку Дорофеева).

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

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

И тест-кейсов тут всё ещё нет.

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

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

Но это не rocket science, это дело можно и самостоятельно разрулить.

Третий этап.

После комбинаторики надо подумать, есть ли смысл применять ту или иную технику для того, чтобы упорядочить полученные данные.

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

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

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

Если вы не видите закономерностей и нелогичностей, значит, они проходят мимо вашего сознания.

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

Если анализ показывает, что нужно сделать 50 тысяч тестов, значит, нужно сделать минимум 50 тысяч тестов.

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

Например, украинец попадает в домен жители Украины. Молдаванин попадает в домен жители Украины, если он живет в Украине, не являясь при этом украинцем.

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

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

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

Тест-кейсы — это инструкции по созданию тестовой ситуации, а не «set of input values» и blah-blah-blah. Придумывать тестовые ситуации легко и просто только ПОСЛЕ этапа анализа тест-дизайна. Их можно писать буквально без того, что называется «Steps to reproduce», их можно писать одной строкой. Тест-кейс, даже если не выглядит, как трехколоночная шняга, тем не менее остаётся тест-кейсом.

Эстимация времени на тестирование — за этим марш сюда: Оценка времени на тестирование: неочевидные надводные камни

Резюме

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

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

Данные, которые собираются на этапе анализа, комбинируются (смешиваются и перемножаются). Техники тест-дизайна основаны на комбинаторике данных.

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

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

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

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

Всё, туй коныць.

Вопросы

Як це все робити, коли в тебе еджайл, і дуже коротка ітерація? Наприклад, ітерація день або тиждень. Ти просто не маєш можливості всі ці аналізи проводити.

Маешь. Не умеешь — не берись.

Так программисты поначалу воспринимают TDD, мол, у меня нет времени код писать, а вы хотите, чтобы я ещё и тесты писал 🙂

Внутри agile захардкоджен тот самый waterfall, который объявлен «плохим». Waterfall это нормально, это должно быть. Мы основаны на waterfall, то есть сначала случается свадьба, а уже потом появляемся мы. Если нарушить процесс, то, соответственно, результат будет… ну, вы сами видите, что получается.

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

На рахунок тест-дизайну і цього всього, що було сказано, це все звучить класно, але в мене складається враження, що це така утопічна розповідь про те, як би воно мало бути. Це ідеалізовані абсолютно всі у нас умови, і от в тебе час на це, і на це. Суть в тому, що в сучасних умовах і в тому, як швидкоплинно оці з девеломпент, делівері, і т.д., це все відбувається, то реальність показує, що в тебе час дуже обмежений. І це велика розкіш, коли ти можеш дозволити собі зробити оце все, що ти описав. А далі?

Когда умеешь это делать, ты делаешь это быстро. Чистить зубы тебя никто не заставляет, но ты это делаешь, причем быстро. Соответственно, когда умеешь это делать, делаешь это быстро, потому что это просто можно делать. И один час анализа потом начинает помогать в развитии проекта, иногда экономя целый месяц. То есть, есть вещи, о которых с самого начала почему-то никто не подумал. Требования складываются достаточно просто. Например, требование о том, что мы выдаем скидочную карту всем тем, кто накопил в системе много денег и кому больше 18 лет. А если юзер накопил много денег, но 18 лет ему еще не исполнилось? Это все относится уже к анализу и тестированию. В требованиях этого нет, потому что требования создаются по-простому. Анализ — это предусматривание, и он делается быстро. Кажется, что он делается долго, но на самом деле это не так.

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

Нет. Ты точно так же понимаешь, когда ты наелся. Просто понимаешь, и всё.

Если говорить про доменное тестирование — этих доменов достаточно много. До какой степени мы должны доходить?

До тех пор, пока не исчерпается воображение.

Но это очень субъективно…

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

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

Предположим, что есть пять университетов, в которых стоят пять компьютеров одной и той же модели. Каждый из этих компьютеров в какой-то момент становится уникальным артефактом. У какого-то компьютера памяти нашили больше, у какого-то меньше. У какого-то скорость повысилась, у другого скорость ниже. Все программы в древние времена писали для отдельно взятых компьютеров (то есть невозможно было в офисе написать программу, приехать к клиенту и её установить на его компьютере, априори это было невозможно). Мы можем себе это представить? Для этого ноутбука отдельная программа, для этого отдельная, и они не синхронизируется абсолютно. В наше время это уже сложно представить, в наше время программы пишут ВООБЩЕ. В те времена это было норм, просто из-за того, как все было устроено. И тест-дизайн помогал фокусироваться. И это великое благо – умение сфокусироваться и действительно понять, что важно, и что неважно. И не разбегаться сразу во все стороны, как мы к этому стремимся иногда.

Виходить так, що тест-дизайн существовал в якомусь сенсі до нинішнього моменту в якихось вузьких кругах. Що зробити для того, щоб його відродити, зважаючи на те, наскільки популярний agile, небагато часу, все гнучко, і в принципі, немає на достатньому рівні документації. Як жити?

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

Відсутність документації, її недостатність… [не позволяют заниматься тест-дизайном]

У нас никогда не будет адекватных требований просто потому, что они пишутся физиологически не так, как мы это себе представляем. Мы воображаем, что это документ, в котором четко все написано. На самом деле любые требование это как фотография из отпуска – ты на нее смотришь и вспоминаешь, что было до неё, и что было после. Целый контекст так появляется. Другой человек на неё смотрит и видит, что на фотке просто человек стоит на фоне моря. Контекст должен быть. Тест-дизайн помогает врубиться в контекст. Тест-дизайн помогает тестировщику поднять свою глупу дупу и пойти спрашивать – вот я понял, что надо так и так, я правильно понял? Мне кажется, что надо вот так — я правильно понял? Надо ходить и спрашивать, а не просто получать документ и тестировать строго по ним, потому что это тоже очень глупо. Требования это не закон. Требования это документ, которые пишется группой людей, которые о чем-то уже договорились. Когда они о чем-то договорились, они понимают, о чем там написано. И даже когда не все четко, они все равно все хорошо понимают. Анализ, как возможность сфокусироваться на чем-то, помогает начать понимать то, что скрыто за какими-то, казалось бы, невнятными строками. А еще если читаешь о том, как требования создаются (у Вигерса), то понимаешь, что их создают вообще не глупые люди, хотя поначалу кажется иное. Но когда сам начинаешь писать требования, то очень быстро начинаешь понимать, что требования пишут нормальные, классные пацаны, им надо просто помочь, а не доказать, что они ошиблись и сделали плохую работу.

Представлення результату аналізу… скажімо, блокнот, таблиця, майнд-мап і так далі.

Абсолютно неважно. Карандаш и бумага. Notepad и курсор. И дальше как угодно.

Почему в твоей схеме эстимация времени на продумывание тест-кейсов и на их создание учитывается по-отдельности?

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

Але тест-кейс пишеться на основі документації якої на етапі естімації ще немає.

Соберись! Когда ничего нет для анализа, то и анализировать невозможно в принципе.

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

Пяти.

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

Получается, по условиям тест-дизайна можно ТЗ писать?

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

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

Дяка за увагу.

Если «это» распознается как «девица красная», то это можно отложить на потом (можно съесть, если что).

Если «это» мент чудище поганое, то надо бежать, даже если некуда.

Ну а ежели «это» — Lamborghini Gallardo, которое на тебя летит, повизгивая тормозами, то бежать уже некуда, постой и посмотри на эту красоту инженерного тестостерона.

Ну а ежели это девица красная в форме мента поганого за рулем Галлардо… Вот тут прям надо посмотреть и подумать: сразу бежать, или сперва надо доставать столовый прибор. Тут мозг не готов к реакции. Так и помереть легко.

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

В общем, мозг лучше знает, как спасаться. Эволюция же.

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

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

Простейший пример:

— …И ещё мы в джунглях ели шашлык из игуаны.

— А на что похоже мясо игуаны?

— Ну, оно чем-то похоже на мясо крокодила.

— А мясо крокодила на что похоже?

— Ну, чем-то на мясо страуса.

— А мясо страуса на что похоже?

— Ну, чем-то на мясо утки.

— Ага, а мясо утки похоже на мясо курицы, только более жесткое. Ок, я понял, мясо игуаны похоже на мясо курицы.

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

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

Автомобиль — это когда я быстро и уютно еду на работу. А еще там четыре колеса и мотор. И делает дыр-дыр.

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

Нет.

Не надо так.

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

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

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

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

Не надо так.