Урок 3. Слайд 139-140

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

Доехал до dautov-bros (пост до сих пор не проплачен), рассказал шаги воспроизведения. Мастер секунд десять смотрел на меня, еще семь на велосипед, потом взял и дернул спицу. Спица силно отогнулась и дзенькнула.
Итого протяжка спиц мне выйдет в совсем чуть-чуть денег, два, а то и три дня без велосипеда, потому как в славном нашем городе велосипедистов развелось как собак, велосервисов же прибавилось незначительно, а своими руками - это не про меня и не про нас, да.
А еще - продолбаный выходной.
А также теперь перед каждой поездкой буду не только щупать покрышки на предмет давления, но и иногда дергать за спицы на предмет - не ослабли ли.

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

Поехали:

Слайд 139
Теперь о экзаменах.

Слайд 140
Это видео используется во многих различных курсах. Я буду говорить только о тех, о которых я слышал в Флоридском техническом и в ассоциации тестирования ПО. В рамках этих курсов мы публикуем инструкцию по обучению, содержащую все вопросы, которые могут быть на экзаменах. Мы также включили ссылки на документы в которых содержится описание эвристик, которые помогут ответить на экзамен в виде эссе и два видео, объясняющие, как мы классифицируем их.

(прим. переводчика, дальше рассказ о том, как проводить экзамен, дни, сроки и т.п.)

Слайд 141
Пустой.

На этом заканчивается 3 урок.

Урок 3. Слайд 138

Порекомендовали купить машинку для чистки цепи:

Увидев картинку, коллега тут же вспомнил текст песенки:

Фаллоимитатор 25 на 8
На пальчиковых батарейках
Он не предаст, и никогда не бросит
Его не заберут в армейку

Хм.
Поехали:

Слайд 138
Итак, позвольте подвести итог по оракулам.
Иногда программа ведет себя очевидно неверным способом. 
В таком случае, если мы можем описать поведение и распознать ошибку, мы можем зарепортить ее, не тратя много времени на раздумья.
Но в других ситуациях дефект сложно обнаружить, сложно распознать, объяснить. Если мы думаем об оракулах, как о надежных и твердых правилах, если мы вообще считаем оценку с помощью тестирования надежным и быстрым делом, то мы пропустим много серьезных проблем.
Оракулы тестирования дают нам больше свободы при ответах на нечеткие вопросы, больше возможности работать с подозрительными и нечеткими результатами, и позволяют создавать ситуации, которые могут быть потенциально проблематичными для кода.

Урок 3. Слайд 137

Поехали:

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

Картинка:

Урок 3. Слайд 136

Поехали:

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

Картинка:

Урок 3. Слайд 135

Поехали:

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

Картинка:

Урок 3. Слайд 134

Поехали:

Слайд 134
Следующие три слайда покажут, как широко используются модели для тестирования. например, с моделью состояний, если мы знаем, в каком состоянии находится программа, мы можемм узнать, что мы можем или не можем делать с ней дальше. На презентации тестирования основанного на моделях, James Tierney и Harry Robinson процесс исследования программ для создания моделей. Они нашли много несоответствий, которые делают не только модель гораздо более сложной для понимания, но и программу более сложной для использования. Если программа слишком сложна , чтоб упрощенно представить ее в виде модели, то иногда стоит исправить саму программу, вместо того, чтоб делать модель сложнее.

Содержимое слайда:

Урок 3. Слайд 132-133

Ну или как-то так:

Поехали:

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

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

Содержимое слайда:
Что делает модель моделью?

• Модель проще объекта за счет скрытия ряда аспектов
• С моделью можно работать делая предсказания и принимая решения на счет оригинала
• С моделью проще работать, чем с оригиналом

Урок 3. Слайд 130-131

Поехали:

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


Слайд 131
Мы можем создавать модели практически для всего. Представьте, что кто-то продает страховые полисы, используя программу для того, чтоб помочь себе лучше понимать нужды клиента и для выставления счетов. Такая программа реализует модель процесса продажи. Программа реализует фичи - те фичи, которые архитектор считал важными. Программа задает те вопросы для получения информации, которые архитектор считал важными и не задает другие, неважные вопросы.
И если ПО помогает продавцу  быстро получить нужную информацию и проводить правильную политику продаж, то модель хорош.
Если продавец работает в обход ПО, или чувствует, что ему задают неправильные вопросы, или в неправильном порядке, или неправильным способом, то модель плоха.

