Простота и понятность тест-дизайна

Зачитано на «Uzhhorod developer meetup 13.0» в Ужгороде 20 сентября 2017.

Видео нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Посему:

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

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

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

Не надо так.

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

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

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

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

Демонстрация https://youtu.be/z573ocyltSk?t=16m11s — тестировщик часов со стрелками первым делом проверил бы, что часы в полной комплектации, что у них есть стрелки…

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

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

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

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

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

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

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

Не надо так.

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

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

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

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

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

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

  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 и курсор. И дальше как угодно.

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

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

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

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

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

Пяти.

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

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

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

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

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

15 ответов на “Простота и понятность тест-дизайна”

  1. «Тест-дизайн — это анализ, а затем осознание задач, которые программное обеспечение будет выполнять.»
    Ну вот и спрашивается, к чем тут тогда вообще слова тест и дизайн? Если сразу можно сказать «Анализ задач выполняемых ПО», например.
    Давайте назовем что-то тем чем оно не является чтобы потом делать пространные доклады пытаясь обьяснить что мы имели в виду вообще. (Я сейчас ни о ком-то конкретно)

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

  2. А мені дуже сподобалась Ваша стаття! Багато чого нового в ній для себе знайшла, а ще читається легко і місцями дуже смішна)
    З приводу того, що в сучасних реаліях для аналізу немає часу. Ну то це ж питання не до автора, правда? Тут написано як правильно, а те чи слідувати цьому прикладу чи робити «як всі» залежить лише від нас та нашого бажання, щось змінювати.

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

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

  4. Сперва мы что-то делаем с требованиями,
    потом делаем какой-то тест-дизайн,
    после этого появляются КАЕИЕ-ТО тест-кейсы
    и потом КАК-ТО тестируем руками.
    🙂

  5. Дякую дуже, працюю кілька місяців як trainee, але вже гостро відчувається брак підходу до тестування як процесу, розуміння суті, як це повинно робитися, чому потрібно проводити тестування. Бувають дні, коли виглядає на те, що мавпа теж може робити цю роботу, чи, скажімо, будь-яка людина з вулиці. Має ж бути якась різниця, окрім того що володієш певним набором термінів і знаєш 4-5 black-box технік тест дизайну(в плані знаєш, що вони є, а не повністю їх опанував)?
    Після кількох таких днів, дійшов до очевидного висновку, що тестування це інтелектуальна дісяльність і потребує відповідного, інтелектуального підходу.
    Дуже радий, що якраз в цей час прочитав статтю, яка пропонує цей підхід через «анализ и осознание». Не знаю чи відношуся до, тих людей в кого в кого тест-дизайн получається, але принаймні теcтуватиму грамотніше.
    P.S. Стосовно Agile. Мені здається, що якраз за умови цих, чуть не щоденних, делівері, і потрібно робити все правильно і грамотно.

  6. Блестящая статья. Я шёл к пониманию правильного определения тестдизайна последние лет 5 из 12 возможных. Реально сложно объяснить другому человеку не на пальцах что ты от него хочешь. В вашей статье особенно в первой части всё очень доходчиво и верно. Некоторые вещи взял себе на заметку для повышения эффективности описания этого самого тестдизайна для команды.
    Один вопрос. Из личного опыта между 1.Анализ и 2.Комбинаторика я рекомендую, даже скорее требую от тестировщика понимание функционала и отображения его в графической форме. Таким образом при ревью становиться понятно насколько тестировщик осознал функционал, где он что не заметил или подзабыл и что он собирается комбинировать на следующем этапе. Но. Любая креативная графическая работа довольно трудоёмка и требует дополнительных немалых затрат. Есть ли у вас опыт применения графики для тест дизайна с целью вышесказанного? В моём случае это тестирование embedded т.е. присутствует влияние ХВ ну и интерфейсы само собой.
    Спасибо.

    • Спасибо.
      Графика у меня примитивная, «карандаш и блокнот» с примитивной схемой (иногда рисуется «сам по себе» при обсуждениях), а в итоге всегда остается только список идей в Notepad — а именно он и нужен.

  7. Интересная идея в статье, но ее трудно воспринимать, бо довольно много воды. Немного перефразирую одно из заключительных предложений, чтобы передать это ощущение наполненности водой:
    «Сначала делаем анализ всего того, что можно проанализировать; сначала учитываем всё то, что можно учесть; и уже потом придумываем все, что можно придумать».
    Если высушить текст на 70-80%, то получится чудесная, понятная и здоровая идея о том, как ещё можно строить процесс тестирования. Спасибо!

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