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

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — садись и слушай. Однажды, давным-давно…

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

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

Ну, и чо?

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

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

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

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

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

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

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

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

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

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

И нет, тут подразумевается не покрытие требований тест-кейсами (это всё делается позже, как правило, нами), а проверка требований разными аналитическими инструментами.

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

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

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

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

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким? 🙂

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

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

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

Важно уметь не подменять простую логику («я прочитал требования») с той самой аналитикой («я изучил требования»).

Совершенно ненужный эпилог

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

You know it’s sad but true.

Видео нет.

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

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

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

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

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

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

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

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

Пяти.

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

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

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

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

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

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

Согласно pairwise.org , есть множество софтинок для этого дела, и от Microsoft (их несколько, не только PICT), и от NASA (уже недоступна, в космос улетела), от Motorola, от IBM, и др.

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

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

Есть и онлайновые сервисы: hexawise, inductive, testcover — смотреть большой обзор, я ими не пользуюсь, предпочитаю консольную Allpairs (скачать бесплатно с джеймсобаховского сайта), бо привык к ней, и она не привязана к одной операционной системе.

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

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

Затем нужно уметь составлять таблицу данных, которая будет обработана Allpairs. В Excel (или в Calc) нужно сделать таблицу с перечислением сущностей и их параметров, затем экспортировать эту таблицу в текстовый файл с разделением столбцов через «TAB». Затем скормить этот текстовый файл Allpairs на обработку.

Непосредственно Allpairs привык использовать так: в каталоге с программой allpairs.exe создаю подкаталог (‘Test’), в который сохраняю текстовые файлы (с таблицами из Excel). В этом же подкаталоге появится и файл с результатами работы allpairs.exe.

Перехожу в этот подкаталог (‘Test’), и уже из него обращаюсь к allpairs.exe, которая находится на одном уровне выше.

Указываю в этом вызове файл, который надо обработать (назвал его input.txt) и приказываю вывести результат работы в файл, который на диске еще не существует (назвал его output.txt).

В Unix алгоритм работы (методология) тот же, но

1. перед вызовом программы обязательно нужно указать ‘perl’,
2. в самом названии программы указывать расширение ‘.exe’ уже нет необходимости,
3. слэши другие.

Нюансы под макой и убунтой (вот, казалось бы): таки надо внятно указать обращение к файлу allpairs.pl:

perl ../allpairs.pl input.txt > output.txt

— Ну это-то то понятно.

— Понятно-то понятно… Например, ты знаешь про самую крутую технику тест-дизайна — редбрик тестинг?

— Нет. Рассказывай.

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

— Ты сволочь.

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

Видео, как всегда, уже недоступно. Блэт.

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

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

Про сам митап: организовано мощно, всё учтено, перекусон вообще блеск!

Что заметил ВООБЩЕ: под meetup подразумевается встреча специалистов какой-то отрасли в неформальной обстановке для обсуждения какой-либо темы или ряда тем. Типа, джем для музыкантов. Но докладание превращает неформальность митапа в мини-конференцию, в которой есть много формальностей, которые всеми соблюдается, уж ничего не поделать. Этот митап тоже выглядит как мини-конференция, разве что действие происходит в офисе

В тот же вечер заглянул в новый львовский склад старых ружбаек и немецких касок — отличное место, там таки ждут вежливых гостей!

Львов, «Залiзна шапка»

PS Если нужон перевод заголовка, то: «Тест—дизайн в очумелых руках тестировщика».

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системы — Действие — иное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «Действие — Результат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the Cart — Proceed to Checkout — Checkout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

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

Что надо сделать

1. определить happy path — их может быть несколько.
2. определить другие сценарии и ветвления к ним.
3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.