Содержимой слайда:
Несколько оракулов основаны на следующих моделях:

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

Урок 3. Слайд 129

По следам факапов, прекрасное:

Раньше у нас было правило: нельзя выкатываться в пятницу вечером. Теперь у нас новое правило: совсем нельзя.

 Поехали:

Слайд  129
Регрессионное тестирование это повторение. Мы запускали тест на предыдущей версии программы. Теперь мы запускаем его снова. Если программа прошла тест в прошлый раз, мы можем записать выход и сравнить старый с новым. Если в этот раз выход другой, то, возможно, произошла ошибка. Или старые выходные данные устарели.
Регрессионный оракул очень распространен. Некоторые используют его как базу для автоматизации тестирования. Но я продолжаю встречать людей, которые рассказывают мне о своих проектах, в которых 90% несоответствий между текущей и предыдущей версией приложения не являются багами. Некоторые рассказывают о том, что большая часть их времени работы с тестами состоит в том, что они меняют старые тесты в связи с изменениями в программе. Я лично видел подобные ситуации в больших компаниях. Да, выполнение всех этих тестов автоматизировано. Но ручной труд по обновлению всех этих тестов снова и снова огромен, бессмыслен и непродуктивен. Они находят мало багов и дают небольшую уверенность в том, что их нет.

Картинка:

Урок 3. Слайд 128

Вы любите котиков. А котики вас - нет.

Поехали:

Слайд 128
Ограничения тестирования иллюстрируют идею частичного оракула. Очень сложно сказать, является ли ответ правильным или ошибочным, но легко - правдоподобным или невозможным. Если программа говорит нам, что в американском почтовом коде 6 цифр или канадский состоит только из чисел, то неважно, какой ответ верный, так как именно  это информация - ошибочна. Эти типы тестов не подтверждают то, что программа работает. Они делают ошибки очевидными.

Урок 3. Слайд 127

Поехали:

Слайд 127
Я не буду обсуждать все детали этой таблицы в лекции. Их слишком много. Больше о них вы могли бы узнать самостоятельно. Но я дам пару комментариев.
Основная догадка Doug в том, что все оракулы являются эвристиками. Тестирование предоставляет неполные данные, которые пригодны для использования, а не точные и всегда правильные оценки.

Картинка:

Урок 3. Слайд 126

Поехали:

Слайд 126
Список эвристик консистентности Баха и Болтона - одна из структур, которую многие находят полезной. Другая структура, с которой работали более 14 лет, принадлежит Doug Hoffman, который опубликовал идею о том, как сравнивать и оценивать оракулы в виде таблицы.

Картинка:

Урок 3. Слайд 125

А помните, я скидывал истории и шутки планеристов?
Вот и водники подтянулись:
Раз:

Туристы-водники обсуждают:
— По какой реке пойдем?
— Да по Пьяни...
— Это понятно, что по пьяни, а по какой реке-то?
P.S.: Пьяна - pека в Hижегоpодской области.

Два:

 ... влетаем мы с ней в кусты, я ей кричу: "Юбку снимай!" , а она говорит: "Не могу, очко заклинило...

Три:

Зарубился сам - заруби товарища

Четыре:

 Цитата из отчёта: "... стоянка ниже порога сильно осложнена наличием крокодилов..."

Пять:

В альплагере сезон скидок. Скидывается каждый десятый»

 Спасибо Тане за подгон.

Поехали:

