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

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

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

Александр Александров сказок не читает, но при запуске видео с его докладами у меня всегда возникает то самое ощущение из навсегда ушедшего времени и волнение ожидания торта.

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

И там вообще не для джунов (там над вами хохмят).

Я перегнал доклад в полноценную текстовую версию, бо оно того варто. Видео — в конце.

Александр Александров

Экономика тестирования. Версия 1.0 (2018)

О чём будем говорить

• Общеизвестные (но не до конца) истины, или почему такая тема
• На что влияет экономика тестирования
• Что такое Версия 1.0 — Подробно
• Зачем нужна Версия 2.0 — Кратко

Почему такая тема

Эту тему я обдумывал на протяжении прошедшего года, и ещё не нашёл ответы на многие важные вопросы.

Например, для меня было неожиданностью узнать, что тезис о том, что «Исчерпывающее тестирование невозможно» — не для всех очевиден. Когда меня спросили «А почему?», я сослался на книгу Гленфорда Майерса «Надёжность программного обеспечения» (1979), где был приведен пример причины. Ответ был: «Ну, там же математически не доказано, что это так!..» Я вспомнил своё математическое образование, и указал на теорему Кантора, которая говорит о том, что множество натуральных чисел — счётное (то есть, это бесконечное множество,  элементы которого можно перенумеровать натуральными числами), а раз счётное, то оно не конечное. И если сделан калькулятор, который складывает натуральные числа, то НЕВОЗМОЖНО  провести его исчерпывающее тестирование — и так далее, и так далее.

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

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

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

Вроде бы абсолютная истина, но вопросы на эту тему появляются снова и снова на самых разных уровнях, и особенно на уровне топ-менеджмента:

• «Когда вы завершите тестирование?» (Когда? «Завершить» означает «Сделать всё». Когда можно сделать всё?).
• «Когда будут найдены ВСЕ дефекты?» (не то что половина, но даже 99% найденных дефектов, конечно же, никого не устроит)
• «А когда мы поставим заказчику ПО без дефектов?»
• Если дефект в продакшн — «Почему этот дефект не был найден?»
• «А почему ВСЕ дефекты, которые были обнаружены в продакшн, не были найдены до передачи в продакшн?»

Ну, а как на эти вопросы отвечать? Они все подразумевают исчерпывающее тестирование, которое мы не можем провести. Как выходить из положения?

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

• Если ущерб от незакрытого дефекта не превышает затрат на его исправление, то исправлять дефект не надо;
• Если ущерб от потенциального дефекта не превышает затрат на его поиск и исправление, то искать дефект не надо;
• Если суммарный ущерб от всех известных незакрытых дефектов не превышает выгоды от внедрения существующей версии системы, то ее надо внедрять (пусть даже и с известными незакрытыми дефектами).

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

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

• Все разработать — Можно
• Все протестировать — Нельзя

Разработчики могут сделать всё. Они могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» — например, два с половиной месяца. А почему? А потому, что там 18 фич, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты в этих 18-ти функциональностях? А сколько времени нужно тестировщику, чтобы написать для них ВСЕ тест-кейсы? А сколько времени нужно тестировщику, чтобы проверить ВСЮ функциональность? Никакого времени не хватит. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.

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

Пример: «Если потратить столько-то человеко-часов, получится приемлемое качество (не очень много дефектов останется). А если потратить меньше, то качество будет хуже (больше дефектов останется)». Это значит, что если мы потратим 5 000 ч/часов, то мы найдём 97% дефектов, а если мы потратим меньше, то мы найдём меньше дефектов. В такой формулировке мы можем говорить, как нам организовать тестирование — конечно, при определённой зрелости процессов разработки.

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

• Рецензирование требований
• Разработку тест-кейсов
• Ручной прогон тест-кейсов
• Автоматизацию тест-кейсов
• Анализ результатов и подготовку отчетности

Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги — мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации  и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Качество.

На что это влияет

Давайте рассмотрим анатомию процесса планирования.

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

