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

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

Предположим, что кто-то из 19-го века воображает Киев 21-го века. Вердикт: там все должны были бы летать! И это логично: ЕСЛИ в городе три миллиона человек, И каждому нужен личный транспорт, ТОГДА надо будет как-то впихнуть в город ещё и три миллиона коняжек — единственно доступный вид такси в ту эпоху. А коняжки с одной стороны жрут, а с другой… нет. И для грезящего киевлянина 19-го века было очевидно, что в Киеве 21-го века все будут летать, бо кто сможет ходить по делам по навозу в белых тапках?

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

И никто не летает.

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

И тут мы или зацикливаемся, или активно ждём новых, неведомых технологий.

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

Commited.tech – пример этой идеи. Я сразу не понял, что там и как, сайт выглядит как набор лекций-докладов-воркшопов, некоторые в свободном доступе, другие по подписке, чуть менее чем $5 в месяц.

Потом понял, что некоторые лекции — не лекции, а интервью с:

• Michael Bolton
• James Bach
• Rex Black
• James Whittaker, который автор книги “How Google Tests Software”
• Baruch Vinogradov (или Alexei Sadogursky, их уже их собственный ИИ не различит!)

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

Воркшопы заявлены разной длительности, некоторые по 2 часа, а которые и по 9 часов.

Похоже, что будущее за этим форматом, и к этому надо попривыкнуть. Education as a service, чо!

Как это читать? EaaS, что ли?!

Отдельно-подробно про то, как вся эта идея работает — https://commited.tech/how-it-works/

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

Соппсно, у нас в корпорации кто-то туда заплатился (не путать с «зааплаился») и по итогу получил доступ к скрытым ссылкам на все видео на ютюпе и, как партия велела, раздал их по внутренней связи всем принудительно интересующимся. Я интересунулся и сперва посмотрел, ап чём и как там Александра Ковалёва говорила.

Потом посмотрел на других.

И, что?

И это было не то.

Без реверберации зала (с залом) всё воспринимается иначе, нежели… воспринимается как обычный чёртов платный вебинар. А поэтому резко хочется чаптеризации (оглавления), точности и однозначности, чтобы пролистывать, и если этого нет… это надо учитывать. То есть, условно это конференция, а на деле — вебинары.

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

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

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

Ритм и темп речи тоже надо тренировать, выверять, экспериментировать — та еще морока.

И надо выстраивать все «шашлыком», ровно держать одну тему/идею, обходиться без ВНЕЗАПНЫХ роялей, последовательно нанизывая мясо на шампур. И давать прожевать, это можно делать по-разному, хотя бы через краткое резюме каждой главы.

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

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

Положительный пример: ну, например, почти все стандартные стратоплановские видео.

И важнецки важнейшего становится место, из которого докладчик вещает. Те, которые вещают откуда-то «с под крыши дома своего» в стандартные телефонные гарнитуры… вот сразу в сад.

Отрицательный пример: …ну, например, почти ВСЕ видео из уже неоднократно проведённых онлайновых конференций https://www.onlinetestconf.com/ — смотрим каноничный пример того, как несколько участников одного доклада звучат очень по-разному. Ухи, ухи!

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

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

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

И отдельный вопрос про доступ ко всем таким видео.

Ок, причинная конференция была с платным доступом, этим можно объяснить доступ к записям только для участников «только по ссылке». Формально да, но оно же через йо-хо-хо всё равно расползается достаточно свободно и бесконтрольно. В чём смысл их полупрятать?

Но и видео с бесплатной онлайнтестконфовской движухи тоже распространяются в виде «только по ссылке». В чём смысл их полупрятать?

— (голосом пионера) Приглашаем всех на «Анонс_final», ежегодную конференцию для анонимных анонсистов и финалистов и всех-всех-всех, которых интересует качественный процесс анонса и финализации! Спешите скорее, билеты уже в продаже!

— ПАГАДИТИ! Это же «Selenium Camp», ежегодная конференцию для разработчиков и QA и всех тех, кого интересует качественный процесс разработки и тестирования, которая успешно состоится 21-22 февраля 2020 в Киеве! Что за анонсисты? Какие финализаторы… Спешите скорее, билеты уже в продаже!

— (по телефону из Кишинёва) Да это файл с пресс-релизом так назвали, «Анонс_final». Никто не виноват. Спешите скорее, билеты уже в продаже!

В этом году:

• веб-автоматизация с или без WebDriver / Selenium;
• масштабирование автоматизации тестирования (облако, инструменты, experience reports);
• тестирование микросервисов (инфраструктура, контракты, подходы);
• инструменты тестирования (smart reporting, AI, smart tests execution);
• мобильное тестирование (практические аспекты);
• инфраструктура автоматизации тестирования (когда, где и как проводить тесты);
• машинное обучение и автоматизация тестирования (предложения, чат-боты, модели);
• метрика и мониторинг;
• управление тестовыми данными и генерация;
• качество кода в автоматизации тестирования (реальные истории);
• hardware / роботы / IoT (experience reports).

— ПАГАДИТИ! А где это пройдёт-то?

— Дык, в пресс-релизе не было написано…

— (по телефону из Кишинёва) Да там же, где и всегда: Киев, ул. Вадима Гетьмана, 6, Mercure Congress Hall.

Формат:

1. 2 дня практических докладов от отечественных и иностранных спикеров,
2. 3 параллельных потока,
3. BOF сессии, где освещаются самые актуальные давно известные темы и вопросы,
4. Виски-фуршет для неформального общения со всеми теми спикерами и участниками конференции, которые предпочитают коньяк,
5. 40% скидка на билет для тех, кто только переходит от ручного до автоматизированного тестирования (то есть, для начинающих.)

И да, нумерованный список был выбран нарочно 🙂

Среди спикеров обнаружены:

Simon Steward (Selenium Project, UK), Marcus R Merrell (Sauce Labs, USA), Elias Nogueira (Waes, Netherlands), Николай Алименков (XP Injection, Украина), Андрей Солнцев (Codeborne, Estonia), Иван Крутов (Aerokube, Россия), Сергей Пирогов (EPAM, Украина).

Одна из редких конференций, на которые надо поскорее поспешить, бо билеты уже в продаже! Do you feel it?!

Всем сидеть.

Сидеть!

А можно мы встанем, да?!

Нет! Все по местам!

Сидииииим…

Быстро всем встать, быстро всем к еде, быстро, быстро, быстро!

Были же времена, твой кролик пишет ковид!…

Ещё в тему

Так вот что такое «Регрессионное Тестирование»!

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

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

И да, это чёрно-белая картинка с телевизионными искажениями, бо вы офигели требовать цветной 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.

С 2012 года в Astound Commerce проходят регулярные образовательные Boot Camp для тестировщиков ПО. Рассмотрим как и почему это простое (как казалось поначалу) мероприятие превратилось в полноценный сервис, который помогает компании планомерно запускать новые проекты к определенной дате и с подготовленным к работе персоналом.

Видео нет.

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

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

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

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

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

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

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

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

Пяти.

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

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

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

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

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