Слайд 125
Позвольте мне подвести итог по оракулам консистентности.
Мы исползуем их в трех общих случаях.
Когда мы находим баг, мы пытаемся выяснить. почему мы думаем, что это баг. Если ответ не очевиден, будет удобно спросить: "какой вид несогласованности мы наблюдаем?" А затем мы проводим исследования, чтоб подтвердить или опровергнуть предчувствия.
Когда мы репортим баг, иногда нам нужно объяснить, почему мы считаем, что это баг. Эвристики помогают структурировать наше объяснение: я считаю, что это баг, так как считаю, что люди будут ожидать другого поведения.
И наконец, мы используем эти эвристики как руководство по архитектуре тестов. Когда я знаю. что продукт должен делать, я проектирую тесты так, чтоб они проверяли, делает ли  продукт это.

Урок 3. Слайды 123-124

Я считаю, это очень правильное и ответственное отношение к детской психике:

Поехали:

Слайд 123
Давайте рассмотрим самый сложный для обсуждения предмет - согласованность с целями. иногда очевидно, что программа предполагает облегчение выполнения определенной задачи. Если это достаточно очевидно, то все, что вам нужно сделать, это сказать: "Я пытался сделать это".
Но в некоторых случаях программисты не понимают целей программ и то, какую пользу она должна приносить заказчикам. Эта проблема особенно часто встречается в компаниях, которые считают, что программисты это просто люди, которые превращают в код то, что написано в спецификациях. Такое отношение можно заметить во многих книгах и им заражены многие компании.
в таких случаях, программисты отвечают: "Но мы сделали все что должны были". Они могут быть правы, но программа будет все еще с ошибкой. Вам нужно спорить не с программистами, а с теми, кто сказал им так делать.

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

• Чего хотят люди достичь, используя эту программу?
• Какова природа задачи?
• Как выполняют ее люди в реальном мире?
• Как люди понимают, что они выполнили такую задачу?

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

Урок 3. Слайды 121-122

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

Пожалуйста. Я в ответ в ближайших выпусках тоже забацаю ссылки на настоящих, живых людей.


Поехали:

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

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

Урок 3. Слайды 120

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

Поехали:

Слайд 120
Бах и Болтон подходят к проблеме другим путем. Если программа показывает что-то, что не выглядит правильным, то на чем основывается это чувство? Чем аргументирует тестировщик, говоря, что программа работает некорректно? Они разработали список эвристик консистентности, описывающих ожидания людей.
Например, когда вы сравниваете программу со спецификацией или рекламой или мануалом, вы наблюдаете неконсистентность с тем, что компания заявила о программе. Когда вы сравниваете результаты теста с эталонной программой, вы наблюдаете неконсистентность со сравниваемым продуктом. Но есть ограничения по сравниваемости. Мы знаем, что два продукта можно сравнить в одном направлении - работа с числами и данными, но нельзя в другом - работа  с памятью.

Содержимое слайда:

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

Урок 3. Слайды 118-119

Поехали:

Слайд 118
Работая с паззлами, студенты часто говорят, что они могут решить, корректен ли размер, измеряя его.
Все не так просто. Единица измерения размера символа - точка. В дюйме 72 точки. Но символы, высота которых 10 точек намного короче своих двойников в других шрифтах.
Так что вместо того, чтоб попытаться точно измерить, что может быть очень сложно, мы полагаемся на простую эвристику, которая состоит в сравнении больших символов с меньшими и в сравнении с другой программой, которой мы больше доверяем.

Слайд 119
Вернемся к оригинальной идее о том, что тестирование это сравнение результата теста с ожидаемым.
Тут есть четыре проблемы:
Первая: наши ожидания могут быть ошибочными.Если программа работает не так, как описано в спецификации, то часто это бывает из за того, что ошибка в спецификации или она устарела. Если программа работает не так как эталонная, то может случиться, что в эталонной программе баг.