Значит, необходимо пользоваться методами и моделями оценки трудозатрат на тестирование (я рассказывал об этом в 2011 году на SQA Days в Москве в докладе «Оценка трудозатрат на тестирование в проектах сопровождения» https://sqadays.com/ru/talk/12185). На основании полученных оценок планируются активности по тестированию. Необходимо также  отслеживать процесс тестирования, чтобы вовремя обнаружить отставание от плана и скорректировать его.

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

Мы можем недооценить трудозатраты на тестирование. Да, мы можем их недооценить с самого начала. Например, мы запросили 5 000 ч/часов, а их в проекте нет, и нам предлагают —  возьмите 3 500 ч/часов и как-то выкручивайтесь. Что ж, давайте крутиться.  

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

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

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

Подробно о Версии 1.0

Недооценка трудозатрат на тестирование часто приводит не к изменению  стратегии тестирования, а лишь к увеличению трудозатрат (дополнительному времени, персоналу и др.) и, как следствие, к увеличению сроков и/или стоимости проекта. Или мы недооценили трудозатраты, или нам их недооценили — что делать? «Дайте нам то, чего нам не хватает! Да, мы получили оценку в 3 500 ч/часов, но поскольку всё пошло не так, нам надо ещё. Нам надо больше людей и времени». Чем это плохо? Мы выходим за обещанные рамки, за сроки и за стоимость, а для заказчика ничего хуже этого не бывает, потому что ложка дорога к обеду. Конечно, если вы сделаете работу в срок, но плохо — это неприемлемо, но если вы сделаете хорошо, но на полгода позже — подумайте, что хуже. 

Рассмотрим решения реальных кейсов. Первый: «Главное — получить проект, а там посмотрим». Мы участвуем в тендере. Мы оценили трудозатраты на тестирование  в 500 ч/часов. Получилось дорого, поступает указание урезать трудозатраты, но разработчиков урезать нельзя! При таких трудозатратах проект продать нельзя, поэтому уменьшили тестирование до 300 ч/часов. Дальше — больше. «Непонятно, что в проекте делают тестировщики. Если они поставляют ПО с дефектами — от этого проекту только хуже. Если они тест-кейсы пишут — да кому эти тест-кейсы нужны?!» Мне приходилось эту фразу слышать от топ-менеджмента неоднократно.

Хорошо, мы согласились на 300 ч/часов. Как мы это сделаем за 300 ч/часов — мы не знаем. Но мы согласились с этой оценкой, пообещав тем самым  сделать все в полном объеме, со всеми артефактами. И вот эти часы исчерпались. Дальше что? Чудес не бывает: либо тестирование останавливается, что для проекта губительно с технической точки зрения, либо тестирование продолжается себе в убыток, и приходят грозные дяди из финансового подразделения и спрашивают, почему компания несёт убыток. А если к тому же компания торгуется на бирже, нам говорят «вы показываете низкую маржу, от нас побегут инвесторы». Результат: качество проекта непредсказуемо.

Второй кейс: «Любой каприз за ваши деньги». Сколько раз мы говорим это заказчику? Заказчик воспринимает это буквально, и начинает требовать любой каприз за свои деньги. Проект выполняется по модели Fixed Price, потому что все стремятся минимизировать затраты, начинаются изменения, повторное тестирование, мы получили свои 500 ч/часов, мы их честно израсходовали, потому что мы подписались под «ваши капризы» и всё, результат печальный. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

Третий кейс: «Тестирование от забора до обеда». Мы оценили трудозатраты  на тестирование в 500 ч/часов и получили согласие на эти трудозатраты. У нас есть команда, и мы начинаем тестировать, не заботясь о  приоритетах и целях, мы тестируем всё, что под руку попадается, потому что всё это заказчику нужно — он же сам нам об этом сказал. Мы заказчика очень любим и хотим сделать работу хорошо, но вот 500 ч/часов исчерпались. А что происходит с приложением, когда эти 500 ч/часов исчерпались? А бог его знает. Что-то протестировано, что-то нет, где-то написаны скрипты автоматизации, которые, правда, ничего не находят, но они же написаны. Регрессионное тестирование с помощью автоматизации — это такая фишка, которая с одной стороны, может ничего не дать, а с другой стороны, деньги жрёт так, что никакая расточительная длинноногая молодая так не сможет. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

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

Кратко о Версии 2.0

Поговорим о том, в чём разница между экономиками тестирования версии 1.0 и 2.0.

Версия 1.0 — это парадигма, в которой, к сожалению, мы с вами сегодня работаем. Нам дали сколько-то ресурсов, а теперь мы должны дать результат. Почему всё так устроено? А потому, что мы знаем, как эти ресурсы использовать. К примеру, мы знаем, что из 500 ч/часов 200 мы потратим на написание тест-кейсов, 100 на автоматическое тестирование и 200 на ручное — но это все в идеальном мире, если не будут радикальных изменений, все тестировщики будут прекрасно работать, и так далее. А если мы обосновываем оценку, показываем ее реалистичность и  эффективность, и будем оценивать все риски, то за эту оценку, уж извините, любой нормальный менеджер проектов открутит вам голову, ибо ему непонятно, почему тестировщики должны ошибаться — они же тестировщики! Это разработчики могут ошибаться, но чтобы тестировщики — никогда 🙂

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

А что такое Версия 2.0? Вот мы получили оценки. Эти оценки играют роль запасного парашюта. Это то, как мы будем работать, если у нас ничего более эффективного не получится. Но Версия 2.0 говорит нам о том, что надо использовать обоснованные трудозатраты эффективно, анализируя проектную ситуацию. Мы будем писать тест-кейсы? Если будем, то какие? Какие тестовые данные мы будем использовать и где мы будем их брать? От заказчика? Свои? Какие нам нужны тестировщики — мало сильных (но дорогих) или много слабых (зато недорогих)? Нам нужна стабильная команда для данного проекта или нет? Нужна нам автоматизация вообще, и если да, то какой инструмент, какое покрытие должно быть обеспечено?

Если для Версии 1.0 критерии — это возврат инвестиций в трудозатраты (ROI), то для Версии 2.0 критерий — это максимизация выгоды. И это разные вещи.

Заключение

Перечислим кратко основные тезисы.

• Исчерпывающее тестирование невозможно.
• Тестирование — это в том числе и экономическая деятельность.
• Версия 1.0, или Что надо сделать. Работаем в рамках плана и оценки, при нехватке ресурсов просим их добавить (экстенсивный подход)
• Версия 2.0, или Как надо сделать. Работаем в рамках плана и оценки максимально эффективно (интенсивный подход)

Благодарности

Наконец, позвольте поблагодарить:

• Организаторов конференции SQA Days # 24 за приглашение и возможность выступить.
• Моих коллег Андрея Ладутько, Александра Лукашева, Андрея Павлова, Алексея Федорова и Александра Куцана за детальное обсуждение тематики доклада и поддержку.
• Программный комитет конференции SQA Days # 23, благодаря усилиям которого на SQA Days # 24 появился этот доклад и, надеюсь, на SQA Days # 25 появится доклад «Экономика тестирования. Версия 2.0» и его широкое обсуждение.

Вопросы и ответы

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

Не стройте иллюзий о том, что вы перекладываете ответственность. Если вы согласились на 300 ч/часов вместо 500, то вы взяли на себя ответственность, что протестируете всё за 300 ч/часов. Придут и спросят: ну как же, вы же обещали? Вы же сказали, что за 300 ч/часов ВСЁ протестируете, и дефектов не будет. Но дефекты есть. Тогда за что вы зарплату получаете?

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

Сколько времени у вас занимает разработка оценки для проекта и кто это делает?

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

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

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

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

Стоит ли закладывать оценку трудозатрат на оценку трудозатрат в тестировании?

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

Опять же, все это зависит от сложности проекта. Здесь уместно такое сравнение — а как лучше целоваться? Голову в какую сторону наклонять? Глаза закрывать или нет? А критерий очень простой — когда люди целуются, главное — чтобы им обоим это нравилось.

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

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

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

Этот расчёт может быть очень полезным с точки зрения обоснования трудозатрат на тестирование. Когда вам заказчик говорит «А на что вам 500 ч/часов на тестирование?» можно ответить «ОК, давайте снизим до 300. В этой функциональности раз в месяц у вас будут возникать отказы, и центральная система банка будет простаивать шесть часов. Можно посчитать, сколько вам будет стоить этот простой?» Вот это и будет объём убытков. Вы нам не даёте деньги на 500 ч/часов — значит, у вас будут убытки, и вот столько они будут стоить (обычно, больше пресловутых 500 часов на тестирование).

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

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

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

Пример — штрафные санкции из  контракта Сбертеха: шесть серьезных дефектов в продакшн за полгода — штраф в размере стоимости контракта на разработку ПО. Шесть дефектов в огромной системе — это абсолютно реальная вещь. Есть резон брать на себя такие риски?

Если всё протестировать нельзя, то следует ли из этого, что у нас всегда непредсказуемое качество? И как можно его предсказать?

 Позволю себе сослаться на свой доклад на SQA Days в 2009-ом в Питере, где это обсуждалось https://www.slideshare.net/SQADays_2009_Piter/ss-1703956 (сохранились только слайды).

Предсказать можно. Да, есть методы количественного управления — «шесть сигм», статистическое управление и так далее. С вероятностью 99,97% можно оценить количество дефектов, которые у нас будут на выходе. Если есть более тридцати измерений, то статистика весьма достоверная, и можно предсказывать количество дефектов. Это требует определённой процессной культуры и определённой профессиональной инженерной культуры в тестировании, но до конкретного уровня и с конкретной точностью это оценивать можно. Тогда вы скажете, что если тестирование будет проводиться с такими-то параметрами, то у нас будут в продакшн (упростим для простоты) два серьезных дефекта на 10 000 строк кода. Мы можем соотнести затраты и выгоду, и защитить эту оценку.

А в ситуации «Дайте нам 500 или 5 000 ч/часов, только мы не знаем, что получится в результате», демонстрируется профессиональная  беспомощность, что не есть хорошо.

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

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

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

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

Оценивали ли вы затраты на обучение и на тестирование? Есть ли техники нахождения баланса, когда дешевле привлекать специалиста извне, или дешевле обучить своих сотрудников?

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

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

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

• Design tab of the toolbar ribbon.
• Page Setup > Slides sized for:  выбрать нужный формат.
• Orientation = Landscape

Установить картинку как шаблон слайдов

• View > Slide master
• Установить шаблоны для каждого типа слайдов по-отдельности — будет достаточно отредактировать слайды типа «Title» и «Title and Content».
• Close Master view.

Отредактировать картинку шаблона слайдов

• View > Slide master
• Можно сохранить уже установленную картинку: по нужному слайду правой кнопкой и Save Background
• Можно залить свою картинку: по нужному слайду правой кнопкой и Format Background > Fill > Insert from [File].
• Close Master view.

Видео нет.

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

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

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

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

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

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

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

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

Пяти.

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

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

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

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

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

• https://github.com/testitquickly/Software-Testing-Glossary

This is not an another ’Full glossary of terms used in Software Testing’, or ’Let’s bring together every known term in our industry, because everyone needs it. . . ’.

I just had to notice my own definition dictionary of some terms, so I did it.

English is not my native language, so you can ping me about ANY inaccuracy in this doc. Thank you in advance.

This doc will be updated, if needed.

Also you can:

1. ask me, if something wrong or unclear.
2. understand, that some terms require a detailed explanation, which is a subject of a whole lesson, apart from of a glossary.
3. use and share this doc in any way with no commercial purposes.

What is a test case grandpa.pdf

Скачать без активации и последствий.

Когда все тестировщики помрут, так оно и…

Вы покайтеся да раскайтеся заранее.

Сегодня имел удовольствие поматериццо объяснять начинающему тестировщику, что не существует «автоматизация тестирования» как некий отдельный объект или навык, который нужно учить отдельно от всего; что учить автоматизацию тестирования нужно в комплексе со всем остальным; что не надо «Сперва я выучу html, а затем CSS, потом JS и Selenium IDE», что надо ковырять всё одновременно.

А он не поверил.

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

1. Деловая

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

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

В остальном мне было тяжко. Смена часовых поясов — ой, полет Киев-Москва-Екатеринбург — ой, многочасовая работа над презентацией (мало писал, много думал) — ой, и большую часть времени я очень старался просто не заснуть, упился чаю, живот раздулся и не хотел сдуваться. И очень хотелось посмотреть Екатеринбург.

Огнетушитель был предоставлен устроителями конференции

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

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

Конечно, это нам не однополярные конференции вроде SQA Days (#17 пройдёт 29-30 мая 2015. Минск, Беларусь). На «дампе» тестирование заняло всего пять докладов. Мне показалось, что в тех краях народ не делает радикальных прорывов в отраслевых нишах, а просто старается прожить спокойно. Если да, то «битвы» устраивать не с кем, бо там требуется активное участие аудитории, а для этого аудитория нужна боевая.

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

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

Как-то так.

Напряженный момент в ходе доклада

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

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

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

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

* * *

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

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

Активно махая кадилом,

Спасал он заблудший болид.

И за тормозные колодки

Прочел семь мощнейших молитв.

За спойлер и стеклоподъемники,

Парктроник и коленвал

Два дня на коленях стоя,

Он землю лбом пробивал… ©

Доехал до аэропорта без аварий. Девять иконок же, ёпта…

PPS А Екатеринбург я так и не посмотрел. Гостиница была на пол-пути между городом и аэропортом, я прибыл туда поздно ночью, с утра конференция (тоже за чертой города), вечером срочно на самолет, поэтому у меня в активе первый город, который я так интенсивно почти посетил…

2. Задорная

Когда я говорил, что поеду «на дамп», у меня уточняли, не сыкотно ли мне ехать в Россию вообще, бо резня на восточных окраинах страны круто попортило отношение к РФ вообще и к их лидеру в частности. Ну а вдруг их лидер придёт на ихню конференцию? Что я, смогу смолчать? Но я как знал, что там всем вот это вот всё будет пофигу. Приехал, а там действительно всем вот это вот всё сильно пофигу. Ну, ок.

Но то Урал (мотоцикл, гитара, стиль жизни, все дела). Другое дело — в Москве.

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

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

А вот этап «планировать, ихде я буду спать в Москве» у меня прошел быстро. Слишком быстро.

Я ж в Москве был буквально проездом, и следующим морозным утром мне всего лишь нужно было встретиться с дедушкой русского тестирования в районе метро Алексеевская, поэтому я решил переночевать не в аэропорту (там есть гостиница, но там номер стоит $300, пригласите к себе тракториста), а в самом простом и дешевом месте, вроде хостела, близ места будущей явки. Хостел нашел заранее, описание его на его сайте было прекрасным, бронь заранее запросил, ответ получил, мол, окай, давай, брат, к нам.

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

Ну я и прибыл в хостел в 23:50, паспорт показал, откуда прибыл сказал, про бронь напомнил, и получил в ответ «А молдаван и хохлов мы не принимаем».

Хм…

Ну, про молдаван понятно, мы ж народ простой, мы тебе сразу скажем «Здарова!«, да я и сам себя не принял бы с самим собой у самого себя ночевать. Но смолчать перед равнодушным хозяином постоялого двора было как-то неудобно, поэтому я уточнил: «А хохлы вам чем не угодили?» А вот есть распоряжение милиции на этот счёт, пааанятна, да, только граждане России у нас могут переночевать. Поэтому давай досвидания.

Я и дал. Блеать. Пешочком. По громадному и шумному проспекту Мира. Интеллигентская мразь, не продумал вариант отказа в грёбанном хостеле, остался на улице, ночью, без плана «Б», без местного телефона, без интернета, с двумя тысячами рублёв (казалось бы, достаточно для…), без возможности to be agile in this fakin’ cynical world.

Ну и куда?

Ночью на проспекте Мира работает какой-то секс-шоп, в котором мне посоветовали валить в строго вправо, и на смартфоне карту показали, и объяснили всё как полагается, щастья им и продаж, пацаны, идите к ним скорее покупать всяки ихни шняжки. Я рысью прошёл в указанную сторону, и да, там обнаружилась отличная гостиница, и там был прекрасный холл и прелестный администратор, но номера у них только от $75, а у меня в кармане в рублях только $40… «Да блин!» ©

И пусть при себе есть достаточно украинской таньга, но их в Москве можно обменять на туземные бабки чуть менее, чем в двух местах во ВСЕМ ГОРОДЕ, факин фак, и только днём, а не в полночь!

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

In Soviet Russia не ты учишься жизни, а жизнь учит тебя, и учит быстро 🙁

Но епта, я тоже выходец из Soviet Russia, меня этой ‘hernia simptomatica’ не напугаешь. Хлебаю кофе и последовательно рассматриваю варианты дальнейшей жизни на протяжении минимум десяти часов. Надо безопасно поспать, поесть, встретить рассвет в добром здравии и не в опорном пункте милиции в качестве молдаванина. Есть варианты?

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

От досады сунул свою дебитку в ближайший банкомат, а там хз почему (вроде снимал же всю наличность перед отъездом…) оказалось в наличии 600 родных, красивых, качественных гривен. Ну и снял их я, и вуаля, у меня собралось наличных 3000 руб, ура, я внезапно перешел из низшей ценовой категории в среднюю, ура, я внезапно платежеспособен, я внезапно человек, меня внезапно ждет более «поблизости» гостиница, в которой можно за эти три тышши заночевать, и я скоренько понесся отдаваться в руки грамотного room-service, где граждане России принимают на постой неграждан России, где нет особых распоряжений милиции на этот счет, где есть горячая вода, телевизор, водка, валенки, балалайка…

Отоспался на отличненько. Ноги уже отваливались от ушей и дальше от всех этих ваших передислокаций собственных войск по столице… Перед сном отметил только то, что на надверных указателях насчет «Не входить» или «Сделайте уборку» написано ‘Please remove the room‘ 🙂

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

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

Не напоминает подготовку к запуску очередного проекта по строительству очередного интернет-магазина?

Утром в окне гостиничного номера ВНЕЗАПНО проявился следующий пейзажик:

Внезапный утренний вид из окна гостиницы на Ярославской улице

Но это уже день. Это уже не страшно. Уже можно и звонить, и ездить, и разговаривать, чем я и занялся.

А потом спокойно улетел.

Отличная конференция DUMP, всем рекомендую!

Или вот нам видео:

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

..

.

Видео других докладов на странице конференции.

* * *

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

Также есть полноценный текстовый вариант доклада (благодарим Елену Коваленко за “Час та натхнення”).