Вторая: даже если программа и оракул совпали, то тут все равно может быть баг. вспомните программу которая складывает 2 и 3 пять часов. Эталонная программа не даст всех возможных случаев. Нет полных спецификаций. Всегда есть аспект программы - в большинстве случаев достаточно важный - для которых тестировщик не знает, как определить, правильно или нет ведет себя программа.
Третья. У Open Office и WordPad был в сущности один и тот же баг со шрифтами, но я сказал, что это серьезный баг для Open Office и тривиальный для WordPad. Когда Джеймс учит этому, он говорит, что он, вероятно, не репортил бы формально этот баг, а просто рассказал о нем программистам. В моей практике все немного по другому. я хочу чтоб все особенности были записаны, поэтому я репорчу о каждом несоответствии между результатами и ожиданиями. Но если я считаю, что это неважно, то я так и говорю. Я не трачу много времени на это и я не давлю на людей, чтоб они это исправляли. Чтоб определить серьезность бага, мы должны полагаться на человеческие суждения. в этом оракулы редко помогают.
И наконец, есть проблема доверия. Когда вы говорите, что программа работает некорректно, почему вам кто-то должен верить. Может быть, никто не стал бы оспаривать вас, если бы вашим оракулом была спецификация или заслуживающая доверия эталонная программа. Но что, если программа плохо себя ведет способом, который не покрывается оракулом? Игнорировать? Репортить и надеяться, что вам не придется ее защищать? Мы репортим, но мы должны быть уверены, что читатель будет ясно понимать, почему мы считаем, что это проблема.

Урок 3. Слайды 115-117

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

Поехали:

Слайд 115
Чтоб оценить результат теста, полезным будет думать о рисках или о влиянии.
В случае WordPad'а небольшая ошибка в размере шрифта практически не несет риска. Никто не будет относиться к этой программе как к серьезному текстовому процессору и не будет работать в ней с разметкой текста.

Слайд 116
В отличие от него, для Word'а, профессиональной настольной программы, подобная ошибка будет серьезной проблемой. Эти программы спроектированы так, чтоб поощрять ожидания профессионального отношения к форматированию текста.

Слайд 117
Если вы один из моих студентов, то вы наверняка работали с примерами перед просмотром видео. В примерах спрашивается, корректно ли отображает Open Office шрифты.
Если мы хотим тщательно это протестировать то должны подумать о некоторых вещах, которые стоило проверить:
Мы должны проверить каждый шрифт, так как с некоторыми программа может работать отлично, но сломаться на других. Да, такое случалось. Мы можем винить в этом нестандартные коды для этих шрифтов, но если Word отображает их корректно, а Open Office нет, то это проблема.
Мы должны проверить каждый символ.
И мы должны проверить взаимодействие со всеми переменными, имеющими отношение к шрифтам.

Урок 3. Слайды 112-114

Ничего не происходит.

Поехали:

Слайд 112
Если смотреть более внимательно, то мы заметим, что WordPad и MS Word выглядят полностью аналогично в этом плане.

Слайд 113
Но у нас есть способ легко сделать наш тест более точным. Выделив текст, мы сможем увидеть конкретную ширину и высоту шрифта и визуально сравнить редакторы.
Это одна из важных тактик тест дизайна. Когда результаты требуют человеческой инспекции, найдите способ сделать эту инспекцию более точной, простой и очевидной. Сравнение с эталонной программой - слишком долгий путь.
В данном случае, как и в случае с Open Office, WordPad некорректно обрабатывает разницу в размерах шрифтов, в частности в ширине.

Слайд 114
Мы видим разницу. Word обрабатывает размеры корректно. Open Office и WordPad - нет. Должны ли мы беспокоиться об этой разнице? Нет системы, которая решит это за вас. Здесь необходимо человеческое суждение.

Урок 3. Слайды 110-111

Мда. На Урале лето бывает только за деньги и в другой стране.

Поехали:

Слайд 110
Давайте рассмотрим пример. Это скриншот текстового процессора Open Office.  Open Office - свободное ПО, но при этом прямой конкурент Microsoft Office. Люди используют обе эти программы для самых разных целей. Open Office спроектирован так, чтоб быть полностью совместимым с MS Office, так что людям удобно работать в каждой из программ, нужно лишь сохранить файлы и редактировать их иногда в Open Office иногда в MS Office.
Тест показывает, как Open Office отображает различные размеры шрифтов.
Если вы посмотрите внимательно, вы увидите, что программа отображает одинаково разные размеры шрифтов. Например шрифты 7.5 и 8.5 одного размера.
Люди, используют  Open Office для серьезной работы, включая разметку сложных документов. Если он не может отображать размеры шрифтов корректно, это серьезная проблема.

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